虽然中台在这几年变得非常的火，但是我理解这并不是一个全新的概念，我在华三工作的时候，公司的口号就是大平台，小产品。只是场景不同，交换机和路由是的协议都是标准的，所以华三的comware平台在设计之初就是平台化的。但是互联网行业是一个快速变化的行业，一个产品快速推出，快速迭代，随着用户和需求的增长系统不断的演进，最终导致多个产品之间有了很多重复开发的功能，然后回过头来进行平台化改造的过程。但是中台比一个产品的平台更难，因为中台做的是一个企业级的架构。
当然还有另外一种中台，中台是前台与后台之间添加的⼀组“变速齿轮”，它为前台而生，易于前台使用。
中台到底是什么根本不重要，持续提高企业对于用户的响应速度才是最重要的。
1 中台介绍
数据孤岛，烟囱式的架构，造成大量的重复建设和资源浪费。最自然的想法就是将重复的组织和系统进行整合，将各个前台系统中的公共部分进行平台化改造，作为公共的平台对其他应用提供服务。
- 中台的目标：减少沟通成本， 提升协作效率。
- 中台的实现手段：指定标准和规范
- 原则：集中管控，分布式执行。
中台的定位：定义好边界，我要什么，不要什么，不是什么都做。
- 业务中台：就是在产生数据， 狭义层面，业务中台需要具体承载支撑业务开展的必要业务元素，封装着为了保障业务可以顺利开展需要解决的必要问题的解决方案。
- 数据中台：做数据的二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能。”
- 技术中台：一些中间件的集合，可以说是中间件的平台。助力前台和业务中台、数据中台的快速建设。
为了快速响应用户的需求，借助平台化的力量可以事半功倍。 平台化思想恰好鼓励企业不断抽象沉淀自己核心的底层能力，通过平台化包装，得以更好地赋能前台业务，用底层的确定性来帮助企业应对前台业务以及最终用户需求的不确定性。
中台关注为前台业务赋能，真正为前台而生。
随着业务的不断发展，这种“前台 + 后台”的齿轮速率“匹配失衡”的问题就逐步显现出来了。中台就像是在前台与后台之间添加的⼀组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁和润滑剂。它为前台而生，易于前台使用，将后台资源顺滑地通过前台导流向用户，支撑企业更好地响应用户。企业在平台化的过程中，为了能不断地给前台业务提供更好的服务，来支撑企业对于用户的持续响应，增加企业的用户响应力，企业需要构建自己的中台。
- 企业级：中台建设的事情并不是一个技术问题，而是一个要上升到企业架构的问题。做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景。
- 能力：定义了中台主要承载的对象
- 复用：定义了中台的核心价值，也承载了上面讲到的从平台化到中台化的演进过程。传统的平台化对于“可复用性”和“易复用性”并没有给予足够的关注，更多关注的是如何消除掉重复的能力建设，既所谓的“去重”。
- 平台：定义了中台的主要形式。区别于传统应用系统拼凑的方式，中台通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务，来满足对于业务的快速响应和复用的需求。
2 如何实现
中台本质上也还是个架构问题，只不过不再是我们经常看到的技术架构，而是上升一个层次，是个企业架构的问题。
如果正在计划或者已经开始建设中台，下面的四个问题，思考一下，是否已经想清楚了呢？能不能用一页 A4 纸把这些问题的结论写下来，然后给其他人看看，理解又是否一致呢？
2.1 中台建设的愿景是什么？
遇事不决看愿景
中台应该什么样？中台应该怎么建？最重要的是：
- 你建中台是为了解决什么问题呢？
- 对于企业和业务又有什么价值？
消除烟囱，移除孤岛等“大话”。其实是还没有搞清楚中台建设的愿景。
中台就像一个产品一样，需要一个明确的愿景，要让所有人能够清晰明确地知道，中台建设对于企业对于业务的价值，从而可以一起始终向着同一个方向持续前进。如果愿景缺失，那我们就会很容易在中台建设过程中迷失自己的方向，失去定力。
愿景帮助我们了解自己中台建设的目标，帮助我们判断哪些事情是符合中台建设愿景的，作为中台团队我们需要去考虑。在这之外，更重要的是帮我们判断哪些事情不是中台要去做的，为中台做减法，这点在中台的建设过程中其实更加重要。
尤其是在中台建设初期，项目往往还处于试点的阶段，可支配的人员和资源不会特别多，如果没有自己的方向，就会陷入到上面小王所处的境地，把中台变成一个内部共享的外包团队。
这个愿景是需要所有的角色，上到企业管理层，下到每一位中台的相关人员都要明确并达成一致的。
2.2 中台的用户和客户是谁？
这中台的建设通常都会伴随企业内的组织重构以及利益和职责的再分配。如果没有搞清楚中台建设的各个干系方关系，必然在中台的建设过程中就会四面碰壁，陷入“干系人旋涡”之中，面临多方面的阻力，陷入一个非常被动的局面。
所以在中台建设之前，我们最好先搞清楚中台如果作为一款产品，它的用户是谁？客户又是谁？用户和客户是一个群体么？除了用户和客户还有哪些干系方？他们对于中台都有什么期望，这些期望又是否一致呢？
需要找到企业管理层与业务线关注点的结合点，也就是长期战略价值和短期战术价值的结合点。在保持自己方向的前提下，找到各方利益的结合点，是一件非常困难且有必要的事情。否则，在建设过程中就会受到各方的阻力，产生摩擦，导致中台很难推进落地。
中台也不应该只是极力去满足各方的诉求，中台团队毕竟不是业务的外包团队。中台需要有自己的思想和规划，要能做到听得进别人的话，但是还要明确自己的目标，走自己的路。而自己的目标，就是来源于上面提到的中台建设愿景，而中台的愿景也往往来源于企业的战略需要。
2.3 中台的钱由谁出？
对于企业内部，可能代表的就是人和资源。所以，这个问题还可以引申到中台的人从哪来？从前台团队借调么？还是重新招聘新组建呢？一个中台建设往往会持续很长的时间，那这些人的成本又由谁来承担呢？ 这些问题如果没有考虑清楚，也会给中台建设带来非常大的麻烦。
中台建设的前期（从 0 到 1），不是直接从前台业务团队划出资源，而是由企业本身的战略储备资源投资建设。经过一定时间的建设期，比如 6 个月，然后逐渐找适合的前台业务进行试点接入，如果效果好的话再推广到更多的前台业务团队。当服务稳定之后，对前台也产生了稳定的价值之后，再逐渐从前台收取一定的资源，可以是人也可以是其他资源，既所谓的收回投资并实现盈利。这里的盈利只是个比喻，可能是满足了企业管理层对于企业战略目标的需求。
这种模式的好处是中台团队在中台的建设初期会有更多的自主权，在启动和脆弱期不会受到太多现有业务压力的影响，能更好地实现中台自己的建设愿景。但缺点是企业需要有较雄厚的战略资源支持，也需要有更大的战略决心。我看到很多互联网企业的中台建设，也往往都是采用类似的模式，所以在外界看来，他们的中台建设都非常直接且迅速。
2.4 中台的目标怎么验证？
中台作为前台的服务者，不但无法分享业务成功的喜悦，反而很容易被甩锅成了背锅侠。
所以，以终为始，在建设前就应该思考如何验证和度量中台。通过提前考虑这个问题，让我们可以在建设的中后期规避一些扯皮和风险。
目前业界有一些中台的考核标准我们可以作为参考，例如阿里巴巴的中台考核就是设计成：40% 稳定性 +25% 业务创新 +20% 服务接入量 +15% 客户满意度。
那我们自己的中台能不能简单复用人家的指标呢？答案肯定是否定的。中台建设的愿景不同，考核的方式和指标也自然不同。
比如回到极客地产的这个例子，中台建设的愿景是支持业务转型，支撑的是新的业务，那可能早期就没必要要求那么高的稳定性和接入量，可能只支撑一到两个新的业务线，更多看的是服务的满意度，或是其他指标。
最后，建议你不要等建设完了再去考虑如何度量的问题，尽量提前考虑甚至在建设之前就约定清楚，这样才能最大程度地
3 如何规划中台
如何沉淀成平台
如果是企业级的问题，你要解决的就是实现企业目标这个级别的问题。这样的问题本身就是模糊的，一般也都是战略级别的，所以不能只从现状的业务入手，要从企业的战略分析开始，充分考虑未来架构规划对于战略的影响。
如果是企业级的问题，你将面对的就是企业的组织问题。组织问题有时候要比业务问题难处理得多得多，因为涉及到企业利益的再分配。一旦碰到组织和利益的问题，就会有各种被我称之为“为什么系列”的问题，比如最常碰到的就是为什么要配合中台？我为什么要把数据给中台？我为什么要用中台？等等类似的问题。
还有，如果是企业级的问题，回归到业务上，也和过去做系统完全不同。你面对的将是企业的业务全貌，甚至是那些未来才会出现的，现在还不知道长什么样子的潜在的创新业务
- 调研：建立全局视野。从企业的愿景和战略出发，结合行业趋势，竞争对手，客户群和业务现状，以及IT资产盘点，全方位理解企业战略，市场环境和IT全貌，帮我们做出正确判断。
- 规划：根据上面收集的各个维度的信息，对架构进行定义。仍然是企业架构层面，如到底需不需要中台，整体的实施路径。
- 设计：针对实施路径中的产品进行详细的设计。从需求分析到架构设计，到实施计划等。这就是一个标准的产品设计过程了。
- 交付：采用基于敏捷等开发方式进行交付，通过持续的交付和改进，减少现实和设计的偏离。
3.1 调研
中台这种解决方案到底适合不适合企业，仍然是需要调研和判断的。所以，如果我们一开始就把中台作为一个确定的既定方向，难免会限制住我们的视野，有可能会错过比中台更好、更简单、更有效的解决方案，或是过早地进行过度设计，在根本不需要中台的场景下，大张旗鼓地开展中台建设，劳民伤财。
目前很多企业的中台建设，目的就是识别企业核心能力，沉淀到中台，并以此为跳板和支撑，进行业务的创新和探索，想要跳到另一个更有发展的全新赛道上。
我们需要由内到外，分析行业和竞争对手.
同时通过自上而下的企业战略分解
- 基于愿景出发
- 确定阶段性目标和期望达到的状态
- 确定达成目标的路径
- 确定具体措施和行动。
这个过程中，某一个中台可能知识推导过程中的一个具体措施而已。
同时需要进行自上而下的现状调研和分析。因为每一家企业能够生存发展都是经过市场考验的，一定要基于现状，收集痛点。同时还需要能跳出过去的限制，从业务出发，从用户出发，进行探索新技术和新架构大的可能性。
3.2 规划
规划和分析过程中，虽然发现中台建设是必要的，但是相对于企业和行业现状，并不是优先级最高的事情，或不具备相关条件，贸然开展中台建设是非常危险的。只有确实需要中台，而且优先级也很高的时候才应该开展中台建设。
通过领域驱动设计（DDD）识别出有哪些类似的能力复用场景。
3.3 设计
这个阶段要解决的是中台的愿景是什么，包含哪些内容，从那开始落地，完成设计阶段。完成设计阶段，应该能够清晰地指导如何开始进行中台建设，这时候就可以着手进行开发工作了。
