近中台的文章比较多，大多数谈历史，谈原因，之后就是谈技术了，但是中台真的实施起来，却躲不开下面的灵魂拷问。
问题一：到底哪些应该作为中台，哪些不应该作为中台，是谁决定的？如何决定的？
问题二：每一个中台应该有哪些功能？谁来定义？和业务方如何切分？怎样保证切分的合理？每一个中台应该有多大？按接口数？代码行数？什么时候决定再拆分？谁决定？
问题三：维护每一个中台的团队应该有多大？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代码，范禹顶着业务压力让天猫研发团队全力配合，真的是福报，没有他们就没有现在的阿里中台”
第四：满足业务方利益，《阿里中台战略思想与架构实战》集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享事业部
而网易的中台模式就稍有不同，有以下的特点。
：不同的BU业务差别很大，很难共享
第二：即便有类似业务，考拉，严选成立相距一年，严选成立时，考拉中台尚未经历双十一洗礼，未成为成功案例
第三：杭州研究院的孵化机制，容易促成战略合作，贴身服务。
第四：满足业务方利益，成本和数据是大的利益。
下面我们来看市场经济模式下的几个中台要点。
要点一：中台的立项，扩张，消亡
共享能力组的成立是和创业公司是一样的，要在公司里面立项，写ppt，做规划以及将达到的效果，可由二级部门主管申请立项，委员会评估，一级部门主管审批，方才能立项。你可能会问，这不和计划经济委员会一样的嘛？还不是需要审批？其实不是，这里的委员会其实是风投的角色。
就像20年前任何一个投资人也不可能从20家电商公司里面挑出阿里来一样，共享能力组成立之初，谁也不能确定这个共享能力是公司一定需要的，或者一定能够让业务方满意的，但是没关系，投资人有资金池，可以给每个创业公司20万资金试试，然后让市场决定死活。共享能力大部门有人力资源池（记住，这个部门是战略成立的，因为已经有拳头产品而达到一定规模），在这个资源池里面，每年立几个项，每个项目一个到两个披萨的人数，还是会在公司的成本可承担范围之内的。接下来要看每个共享能力组的组长有没有本事让内部客户都用起来，让自己的组成长为100人，或者解散。这个计划经济直接成立一个中台组100个人是两个概念。
你可能会问，立项会不会乱立项。由于是类似风投的样子，立项可不是随便立的。如果是技术共享能力，则一定是业内主流技术，就像做Kubernetes创业的公司多，做swarm创业的公司就没有。如果是业务共享能力，则一定是拿下了内部标杆客户的，例如某拳头产品已经开始用某共享能力。你可能会问，还没立项，怎么能够让内部标杆先用着呢？当然立项申请者在公司内部的人脉和影响力当然至关重要了，如果他能够劝说内部标杆使用，则立项往往就不是问题。这和创业公司也是一样的，所谓天使轮，投资就是投人嘛。
共享能力组成立之后，接下来就是市场来说话了，业务方或者买你的人，结算人力成本，或者买你的技术平台，像云一样的结算，或者买你的SaaS服务，按调用数结算。这个团队需要能够自力更生，如果这个组服务的好，产品好，公司内部大家都用，你的收入就多，就能够多招人，团队规模就会越来越大，你们这个组升职加薪就不是问题，如果内部服务的特别特别好，还能对外输出呢，到时候或成立独立一级部门，或独立公司，或被收购，走上人生。当然如果这个组服务的不好，或者这项公共能力是个伪需求，那公司内部没有人用，你就没有收入，也就永远这么点人，可能过一段时间就解散去其他组了。
当然市场经济鼓励大家创业的前提是社会保障要好，公司内部也应该有这样的机制，创业不成功的组不会失业，只不过耽误一两年升职和高幅度加薪而已（高风险高收益嘛，你也可以永远选择跟着别人干），还是可以以平级去其他组的。
所以是市场决定剩下哪些共享能力组——也即中台，也决定了这个共享能力组到底应该有多少人。这个时候存在的共享能力组，才一定是公司切实需要的真实需求，人数也是几乎恰当好处的服务当前的内部客户。
要点二：与业务方界限
接下来，我们来看和业务方如何做功能切分，划清界限。怎么划清呢？怎么可能划清呢？
任何一个中台初创，对于内部大客户，一定是贴身服务，不分界限的，会深入腹地100M（这不可衡量，反正就是满意为止），会做超出共享能力的事情吗？当然会啊，你这个时候温饱问题还没解决啊，内部大客户让你做啥你不做？就像外部打标杆客户一样的，你一个案例没有，个客户你就和别人划清界限，这个你不做，那个我不做，人家肯定抛弃你啊。
但是贴身服务，并不代表中台负责人不具备产品思维，而是一定要具备产品思维的。也就是说，我虽然是抱内部大客户大腿，深入腹地100M，但是我心里要清楚，哪些是作为中台产品应该包含的，哪些是其他业务可以复用的，哪些是这个内部大客户定制化的，在实现的时候，要注意区分好，下次服务非标杆客户的时候，可以不用那么深入腹地，撤回来一段距离，撤回来多少呢？取决于这个中台的属性，可以撤回30M，形成一个有业务属性的SaaS中台，例如智能客服，用户中心等，也可以撤回60M，形成一个没有业务属性的技术平台，例如云，大数据，微服务平台等。
随着老业务的稳定，中台成功服务多个拳头业务，话语权也会越来越强，对于公司新孵化的业务，可以要求按照标准接口使用中台。一方面，中台组可以理直气壮的说，人家某某业务都是这样用的，你也应该这样用，这就是标杆的示范作用。外部打标杆客户，不也是这个效果么？另一方面，公司新孵化的业务正在要求快速上线，有一个现有的中台，已经很开心了，还要啥定制化呀。
所以，中台和业务直接的界限，不是计划委员会画出来的，而是先深入腹地，再撤回来，终找到一个双方平衡的界限的。这个界限，一定是双方都感觉合适的。
要点三：如何让业务方使用中台
接下来，我们再来看，如何让业务方使用中台？是否允许业务方不使用中台？靠行政命令吗？当然不行，要靠利益，也即给业务方带来实实在在的好处。
中台应该分BU级别的中台和公司级别的中台，不需要强求整个公司一定非得用公司级别的中台。你可能会说，这样不就相当于没有中台吗？能不能强制呢？肯定行不通的。
我们将公司的业务分为两种情况，是快速发展期，这种业务是公司战略投入，赔钱都愿意做，就是要快速抢占市场的，第二是稳定期，这种业务需要给公司带来正向的现金流，保证公司的长期运行。
一般来说，对于快速发展期的业务，要允许他们自建BU级别中台，因为实话实说，拦也拦不住。你要知道，公司对于战略投入级别的业务的人员配比和对于中台部门的人员配比完全不成比例，人家可以哐哐招人，团队翻倍增长，而中台部门的人只能缓慢增长，而且公司对于战略级别业务成本容忍度高，也即不怕花钱，你倒是想快速迭代，赶上人家业务发展，你人也不够啊。
可不可以要求支撑战略级别的业务的中台组以同样比例招人呢？也不现实，因为每个业务方都知道，人还是放在自己手里更加灵活。
可不可以强制命令必须使用中台部门的中台呢？也不现实，人家战略级别部门的老大什么话语权，中台部门的老大什么话语权，人家只要说一句，万一后面支撑跟不上，公司少赚多少亿谁负责？就没人拦得住。
所以，要允许快速发展期的BU自建中台，中台部门可以用专家咨询，人力外包，产品私有化部署的方式，帮助他们自建中台，别忘了战略级别BU将来就是拳头部门，也是具有示范效应的，这里积累下的自建中台的经验和能力，也是可以沉淀下来，服务其他内部客户的。
当业务稳定下来，在市场上跑马圈地结束了，进入稳定期，公司就开始有正现金流的需求了，这个时候业务方开始有成本压力的时候，中台的价值就体现出来了，业务方就开始考虑，自己要不要单独养一批人做这个，还是直接用中台能力就可以了，这个时候，业务方可能还会返回来使用公司级别的中台。
所以，劝说业务使用中台的个就是降低成本，这对刚开始孵化的业务线比较有吸引力，对于步入稳定期的业务线也有很大作用。
另外一个在中台发展过程中，对拳头产品进行贴身服务带来第二个利益就是数据，拳头产品会积累下来特别多好的数据，并可以根据这些数据推出一些服务，让其他业务方难以拒绝。比如A拳头业务积累下10亿用户的数据，全部打好标签，B拳头业务积累了几百PB的邮件从而有了反垃圾算法，C拳头业务在挖掘了几十年的新闻数据后从而有了推荐算法，现在都积累到了中台里面，一个新建的业务，你不想上来就用上这些吗？
要点四：中台部门的业绩制定
后，对于中台组的KPI制定，可以有以下几个维度。
如果是业务相关的中台，可以参考业务指标，例如用户留存，用户点击等。
如果是技术平台的共享能力，可以使用SLA进行衡量。
如果是SaaS类的服务，可以通过调用次数来制定定价模型。
另外，由于公司内部无法做到完全竞争，例如内部业务可自研，可用中台，但是不可用外部的服务，会存在不得不用的情况，要引入满意度评分。
只有市场经济的方式，才能使得每个部门在保证整个公司利益大化的情况下，保持恰好的人员规模和中台复杂度，使得公司快速创新。
如果你不是用市场经济的方式解决这些问题，那你能分享一下你是如何解决这些问题的嘛？
后推荐几篇文章
再推荐几本书
《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》
《中台战略：中台建设与数字商业》
《企业级业务架构设计：方法论与实践》
