从软件架构看中台：中台首先是管理方法，其次才是软件方法
近几年IT市场上中台产品的建设情况，应该是可以用“有人辞官归故里，有人星夜赶科场”来形容，各家拆中台、建中台此起彼伏，各路中台好坏的说法甚嚣尘上，这里面有对中台深有研究的专家给出中肯之言，也有只在吹嘘高大上概念的，也有在说中台末路的，信息鱼龙混杂； 这篇文章想搁置争议，我们更多的想去聊一聊中台的背后，在企业软件架构中的位置，中台可能的做法；设计中台之初想解决的是什么问题以及为什么有的落地的好，有的落地的很差，这背后的要点在哪里。同时，帮助非IT的同学也能对中台有基本的了解去更好的用好中台，对一些八股文免疫，无论对方来自所谓的大厂。 这是一张传统电商企业经典的软件架构图，我们以此为案例进行分析： 图1 软件架构图 从最开始的小门小店、软件的MVP到后面各个板块完善的系统，企业的发展过程也是企业软件架构逐步完善的过程，世界上没有最完善的软件架构，只有当前场景下尽量最优和最合适的软件架构： 康威定律：“任何组织在设计系统时，都会倾向于构建出与其自身信息结构相匹配的系统”，即一个组织内部的沟通方式、团队的结构与企业管理文化，是直接影响最终软件系统的架构和设计。 所以笼统的去谈论中台好坏并无意义，因为中台首先是管理方法，其次才是软件方法，我认为更值得客观讨论的是：企业在什么场景下，引入和设计怎么样的中台对企业发展是有利的，什么样的认知是有害的，这篇文章会就此问题进行讨论。 一、中台的适用场景 我们软件传统的开发模式无非是前台+后台，上面的架构图里面的软件系统和整体系统基本都是这么设计的，各个组织和各个系统各司其职对业务进行支持，如果此时： 随着公司业务的发展，公司内部开始开发多条产品线，这多条业务线隶属于多个部门，但它们又有很多通用的模块，对所有共性的业务模块的支持，如何提升效率； 产品服务的某些能力是有可能在多种场景下去复用，需要的是对问题较为完善的解决方案框架； 业务部门增多，但是不同业务部门都会只专注于自己的事情，提的需求也只是局部的，那么问题是，难道局部最优就是整体最优了吗？或者说业务部门此时此刻理解的局部最优，就是真的是符合整体利益的局部最优解吗？ 在直线职能式的组织框架下，很多时候遇到的问题愈发深刻，已经不是单个团队可以解决的时候，我们经常说要去做难而正确的事情，但是在kpi或okr的机制下，很多时候很多组织事实上是在回避那些长期困难的事情，那什么样的组织和软件架构去执行产品运营战略，先行去攻克那些交叉的复杂问题，也得有能力去探索出一条可行的路出来，打造MVP（最小可用版本，宁缺毋滥）和PMF（适配客户，小步迭代）出来？ 信息和数据分散在各个系统，如何打破各个异构系统之间的孤岛，统一数据让数据产生价值？ 需要说明的是，这些问题也是企业发展中遇到的常规性问题，历代管理人员和软件工程师都给出了解决路径，中台只是其中的一种，事先人们不应该过度夸大中台的作用，应以落地结果为导向进行客观评价。中台为解决上面的问题提出了三种形式：产品中台、技术中台和数据中台： 产品中台：产品中台首先应该代表先进生产力，设计和沉淀可复用标准化产品和产品能力，为业务提供完善的问题解决方案或产品能力，坚持长期主义，在效率和核心价值提升上助力业务发展和敏捷创新； 技术中台：将企业通用的底层技术能力，基础设施、工具链、中间件、开发支持平台等抽象和统一管理为可复用的中台服务，为各个业务线提供统一、规范的技术支撑，核心目标是避免重复开发来提升效率、降低系统故障率、通过标准化能力支持产品创新和沉淀技术资产； 数据中台：建立合理的数据管理框架，沉淀数字资产，将企业内部多源异构系统的数据进行采集、整合、治理、建模与服务化，统一管理进行全链路分析。 二、数据中台的本质 在图1的企业架构图我们可以看到，在目前的架构下，企业各个业务系统都在管理自己那一块的数据，多个异构系统之间就必然存在数据孤岛，数据和信息已经被分散在各处，对以上的问题5的数据孤岛问题，为了完成对数据的统一管理，数据中台包含了2个部分： 数据采集：实现基本的数据采集、数据仓库建立和数据分析能力的共享，是将做数据相关工作的技术团队整合，根据顶层设计和业务需要进行统一管理； 数据应用：对各业务线的数据打通、数据共享和协同运用，以实现具体的业务目标为目的，比如企业经营数据分析、用户数据分析等，一般是通过数据仓库的bi分析工具、建立主数据分析平台来实现。 图2 数据建设 通过建立数据仓库（DataWarehouse），解决异构系统统一的数据经营分析问题而存在（所以数据仓库只读不写），在管理上从上而下把统一分析的体系定下来，然后再通过统一的规则，对数据仓库进行写入和存储，然后再根据统一标准进行分析做应用层的呈现。其次，对于一些固定数据的加工逻辑，可以在数据仓库上建立了小的数据仓库即数据集市（Data Mart）来进行交易和映射完成，方便不同的业务对数据进行规范化的处理需求，底层数据源还是一致的； 主数据平台一般是以人或物或某个基础的实体，可以打通各个业务屏障将数据资产统一管理起来，根据需要把全链条必要的客观的数据也放进来进行统一管理和分析，在全局角度根据业务模型统一分析找到规律来辅助决策，主数据特别是用户主数据在对用户数据全链路分析方面极具意义，物料清单主数据对产品生产所需材料及其相关信息的核心数据进行管理，对企业标准化生产、成本核算和供应商物料供应效率都很有意义，读者可以根据产品设计所需进行灵活应用； 建设数据中台是发掘数据价值的基础，在Ai时代，Ai的实时数据分析和推理能力将会进一步放大数据价值，但是基础一定是要先做好数据框架的管理和维护。同时，需要说明的是，在软件行业大家普遍认为数据中台并不是一个新的事物，因为在中台出现之前这些数据工作已经在进行，数据中台到目前并没有很突出的理论贡献出来，不过这也反过来一定程度上也证明了这套数据设计框架自身的先进性。 三、产品中台的本质 产品中台是想从小中台验证价值，通过中台实现杠杆效应，提升效率，撬动业务实现规模化创新，为了实现这个目标，产品中台的建设可以概括为中台向前和中台向后： 中台向前：产品中台向前直面业务，对标核心数据，实现业务需求，打造系统化的完整产品解决方案进行完整的输出，沉淀优质经验，不断迭代； 中台向后：产品中台向后把某些产品能力抽象为更细的通用能力，在更多场景里面接入，对此同类问题提供标准化的解决能力； 图3 产品中台 在企业发展越来越大的时候，在直线职能式的组织框架下，很多时候遇到的问题已经不是单个团队可以解决的了，对以上的问题4，需要去探索出前沿的这些交叉复杂性问题，打造出来产品的MVP版本。中台在这方面具有先天的优势，从以上架构图可以看到，中台日常就会调用后台的各种基础服务，是从全局的角度来看待问题和设计系统，找到最本质的流程去设计，然后承接前台各个业务线的需求，输出通用优质的产品框架和个性化方案，落地即是当前最优解； 中台事实上承担了各个业务支撑器的作用，支撑着多个部门和系统，由中台牵头，以业务的核心数据指标为优化目标，以“小中台大前台”的方式，可以更高效的设计出MVP最小可用版本进行小范围验证，再通过PMF适配客户进行落地，以此来解决复杂交叉的企业问题，同时以此推理，对于新的产品创新这个路径同样具备可行性，中台理论上可以以MVP和PMF为抓手，作为创新中心进行存在，根据顶层战略需要，提前预判业务发展方向，在中台层面探索新的产品方案建设，为业务探索前沿的产品能力建设，主动去解决复杂问题，既能开疆拓土，也能打扫后院。 四、写在最后 在行业来看，无论是阿里、字节、美团、SHEIN等企业内部中台建设，无非也是以上几种，效果也是有好有坏，比如美团以产品中台统一外卖、到店、酒店和旅行等用户体系和交易流程，字节的APP工厂的成绩，也有大厂的中台偏离业务导致总是落后一步。中台首先是管理方法，其次才是软件方法，希望我们的视野更加广阔，兵无常势，水无常形，产品经理的角色必须为始终产品的价值埋单才是唯一正途，回归常识而不是虚名，从最本质的东西出发才是最有力量，希望这篇文章能对你有所启发。 本文由@大风吹 原创发布于人人都是产品经理。未经许可，禁止转载。 题图来自 Unsplash，基于 CC0 协议 该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。提供信息存储空间服务。
近几年IT市场上中台产品的建设情况，应该是可以用“有人辞官归故里，有人星夜赶科场”来形容，各家拆中台、建中台此起彼伏，各路中台好坏的说法甚嚣尘上，这里面有对中台深有研究的专家给出中肯之言，也有只在吹嘘高大上概念的，也有在说中台末路的，信息鱼龙混杂；
这篇文章想搁置争议，我们更多的想去聊一聊中台的背后，在企业软件架构中的位置，中台可能的做法；设计中台之初想解决的是什么问题以及为什么有的落地的好，有的落地的很差，这背后的要点在哪里。同时，帮助非IT的同学也能对中台有基本的了解去更好的用好中台，对一些八股文免疫，无论对方来自所谓的大厂。
这是一张传统电商企业经典的软件架构图，我们以此为案例进行分析：
图1 软件架构图
从最开始的小门小店、软件的MVP到后面各个板块完善的系统，企业的发展过程也是企业软件架构逐步完善的过程，世界上没有最完善的软件架构，只有当前场景下尽量最优和最合适的软件架构：
康威定律：“任何组织在设计系统时，都会倾向于构建出与其自身信息结构相匹配的系统”，即一个组织内部的沟通方式、团队的结构与企业管理文化，是直接影响最终软件系统的架构和设计。
所以笼统的去谈论中台好坏并无意义，因为中台首先是管理方法，其次才是软件方法，我认为更值得客观讨论的是：企业在什么场景下，引入和设计怎么样的中台对企业发展是有利的，什么样的认知是有害的，这篇文章会就此问题进行讨论。
一、中台的适用场景
我们软件传统的开发模式无非是前台+后台，上面的架构图里面的软件系统和整体系统基本都是这么设计的，各个组织和各个系统各司其职对业务进行支持，如果此时：
- 随着公司业务的发展，公司内部开始开发多条产品线，这多条业务线隶属于多个部门，但它们又有很多通用的模块，对所有共性的业务模块的支持，如何提升效率；
- 产品服务的某些能力是有可能在多种场景下去复用，需要的是对问题较为完善的解决方案框架；
- 业务部门增多，但是不同业务部门都会只专注于自己的事情，提的需求也只是局部的，那么问题是，难道局部最优就是整体最优了吗？或者说业务部门此时此刻理解的局部最优，就是真的是符合整体利益的局部最优解吗？
- 在直线职能式的组织框架下，很多时候遇到的问题愈发深刻，已经不是单个团队可以解决的时候，我们经常说要去做难而正确的事情，但是在kpi或okr的机制下，很多时候很多组织事实上是在回避那些长期困难的事情，那什么样的组织和软件架构去执行产品运营战略，先行去攻克那些交叉的复杂问题，也得有能力去探索出一条可行的路出来，打造MVP（最小可用版本，宁缺毋滥）和PMF（适配客户，小步迭代）出来？
- 信息和数据分散在各个系统，如何打破各个异构系统之间的孤岛，统一数据让数据产生价值？
需要说明的是，这些问题也是企业发展中遇到的常规性问题，历代管理人员和软件工程师都给出了解决路径，中台只是其中的一种，事先人们不应该过度夸大中台的作用，应以落地结果为导向进行客观评价。中台为解决上面的问题提出了三种形式：产品中台、技术中台和数据中台：
- 产品中台：产品中台首先应该代表先进生产力，设计和沉淀可复用标准化产品和产品能力，为业务提供完善的问题解决方案或产品能力，坚持长期主义，在效率和核心价值提升上助力业务发展和敏捷创新；
- 技术中台：将企业通用的底层技术能力，基础设施、工具链、中间件、开发支持平台等抽象和统一管理为可复用的中台服务，为各个业务线提供统一、规范的技术支撑，核心目标是避免重复开发来提升效率、降低系统故障率、通过标准化能力支持产品创新和沉淀技术资产；
- 数据中台：建立合理的数据管理框架，沉淀数字资产，将企业内部多源异构系统的数据进行采集、整合、治理、建模与服务化，统一管理进行全链路分析。
二、数据中台的本质
在图1的企业架构图我们可以看到，在目前的架构下，企业各个业务系统都在管理自己那一块的数据，多个异构系统之间就必然存在数据孤岛，数据和信息已经被分散在各处，对以上的问题5的数据孤岛问题，为了完成对数据的统一管理，数据中台包含了2个部分：
- 数据采集：实现基本的数据采集、数据仓库建立和数据分析能力的共享，是将做数据相关工作的技术团队整合，根据顶层设计和业务需要进行统一管理；
- 数据应用：对各业务线的数据打通、数据共享和协同运用，以实现具体的业务目标为目的，比如企业经营数据分析、用户数据分析等，一般是通过数据仓库的bi分析工具、建立主数据分析平台来实现。
图2 数据建设
通过建立数据仓库（DataWarehouse），解决异构系统统一的数据经营分析问题而存在（所以数据仓库只读不写），在管理上从上而下把统一分析的体系定下来，然后再通过统一的规则，对数据仓库进行写入和存储，然后再根据统一标准进行分析做应用层的呈现。其次，对于一些固定数据的加工逻辑，可以在数据仓库上建立了小的数据仓库即数据集市（Data Mart）来进行交易和映射完成，方便不同的业务对数据进行规范化的处理需求，底层数据源还是一致的；
主数据平台一般是以人或物或某个基础的实体，可以打通各个业务屏障将数据资产统一管理起来，根据需要把全链条必要的客观的数据也放进来进行统一管理和分析，在全局角度根据业务模型统一分析找到规律来辅助决策，主数据特别是用户主数据在对用户数据全链路分析方面极具意义，物料清单主数据对产品生产所需材料及其相关信息的核心数据进行管理，对企业标准化生产、成本核算和供应商物料供应效率都很有意义，读者可以根据产品设计所需进行灵活应用；
建设数据中台是发掘数据价值的基础，在Ai时代，Ai的实时数据分析和推理能力将会进一步放大数据价值，但是基础一定是要先做好数据框架的管理和维护。同时，需要说明的是，在软件行业大家普遍认为数据中台并不是一个新的事物，因为在中台出现之前这些数据工作已经在进行，数据中台到目前并没有很突出的理论贡献出来，不过这也反过来一定程度上也证明了这套数据设计框架自身的先进性。
三、产品中台的本质
产品中台是想从小中台验证价值，通过中台实现杠杆效应，提升效率，撬动业务实现规模化创新，为了实现这个目标，产品中台的建设可以概括为中台向前和中台向后：
- 中台向前：产品中台向前直面业务，对标核心数据，实现业务需求，打造系统化的完整产品解决方案进行完整的输出，沉淀优质经验，不断迭代；
- 中台向后：产品中台向后把某些产品能力抽象为更细的通用能力，在更多场景里面接入，对此同类问题提供标准化的解决能力；
图3 产品中台
在企业发展越来越大的时候，在直线职能式的组织框架下，很多时候遇到的问题已经不是单个团队可以解决的了，对以上的问题4，需要去探索出前沿的这些交叉复杂性问题，打造出来产品的MVP版本。中台在这方面具有先天的优势，从以上架构图可以看到，中台日常就会调用后台的各种基础服务，是从全局的角度来看待问题和设计系统，找到最本质的流程去设计，然后承接前台各个业务线的需求，输出通用优质的产品框架和个性化方案，落地即是当前最优解；
中台事实上承担了各个业务支撑器的作用，支撑着多个部门和系统，由中台牵头，以业务的核心数据指标为优化目标，以“小中台大前台”的方式，可以更高效的设计出MVP最小可用版本进行小范围验证，再通过PMF适配客户进行落地，以此来解决复杂交叉的企业问题，同时以此推理，对于新的产品创新这个路径同样具备可行性，中台理论上可以以MVP和PMF为抓手，作为创新中心进行存在，根据顶层战略需要，提前预判业务发展方向，在中台层面探索新的产品方案建设，为业务探索前沿的产品能力建设，主动去解决复杂问题，既能开疆拓土，也能打扫后院。
四、写在最后
在行业来看，无论是阿里、字节、美团、SHEIN等企业内部中台建设，无非也是以上几种，效果也是有好有坏，比如美团以产品中台统一外卖、到店、酒店和旅行等用户体系和交易流程，字节的APP工厂的成绩，也有大厂的中台偏离业务导致总是落后一步。中台首先是管理方法，其次才是软件方法，希望我们的视野更加广阔，兵无常势，水无常形，产品经理的角色必须为始终产品的价值埋单才是唯一正途，回归常识而不是虚名，从最本质的东西出发才是最有力量，希望这篇文章能对你有所启发。
本文由@大风吹 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
提供信息存储空间服务。
你的反应是什么？
