如何建设中台？中台建设的组织、支撑技术和方法论

编者按：本文转载自网易副总裁，网易杭州研究院执行院长汪源的个人公众号“冷技术热思考”（欢迎搜索关注）。上一篇中台系列的文章重点阐述了中台的概念，本文是系列文章的第二篇，目的是说明什么情况下可以考虑建设中台，如果要建怎么建的问题，可以作为企业思考中台建设的大框架。以下为原文（有少量改动）：

本文将例举典型的需要建设中台的场景，供参考判断要不要建中台。建设中台需要考虑组织、技术支撑和方法论，往往还需要咨询服务的帮助，本文也可以作为思考中台建设的大框架。

要不要建设中台？

要建设中台，首先要考虑要不要建设中台。话说的这么绕是因为现在有很多不明就理就想建中台的。这个问题先做个初略的判断。
01业务中台的典型场景

对业务中台来说，比较符合的场景主要有：
· 业务系统研发团队至少大几十人（含外包的），需求多变化快，系统又涉及多个领域（比如做ERP、电商的），业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚，提高研发效率。
· 做相似行业的外包项目为主，业务规模也做的比较大的（一年有两位数的项目）。这时业务中台可以提升软件复用，降低定制化成本，提高研发效率。如果你做外包，每个项目都完全不一样，那中台也救不了你。

此外还有以下场景可能不需要建设完整的中台，但适合落地与中台相关的微服务技术的：
·  大规模互联网式在线系统，对稳定性和弹性要求高当前搞不定的。微服务或业务中台可以比较好的解决这些问题。
·  掉到IT竖井的坑里想爬出来的，通过项目外包做的系统无法管理和维护的。微服务或业务中台可以对系统的API、文档等进行有效管理，也能实现系统间的打通。

02数据中台的典型场景

对数据中台来说，比较符合的场景主要是数据产品比较多，每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。比如电商就是典型。如果这些数据产品和运营人员还在多个团队，那基本上数据中台没跑了。如果经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题，那基本上数据中台也没跑了。

并不是数据量大就需要建中台，主要还是看用数据的姿势是不是比较复杂，当前问题是不是比较多。对于这类符合的业务，数据中台能把层层数据直到最上层的指标梳理清楚，提升数据质量，从而提升运营效率。把数据理清楚了，往往还能降低数据存储和数据开发人员的成本。

除了上述判断，还有一条是同行对比。如果一个行业大家都有点跃跃欲试想弄中台，那领先者一定要想办法抢先（既然是领先者了，往往也符合上述标准），不然就可能被颠覆。跟随者要不要想办法抢先从而超越领先者呢？可能不好说吧，但如果领先者已经建了，跟随者一般得紧跟，否则真可能被甩开了。

如果根据上述逻辑觉得大致要考虑去搞一把中台的话，那请继续读本文以下内容，读完本文后续内容然后更具体的看看问题存不存在，条件是否具备。要建设中台，需要考虑组织、支撑技术、方法论这三个方面，往往还需要咨询服务。

中台组织

中台作为一种有业务属性的共性能力，首先就需要一个懂业务、承担业务职责的专职的组织机构来负责。要不要建中台，首先要看领导有没有魄力去整合建立一个中台组织。因为原来的平台部通常不懂业务，懂业务的人各自分散在前台业务部门，所以建立中台组织往往涉及人员、组织架构和部门职责的调整。 正因为如此，中台的建设往往需要作为一把手工程才能成功。

中台组织的层次与中台的层次最好是对应的，BU级的中台组织最好直接向BU老大或分管的CXO汇报，企业的中台组织最好直接向CEO或分管的CXO汇报。

这里特别说明一点的是如果不建设在线业务中台，而只是采用微服务、云原生等技术的话，可以不涉及组织方面的大规模变动，就在原来的研发部实现转型。通常来说也可以实现一定的系统可用率、弹性和研发效率方面的提升。

中台建设的支撑技术

建设中台一般需要一套支撑技术。
这里特别说明一点的是如果不建设在线业务中台，而只是采用微服务、云原生等技术的话，可以不涉及组织方面的大规模变动，就在原来的研发部实现转型。通常来说也可以实现一定的系统可用率、弹性和研发效率方面的提升。

同时，数据中台还需要强大的大数据计算引擎、数据集成 / 同步 / 交换引擎，还往往需要一套敏捷BI系统：
· 大数据计算引擎：数据中台要管理的数据规模和复杂度往往都很高（否则搞中台属于为赋新词强说愁），所以传统的数据库和数据仓库基本上支撑不了。当前的技术环境下，基于hadoop MapReduce或Spark几乎是唯二的选择，当然这也包括了这两者之上的Hive和Spark SQL。能用SQL就用SQL，易于维护，也易于数据血缘的收集。除此之外，流处理可能还需要Flink，交互式查询可能要引入Impala或GreenPlum。
· 数据集成 / 同步 / 交换引擎：一方面数据中台需要强大的数据集成和同步能力才能吸纳各方数据。集成和同步的概念相近，同步更强调实时性。另一方面，数据中台往往由多种数据计算引擎构成，就需要同步或交换引擎实现不同引擎见的数据交换。
· 敏捷BI系统：建设数据中台通常最重要的目的是为了支持业务运营和决策，为此需要基于数据中台进一步开发数据产品。敏捷BI系统是开发数据产品快速、轻型的手段，能够尽快尽早的发挥数据中台的价值。

此外，对于互联网业务，统一的埋点引擎往往也是数据中台所需要的。如果埋点的逻辑都不统一的话，建数据中台的时候会发现数据的源头就是乱的，后续也都没法做。其他行业业务，数据采集也属于基础工作，也是要先做好的。

由此可见，建设数据中台需要的技术支撑体系也是相当的庞大，复杂。所幸的是这十年来Google等领先的企业、Hadoop / Spark等开源社区以及大量的厂商大致联合探索出了一条可行的路径，方法论和技术路线都比较统一了。以此为基础，就可以提供较成熟的数据中台技术支撑产品，如网易杭研研发的“网易猛犸V6.0 + 网易有数”就是一套较完整的数据中台产品。

中台建设的方法论
复杂事务都需要方法论的指导（和约束），组织管理有虚虚实实的一大套各种理论，研发有敏捷方法或IPD流程，中台是复杂事务，所以也需要方法论。因为中台建设涉及组织和技术两个维度，所以中台的方法论也应该要覆盖这两个维度。目前而言，技术维度的方法论相对成熟，因为复用了很多原有的方法论。

01在线业务中台方法论对于业务中台，微服务、网关、REST API及语义化版本控制、六边形架构是侧重于技术架构的方法论，DevOps、敏捷项目管理是侧重于流程层面的方法论，领域驱动设计（DDD）是侧重于业务架构的方法论。


要做好业务中台，以上方法论大概都不可或缺。
大家可以看到，除了微服务跟中台大致是同步发展的之外，其他方法论都是早前就存在的东西。正因为有这么多合适的方法论存在，中台才变得可行，无论如何在短期内要发展出这么多方法论是不现实的，因为方法论的威力不仅在于它要好，还在于它要流行。

技术架构和流程方面的方法论已经很流行，无需多说（六边形架构放在和DDD一起介绍）。值得关注的是领域驱动设计这么一个10多年前就被提出，这么多年一直不温不火的方法论，突然在中台领域似乎找到了它的最佳安身之所。这样的现象是会昙花一现，还是会长期持续，值得思考。

DDD的核心概念是通用语言和限界上下文。通用语言指的是在一个业务领域内通用（但不是在更大的领域内也完全通用的）的概念、术语等语言，限界上下文指的是相邻通用语言之间“翻译”的边界，比如前台业务的用户可能要变成后台清算的客户。

我觉得DDD的通用语言和一直以来的领域建模是比较相似的，更具创新意义的是限界上下文。在架构设计中，我们要不要构造那种拥有非常多属性，但每个使用者只使用少量属性，或者属性的名称和含义对使用者来说不贴切的对象？如果没有限界上下文的约束，可能会认为这样毕竟实现了更多的复用，是好的，但用限界上下文的理念来看，这样很可能是不好的。每个领域应该专注于自己领域的语言，领域之间要交互怎么办？加一种翻译机制，也就是限界上下文解决。

领域驱动和限界上下文的理念会自然延伸出六边形架构的设计。所谓六边形架构指的是一个程序的内部只需要处理业务逻辑，他的数据 / 请求从哪里来，数据要存储到哪里去（或者领域事件要发布），都通过各种适配器完成。因为这样的适配器可能较多，就不再像传统的三层（三明治）架构。不过如果六边形只有一个Input和一个Output适配器的话，和三层架构就还是差不多的。我想从三层架构进化到六边形架构的主要原因还是因为现在的环境已经从传统的C / S或B / S这样只有一个前端，也只有RDBMS这样的一个后端发展到前面有Web / 移动等多个端，向后也有RDBMS / NoSQL等多个端，横向也有服务化 / MQ等多个端的多端环境。我不知道哪天会不会发展出一个十面埋伏架构出来。

02数据中台方法论

数据中台的方法论也是博采众长，最核心的来自于数据仓库领域关于数据仓库规划实施和指标体系建设的方法。在数据仓库领域，有两套截然不同的方法之前一直是较劲的，一个是数据仓库之父Bill Inmon所倡导的自上而下的方法，另一个是另一位大师级人物Kimball所倡导的自下而上的方法。在我理解，所谓Kimball的模式之所以说是自下而上，是因为基本上中台团队只负责从ODS到DWD到DWS就完了，往上就是所谓的ADS，其实已经是面向各个业务（或者数据产品）了。你都可以说ADS层不属于数仓。这样的方法在中台作为一种新生事务没法有很强的话语权时显然是更容易做出的选择，可能未来中台概念深入人心，集团高度重视，说不定Inmon方法又会重新流行？但也可以思考这种细节上都体现了领导的管理意志的中台还是中台吗。指标设计的方法论基于Kimball方法中的粒度建模的方法，做了比较大的细化和改进。

划分主题域是建数据中台的常见实践，不过主题域划分与行业强相关，比如对零售业常见的有商品、交易、流量、用户、营销等域。

数据中台统一通过数据服务系统实现OneService的设计，不清楚有什么来源，不过类似于在业务架构中很常见的网关模式。数据质量、数据安全、元数据、生命周期管理也都是数据治理领域比较常见的概念，但一方面要实现针对大数据技术环境的落地，另一方面更面向业务支持而非管控来设计。

实施数据中台通常还需要制定很多规范或标准，这也可以说是方法论的一方面。有很多规范是命名规范，其中数量最大的往往是数据仓库中的表，上万张表甚至更多都是很常见的，所以表的规范命名非常必要。一种好的表的命名规范，要反映其所在数仓分层、主题域、业务过程、时间周期等信息。计算任务也需要一定的命名规范。数据埋点也需要规范性的编码位置信息、内容信息和事件信息。


03组织维度的方法论及其他业


其他类型的中台也都有各自的方法论。如搜索中台，B公司有比较详细的对外分享的资料，其方法论主要体现在规范了搜索系统的关键流程，如内容引入和加工、离线训练、在线召回和排序等，还会涉及到查询改写、展示设计等要点。

以上说的都是中台技术维度的方法论，组织维度的方法论目前还没有看到好的系统性分析成果。在《企业IT架构转型之道》中只有很少的篇幅介绍中台组织维度的方法论，在另一本讲数据中台的书中，干脆就只字没提组织方面的内容。业界关于中台组织的方法论，主要包括多职能小微团队、业务架构师主导、协作沟通机制、轮岗、共建、考核机制等。业界也有从一般性的组织管理维度（如垂直型组织、矩阵型组织等等）分析，过于宽泛，说了等于没说。

中台组织层面的方法论可能是相对不成熟的，比如中台和前台、平台之间的边界和动向问题，似乎没有明确的方法。我认为可能主流会符合“前台->中台->平台“单向流动的中心法则。可能中台组织的终极目标是发展为平台，因为还是要追求把能力做成熟和标准，我这也可能是很反动的说法。

作为集团的创新业务孵化中心，网易杭研每时每刻都针对很多业务线要并行发展，为此打造了一个又一个共享能力中心，千方百计提升创新效率。12年来感觉摸索了一些关于中台的建设经验，当然可能更多的是教训，这段经历的体会后续我将会做个梳理，发出来供大家讨论。

中台建设的咨询服务


说到咨询，我首先想到的是技术进步的驱动力发生了很大的变化，从厂商和咨询公司驱动变成了领先客户驱动。以在线业务为例，传统的SOA和Web Services技术是传统厂商驱动的。这些厂商自己不用产品但要卖产品，所以一不小心就把产品搞的不必要的复杂。另外这些厂商和咨询公司本来就是共生共荣的关系，所以也得把产品搞的复杂一点吧，不然咨询公司就没生意了。新生代的微服务技术主要是领先的互联网企业驱动的，自己造产品自己用，能简单一点就简单一点，最好是做成各个业务部门自己就能用。

所以新生代的中台技术是尽力将咨询的必要性尽量降低的，但是因为当前实践中台的都是很大的互联网企业，业务复杂度不可避免的很高，对于大多数想要实践中台的非互联网企业来说，仍然是需要咨询服务。

现状是，当前中台的咨询非常欠缺。因为这些中台都是互联网企业搞的，当前的厂商和咨询公司都没什么能力做这块的咨询。我们可以看到一些咨询公司，不懂中台，把什么都往中台的概念上凑。当前也就互联网企业或有很强互联网企业背景的团队才有能力做咨询，但资源很有限。希望咨询公司们能够聚焦于真正的中台，透彻理解什么是中台，提升自己的咨询能力。




作者简介


网易副总裁，网易杭州研究院执行院长 汪源
2006年获浙江大学计算机专业博士学位，之后加入网易公司。现作为网易杭州研究院执行院长，全面负责网易集团公共技术支撑工作与云计算、大数据业务，主要包括云计算与服务端架构、前端技术、大数据挖掘分析、信息安全、多媒体、运维、质量保障等方向。