从技术角度杂说一下：中台

原文：https://www.ealearning.cn/6107.html

国内两大电商企业，一个企业的平台技术部门和我说要学企业架构，特别是业务架构。另一个企业的技术学院说公司要转向基于组件开发的模式，希望我对他们JAVA人员培训体系提建议，特别是组件开发这一块。这都和中台这个词有关，今天我结合敏捷开发、企业架构、软件工程等视角来简单说说中台……

中台战略

15年阿里巴巴集团CEO张勇宣布正式启动2018年中台战略，打造“大中台、小前台”的组织机制和业务机制，由树状管理变为网状管理，实现管理模式创新：作为前台的一线业务会更敏捷，更快速适应瞬息万变的市场；中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。由此，推动集团电商零售平台的全面改革升级，实现云计算、阿里妈妈、菜鸟等新兴业务的全面独立发展。

从战略上来说，“中台战略”提出后，阿里巴巴实际上已经开始由一家商业公司开始向社会型公司转变升级，通过阿里巴巴各大平台，为社会各个行业发挥出更大的作用。京东之后也提出“未来十二年只有技术”，也是希望转型为技术型企业，这也会带来组织的改变。

团队扩展策略

战略就不多说，我今天基于自己的经验从技术角度来说说关于中台的事。中台解决的问题是什么？是什么萌生了中台？我想先从敏捷开发角度来谈。

敏捷里会谈到一个话题，即随着工作范围越来越大，仅靠一个团队搞不定的时候，如何进行组织扩展的问题？

我们会有多种团队扩展策略，例如基于岗位职能、基于位置、架构分层、基于组件或基于特性等

这几种策略中，核心是两种：基于组件和基于特性，所以我们来说说这两种扩展策略好。

有的人可能会说，每个人都知道基于特性扩展好。而有的人会说，基于组件能提升概念集成和重用。其实，我们不能基于简单认知教条的认定哪一种最好。而应该从一些经济要素去分析，这些要素可能包括浪费、循环周期、可见性、有效性、重用等。等认真分析完之后，你会发现，其实两种各有利弊。

好处就不说了，我们简单罗列几个问题，例如基于组件的问题：

基于特性的问题：

综合考虑，大家发现，还是组合起来扩展更好，于是就有了这样的组织

我去培训过的几个企业都是这样的组织，有企业平台组和业务产品线组，只是应用敏捷程度不一样和具体对这种方式下如何开展成熟度不一样。但这是另一个话题，我们今天就不展开说了。

中台的自然形成驱动力是复用

做的事情大了，组织自然就要变了，结果自然而然就变成这样了，所以说什么中台战略这有时也是自发到一定程度后才蹦出来的。就像我以前公司，很多产品都基于图形开发，公司发现每个团队自己干不行啊，除了浪费之外，还有就是底层不是什么人都能干的，所以就弄了个图形平台。慢慢的公司所有和图形相关的产品都不开发底层了，直接复用就可以了，而且保证质量和速度。慢慢的，随着现在大家对商业思考的转变，发现开放出去提供给其他人使用更好啊，于是就把技术放出去，就出现了BIMFACE，给建筑领域的软件开发者提供BIM应用开发平台。

中台和架构

上面从敏捷组织扩展角度说了一下中台出现的必然性，现在从企业架构角度来谈谈。

大家知道现在提出中台概念的人之前也都是干内部系统的，而企业架构出现的起源就是企业内部信息化规划，而中台上升为战略，自然和企业架构也是比较容易扯上关系的。企业架构的文章我也写了很多，简单的说它分为几个不同架构层次：战略架构、业务架构和IT架构。IT架构又分为数据架构、应用架构和技术架构。技术架构是中台概念提出者一开始的优势所在，但一开始也都很苦逼的，因为技术牛不代表你当时有地位。从企业信息化发展阶段来看，IT人一开始地位都不高，业务人员占绝对主导地位。

随着企业内部市场机遇，IT人可能找到一个砝码，有机会让业务人员真正和他们协作。这个协作就来自集成的需求，而集成也是企业架构中应用架构的话题。虽然有了技术架构的基础，但这更看重应用架构的水平，所以能提出中台并实践也是需要较大的能力提升。 可能很多人不知道广联达，但是在建筑行业里也算老大了，我们公司的产品遍布各个层级，涉及的人员也非常广

我在公司最早做的是一个项目成本管理软件，模块就有好几百个，一个规则文档有时就要理解半天。最早我们设计应用的时候，都是想做一个大而全的系统，慢慢的我们发现这样对于软件本身并不是很好，经过好多年的工作经验和思考，我们慢慢的转变为了分层去设计。

大而全的去做应用架构已经不适合现在的企业发展需求，而基于企业架构规划基础之上，去做小而精的应用是一个更好的办法。只是这要求我们提升我们复用的能力，这个在后面讲软件工程时我再和大家分享。很多做企业架构的人都有一个体会，往往是现在IT系统实在整不动了，被逼无奈想办法去改善一下。于是开始从技术架构网上，开始探寻是否数据架构和应用架构能帮助自己。

如果有方法，幸运的话能看到成绩。成绩出来了，IT人员或者公司其他领导自然有更多想法了，能不能再发挥大一点的价值。于是自然就上升到了企业架构的业务架构和战略架构层次。

这是一种典型的自发由下而上的演化过程，如果幸运的话，一帮想做事的人在一起就慢慢的开始形成了以IT架构来适应甚至驱动业务开发的方式，这其实也是企业架构的思路。在2011年中国软件技术大会我做了一个【产品架构开发方法】的主题演讲，其实就是借鉴企业架构思路去开发产品。

软件工程中的复用

上面我们谈了敏捷和企业架构的话题，这两个话题要到落地其实在不同阶段的时候都会涉及到软件工程的话题，所以我们最后从软件工程角度来谈谈中台。前面我讲到中台的提出其实是一种复用的需求，而关于复用的解决方案有很多，我们按时间分类可以简单罗列如下，

大家可以看到，现在大家经常提到的微服务其实本质上和2000年提出的服务是一样的，以前提的多的是SOA。服务划分属于应用架构，服务实现属于技术架构，但是说到软件工程，我们还是要提到服务之后出现的产品线工程。模型驱动就不多了，想了解的可以找一下我2012年做的一个【规模化产品开发探讨】的演讲讲义，我们接下来主要说说产品工程线的话题。

简单的说，产品线工程主要氛围两个阶段，一个开发核心资产，如果是按照本文最开始说的基于组件扩展组织的话，这个核心资产就是可以被其他组织复用的组件。当然，产品线工程里面谈的复用不只是组件。另一个是产品开发，也就是使用核心资产进行业务开发。具体术语我就不说了，大家看下面这张图就行了。

在产品线工程中，我在公司经常谈的是平台两个字。但这个平台和我们现在商业战略上说的平台不是一个概念，而是指技术平台和业务平台。很早的时候我在博客园也写过一些这方面的文章。

如果你对企业也想提出“中台战略”，如果让我给IT人员能力提升提建议的话，那就是要IT人员开始关注业务，开始懂业务。因为你们要做的是业务平台，而不是以前的技术平台了。这是多年前开发的整体架构图，大家可以看到这里除了平台层，还是业务应用层，右边还有工具集。这些组合起来就形成一个规模化研发平台

有了这些基础，那么支持多产品线就容易多了

当然，说起来简单，但是做起来还是很难的，这比推行敏捷还要难很多倍。但是如果你对前台产品少，产品逻辑简单，那么中台就可以不那么复杂，可能敏捷再结合企业架构就可以搞定。如果你的产品线和建筑企业管理一样，产品多、规则复杂，那么软件产品线工程值得去应用。