本文将例举典型的需要建设中台的场景，供参考判断要不要建中台。建设中台需要考虑组织、技术支撑和方法论，往往还需要咨询服务的帮助，本文也可以作为思考中台建设的大框架。
要不要建设中台？
要建设中台，首先要考虑要不要建设中台。话说的这么绕是因为现在有很多不明就理就想建中台的。这个问题先做个初略的判断。
业务中台的典型场景
对业务中台来说，比较符合的场景主要有：
此外还有以下场景可能不需要建设完整的中台，但适合落地与中台相关的微服务技术的：
数据中台的典型场景
对数据中台来说，比较符合的场景主要是数据产品比较多，每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。比如电商就是典型。如果这些数据产品和运营人员还在多个团队，那基本上数据中台没跑了。如果经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题，那基本上数据中台也没跑了。
并不是数据量大就需要建中台，主要还是看用数据的姿势是不是比较复杂，当前问题是不是比较多。对于这类符合的业务，数据中台能把层层数据直到最上层的指标梳理清楚，提升数据质量，从而提升运营效率。把数据理清楚了，往往还能降低数据存储和数据开发人员的成本。
除了上述判断，还有一条是同行对比。如果一个行业大家都有点跃跃欲试想弄中台，那领先者一定要想办法抢先（既然是领先者了，往往也符合上述标准），不然就可能被颠覆。跟随者要不要想办法抢先从而超越领先者呢？可能不好说吧，但如果领先者已经建了，跟随者一般得紧跟，否则真可能被甩开了。
如果根据上述逻辑觉得大致要考虑去搞一把中台的话，那请继续读本文以下内容，读完本文后续内容然后更具体的看看问题存不存在，条件是否具备。要建设中台，需要考虑组织、支撑技术、方法论这三个方面，往往还需要咨询服务。
中台组织
中台作为一种有业务属性的共性能力，首先就需要一个懂业务、承担业务职责的专职的组织机构来负责。要不要建中台，首先要看领导有没有魄力去整合建立一个中台组织。因为原来的平台部通常不懂业务，懂业务的人各自分散在前台业务部门，所以建立中台组织往往涉及人员、组织架构和部门职责的调整。正因为如此，中台的建设往往需要作为一把手工程才能成功。
中台组织关键要懂业务和承担业务职责。举个例子，一个大数据平台的建设运维团队不是一个中台组织。一个团队如果做了非常完善的中台产品（如开发了数据中台所需要的指标管理系统、数据仓库开发系统、数据质量管理系统等等），但只是把产品提供给业务方使用，这个团队仍然不能说是中台组织。只有当这个团队承担起指标体系的建设和管理、数据仓库的设计和实施、数据质量的保障等工作时，才可以说是中台组织。而要做到这一点，这个组织肯定是比较了解业务的，它的目标和考核也一定与业务有相关性（肯定不只是平台稳定性这样的非业务指标）。
中台组织的层次与中台的层次最好是对应的，BU 级的中台组织最好直接向 BU 老大或分管的 CXO 汇报，企业的中台组织最好直接向 CEO 或分管的 CXO 汇报。
这里特别说明一点的是如果不建设在线业务中台，而只是采用微服务、云原生等技术的话，可以不涉及组织方面的大规模变动，就在原来的研发部实现转型。通常来说也可以实现一定的系统可用率、弹性和研发效率方面的提升。
中台建设的支撑技术
建设中台一般需要一套支撑技术。
在线业务中台支撑技术
建设在线业务中台一般需要云原生、DevOps、微服务技术体系的支撑，这是因为：
微服务技术：中台是一个独立的组织负责并为多个前台业务服务，因此需要一个标准的服务接口、成熟的服务治理能力和高效的敏捷研发技术。在当前的技术环境下，采用地球人都熟悉的 REST 风格的同步 API、消息队列异步通信作为标准的服务接口技术，采用服务框架（如 Spring Cloud 等）、API 网关、APM 等作为标准的服务治理和敏捷研发技术是最合适的选择。不再建议采用传统的基于 ESB 的服务化（SOA）技术，因为 ESB 产品过多的介入到业务逻辑中，导致前台业务的变更往往需要中台团队的配合才能完成，这样就失去了建设好中台，支撑前台高效创新的意义。此外，中心化的 ESB 软件和复杂的基于 XML 的 WS-xxx 等协议也影响到系统的可用性和性能。可以参见 Martin Fowler 在 P of EAA 中的评价，Web Services 是应用集成而非应用开发的技术。
DevOps 技术：如果不通过 DevOps 使得各微服务都能自助式的部署更新，则微服务带来的敏捷性就无从发挥，反而因为服务数量的增加导致研发效率的下降，因此持续集成、持续发布等 DevOps 技术一般是实现微服务的必备。
云原生技术：微服务和 DevOps 要求底层的基础设施是灵活可编程的，否则根据 Amdahl 定律，只要有一个必须的环节是低效的，整体的效能也提不上去。需要强调的是中台要敏捷，这一方面是因为中台具备业务属性，且支撑了非常丰富的前台业务，前台业务的敏捷性要求有一部分就会传导的中台层；另一方面是中台的重要性使得其需要持续不断的优化，即便对外提供的服务不变，内部实现也会经常变。
分布式事务技术：实施微服务拆分后，复杂的业务流程不再能通过数据库的事务机制来实现 ACID 特性，为此还需要服务层面的分布式事务处理技术。典型的分布式事务处理模型包括 TCC、Saga、FMT 等。其中 TCC 和 Saga 需要各服务实现定制化回滚逻辑，侵入性比较严重，用起来门槛比较高。FMT 模式对于 Java 可以做到加一行注解（如 @GlobalTransaction）即可实现分布式事务，剩下的由框架自动处理，用起来方便的多。Saga 模式是 Princeton 的两位研究者在 1987 年提出的，灵活性和并发度最好，但需要通过语义锁等精细的设计才能发挥出来。
由此可见，在线业务中台的技术支撑体系是相当复杂的，所幸的是 Netflix、Google 等世界领先的互联网企业由于自身业务需要打造了很多实用的技术模块，开源社区也贡献了不少力量，CNCF 组织又做了很好的汇集和标准化。通过将相关技术加以整合，已经有了不错的产品可用，如网易轻舟微服务就是一套产品化设计良好、功能丰富的在线业务中台支撑技术产品。
一般而言，前台也会和在线业务中台一样采用云原生等同样的技术体系，这是因为前台更需要敏捷性。在完善的中台支撑之下，前台会比较轻，还可以考虑采用 FaaS Serverless 技术，不过目前这方面的实践还不多（特别在中国），相关的支撑技术也不是很成熟。
数据中台支撑技术
建设数据中台一般需要一整套如下典型的支撑技术：
指标管理系统：指标是中台与前台之间最关键的接口，也是建设数据中台的牛鼻子，因为它是最核心的业务语言，且指标不一致、数据常出错是建设数据中台最常见的出发点。如果指标体系没有统一的方法论，进行统一建设，那么就很难说是数据中台。指标管理系统一般要实现一套一致的方法论（如原子 / 派生 / 复合指标、维度、修饰词等），做好指标的业务和技术口径管理，还需要支持指标的审批管理。数据中台的指标无法交给各前台业务自助式的建设。
数据服务系统：类似于在线业务中台需要通过 API 网关提供标准化的服务，数据中台也需要一个标准化的服务方式，通常称为数据服务系统，也可以说是数据网关或数据门户。类似于别的网关类产品，数据服务系统需要提供鉴权、日志审计、流控、协议转换（如 SQL Dialect 之间的转换）等功能，也应该发展多引擎融合查询、逻辑模型等扩展功能以提高服务接口的稳定性和实现的灵活性。
元数据管理系统：元数据管理是整个数据中台的基础和中心，所有的其他系统都依赖元数据管理。元数据管理首先要做好的当然是数据模式或目录（catalog）的管理，至少要知道中台里都有什么数据。对复杂的数据中台来说，数据血缘也很重要。没有血缘信息，不知道数据间的依赖关系，数据质量肯定管不好，因为不知道一个数据的质量问题怎么来，又进而会影响什么。同样的如果没有血缘，数据资产也肯定管不好，因为不知道什么数据有价值什么没价值，这就像如果你不知道一个函数被谁调用，你就不知道它是不是死代码一样。元数据管理系统往往也需要提供一个基础的访问界面，通常称之为数据地图。
数据仓库开发与管理系统：除了指标管理，数据仓库的开发是将一大堆初始数据建设梳理成一个漂亮的数据中台的核心过程。一般来讲数据中台更适合用 Kimball 的维度建模方法而非数据仓库之父 Bill Inmon 所提倡的方法，这是因为 Inmon 强调顶层设计，而 Kimball 强调至下而上。如果要建设数据中台，肯定是因为前台业务复杂多变，这时强调顶层设计会导致中台建设缓慢、僵化。因为中台虽然应该是由组织高层决策，但目的却是为了支持前台业务，而不是为了控制。支持而不是控制，这一点绝不能本末倒置。
数据质量管理系统：所有复杂的系统都需要专业的质量管理，在线业务系统有一系列的弹力设计和 APM 等监控运维工具，数据中台也需要专业的质量管理。数据质量管理系统通常设计为支持丰富的稽核 / 校验 / 比对规则，监控数据是否准确、实时、一致，还要做到及时的报警，分析影响面，提供快速修复的手段等。但这些手段只能发现和补救问题，不能预防问题，要预防问题，还要通过测试工具减少代码 bug、通过资源弹性应对性能波动、通过优先级调度优先满足重要业务需求等。相对来说，当前数据中台领域的质量管理没有在线业务领域的成熟，如在线业务领域的测试手段远比数据领域的精细，在线业务领域很常见的熔断、限流、服务降级等模式在数据领域都没有成熟的实践方法（优先级调度可以说是实现了部分的服务降级功能），随着数据中台越来越广泛和重要，这些技术应该也需要持续发展，但技术上的挑战不小。
数据安全管理系统：数据中台因为汇集了组织所有有价值的数据资产，因此良好的安全管理是必须的。细粒度的权限和审计是基础，一般的还需要隐私 / 敏感数据的脱敏处理、数据加密（特别是将数据托管在第三方平台之上时）、数据泄漏防护（比方说一种常见的方法是限制将数据下载到本地的数据量）等技术。发展到高级阶段甚至可能还需要联邦学习、数据沙盒等技术。
数据资产管理系统：在数据质量和安全单列的情况下，数据资产管理主要负责的是数据的生命周期管理、成本的统计分析与优化等工作。
同时，数据中台还需要强大的大数据计算引擎、数据集成 / 同步 / 交换引擎，还往往需要一套敏捷 BI 系统：
大数据计算引擎：数据中台要管理的数据规模和复杂度往往都很高（否则搞中台属于为赋新词强说愁），所以传统的数据库和数据仓库基本上支撑不了。当前的技术环境下，基于 Hadoop MapReduce 或 Spark 几乎是唯二的选择，当然这也包括了这两者之上的 Hive 和 Spark SQL。能用 SQL 就用 SQL，易于维护，也易于数据血缘的收集。除此之外，流处理可能还需要 Flink，交互式查询可能要引入 Impala 或 GreenPlum。
数据集成 / 同步 / 交换引擎：一方面数据中台需要强大的数据集成和同步能力才能吸纳各方数据。集成和同步的概念相近，同步更强调实时性。另一方面，数据中台往往由多种数据计算引擎构成，就需要同步或交换引擎实现不同引擎见的数据交换。
敏捷 BI 系统：建设数据中台通常最重要的目的是为了支持业务运营和决策，为此需要基于数据中台进一步开发数据产品。敏捷 BI 系统是开发数据产品快速、轻型的手段，能够尽快尽早的发挥数据中台的价值。
此外，对于互联网业务，统一的埋点引擎往往也是数据中台所需要的。如果埋点的逻辑都不统一的话，建数据中台的时候会发现数据的源头就是乱的，后续也都没法做。其他行业业务，数据采集也属于基础工作，也是要先做好的。
由此可见，建设数据中台需要的技术支撑体系也是相当的庞大，复杂。所幸的是这十年来 Google 等领先的企业、Hadoop / Spark 等开源社区以及大量的厂商大致联合探索出了一条可行的路径，方法论和技术路线都比较统一了。以此为基础，就可以提供较成熟的数据中台技术支撑产品，如网易杭研研发的“网易猛犸 V6.0 + 网易有数”就是一套较完整的数据中台产品。
中台建设的方法论
复杂事务都需要方法论的指导（和约束），组织管理有虚虚实实的一大套各种理论，研发有敏捷方法或 IPD 流程，中台是复杂事务，所以也需要方法论。因为中台建设涉及组织和技术两个维度，所以中台的方法论也应该要覆盖这两个维度。目前而言，技术维度的方法论相对成熟，因为复用了很多原有的方法论。
在线业务中台方法论
对于业务中台，微服务、网关、REST API 及语义化版本控制、六边形架构是侧重于技术架构的方法论，DevOps、敏捷项目管理是侧重于流程层面的方法论，领域驱动设计（DDD）是侧重于业务架构的方法论。要做好业务中台，以上方法论大概都不可或缺。
大家可以看到，除了微服务跟中台大致是同步发展的之外，其他方法论都是早前就存在的东西。正因为有这么多合适的方法论存在，中台才变得可行，无论如何在短期内要发展出这么多方法论是不现实的，因为方法论的威力不仅在于它要好，还在于它要流行。
技术架构和流程方面的方法论已经很流行，无需多说（六边形架构放在和 DDD 一起介绍）。值得关注的是领域驱动设计这么一个 10 多年前就被提出，这么多年一直不温不火的方法论，突然在中台领域似乎找到了它的最佳安身之所。这样的现象是会昙花一现，还是会长期持续，值得思考。
DDD 的核心概念是通用语言和限界上下文。通用语言指的是在一个业务领域内通用（但不是在更大的领域内也完全通用的）的概念、术语等语言，限界上下文指的是相邻通用语言之间“翻译”的边界，比如前台业务的用户可能要变成后台清算的客户。
我觉得 DDD 的通用语言和一直以来的领域建模是比较相似的，更具创新意义的是限界上下文。在架构设计中，我们要不要构造那种拥有非常多属性，但每个使用者只使用少量属性，或者属性的名称和含义对使用者来说不贴切的对象？如果没有限界上下文的约束，可能会认为这样毕竟实现了更多的复用，是好的，但用限界上下文的理念来看，这样很可能是不好的。每个领域应该专注于自己领域的语言，领域之间要交互怎么办？加一种翻译机制，也就是限界上下文解决。
领域驱动和限界上下文的理念会自然延伸出六边形架构的设计。所谓六边形架构指的是一个程序的内部只需要处理业务逻辑，他的数据 / 请求从哪里来，数据要存储到哪里去（或者领域事件要发布），都通过各种适配器完成。因为这样的适配器可能较多，就不再像传统的三层（三明治）架构。不过如果六边形只有一个 Input 和一个 Output 适配器的话，和三层架构就还是差不多的。我想从三层架构进化到六边形架构的主要原因还是因为现在的环境已经从传统的 C / S 或 B / S 这样只有一个前端，也只有 RDBMS 这样的一个后端发展到前面有 Web / 移动等多个端，向后也有 RDBMS / NoSQL 等多个端，横向也有服务化 / MQ 等多个端的多端环境。我不知道哪天会不会发展出一个十面埋伏架构出来。
数据中台方法论
数据中台的方法论也是博采众长，最核心的来自于数据仓库领域关于数据仓库规划实施和指标体系建设的方法。在数据仓库领域，有两套截然不同的方法之前一直是较劲的，一个是数据仓库之父 Bill Inmon 所倡导的至上而下的方法，另一个是另一位大师级人物 Kimball 所倡导的至下而上的方法。在我理解，所谓 Kimball 的模式之所以说是至下而上，是因为基本上中台团队只负责从 ODS 到 DWD 到 DWS 就完了，往上就是所谓的 ADS，其实已经是面向各个业务（或者数据产品）了。你都可以说 ADS 层不属于数仓。这样的方法在中台作为一种新生事务没法有很强的话语权时显然是更容易做出的选择，可能未来中台概念深入人心，集团高度重视，说不定 Inmon 方法又会重新流行？但也可以思考这种细节上都体现了领导的管理意志的中台还是中台吗。指标设计的方法论基于 Kimball 方法中的粒度建模的方法，做了比较大的细化和改进。
划分主题域是建数据中台的常见实践，不过主题域划分与行业强相关，比如对零售业常见的有商品、交易、流量、用户、营销等域。
数据中台统一通过数据服务系统实现 OneService 的设计，不清楚有什么来源，不过类似于在业务架构中很常见的网关模式。数据质量、数据安全、元数据、生命周期管理也都是数据治理领域比较常见的概念，但一方面要实现针对大数据技术环境的落地，另一方面更面向业务支持而非管控来设计。
实施数据中台通常还需要制定很多规范或标准，这也可以说是方法论的一方面。有很多规范是命名规范，其中数量最大的往往是数据仓库中的表，上万张表甚至更多都是很常见的，所以表的规范命名非常必要。一种好的表的命名规范，要反映其所在数仓分层、主题域、业务过程、时间周期等信息。计算任务也需要一定的命名规范。数据埋点也需要规范性的编码位置信息、内容信息和事件信息。
组织维度的方法论及其他业
其他类型的中台也都有各自的方法论。如搜索中台，B 公司有比较详细的对外分享的资料，其方法论主要体现在规范了搜索系统的关键流程，如内容引入和加工、离线训练、在线召回和排序等，还会涉及到查询改写、展示设计等要点。
以上说的都是中台技术维度的方法论，组织维度的方法论目前还没有看到好的系统性分析成果。在《企业 IT 架构转型之道》中只有很少的篇幅介绍中台组织维度的方法论，在另一本讲数据中台的书中，干脆就只字没提组织方面的内容。业界关于中台组织的方法论，主要包括多职能小微团队、业务架构师主导、协作沟通机制、轮岗、共建、考核机制等。业界也有从一般性的组织管理维度（如垂直型组织、矩阵型组织等等）分析，过于宽泛，说了等于没说。
中台组织层面的方法论可能是相对不成熟的，比如中台和前台、平台之间的边界和动向问题，似乎没有明确的方法。我认为可能主流会符合“前台 -> 中台 -> 平台“单向流动的中心法则。可能中台组织的终极目标是发展为平台，因为还是要追求把能力做成熟和标准，我这也可能是很反动的说法。
作为集团的创新业务孵化中心，网易杭研每时每刻都针对很多业务线要并行发展，为此打造了一个又一个共享能力中心，千方百计提升创新效率。12 年来感觉摸索了一些关于中台的建设经验，当然可能更多的是教训，这段经历的体会后续我将会做个梳理，发出来供大家讨论。
中台建设的咨询服务
说到咨询，我首先想到的是技术进步的驱动力发生了很大的变化，从厂商和咨询公司驱动变成了领先客户驱动。以在线业务为例，传统的 SOA 和 Web Services 技术是传统厂商驱动的。这些厂商自己不用产品但要卖产品，所以一不小心就把产品搞的不必要的复杂。另外这些厂商和咨询公司本来就是共生共荣的关系，所以也得把产品搞的复杂一点吧，不然咨询公司就没生意了。新生代的微服务技术主要是领先的互联网企业驱动的，自己造产品自己用，能简单一点就简单一点，最好是做成各个业务部门自己就能用。
所以新生代的中台技术是尽力将咨询的必要性尽量降低的，但是因为当前实践中台的都是很大的互联网企业，业务复杂度不可避免的很高，对于大多数想要实践中台的非互联网企业来说，仍然是需要咨询服务。
现状是，当前中台的咨询非常欠缺。因为这些中台都是互联网企业搞的，当前的厂商和咨询公司都没什么能力做这块的咨询。我们可以看到一些咨询公司，不懂中台，把什么都往中台的概念上凑。当前也就互联网企业或有很强互联网企业背景的团队才有能力做咨询，但资源很有限。希望咨询公司们能够聚焦于真正的中台，透彻理解什么是中台，提升自己的咨询能力。
CIO之家 www.ciozj.com 公众号:imciow