“中台”这个概念火了一年多，很多公司都进行了实践，关于中台的文章，也真的是百家争鸣，笔者在阅读了一些资料后，按照一些伟大公司“黄金圆环”的why→how→what顺序，将所阅读的信息整理成本篇，算是在百家争鸣中响应一家。本文适用于初期概念导入，更多操作类、实践类敬请期待下一篇。
本文约8000字，重点图片9张，预计阅读时间为30分钟，建议多次阅读。
本文·导读·目录
⒈ 为什么要平台化？为什么要建中台？（why）
⒉ 如何建立中台？（how）
⒊ 中台是什么（what）
⒋ 总结
⒌ 推荐阅读
Part 1 为什么要平台化？为什么要建中台？（why）
1.1企业为什么要平台化？
先说答案：
因为互联网时代流量为王，⽤户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。
不断快速响应、探索、挖掘、引领⽤户的需求，才是企业得以⽣存和持续发展的关键因素。那些真正尊重用户，甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展；⽽反之，那些在过去的成就上故步⾃封，存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。
很残酷，但这就是这个时代最基本的企业⽣存法则。
⽽平台化之所以重要，就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力：⽤户响应力。这种能力可以帮助企业在商战上先发制⼈，始终抢得先机。
在互联网时代，商业的斗争就是对于用户响应力的比拼。
下面举2个经典例子：
1.阿里中台
最先想到的应该就属是阿⾥的“⼤中台，⼩前台”战略：阿⾥⼈通过多年不懈的努力，在业务的不断催化滋养下，将⾃己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。
2.海尔中台
海尔于2005年启动了“人单合一”管理模式改革，海尔最大化地释放了每名员工的工作活力，企业则转化为员工“自我创业”的平台，打造“平台型组织”，并致力于构建“全球商业生态系统”，与顾客变交易关系为交互关系，开放式创新，共同谋求发展与进步，互惠互利，实地践行“无边界企业”原则。
可见在互联⽹热火朝天、第四次工业革命的曙光即将到来的今日，企业能否真正做到“以用户为中心”，并不断提升自己的用户响应力来追随甚至引领用户的脚步，持续规模化创新，终将决定企业能否在这样充满挑战和机遇的市场上笑到最后，在商业上长久保持创新活力与竞争力。而平台化恰好可以助力企业更快更好的做到这些，所以企业需要平台化。
1.2企业为什么要建中台？
平台化并不是一个新概念，那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?
同样我先给出答案：
为了更快的响应市场，打赢战争！“消除烟囱”、“架构解耦”、“统一中台”、“服务重用”都是为了能够快速的赋能业务进行落地实施、改造、试错、转型，企业降本提效的手段。
众所周知，阿里拜访芬兰的游戏公司Supercell后提出中台战略的。这个公司是典型的小团队运作方式，每个独立团队不超过7人（典型的Scrum团队规模），称之为Cell（细胞）。团队自己决定做什么样的产品（自组织的团队），以最快的速度开发出公测版，获取用户反馈（精益创业的模式），如果用户不欢迎，迅速放弃这个产品（fail fast, fail cheap）。团队失败时没有惩罚和悲伤，反而会庆祝从失败中学到了东西（容忍失败的文化很重要）。这个模式使得Supercell成为年税前利润15亿美元的游戏公司。这个公司有多少人呢？不超过200人。这个公司开发过哪些游戏？有《部落战争》《海岛奇兵》《卡通农场》等。为什么Supercell能按这种模式运作？是因为它构建的“中台”能力，包括多年积累的非常科学的研发方法和体系。
这种强大的业务试错能力是Supercell相比于其他游戏公司最大的差别，也是最核心的竞争力。
而大部分企业IT建设都是“烟囱式”，都是基于业务需求建设系统，无法承受业务爆发式增长和业务创新的重担，具有典型的三大弊端：
1. 重复功能建设和维护带来的重复投资，造成成本和资源浪费。
2. 打通“烟囱式”系统间交互的集成和协作成本高昂。实施SOA项目，构建企业服务产品线，基于服务的方式来解决交互问题，其中牵涉大量的协同和开发成本 。
3. 不利于业务的沉淀和持续发展。ESB是解决不同系统间互联互通的好架构，但各个系统自顶向下的建设模式，导致了新的业务发现有服务不能很好地满足需要后，原服务方可能不想改造服务，或改造可能对原有业务带来极大风险，导致新业务方不得不再造一个烟囱。
烟囱方式建设的系统体系，导致企业中一个业务领域的数据和业务往往被打散在不同的系统中，采用系统打通的方式解决了眼前的业务交互问题，但治标不治本。
随着企业业务的发展壮大，重复造轮子的同时还会致使各个系统不断膨胀，变得臃肿，形成了一个个大泥球的“烟囱式单体应用”，渐渐拖垮了“⽤户响应⼒”，用户满意度降低，企业竞争力也随之不断下降。以淘宝单一系统模式为例，就有以下弊端：
1.团队协同成本高，上线前分支合并，各种包冲突，代码冲突，需要各团队间进行确认和协调；
2.应用复杂度已超出人的认知负载，各种业务错综复杂，牵一发而动全身；
3.错误难于隔离：所有代码运行在同一个环境中（JVM），任何一个小功能或非核心功能可能引起整个业务受影响；
4.数据库连接能力很难扩展，数据库集群的连接数量有限，随着应用实例数量增加，越来越不够用。平台也因为过高的数据库连接而处于一个非常不稳定的状态；
5.应用扩展成本高。通常系统出现业务处理瓶颈时，只是由于一个或几个功能模块负载较高，但因为所有功能打包在一起，没法对单独的几个功能模块进行服务能力扩展，只能将整个应用进行扩容，带来了资源额外配置的消耗。
6.所有服务都通过服务总线，服务总线的访问和计算压力都很大。一般企业服务产品线包含的功能非常多，如服务发现、注册、路由等，对服务器的要求较高，所以每次扩容升级都会带来在软件授权和硬件资源上的不小投入。另外，服务总线的调用量比较大，网络带宽要求可能会超过目前网络设备的能力范围，成本高。
中台就是在VUCA时代帮助企业在开展数字化工作，帮助企业赢得战争的指挥官体系。
指挥官体系的核心能力包含两点：
1. 由用户体验驱动内部运营管理不断完善。
在这种指挥官体系的管理下，企业会越来越体现出这两个特点：协同、进化。IT部门的职责是要助力企业从关注内部经营管理转向关注外部用户体验。这个指挥官体系的核心是用户体验驱动，用户为大。什么叫用户为大？什么叫用户体验驱动？举个例子：假设一个做零售的企业，它经常没货，那这个问题应该谁去处理？客服，因为客服是最需要直接面对用户回答这个无货的问题的角色，也是安抚用户的第一人。但是客服的工作不能仅此而已，他还需要做什么？他需要来找采销的麻烦，要求采销补货，不行就处罚，这个无货的后果不能让用户承担，客服必须要有反馈用户体验的权利。另外，上述例子中无货的用户体验，必须要有数据记录，数据孕育革新是基础。要构建用户为大、数据驱动的体系，用户为大不是企业里各个BU的负责人为大，各个BU做不好，BU的老大就要被干掉，这样的体系才能让让企业越来越好。
2. 由数据驱动内部运营管理不断完善。
互联网时代，无数据不决策，无数据不运营。作为指挥官体系的决策中枢和企业高管，时时刻刻都需要用数据说话，数据化运营增加营收，增效降本。洞察用户画像，深谙用户偏好，用数据驱动来指挥经营决策，莫做“三拍”领导。在认识到数据的重要性的时候，莫忘数据完整性、可用性和闭环，否则徒劳。
所以，企业在平台化的过程中，要结合自身企业实际情况思考，建设自己的中台层（同时包括技术中台，业务中台和组织中台等）。
Part 2 如何建立中台？（how）
每个企业都应该通过理解业务优先级、技术形态、成熟度以及正在进行的项目，为自身定制数字平台战略的目标和实施路径，不可盲目模仿。数字化建设并非一步到位，企业需要根据自己的现实情况与数字化目标，建立自己的数字平台战略，稳步提升能力。数字平台给企业带来了显著的收益：
2.1可行性分析
中台的建设不是那么件轻松的事情。中台战略的推进过程一定是自顶向下的，至少是CIO/CTO 层面向下推动，一定需要得到高层的支持。不然中台团队最初的处境可能会如阿里的“共享业务事业部”一样，不被相关事业部接受，让中台团队的处境十分艰难。建议先评估自己是否适合建中台，从下面几个方面判断与评估：
A.明确并统一各相关方建设中台的目标与意义
毕竟企业在建设中台之前如果不统一人员认知的话，必然在中台的建设过程中就会四面碰壁，各种扯皮、推诿，面临多方面的阻碍，陷入一个被动的局面。需要做好两个方面：一方面，是职责边界的划分问题，需要明确知道那些东西该中台来做，那些不该中台来做，需要业务部门自己去做；另一方面，更多的是涉及沟通的艺术和做事情的方式方法。
B.是否具备建设中台的条件与时机
1）战略分析
企业需要从公司整体的战略布局、核心竞争力、战术方法、业务方向等维度来，明确知道自己的优劣势综合判断，现阶段做与不做中台对于企业未来发展的利弊都有哪些，对于未来业务影响到底有多大。从而进一步明确企业建立中台的目标是真的想赋能业务，做到真正的降本增效，实践用户至上，还只是单纯的想对外秀肌肉。
2）业务调研
只有深入业务，明确业务单元后，梳理出业务价值链条后，拆解各个业务系统的情况，才能评估出业务是否有值得中台化的场景。
同时，也能明白通过组件化、模块化、标准化、解耦等方式来拆分系统和业务，再基于数据服务化的方式，就真的能快速支撑前台业务的迭代更新，从而不断的沉淀能力，做到服务和体验都统一升级吗？
3）数据调研
基于业务统计出数据来源，确定数据资源分类，做好数据评估，确定当前数据容量，结合业务运行频度，数据产生效率，预测数据成长规模。
因为，建设中台是在全域级数据汇集之后，做数据清洗、数据治理、数据资产管理等工作之前。所以，需要对数据使用情况进行盘点，为后续中台建设过程中数据流动和使用机制提供有力依据。
4）技术调研
通过技术现状调研，可以提前了解技术落地情况、人员技术情况，做好建设中台的技术人员准备，提前规避风险。
5）组织分析
通过高层访谈、组织架构分析，明确企业中台的目标与意义，同时调研分析各个事业部对建设中台的看法，为后续中台的沟通落地、推广做好前期准备。
2.2规划和实施
首先要建立“中台“配套的相关管理机制，其次是建立应用架构，从相对容易的基础共享服务开始，到定制与业务贴合的业务中台。在建立中台的过程中，需要配套中台运行的后台基础架构。中台的建设可以总结为五步走。
A.建立合理的管理机制: 中台的建立，切忌做成项目制，中台需要使用产品管理的方式来对待。这是因为中台对外提供的服务需要不停的迭代，适应业务的需求，否则经过一段时间，前台因为中台提供的服务固化，只好自己新建一个服务来满足业务需求，逐渐不使用中台提供的公共服务。对于中台产品来说，必须思考的问题是，这个功能在现在或者将来能满足多少业务场景？如果将来有新的业务出现，是不是能够复用？或者说，需要做多大的调整才可以复用？甚至于，这个功能有没有可能对外输出，提供SaaS化的服务。
B.搭建适合企业的应用架构: 企业和阿里巴巴不同，阿里巴巴基本上都是C端应用，电商、文娱、消费。业务系统都是自己开发。企业则历史包袱重，自主开发能力不强，既有购买的商品化软件，又有自行开发的系统。比如，制造企业既有后端的SAP ERP，PLM，MES，WMS等系统，这些年又产生了面向外部的电商，客户服务，营销服务等前端系统。前端系统由于市场需要变化快，要求系统迭代速度以周甚至天计算，而后台的传统应用，变更和迭代通常以月甚至年来计算。
C.提供基础共享服务: 基础共享服务是面向技术层面的基础公共共享服务，因为大部分服务就是集成功能，因此也可以称为“集成中台”。大致有如下的共享公共服务：
D.数据中台进入到数据时代（DT），数据的重要性越来越被企业认知。对数据的收集，分析计算，深度学习，并转让为企业的核心竞争力。
5.业务中台业务中台每一个企业都是不同的，它是高度个性化的，无法通过直接购买获得，因为它与业务密切相关。业务中台需要长期的沉淀，抽象和归纳。打造一个业务中台绝不是一朝一夕的事情。
Part 3 中台是什么（what）
3.1企业级能力复用平台
中台本身就是一个比较抽象的概念，很多时候我们被那个“中”字困住了，整天在前与中、中与后的具体差别和评判标准上纠结不已。但是，就像「看板」不是“我们看到的那个板子”一样，「中台」也不一定就是代表“处于中间平台”，这两个字作为一个整体，代表了一种新的思维和理念。
那这种新的思维和理念到底是什么呢？是否能够给「中台」这个相对抽象的概念找到一个清晰的定义。因为只有通过定义才能让抽象的概念清晰化，从而明确边界、体现价值。
中台就是「企业级能力复用平台」
一直以来，中台有各种各样的定义曾浮现出来，但至少到目前为止，只有这个定义是我觉得最贴切、最简单、也最准确的，它能解释几乎所有我碰到的关于中台的问题，例如：
1.为什么会有那么多中台，像上文提到业务中台、数据中台、搜索中台、移动中台，哪些才是中台，哪些是蹭热点的？
2.中台与前台的划分原则是什么？
3.中台化与平台化的区别是什么？
4.中台化和服务化的区别是什么？
5.中台该怎么建设？
等等……
这9个字看起来简单，重要的是其背后对「中台」价值的阐释：
·「企业级」定义了中台的范围，区分开了单系统的服务化与微服务；
·「能力」定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
·「复用」定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上；
·「平台」定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑。
3.2 Platformas a Product
但是接触的中台场景越多，就越发现其实每家企业建设中台的目的可能都是不一样的，大面上就能分成：内部研发效能提升、资源整合、新零售、全周期、全渠道、开放银行、多品牌战略、全球化战略、产业互联、构建商业生态等等等等。
当我们真正下定决心，捋起袖子加油干，尝试真正去推动中台落地的时候，才发现原来通往美好远方的是条布满荆棘之路：
·中台的建设经费从哪里来？中台团队的人从哪里来？谁应该为中台的建设买单？
·中台的建设效果如何来体现？谁来验收谁来评价？
·我们说中台是企业级，要支撑多个前台团队，那四面八方的需求涌进来，会不会出现拥堵和排期？如何处理排序需求？
·如果不同的前台团队的需求出现矛盾和冲突，中台如何处理？都是金主，以谁为主？
·前台与中台的职责怎么划分？
·前台不配合中台团队怎么办？
·前台提的需求不合理怎么办？
·……
问：那，如何破？
答：给中台一个边界，产品的边界，将中台团队从共享职能团队转变为中台产品团队，将前台与中台的关系由被服务与服务的关系变为产品与产品的关系，即：Platform as a Product！
有意思的是，在思考这些问题的同时，回头再去看看这几年一直关注的阿里中台，才意识到答案其实一直就在那里。阿里巴巴早已将自身的中台能力，通过产品化包装整合到了阿里云上，对外输出，无论是承载了技术中台能力的Aliware，还是承载着数据中台能力的Dataphin，还是承载着研发效能能力的云效。再去看各大互联网巨头，亦是如此，早已将眼光放到了更宽阔的企业外部，放到了整个社会，放到了各个行业，通过中台能力的产品化包装和输出，开始打造各自的生态系统了。
Part 4 总结
·基于企业的使命与愿景，结合当前的商业形势，制定匹配的公司战略，并基于战略迅速调整组织进行战略落地。再根据康威定律，通过组织的变化引导IT架构的演进，所以中台的诞生只是企业战略层面上，在企业发展某个阶段强调加强组织横向协同性的一个中间产物而已。
·天下大事分久必合合久必分。战略在不断调整，组织就会不断调整，IT架构就会不断调整。凡事没有完美，没有完美的战略，没有完美的组织，也自然没有完美的IT架构，都是在持续地演进中。所以要将关注点从试图找到完美的解决方案转换到提升调整能力上来，这点无论是对于战略、组织还是IT架构都是适用的。
·以用户为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力，是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段，并不是⽬标本身。
·中台(⽆论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应⼒困境，弥补创新驱动快速变化的业务和稳定可靠驱动变化周期相对较慢的单系统之间的⽭盾，提供⼀个中间层来适配的配速问题，沉淀能⼒，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应⼒。
·聚焦到中台建设的过程中，引入产品化的思路则可以让我们换个视角更好的思考中台的边界和责任，思考其核心的建设价值，更好的解决中台建设过程中出现的各种矛盾与问题。
·同时可以将中台切成更小的产品单元，引入类似于组织中台这样的内部孵化投资管理组织，对于中台产品群进行产品化市场运作。这样的好处还在于可以通过投资方向的调整来引导内部IT架构的演进，加速企业的战略调整落地。
·使用产品化的思路来建设中台，还有一个巨大的好处：因为中台作为一个产品，除了产品形式（可能就是API）和用户（内部前台团队）外，其他方面和其他产品没有什么不同。这就意味着在产品构建上我们过去已经积累了的大量成熟的方法和工具，都可以平移应用到中台的建设上来！
漫漫中台路，才刚刚开始，期待下一篇更深入的探讨实操问题吧！例如“中台每个阶段的效果如何来验证？OKR如何定？团队人员如何选拔？知名企业的中台长啥样？….”
*文内图片来自网络
推荐阅读：
1. 中台概念
[if !supportLists]· [endif]对话阿里云总裁行癫：最详解密阿里云顶层设计和底层逻辑
[if !supportLists]· [endif]湖畔大学阿里CEO 张勇：找人的核心，就看2 点
[if !supportLists]· [endif]什么是中台，什么不是中台。所有的中台都是业务中台
[if !supportLists]· [endif]到底啥是平台，到底啥是中台？李鬼太多，不得不说
[if !supportLists]· [endif]平台战略== 中台战略？
[if !supportLists]· [endif]在构建数据中台之前，你需要知道的几个趋势
[if !supportLists]· [endif]火热的数据中台对企业的价值是什么？
[if !supportLists]· [endif]你真地需要一个中台……吗？| 商业洞见
[if !supportLists]· [endif]阿里的中台战略其实是个伪命题 （从企业架构看中台）
[if !supportLists]· [endif]从海尔模式看数字化平台 | 透明思考
[if !supportLists]· [endif]湖畔大学，一所别样的大学
[if !supportLists]· [endif]《中台战略》
2. 中台与组织
[if !supportLists]· [endif]白话中台战略-4：Platform
as a Product(组织篇)
[if !supportLists]· [endif]中台禁区：为什么最关键的组织架构却鲜少人谈？
[if !supportLists]· [endif]《释放潜能：平台型组织的进化路线图》 – 穆胜
[if !supportLists]· [endif]《重塑海尔：可复制的组织进化路径) – 穆胜
[if !supportLists]· [endif]构建网状组织架构 – 读《赋能》 – 为程序员服务
[if !supportLists]· [endif]企业IT的经营模式及其与企业架构师的关系 | 透明思考
[if !supportLists]· [endif]小米、海尔、华为、阿里巴巴的阿米巴运营
[if !supportLists]· [endif]马云的阿里和盛稻和夫的阿米巴
[if !supportLists]· [endif]稻盛和夫“阿米巴经营”和海尔张瑞敏“自主经营体”的两同三异
[if !supportLists]· [endif]《企业IT架构转型之道》
3. 建设经验
[if !supportLists]· [endif]从平台到中台| Elasticsearch 在蚂蚁金服的实践经验（平台与中台）
[if !supportLists]· [endif]滴滴出行构建业务中台应对软件复杂度的具体对策与实践
[if !supportLists]· [endif]七问七答，亲历者讲阿里中台落地的实践
[if !supportLists]· [endif]我的一年中台实战录 （网易教育中台实战录）
[if !supportLists]· [endif]跳开DDD 和中台概念看阿里巴巴交易平台的问题及解决思路
[if !supportLists]· [endif]阿里玄难：面向不确定性的软件设计几点思考
[if !supportLists]· [endif]不要做中台！不要做！不要……要 （中台人员能力模型）
[if !supportLists]· [endif]企业核心业务数字化转型最佳实践
[if !supportLists]· [endif]数字化转型 移动化先行 云栖大会上发布了哪些移动研发新利器？
[if !supportLists]· [endif]《阿里技术手册-研发篇》
[if !supportLists]· [endif]《数据中台》
4. 方法论相关
[if !supportLists]· [endif]谈谈企业的规模化创新
[if !supportLists]· [endif]以愿景与目标驱动，让创新无处不在（精益价值树）
[if !supportLists]· [endif]当用户不是客户，需求价值怎么定？|商业洞见（用户与客户）
[if !supportLists]· [endif]架构设计实践思路：什么是架构，怎么画架构图？（企业架构展开解释）
[if !supportLists]· [endif]Microservices
Guide （微服务）
[if !supportLists]· [endif]EventStorming （事件风暴）
[if !supportLists]· [endif]《Pace-Layered Application Strategy》
