最近集中半年集中处理了不少的中台案例， Legendshop中台得也该总结一下自己的'中台‘心得。
在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。
在有些人眼里：中台应该是组织的事情，在释放潜能：类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。
这些理解都对，但也都有不够准确或不够完整的部分。中台，作为一个还在被定义当中的概念，正处在一个大家都有感觉，但又难以被定义的状态。而且可预见的是，这种相对模糊的状态可能还要维持相当长的一段时间。
与此同时，在查阅了大量资料、并与京东等大厂的中台相关负责人沟通后，我们发现，目前行业内对于中台讨论的视角还是多偏于战略或组织架构层面，而中台更多是因为公司业务在发展到某一阶段时，遇到瓶颈与障碍后，为解决实际问题而提出的解决方案。
中台不是什么新概念，早在2015年阿里就已经提出了建设中台的概念了， 所以大家可以出门左转搜索一下中台的概念。经过阿里的建中台，拆中台（不知道的也可以搜索一下阿里“拆中台”的故事）的一轮骚操作以后是否中台就变得无用了呢？ 要是中台无用那么为什么反而过去半年的客户需要中台的量增加呢？ 所以个人的看法是：当一个事物走下神坛的那一刻就代表她开始走向实用的应用场景了。中台不是消亡，而是变得实在落地到具体应用了。所以我不妨也谈论一下什么企业适合建中台， 中台分技术中台， 业务中台，数据中台，我们怎么具体应用呢？
1.业务中台更多偏向业务流程管理，将业务流程中共性的服务抽象出来，形成通用的服务能力。比如电商平台C2C、B2C、C2B、B2B四种模式，其中订单、交易、商品管理等模块都是有共性的。
2. 业务中台是抽象业务流程的共性形成通用业务服务能力，而数据中台则是抽象数据能力的共性形成通用数据服务能力。
3. 数据中台与业务中台的联系：如果同时拥有业务中台和数据中台，则数据中台与业务中台是相辅相成的。业务中台中沉淀的业务数据进入到数据中台进行体系化的加工，再以服务化的方式支撑业务中台上的应用，而这些应用产生的新数据又流转到数据中台，形成循环不息的数据闭环。
企业前台、后台存在需求矛盾时，为了满足前台的快速迭代需求和后台的稳定性需求，中台概念应运而生，核心是当前台需求来临时，中台能快速的进行响应，从而提升研发效率，降低创新成本，提高工作效率。
首先，中台主动收集前台业务信息和数据，意味着不需要前台有意识去存数据；减轻一线人员的工作量的同时，还能收集到更多数据。其次，综合分析前端各业务数据，并与后台资源数据匹配，得出合理的处理方案，这是最重要的一步。最后，以服务的形式将业务方案结果推给前台。
比如，通过一线销售的销售预测数据，可以做下单备货准备。
“后端前移，支持一线”始终是中台的建设宗旨。对于某些行业，如电商、零售、电信运营商等，中台其实就是其生产系统，离开中台就无法运作。而对于另一些行业，如IT行业、制造业等，中台只是辅助决策系统，重要的决策和发布指令，还是需要人来做。还有一些行业或形态，中台没什么用，如研发、小微企业。
这两个维度基本是知和行的关系，信息维度中台的道理很容易讲清楚；而业务维度的落实和实施则复杂得多。这就像是培训：听课时热血沸腾，出门恢复原状。
中台的出现，本身就是为了通过一次建设，满足不同业务线的需求，减少公司内不同业务线的重复建设。比如阿里是电商业务，不同的业务线如天猫、淘宝、菜鸟、飞猪等等，其实都是在不同的平台去售卖不同定位、类型的商品。所以对于阿里的中台建设来说，一开始核心要建设的就是商品中心、交易中心、营销中心等等。
所以如果公司只有一个核心业务线，中台的建设就是不需要的。只是在开发过程中，可以相对考虑到未来的发展可能，把整体做的比较有扩展性一些。这样万一后续公司出现了多业务线，则可以在原先的核心业务基础上，将其发展为中台。
不过注意一点，为什么说是相对扩展性，因为互联网整体业务变化和技术变化都比较快，如果一开始为了后续可能出现的中台情况，考虑太过完善，有可能会拖慢一开始核心业务的发展。所以这其中的度需要把控。
假如你们公司有多个业务线，接下来需考虑。不同业务线有没有共通性。
腾讯是没有业务中台的， 为什么？
当我们被问到：
· 阿里是做什么的：卖东西的；
· 苹果公司是做什么的：卖手机的；
· 可口可乐是做什么的：卖饮料的；
· 腾讯是做什么的：做游戏的？做通信的？做娱乐的？做投资的？
这里商业模式的定义是狭义的：通过什么产品服务赚到钱。
我们看到阿里、苹果、可口可乐虽然都是多元经营的集团公司，但是核心模式其实是单一的。而腾讯此时看起来就有些特殊了，他的商业模式之间差距有点儿大是不是？
要是你的公司先腾讯一样大，业务毫无联系，那么也不要妄想做一个中台能解决所有问题。
对于一般来说对于一个公司的多个业务线或产品，利用公司的核心优势，其产品只是面向用户或者场景的不同，这种公司是比较适合做中台的。
例如我们过往做过的案例里面的南京钢铁集团：他们需要售卖钢铁， 需要整合上游供应商，需要有招投标，需要使用内部的ERP，内部员工需要生活也需要交易， 这么一些列的交易场景交织组合在一起，同事他们已经在应用这各个专业化领域的里面的数字化工具的时候，我们需要一个中台来整合调整以及打通各个信息孤岛。
前面两个问题回答后，如果觉得仿佛自己公司真的有多业务线，而且业务线真的有很多的共通性。那么可以再考虑一个问题，来验证中台是不是真的有用。做了中台后，真的可以提高我们公司的效率吗？
每一个事情，必须在做之前就要考虑到目标以及结果。回到做中台的初衷，是为了减少重复建设的能力，所以建设初期，我定的中台建设的目标是：业务接入的速度以及效率。所以在做之前，自己可以预想评估下，一些中台中心化建设所花费的成本，以及建设好后业务接入的成本。
有可能业务变化十分快，中台一边建设，业务一边变化，而且接入时候双方也很痛苦。所以一方面要问自己这个问题，同时要结合公司情况，来看某些东西的建设到什么程度对于效率的提升更加有帮助。
比如一般对于交易中心来说，如订单的很多字段其实对于很多平台都是大同小异的，那这部分相对标准化，而且交易这部分比较重对稳定性要求很高，需要不断维护增强稳定性，每个业务线自己开发，也比较不现实，所以这个部分的投入产出比衡量一下，还是比较有意义的。
但是对于如营销相关，可能需要判断，哪些是通用的营销能力，比如券、折扣。这种可以沉淀相关基础的。再丰富的玩法，每个业务不同，就不适合在中台做了。
前面三个问题比较属于产品问题，产品问题都考虑清楚了。需要问最后一个客观因素，就是组织情况，你们公司是不是自上而下的要求其余业务线必须接入中台。
因为在中台建设的初期，比如我们公司是按照滚轮子的方式建设的，就是边满足业务需求，边建设中台。那对于业务来说，肯定有一个等待的时间。如果没有强力要求进行中台接入，很多业务可能都会觉得很麻烦，然后自己做了。长期下去，中台就会变成一个空壳。然后就会陷入恶性循环，别人总觉得你很弱，接入很慢，不愿意接入。
部分组织在数据治理的过程中速度过慢，成效不好，其中一个很重要的原因是权责、部门配合等方面存在问题。 很多情况下，生产数据、使用数据、分析数据的工作人员分布在不同的职能线与部门，角色不同，立场也不同，这些客观存在的影响因素都会影响整个数据治理的最终结果。
比如在我们公司首先从组织结构上，划分了中台以及各个前台，每个前台产品、中台分别作为一个项目，当一个新业务发展时候，由于本身后端开发资源进展，所以必须寻求中台的帮助，让一个新业务可以快速发展起来。
中台是企业组织和业务重构的关键发展路径，其建设是由企业发展过程决定的，而不是由IT发展决定的。互联网巨头搞中台，那是因为它们业务确实需要。至于一般互联网公司，特别是创业公司，对行业和企业业务的理解，大部分到不了那个深度；中台充其量就是一个销售话术或者实施某一类项目。
讲这么多前提条件是叫企业不要去做中台了吗？当然不是， 我们可是做中台的技术公司啊，我这么说叫我们过往的大客户情何以堪？可是我做产品的我，在给企业做这么多数字化规划以后，更是觉得技术本身是为业务服务，推动业务发展的，当然技术也是可以改变世界的。 但是技术可以有多样， 方案可以有多种， 我们不用中台，我们用SAAS， 我们用SCRM，我们用ERP， 我们用社交电商…各种解决方案也是能够帮我们的企业创造出一样多的价值。每个技术模式有他的适用场景。
好吧废话不多说，我还是讲讲怎样建设中台吧：
中台的建设方式市面上主要有两种：
A. 一步建设到位：一步到位，用一段时间建设中台（比如1年、2年），建设好后再提供给多业务使用。
B. 边发展边建设：发展核心业务的同时，考虑多方需求及需求的通用性，边发展边建设中台，形成一次建设，多次使用。
在许多真实的案例中，采用一步建设到位的公司大部分中台化都失败了。为什么呢，其实可以想到，中台的建设主要是为了减少业务重复开发的成本，如果一定要等中台做好了，再进行接入，有可能业务在这个过程中有的已经自己先开发了，重新接入反而是增加了其成本，变得为了建设中台而中台化。
一般采取一步建设到位的大部分是一些传统企业，将中台外包出去，因为必须明确项目范围，所以会按照项目制的方式进行建设。这种会比较难以成功。有客户一上来就跟我说：你们有什么方案先给我， 你们在最短时间内做做到什么， 全都给我上了。 此时我的额头是有多少条黑线， 我明白集中开发是可以省钱，也可以说能直接看见效果。 可是建设中台是分布建设的能够贴合实际。作为乙方当然是希望系统可以一直维护，而不是做出来一个大而全但是企业用不上的中台。
而边发展边建设这个方式，一般适合于公司有一个核心业务，核心业务发展还不错，在核心业务的发展过程中也沉淀了比较多的能力。此时想要进行新业务发展时候，可以在原先核心业务的基础上，将其中台化，然后由其余产品接入。
同时需要对优先级进行判断，比如电商相关的产品，商品、订单均是必须的，则这部分必须要一起上线才可以接入。营销相关可以先有商业化后，再进行建设，一开始不用着急做营销相关产品。
中台建设的目标：减少重复开发，降低业务侧的开发成本。衡量的结果需要按照不同阶段进行区分：
l 初期：业务接入的速度以及效率
l 成熟稳定期：提高稳定性和服务能力，根据需求进行相关扩展
雷达型阶段模型中，BAPO评估模型覆盖了软件工程的业务支撑、架构支撑、软件过程、组织保障四个维度，每个维度有五个级别，可以全面、科学地对产品线的研发能力进行指导和评估，同时CMMI模型主要用于对软件过程改善和软件过程评估，对软件开发流程中的需求开发阶段有较好的参考价值。
在企业中台建设中，我们认为存在四个相互依赖的中台开发问题，即：业务支撑：如何从中台产品中获利；架构支撑：构建中台的技术手段；软件过程：中台开发中的流程、角色、职责和关系；组织保障：角色和职责到组织结构的实际映射。这四个问题互相关联，一个维度的变化会引起其他维度的变化。业务支撑是最有影响力的因素，必须优先考虑；架构支撑反映中台软件结构和规则中的业务问题；软件过程构建由架构支撑确定的中台产品；最后，通过组织保障执行软件过程。
l 技术向来不应该是脱离业务而单独去建设的，中台的建设也不能蒙头只做能力，更多的在于这个能力对于业务的价值。所以做之前还是需要先考虑还业务的价值，再进行动手。避免做到一半，花费了十分多的精力，还发现其用不起来。
l 做产品也是做服务：中台是为了满足企业内部的需要才产生的，所以需要把公司内的不同项目组都当成自己的客户，当产品稳定后需要考虑好怎么更好的服务好不同的业务线，提升对接效率。
· 业务中台与数据中台相互促进，为企业业务的发展、管理者更好的决策提供支持。其中，业务中台的存在是为了围绕公司业务运营进行服务，将获取更多维度数据传递给数据中台，由数据中台挖掘新的价值反馈给业务中台，以优化业务运营。
技术中台说白了就是强调资源整合、能力沉淀的平台体系，当技术前台实现业务功能时，为他们提供底层的技术、数据等资源和能力的支持。