最近中台的文章比较多，大多数谈历史，谈原因，之后就是谈技术了，但是中台真的实施起来，却躲不开下面的灵魂拷问。
问题一：
到底哪些应该作为中台，哪些不应该作为中台，是谁决定的？
如何决定的？
问题二：
每一个中台应该有哪些功能？
谁来定义？
和业务方如何切分？
怎样保证切分的合理？
每一个中台应该有多大？
按接口数？
代码行数？
什么时候决定再拆分？
谁决定？
问题三：
维护每一个中台的团队应该有多大？
10个人？
100人？
用户中心和商品中心应该哪个人多哪个人少？
什么时候能扩招？
谁来定？
绩效如何？
谁来定？
问题四：
和业务方的矛盾如何处理？
业务方是否一定要用中台？
谁有权要求业务方一定用中台？
看完了这些问题，你可能会觉得这些问题还不够深入灵魂，因为大部分人觉得只要有一个英明神武的CIO或者CTO，加上一个英明神武的中台技术委员会，就可以解决上面的问题了。
但是如果仔细想一下一个具体落地的场景，你就会发现，这事儿没这么简单。
例如：中台技术委员会定下来，要构建一个商品中心，组织应该有100人，服务提供50个接口，接口之外的功能都属于业务方定制化需求，所有业务方必须要用商品中心否则枪毙。
这个时候，我们就可以把问题问的更加深入灵魂一点。
问题一：
为啥商品中心是，xxx中心就不是，你怎么知道商品中心能够复用，xxx中心不能，谁长前后眼了吗？
问题二：
为啥是100人，不是50人，不是150人，你能精准评估人力吗？
业务方因为赚大钱狂招人，中台组跟的上吗？
问题三：
为啥xx接口和功能应该属于中台，yy接口和功能不应该属于中台，每个接口都要评估嘛？
评估的过来吗？
技术委员会了解技术细节吗？
为什么他们评估的就是对的？
会不会业务方不满当前接口和功能不使用？
问题四：
业务方一定要用中台服务吗？
不用能把他怎么样？
如果业务方说中台耽误他们赚钱了怎么办？
中台的老大有业务的老大强势吗？
业务方自己偷偷实现一个商品中心wrapper怎么办？
技术委员会天天review代码，看注册中心吗？
这个时候你会发现一个矛盾点，就是技术委员会如果足够高level，就往往无法深入细节，哪怕下面进行汇报也无从判断，如果足够细节，往往level就不太高，则无法控制业务方一定使用中台。
诸葛亮式（
计划经济式
）中台模式
那可不可能Level又高，又精通细节的呢？有，就是这种人太难找了，这就是诸葛亮啊。
三国演义说，诸葛亮身为丞相，Level既高，并且“早起晚睡，凡是二十杖以上的责罚，都亲自披阅”。
这就是中台构建的第一种思路：
诸葛亮式，也可以叫计划经济式
。
这种思路有以下的特点：
第一：
技术委员会具有绝对权威，其依靠的组织的组织目标是统一的，业务方向也相对单一。
就像诸葛亮之所以能够揽大权与一身，调动整个蜀国的力量，是有北伐这个统一的目标。所以这种模式比较适合业务方和中台方的组织目标统一，业务方向统一，归同一个技术委员会管理的情况，多见于BU级别的中台，或者整个公司当前的组织不大，业务相对单一的时候。
第二：
技术委员会对于细节把控要足够细，甚至亲自review接口和架构，单一业务的CTO或者首席架构师可担任。
就像诸葛亮连下层士兵打板子自己都要亲自过问。这种模式要求组织不大，CTO这个级别的人能够了解足够细节，才能够准确判断中台的界限，哪怕下面人来汇报打官司，也能够做到英明神武。但是这一点，就可以排除大部分超大型公司了。
第三：
技术委员会对于中台组织和业务方的绩效，招聘，奖惩都有权力，才能保证策略执行。
第四：
技术委员会要做好鞠躬尽瘁996的准备了。
权利和义务相对等，什么都归你定了，每天一万人来找你拍板。而且诸葛亮勤奋，但是不代表只要勤奋就能成为诸葛亮，鞠躬尽瘁的人好找，鞠躬尽瘁又是诸葛亮的就难了。
如果公司真的能够找到诸葛亮一样的人物，并且建立起来这样一套机制，那上面的问题倒是能够解决了。
第一：
哪些应该作为中台由CTO或者首席架构师拍板，当然会出错，可拆分再融合。
第二：
中台应该有哪些功能以及和业务方如何切分模式由技术委员会统一review敲定，因为中台方和业务方技术委员会都了解细节并且都有话语权，所以可保证合理性，也可随时调整
第三：
维护每一个中台的团队应该有多大由CTO或者首席架构师决定，如遇到业务方和中台方人员不匹配的情况，CTO或者首席架构师可决定给中台组招人，并制定绩效
第四：
技术委员会可决定业务方一定要用中台，因为了解足够细节，可通过review接口，工程，注册中心保证业务方一定用中台，因为可控制绩效，对于没有使用中台的业务方可进行惩罚。
这种计划经济式的中台构建模式，往往难度比较大，事实往往就像当年计划经济的委员会没办法知道某一条街道到底应该放五个煎饼摊，还是两个煎饼摊一样，这个委员会也绝没有英明神武到仅仅通过开会评估，就把上面的这些问题搞定。
市场经济的中台模式
那应该如何解决呢？当然是市场经济了。
第一：
技术委员会制定战略——要有共享能力，其他交给看不见的手（货币化，价格），其依靠的组织是集团化的，组织目标不完全一致（传媒，游戏，电商）
公司的战略先是要定一个基调——“公司应该有一个独立的组织提供公共能力”即可，就像当年邓爷爷定下一个基调——要改革，要开放，要市场是一样的。接下来的细节部分，例如两个煎饼摊还是五个煎饼摊，让市场去决定，邓爷爷他们可不管这个。让价格这只看不见的手起作用。
第二：
因为集团化组织和业务足够大和复杂，技术委员会不可能了解到细节，集团层面的CTO或者首席架构师不会再review接口和架构，更多承担的是组织，营收，成本的管理。
第三：
技术委员会对于集团的各个业务方无法决定绩效，招聘，奖惩。
营收好的业务方VP无论级别还是话语权很强
第四：
中台的实行也应该推行货币化，让价格以及价格背后的利益真正发挥作用。
你可能会问，如果采用市场经济，放任自由，不是乱了吗？其实改革开放之初，大家也是这样认为的，但事实不是。市场经济不代表没有规则，反而是规则更加清晰，规则更加能够反映各方的利益，市场经济定义的规则在流程而不在结果。
如果你直接定义结果，就像上面说的一样，商品中心100人，提供50个接口，接口之外的功能都属于业务方定制化需求，所有业务方必须要用商品中心否则枪毙。这样必定会带来人数或者过多，或者过少，业务方适配困难，中台的演进拖慢业务节奏让公司少赚几个亿。而且我们都很清楚，如果一个规则定义了，但是没有反映背后的真实利益，则必然会出现偏离计划，阳奉阴违的执行，例如中台的演进拖慢业务，业务方自己偷偷实现一个商品中心改个名字叫“商品中心wrapper”，中台委员会难道天天去看注册中心？还是去review代码？这其实和计划经济的时候，直接定义这个胡同五个卖油条的，另外一个胡同十个卖油条的一样，会导致要么油条不够吃，要么油条太多了，要么虽然表面上买油条，但是暗地里因为某一个胡同四川人多就偷偷卖酸辣粉了。
如果我们定义流程和规则，其实很多规则一旦货币化，就和服务外部客户一样的道理了。中台的组织和产品的立项，扩张，消亡，以及服务到什么程度的界限，全部如同对外服务客户一个思路，就能够自然的找到分界线，是人力，资源，功能对于整个公司最恰当的方式。
下面，我们来解析一下市场经济中台的思路。这种思路更加适合集团规模的企业。
在集团模式下打造中台，难度更大，要求：
第一：
中台要有共性，才能被多个业务方使用
第二：
中台要有成功案例，才能推广到多个业务方
第三：
中台的成立要像创业，有立项，扩张，缩减，解散，转岗的流程
第四：
中台的功能定义要产品化，和业务方的界限划分像商业化，能招多少人要货币化
第五：
鼓励业务方使用中台要满足业务方利益，允许业务方使用，抛弃，再使用中台，可帮助业务方建立自己的中台
说到中台的构建，不得不提一本书《阿里中台战略思想与架构实战》，在这里面解析了中台的构建过程，另外还有一篇文章《七问七答，亲历者讲阿里中台落地的实践》，我们会发现，这里面的模式还是符合上述特点的。
第一：淘宝，天猫，聚划算，1688都是电商业务
第二：淘宝2003年创立，天猫创立较晚，两者时间差比较大，淘宝的中台已经成为成功案例
第三：中台和外部商业化一样，一开始要战略合作，贴身服务。《七问七答，亲历者讲阿里中台落地的实践》文章中就提到“回想在交易中台落地的过程中，玄难亲自上阵review代码，范禹顶着业务压力让天猫研发团队全力配合，真的是福报，没有他们就没有现在的阿里中台”
第四：满足业务方利益，《阿里中台战略思想与架构实战》集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享事业部
而网易的中台模式就稍有不同，有以下的特点。
