【转帖】作中台找死，不作中台等死？

作中台找死，不作中台等死？

http://developer.51cto.com/art/201911/605254.htm

 

今年参加了云栖大会，做为中台的践行者，我也更关注中台架构实施的行业情况，学习了其余公司中台的思想和经验。

图片来自 Pexels

云栖大会上，我和作中台实践的同窗，以及在阿里作中台的朋友进行了深刻的交流和探讨，对作中台过程当中遇到的比较纠结的问题进行了思考和总结。

在探讨中台哪些让人纠结不定烦心事以前，咱们依然要谈谈咱们为何要作中台(注：本文中台局限于企业 IT 架构的中台，非广义上的中台)，作中台到底给我带来哪些好处，想不清楚这些就去深刻到中台的细节里也无心义。

中台概念这几年特别火，就像 90 年代不作 ERP 是等死同样，如今作不作中台也好像能定企业生死同样，弄得你们都在搞中台。

可是不是全部的企业都适合作中台，只有符合如下条件的企业，才有实施中台的必要，切莫乱搞。

企业适合作中台的条件

因此，若是您是创业团队，或者业务线比较单一，建议不要盲目尝试中台架构，不然将拖累你业务发展的速度 。

另外，咱们也要清晰的知道实施中台的目的，以及中台会给企业带来的价值，没有实际利益的推进中台就很难落地，或者有形而无神。

中台的价值

明确了中台的应用场景和价值体现，咱们开始实施中台架构的落地。我从今年上半年开始推进中台这件事差很少有几个月的时间，在这个过程当中也是摸着石头过河。

虽然有不少中台的理论知识能够学习，可是实际的过程当中发现，中台的落地是一件很是难的事情，它没有标准，认识也不统一，在一些关键环节存在很多分歧。

正好这次在云栖大会约了几个实践中台的朋友进行了深刻的探讨，把讨论的内容进行总结，但愿中台的建设少一些纠结，多一分信心。

中台定义：思想 VS 工具

什么是中台?每一个人可能有不一样的理解，行业里也没有严格的定义，但我更认同其中一个说法就是：中台是企业级能力复用的平台。

如何来解释这句话呢?

中台的定义

既然核心是能力复用，业务流派认为中台实际上是一套思想，只要可以实现能力的复用，知足降本增效的企业目标，采起的全部措施，和一切可复用的能力都是中台的范畴，因此中台是一种组织方式。

而技术流派的人则认为，既然是能力复用的平台，就必定要有支撑复用的工具，就必须定义一套技术规范来支持复用，中台必定要有基础平台来支撑的。

中台首先要统一思想，围绕能力的复用进行组织管理，将能力组件化，以下图最底层部分。

同时，中台之上咱们要构建能快速落地的技术平台(如图中 OECP 部分)，经过 Low code 的平台能力，实现组件的组装和流程的设计，快速的构建应用。

技术平台是业务无关性的，但业务中台必定是业务相关性的，只要把业务和技术有机的组合起来，把企业的能力沉淀并复用起来，这就有了中台的基础。

中台之上集成开发能力

复用粒度：粗粒度 VS 细粒度

复用是中台建设的核心，是一切的基础，没有复用的意识导向，中台就变成了自娱自乐的游戏。

也许不少人会说，没有中台以前复用无处不在啊，咱们写程序复用代码，作方案复用案例，为何必定要建设中台呢?

首先，再次重申下中台的复用范围是“企业级”，它既不局限于技术同窗内的程序复用，也不局限于一个团队内部的复用，而是站在企业最高的视角，做用于整个企业的 IT 架构;其次是“能力的复用”，能力的范围更加宽泛。

和阿里的朋友谈到复用时，咱们也提到了复用的级别，像阿里云其实就是在基础设施这个级别上的复用。

我本身把复用的级别抽象成下图所示的 5 层：

复用的级别

级别越低，粒度越小，复用的范围越广，但价值体现较低;级别越高，粒度越大，复用的价值越高，但复用范围也比较局限。

因此站在业务和价值角度上，都是先从最高的层次上去复用。只有上层没法实现复用，咱们才会逐步向下层去寻找。

可是有时候站在技术角度，咱们习惯在低层次上去复用，由于这里最接近本身的工做，粒度越小，技术上越可控。

但不论怎样只要咱们能把这些能力很好的组织管理起来并实现复用，就是中台的思惟。

具体到中台落地的 IT 架构，微服务基础架构是目前最流行的方式，由于单纯程序代码的复用价值有限，而传统单体应用的复用又极其的不灵活，而基于微服务架构的业务组件的复用则处在中间层级，灵活性和复用度比较平衡。

组件复用的核心思想是领域驱动设计(DDD)，而我认为 DDD 最大难点是粒度的控制，粒度太粗不灵活、复用性差，粒度太细虽然复用性好，但耦合较大，运维成本较高。

Gartner 对服务粒度划分

Gartner 在研究报告里提出了宏服务、小服务和微服务的粒度划分：

• 宏服务：一种传统的 Web 服务，支持将功能封装于单体应用内。宏服务不支持独立部署或扩展， 它们只能部署为单体应用的一部分，并且它们不须要微服务基础架构。
• 小服务：就服务粒度范围而言，小服务是一种粗粒度、松散耦合、支持独立部署的应用组件。小服务须要微服务基础架构。
• 微服务：微服务处于粒度范围的远端，是一种可独立部署的组件，可以支持单个应用功能的实施。微服务可直接部署到微服务运行时环境中，也每每具有专用数据存储区。微服务须要微服务基础架构。

我本人很是喜欢 Gartner 的划分方式，基于这三种服务的粒度，我也谈谈我对粒度把握的一些思路。

若是咱们想对已存在系统的能力进行复用，能够采用宏服务模式进行，宏服务的模式适合作系统的集成和治理。

咱们对于新的业务和项目，刚开始建议采用小服务的方式进行业务领域的拆分，不建议拆分的过细，这个小服务能知足该需求的基本抽象便可。

从适中的粒度开始，服务的粒度必定是业务推动的过程当中不断演化的，创新业务推进服务的粒度向更细的粒度裂变，而业务成熟稳定后，又推进服务向粗粒度方向聚合。

流程支持：服务编排 VS SOP

实践证实，业务能力输出的内容主要是核心业务数据和业务流程。而在我上面定义的复用级别上，业务流程的复用处在 LV4，也是比较高阶的复用能力。

云栖大会的朋友聚会上，我一个实践中台的同窗谈到中台服务如何更加灵活的支撑前台时谈到服务的编排。

他们的作法是给前台同事提供了一套服务编排的工具，而后发布一系列的原子性的服务，由各前台团队按照本身流程去编排适合本身的逻辑流程。

我不反对服务编排，并且在 SOA 和微服务的架构下，服务编排是必不可少的能力。可是我不承认给前台提供编排工具，而中台只提供原子性服务。

由于咱们在中台的建设中，一直说起的是中台必定是业务相关性的，中台输出的不只仅是工具，更要深刻到具体的业务场景中，提供业务流程的优秀实践。

阿里的朋友在讨论这个问题时提到了 SOP(Standard Operation Procedure)的概念，他认为最好的作法是提供一套标准化的流程+预留可动态注入的扩展点的方式来对前台提供。

好比淘宝和天猫在业务上能够共享一套 SOP，在这套 SOP 的扩展点上各自注入本身不一样的规则，从而知足本身的需求。

从中台的复用范围来看，我特别认同这种方式，由于中台只有提供 SOP，才是真正的实现业务流程这种高阶的复用(就像国外 ERP 宣扬的那样，你购买的不仅是一套系统，还有企业管理到优秀实践)。

固然若是要作到 SOP 的定义，中台团队必须有既精通业务又熟悉技术的人，咱们俗称“业务架构师”，不过水平高的人实在可遇不可求啊。从这点我也理解把工具开放给前台本身作服务编排的同窗了。

虽然我一直在强调中台要深刻业务，要提炼 SOP，但中台又不能过分参与业务，不能由于中台掣肘了业务的敏捷性。

中台提供的能力要具备灵活性和可定制性，便于业务方根据规范自主完成，减小沟通成本，提高效率。

因此服务编排做为工具仍是须要提供，前期经过工具快速尝试探索合适的业务流程，后期经过业务的优秀实践造成 SOP。

服务编排快速创新，SOP 稳定复用

前后顺序：先业务中台 VS 先数据中台

虽然各类中台不少，可是真正和业务保持密切协同的是业务中台和数据中台，阿里巴巴的中台核心也是这双中台驱动的，这里面体现的核心就是一切业务数据化，一切数据业务化，业务产生数据，数据又赋能业务。

业务中台和数据中台双驱动

在和某 Gartner 分析师交流的时候，他的观点是先有业务中台，再有数据中台。

虽然咱们也是从业务中台开始，但我我的并非特别承认这个观点的，我更承认的是先业务后数据，可是对于哪一个中台先开始，彻底要看各企业的自身状况。

若是企业当前最迫切的诉求是避免重复造轮子，提高 IT 生产力，数据基础相对较好或者数据量级不够，建议业务中台先行。

若是企业当前最迫切的诉求是系统繁多但孤岛严重急须要打通，企业已经存在大量的数据急须要在业务上发挥价值，建议数据中台先行。

具备自主技术研发团队特色的科技企业更适合先业务中台，而自主开发能力较弱，应用系统更多依赖第三方外采的偏传统企业，可能更适合数据中台先行。

中台团队：委员会 VS 许愿池

中台的建设是一把手工程，没有自上而下的推进，中台是很难落地的。因此中台变革的第一步就是组织架构的调整，须要创建一个中台团队来负责组织、协调和建设。

中台组织的创建

如何对中台团队定位也是一个难题，在我所见所经历的中台组织中，常常出现两种形态：

第一种是委员会。中台团队是由各业务线选派的同事组成的虚拟组织，其中大部分都是领导，更多的承担组织、协调的角色，具体执行工做分散在原有的各个部门里，这种可称为委员会似的中台。

由于各部门的领导组成，相互之间增强了信息共享，也逐步有了复用的意识，但在企业 IT 建设这个环节，由于没有具体的专一于共享业务的执行团队，协做成本会增高、实际产出可能比较务虚，看着热闹，其实很难体现复用的价值。

第二种是许愿池。中台只是普通的共享研发部门，前台直接把需求丢到这个许愿池里，而后期盼着中台提供一个现成的组件、服务，中台成了为前台打工的了。

累不用说还不讨好，阿里早期的共享业务事业部估计就是这种窘境，没有业务话语权。

中台团队既不该该是委员会也不应是许愿池，中台不只能组织、能引领，又必需要有实际的产出。

中台须要前台滋养，前台更须要中台赋能，中台团队只有成为具备核心话语权的实体团队，企业能力的复用才能最大化的发挥出来。

因此阿里巴巴让其 CTO 行癫张建峰挂帅推动中台战略，才有了今天阿里中台的影响力。

中台和前台要相互赋能

其实中台建设过程当中碰到的问题远不止这些，须要咱们在实践中去探索正确的解题方法。

中台成功的行为准则和行动纲领

最后引用《中台战略》书中的内容结束本文，但愿践行中台的同仁都能马到成功。

参考资料：

《中台战略：中台建设及数字商业》 陈新宇等 机械工业出版社

《MASA 架构》 Gartner 分析报告

做者：谭明智

简介：经历技术、产品、运营等多个领域，如今负责百洋智能科技产品研发。喜欢并擅长作 IT 架构和产品架构，微信公众号：菜根乱谭，欢迎关注，聊产品，聊技术。