七大维度解读「中台」的前世今生
一、中台的起源
中台最早被大家所注意，我相信一定是因为阿里巴巴的中台战略。2015年12月7日，时任阿里巴巴集团CEO的张勇在一封内部邮件中说到：“今天起，我们全面启动阿里巴巴集团2018年中台战略，构建符合DT时代的更创新灵活的大中台、小前台的组织机制和业务机制。”以此为标志，阿里之前的“厚平台，薄应用”也就是顺势变成了“大中台，小前台”。
说到阿里中台的缘起，我们就不得不说一下Supercell这家公司。2015 年年中，马云带领阿里巴巴集团高管拜访了一家芬兰的小型游戏公司 Supercell，让马云及其高管团队感到惊讶的是，这家仅有不到 200 名员工的小型游戏公司竟创造了高达 15 亿美元的年税前利润！
该公司典型的开发模式是以小团队为单位的单独“作战”，每个团队不超过 7 名员工。每个团队都可以自己决定开发什么样的游戏产品，然后以最快的速度推出公测版，如果不受欢迎，就立刻放弃，寻找新的方向。
而 Supercell 之所以能够支持多个团队快速、敏捷地推出高质量的游戏作品，其强大的中台能力功不可没。Supercell 的中台，指的是公司将游戏开发过程中公共和通用的游戏素材和算法整合起来，并积累了非常科学的研发工具和框架体系，构建了一个功能非常强大的中台。这样强大的中台可以支持若干个小团队在短时间内开发出一款新的游戏。
其实Supercell的访问只是阿里正式提出中台战略的一个引子，要想理解阿里建设中台的真正原因，时间还要向前推，一直推到2008年阿里天猫商城的上线。
众所周知，天猫商城相比于阿里旗下原有的淘宝，虽然二者都是面向C端的电子商务平台，但是有着不同业务特点，不能完全复用，因此也就出现了大量的重复建设问题，进而也就自然有了“烟囱式架构”所有的问题。
那么怎么办呢？如何才能避免大量的重复建设和资源浪费呢？如何才能做到打破烟囱的壁垒呢？自然而然也就想到了将重复的组织和系统进行整合。因此，阿里共享事业部正式诞生，负责将前台系统中的公共部分进行平台化改造，在经过一段时间的痛苦期后逐渐成型，才为阿里的大中台战略埋下了重要的种子。
二、中台要解决什么痛点
任何一个新事物的诞生和应用都是有他自身的价值，中台的诞生到底是为什么呢？它又能解决企业什么样的问题呢？这就要分析下现代企业数字化转型中的几个痛点。
痛点一：企业前方市场与企业内部支撑的冲突
为了不被善变的用户所抛弃，企业不得不跟随着用户，必须做到快速响应、灵活运转。但要作为一个能承接大量新业务和新服务的企业，必定需要靠企业内部科学有序体系的稳定支撑。所以，企业前方市场总是会趋于变化无序，而企业内部支撑总归要趋于稳定有序，两者必定冲突。
痛点二：IT系统建设前台与后台的冲突
前台是对接用户的，所以系统需要快速响应前端用户的需求，快速创新、快速迭代。后台是企业对内的，为了支撑前台越来越多的业务，系统不断庞大地起来。系统建设成本越来越高，效率越来越低。前台系统和后台系统的特点决定了，两者的冲突不可避免。
痛点三：大企业的通病（各占山头、重复建设）
企业发展到一定程度，组织架构和层级必然不断膨胀扩张。大企业内部各处都是墙——部门墙、业务墙、数据墙。更不用说那些一味的内部赛马的绩效考核机制，势必更加加剧部门间的相互封闭。
痛点四：传统IT系统架构的弊端
传统的IT系统架构基本都是烟囱式的系统，这就导致了重复建设，缺乏标准，集成困难，让后台不稳定，让前台不敏捷。
前台需要越快越好，后台追求稳定和安全，必然被各种流程、制度所限制，不可能满足前台的速度要求。那么中台的产生，就是为前台而生，是前台和后台的变速齿轮，他让前台更稳定，后台更敏捷。
三、中台的定义
既然中台概念被热火朝天的宣传开来，也致力于解决企业数字化转型的各种问题，那到底什么是中台呢？它是一种思想？还是一种技术？或者是一种架构呢？它有没有明确的定义呢。很遗憾，目前为止还没有为中台做一个明确的定义。但是从迄今为止，有一种说法我认为是最为贴切的，那就是：企业级能力复用平台。
短短的九个字，但它却定义了中台的视角、范围、目的和形式。
中台的视角是企业级的，站在企业发展的高度，来看中台；中台的范围是泛指一切的能力，而不仅仅局限于技术能力和IT能力；中台的目的是为了复用，避免重复建设，降本增效、孵化创新；而中台的表现形式最终是以平台的形式来体现。
虽然给中台了这样一个定义，但中台依然是一个很泛的概念，其实根据不同的功能和类型，我们又可以对中台划分为业务中台，数据中台，技术中台，研发中台，AI中台，甚至是组织中台等等。
我们来看下行业里BAT的中台的形式：
- 阿里的中台强调业务中台+数据中台的双核驱动，一切业务数据化、一切数据业务化
- 腾讯的中台以数据中台+技术中台作为驱动，而数据中台和技术中台又是各种中台的集合
- 百度的中台和阿里、腾讯又略有区别，以AI中台、知识中台两大创新平台为主
四、中台架构的技术要求
前文介绍了中台的定义，那就是企业级能力复用平台，但这是广义的概念，我们常说的中台架构更偏落地的技术实现，站在技术角度，中台架构有哪些特点呢？
1. 组件化
中台提供的服务最好以组件化的方式让业务端可以即取即用。组件化设计可以避免系统间耦合性大，牵一发而动全身——这需要针对共用服务进行抽象设计。通过抽象出的组件化服务，前台业务端可以以组合挑选的方式“按需取件”，减少重复建设得以实现。当前流行的微服务架构为组件化的实现提供了可以实现的技术支撑。
2. 可复用
我们说中台的目的是可复用，减少重复建设，可复用的程度也是检验中台能力的一项重要的衡量标准。服务的高复用是对技术层级上针对共用服务的抽象设计能力的一大考验，需要尽可能近地靠近业务、靠近用户。
3. 可共用
可复用是最大限度的利用企业积累的现有的能力，而可共用是为了打破企业内的各种墙，实现更广泛的业务协同和资源共享。只有将资源充分的开放共享，才能赋能于前台业务，提升前台业务的敏捷度，从而提升创新的效率。
4. 灵活扩展
当所有前台业务都接入中台服务时，中台就成为企业流量的中心，中台服务的稳定性需要保障，中台的弹性能力就需要增强。底层的可灵活扩展能力将非常重要，企业应当应用DevOps、Docker 等先进的开发技术理念，在中台建设前就开启数字化的技术转型。
中台本质上是企业的业务模型。中台如何落地，微服务架构是目前公认的最佳实践，中台落地时会面临微服务应该如何拆分和设计的问题。是否有好的方法来指导微服务的拆分和设计呢？那就是DDD（领域驱动设计），DDD包含战略设计和战术设计两个阶段，通过战略设计完成中台业务边界划分和领域建模，然后将领域模型作为战术设计的输入，完成微服务设计。
五、中台失败的原因
中台对于技术提出了更高的要求，但我们还是应该清晰的认识到广义的中台他不是一个技术上的概念，它是企业管理和企业应用架构紧密结合的产物，如果只是把中台建设聚焦到技术领域、IT能力的话，中台建设往往很难真正落地。
如果2019年是建中台的元年，那么2021年我们又听到很多公司开始拆中台的消息，短短两年中台就已经不行了吗？就像当年的那句不上ERP等死，上ERP那是找死，上中台难道也是找死吗？那些中台失败的原因到底是什么呢？锦囊专家联合数字化奇葩说发起了一项关于中台失败原因的调查，中台失败的原因如图所示：
其中最高的居然是中台团队能力差，看来任何一件错事，总得找人背锅啊。按照老谭的调研和理解，我认为中台失败的原因有以下六大原因：
失败原因一：认知不对称，战略不清晰
正像前文介绍的中台的定义是不明确的，这就导致每个人对中台的认知是不一致的，高层看到的中台，跟基层看到的中台有差异，业务部门和IT部门看到的中台有差异，如果不能拉齐这些差异的认知，中台落地的各个环节就会出现行动偏差。另外，企业对于中台战略不清晰，是导致中台失败的罪魁祸首。
中台战略一定是自上而下的推动，是业务和IT的协同，是一个短期要投入长期见效益的慢工程，不是找个供应商，上套平台就行的，中台建设是无法外包的。中台不是一般的项目，中台也不是一个IT系统，它是企业战略和企业应用架构融合的产物，需要中台思维和持续性。
失败原因二：为了建中台而建中台
你的企业是否需要建中台？每个IT负责人甚至老板都应该思考这个问题！上不上中台需要考虑企业的业态、IT建设的现状、企业的发展阶段以及未来的发展诉求，不要盲目跟风，结合企业自身实际情况确定合适的IT战略。我们总结了以下几种适合实施中台战略的情况供大家参考。
失败原因三：中台建设的“度”不好把握
在企业的信息系统中，可以分为面向市场和客户的体系和面向企业内部运营的体系。对外的体系需要创新、应变、开放、高并发、可扩展！对内的体系需要严谨、规范、集中、可追溯、可深挖！对外的体系适合基于中台建设。
在中台建设中要充分利用现有IT资产，逐步进行系统的拆分，服务化！服务粒度越小，越敏捷，越适合创新；服务粒度越粗，越稳定，越适合标准化。
所以中台建设的度一定要根据当前企业IT现状，并且用动态演变的思维去持续的扩展中台的范围，切忌一上来就搞个大而全的，或者什么都推翻重来。
失败原因四：组织架构不调整、不匹配
根据康威定律，设计系统的架构受制于产生这些设计的组织的沟通结构。简单来说就是你想要一个什么架构，就需要什么样组织进行匹配。中台架构的落地必须有强大组织的推动，就像阿里，CEO张勇站台，CTO张建峰亲自挂帅，共享业务事业部才能承担起中台建设之重任。
很多企业，只是提出了中台的战略，却没有设置相应的团队和职权，那么中台想落地就很难。中台团队既不是委员会也不是许愿池，是一个具有职权的实体团队，并通过全局的领导组织，保持前台组织和中台组织的协同。
失败原因五：中台建设团队能力不行
中台建设作为企业核心能力建设，既要有立足全局的战略规划能力，又要有业务架构抽象能力，同时对技术开发的要求也不低，所以团队能力是个挑战！中台建设是一个企业长期不断调整迭代的过程，以适应客户不断提出的新的需求、市场的快速变化、未来业务模式的创新，传统的依赖供应商进行信息化建设模式将受到挑战。
失败原因六：对中台的过高期望
去年有一篇《阿里去中台和互联网反垄断》的一篇文章，把拆中台的热度推上顶峰，文章的观点，老谭实在不敢苟同。哗众取宠，以偏概全，这也代表了一些对中台期望过高的人的心态，一旦不能满足不是拆中台，就是骂中台无用！
笔者的观点是：
- 中台不是为了管控，核心是复用！中台是柔性的 ！
- 中台不是创新的风向标，它不适合做颠覆式创新，文化才是！中台是创新的加速器，擅长组合式创新！
所有中台不是万能的，它只是企业数字化转型的一种重要实现路径，我们不能对中台有过高的期望，还是要理性的回归到企业数字化转型的价值上来。
六、医疗中台路在何方
上文分享了中台失败的几个原因，其中谈到中台适应的场景，在所有行业中，互联网大厂的中台建设还有新零售的企业实施中台的比较多，是因为他们的业务都是外向型，是需要紧跟市场快速变化，紧贴用户需求需要快速反应的，前台业务极其敏捷，中台从连接前后台来说，从能力积累和能力复用来说，都提供了可为的价值。
但是对于笔者从事的医疗行业来说，医疗资源分布不均，甚至匮乏，在这样的环境下，医疗业务并非敏捷性的业务，但是随着新冠疫情的持续影响，互联网医疗，远程医疗的需求在不断的提升，封闭的医疗信息化的体系就很难支撑了。
这也催生了医院的IT架构数字化转型的强烈需求，传统的医疗IT架构面临着挑战：
- IT架构弹性不足
- 健康医疗大数据的潜力未被开发
- 医院IT的能力与技术升级遇到瓶颈
- 操作便捷性的挑战
医院的信息系统基本上都是烟囱式的系统建设，而且系统多，供应商多，相互集成，成本高，虽然集成平台可以很好地解决医院历史遗留系统之间的互联互通问题。但当面临一个新需求时，系统的修改成本并没有太多改变。换句话说，集成平台更多的是面对过去的治理，对于未来的业务无法真正起到赋能的作用。
医院正在面临信息化建设的多元化需求。压力不仅来自医院内部需求，越来越多的需求来自于医院外，比如互联网医疗、分级诊疗、区域信息平台、医疗大数据等。所有这些需求都需要对医院的数据进行访问，包括患者、就诊、医嘱、检查、检验、医务人员、设备等。此时我们多么希望服务能够共享该多好啊。
比如患者需要到医院就诊预约挂号，可以把挂号这个业务抽象形成“中台”服务，给到窗口、自助机、App、公众号等多种终端系统进行使用，甚至还可以扩展到线上的互联网诊疗。
如果我们从传统的系统建设，系统集成转变成基于中台的服务开发、组件开发，粒度变小，可复用性变强，是不是就能很好地支持上述的场景了呢。
其实，我们来看IDC对于医疗信息化的发展趋势的分析报告，我们正在从医疗系统一体化、集成化的阶段向医疗数字化中台的方向在快速的发展。
这张图片是IDC发布的医疗数字化中台的建设指导框架，可以供大家参考。
中台是一种思想，它的建设并不是一蹴而就的，我们需要把这种思想传递给到医院。随着医院业务的发展，需要对业务不断进行抽象提炼，分层、分步沉淀业务、技术、数据，最终把中台构建成为医院IT能力中心。
医院场景其实没有必要直接套用互联网领域的‘中台’的概念，企业的业务，归根结底落地点就是“买卖行为”，是以盈利为目的的，而医院是以服务社会为主的事业单位，如果一定要用中台这个概念，医疗中台不是只服务于一家医院内部，而是能促进医院和核心医疗机构比如医保间的共享、合作。医院数据是比较敏感的，绝对不能像现在某些互联网公司那种不尊重用户隐私的做法。
其实早在2019年开始，国家医保信息平台建设采用“云+中台”的技术方案，对医保疾病诊断、医疗服务、药品、医用耗材等15项信息启用全国统一业务编码，建设成为统一、高效、兼容、便捷、安全的信息系统。
而笔者带领团队在2019年底也开始了医疗中台架构的探索，虽然这个中台架构经过几年的发展形成我们的研发底座，离最初想象的样子有很大的差异，但是作为研发型的企业本身和运营型的企业在中台的需求上面就存在很多的不同，只要它能解决我们内部快速创新，减少重复建设，实现业务和数据的共享，提升的研发的效率，那么它达到了我当初的目的。
七、中台建设的实施方法和路径
1. 中台建设的价值要求
在建中台之前，我们要明确建中台的目的和价值是什么？盲目跟风肯定是不行的，否则最后效果就很难尽如人意，甚至建设过程中就开始迷路了。
中台建设的价值要求：
- 提质转型、降本增效
- 创新业务的快速推进
- 快速响应变化的需求
- 提高服务的可复用性
- 降低IT系统的复杂度
2. 中台建设的4-ONE要求
中台是企业级能力复用平台，如何才能更好地能力复用呢？能力要被复用，能力就需要有共性，有标准，并且能力能被管理，管理就是将不可控的过程变成可控的过程。所以，在中台建设的实施过程中，我们要建立4-ONE思维：
1）One Standard（统一标准）
统一的业务应用设计标准，研发管理标准，平台和领域能力运营标准。
2）One Model（统一模型）
抽象并定义统一的业务领域模型，并在业务回归（业务应用的开发）中持续的优化升级。
3）One ID/Code（唯一标识）
面对多套业务系统/应用，提供统一的识别标识，以此来保证系统间的数据统一和业务协同。
4）One Service（统一服务）
定义统一的业务能力服务输出方法和业务能力接口。
3. 战略设计和能力管理
中台建设要结合自身实际，重其神而轻其形，只要站在业务能力的沉淀、复用和创新的角度，建立中台思维，这就是中台成功的前提，中台是抄不来的，不能用传统信息化的思维去执行。
中台战略的实施路径：
1）标准制定和系统搭建
搭建面向业务应用开发者的能力开放平台，以此来承载业务前台与中台之间业务通讯的标准流程。
2）领域建模和能力输出
从业务中抽象标准领域模型，并设计标准能力服务（API）。
3）业务改造和数据迁移
基于领域能力和能力开放标准，对业务系统进行改造，并实现数据的结构化迁移。
4）新业务孵化
面向最终客户，基于领域模型，孵化新的业务应用。
中台是能力复用的平台，平台是业务管理、数据管理、能力管理具象的产物，通过建立标准、抽象对象、开发逻辑、共享服务等方式对外提供，通过一个平台将这些有效的组织起来、管理起来，让中台不在抽象，这也是推动中台可落地的一种方式。
#作者#
菜根老谭，微信公众号：CGLT_TAN。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。现负责某科技公司整体产品研发，擅长企业IT架构及互联网产品架构。
本文
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
