对产品经理来说，懂中台架构很重要！
很多地方都在说中台，很多公司都在建中台。那么，究竟需不需要中台，怎么建中台？产品经理首先要想清楚。
中台其本质是企业IT架构的一种形式，和传统IT架构的核心区别在于其更加贴合业务架构，是企业IT战略适应业务战略的高阶抽象，业内称之为中台战略。
本文目的不是探讨中台的起源和概念，而是从中台本质、中台目的、中台落地三个角度来谈谈中台。
相信通过此文，可以让大家对中台的理解有一个新的广度和深度。
我们讨论问题，应当从实际出发，而不是从定义出发。——毛泽东
一、中台的本质：回归企业架构
1. 企业架构回顾
简单回顾两点：
- 企业架构分：业务架构、IT架构；
- IT架构分：数据（信息）架构、应用架构、技术架构。
企业架构的核心作用，就是填补了企业业务规划和具体IT建设之间的差距，最终达到企业战略、业务、IT建设的协调统一。最终目的都是支撑企业目标的实现——中台的本质就是回归企业架构。
很多关于中台的书和文章在追溯中台概念时，近则引用美军海豹突击队的架构，远则引用中国古代的三省六部制。
所以，我们可以认为“中台”本身是一个业务组织架构的概念。阿里的中台战略，本身也是因为业务组织架构的中台化调整，促使IT架构升级转型。
所以，中台概念的核心在于业务架构，业务是其灵魂。
2. 中台是IT架构的一种选择
为了支撑业务架构中台化这个战略目标，“中台”是IT架构的一种选择方式。
以阿里的中台为例，其强调 “共享服务体系” ——这是中台的基础。其初心很简单，即为： 服务重用，快速响应和创新。
基于阿里自身的业务发展，其电商的基因使得关于订单、库存、支付等核心业务流程都是相通的。所以，根据这些不同业务部门而又相同的业务诉求，才发展出符合阿里的中台形态。
量变是过程，质变是结果。
阿里中台的架构，是质变的产物。
我们如果想要设计符合自己公司业务的中台，更要学习阿里IT架构演进的过程，这个过程是量变过程。模仿参考的价值，在于根据对过程梳理，总结规律，再根据规律结合自身企业的需求来实践自己的量变过程。
即使“中台”上线后，阿里也强调“服务需要业务的不断滋养”。
因为市场在变、业务在变，要求IT服务必须也跟着变。
——这才是真正的企业架构所要达到的目的。
本节总结
- 中台的本质是回归企业架构，中台是企业IT架构为了适应业务架构的一种有效的解决方案；
- 阿里中台是基于自身业务架构发展需求，逐步摸索迭代，是量变到质变的产物；
- 任何企业做中台，需要从企业架构入手，梳理出业务架构，根据核心业务流程来规划自己的“服务共享体系”。
二、中台的目的：调和不可能三角
1. 中台需要取舍：主要矛盾、次要矛盾
“不可能三角”是金融金域的一个概念。
类似于项目管理中的时间、质量、成本，并非三个不能同时成立，而是说必须有所取舍，最终达到均衡。
如下图，各边必须有所扭曲才能物理存在。
在IT系统架构中也存在不可能三角，Consistency（一致性），Availability（可用性）和Partition Tolerance（分区容错性）。
通俗解释如下：
- 一致性：数据一致、信息一致；
- 可用性：所有请求的在限定时间内有返回；
- 分区容错性：某个分区有故障，依然保证其他服务正常使用。
上述就是2000年由Eric Brewer的提出的CAP定律，初始目的是针对分布式计算机系统的。但是，我们从企业架构层面看IT架构，其本质逻辑是一致的，就是由个体组织成整体，给外部提供统一的服务。
IT架构要兼顾一致性、可用性、容错性的需求，如何实现最优配置是一个关键点。
我们回到不可能三角理论的初始场景-金融场景。在金融系统中的不可能三角是：资本的自由流动、货币完全独立、汇率稳定。
易纲在中国提出了X+Y+M=2理论来指导中国的金融政策。
我们把该思想带入IT架构中可以如下假设：
- X=1表示数据必须完全一致性，x=0表示完全不在乎数据一致性；
- Y=1表示系统必须100%可用，Y=0表示不在乎系统是否可用；
- M=1表示系统必须具有分区容错性，M=0表示不在乎分区容错性。
如果我们按照上述指标给我们的系统打分，极值的X+Y+M=0，X+Y+M=3不可能成立。，而中台的目的就是在于找到X+Y+M=2的一个解。
比如，我们以电商系统的购物车、支付、登录三个场景为例。
（上述评分仅供参考，解释概念之用）
针对各种不同场景对于CAP取舍，按照辩证法的来说就是找到主要矛盾和次要矛盾。
阿里通过中台划分：业务中台、数据中台、技术中台。其中业务中台又分为：账户、会员、商品、交易、订单、支付等。
不同的业务中台都是找到该场景下的CAP最优组合，然后选择不同的技术中台服务来实现。
而数据中台和业务中台的本质区别在于，业务中台产生数据，数据中台加工分析数据。
2. 中台需要优化资源配置
经济学有个研究的方向就是资源配置。
因为资源总是表现出相对的稀缺性，从而要求人们对有限的、相对稀缺的资源进行合理配置，以便用最少的资源耗费，生产出最适用的商品和服务，获取最佳的效益。
所以，人类社会会有各种规则、制度、结构，这些和IT领域是一样的。因为IT资源也是相对有限的、稀缺的，怎么用最小的成本，实现最大的效益是IT架构要解决的问题之一。
笔者几年前就遇到一个情况，公司的一个项目使用的是阿里云的RDS for MySQL。
因为云资源那时刚刚在公司推广，所以预算没有算在项目组内部，导致有个报表的的sql写了N多个join，每次执行变慢都是申请提高配置，后来配置已经到顶了，暴雷了。
IT资源就是有限的和稀缺的，这个不仅仅是指性能，也包括公司投入的资金和精力。所以，只能通过梳理报表取数逻辑，优化数据物理结构和查询逻辑来解决。优化后，MySQL配置砍了2/3 依然反应很快。
其实，中台的价值和上面例子殊途同归——中台就是用有限的资源，通过架构合理的设计，来产生最大的效益。
本节总结
- 中台需要的是均衡，而不是极致。其需要根据具体场景在一致性、可用性、容错性实现取舍；
- 中台需要降本提效。中台目的在于优化资源配置，实现IT架构效益最大化。
三、中台的落地：侵入性和融合性
1. 中台落地的问题
经常看到一句话：中台是个一把手项目。
这句话的本质核心是：一把手更具有对业务架构调整权力。
但是，现在很多企业实施中台容易出现下面几个问题：
- 照搬别的企业中台架构和设计方案；
- 中台作为一个单纯的IT项目实施，强制让其他系统接入；
- 后期规划模糊，项目进入运营阶段，要死不活。
这种照搬的问题，从古至今各个领域数不胜数。
几年前有个很火的词可以形容这个情况，就是“山寨”。照搬说简单点就是抄、借鉴，说深入一点就是理论和实践的结合。
肯定不存在一套可以支撑所有企业需求的方案，因为每个企业的商业模式不同，业务架构也不同。IT架构是支撑业务架构的，肯定是不同的。
比如，阿里的要做统一登录，但是腾讯却硬把QQ和微信登录拆开；阿里需要交易中心，百度肯定不需要交易中心。
这些都是企业业务架构决定的，回到中台的本质，其实业务架构中台化在IT架构的提现。
中台作为一个单纯的IT项目实施，最后上线后推广效果一般来说都是差强人意的。因为中台项目组的成员一心一意都是中台思维，但是对于其他项目（产品）组的人来说，他们需要的可能就是一个简单的服务共享。
当中台的设计对其他现有系统侵入性太强时，不同项目组成员的项目目标是不一样的。中台想着接入，而其他产品组是求稳求快。
一个中心是忠，两个中心是患——不同目标（KPI、OKR）就是不同的中心，最后肯定是差强人意。
中台是一个和战略比较接近的概念，当做一个项目做，在遇到前面两个问题后，肯定会进入内部的迷茫和踌躇。
因为中台需要顶层设计，需要从上到下的一种共识。它不仅要关注企业的各种业务场景，而且还要关注场景背后的本质，场景是快变量，但背后商业本质是慢变量。
中台就是要抓住慢变量来支撑快变量，就像掌握加速度的这个概念来预测未来速度一样。
2. 公司是否真的需要中台
什么样的企业适合做中台？
这个问题反过来就是：公司IT战略下一步怎么走？
很多事情我们总是做不对，后来才发现，其实我们根本就不需要做这个事。这就是南辕北辙、背道而驰。
先问是不是，再问为什么。
做中台也是这样，先回答我们是不是需要中台，再回答我们怎样做中台。
什么时候需要中台，我觉得要回到企业本身商业模式的本质，以及中台的本质。
根据各项比对来看，企业是否需要中台，个人总结中台本质主要是以下三块：
- 服务共享，使得专业部门专注于领域本身；
- 资源配置优化，解决烟囱式重复建设，降本；
- 快速支撑业务，抓住慢变量，提前准备，当业务的快变量来临时可以快速支撑。
所以企业做中台时，也要考虑是否有以上三点诉求，对应的公司业务就是：
- 是否需要强大的服务共享中心；
- 目前有哪些项目是重复建设；
- 公司的业务是否面临市场快速变化的冲击，需要快速调整。
如果用上文中X+Y+M=2的思维方式，也可以把上述三点分别打分。求和后如果结果等于0，那肯定是完全不需要中台；如果是3，那表示不做中台就会死，这个值可以由公司以及顾问评审确定。
3. 中台落地解决之道
在解决了企业要不要做的问题后，进入了怎么落地的问题。
根据个人经验和与业内高手交流，我把步骤分为如下：
- 梳理业务架构，找出相同痛点——做出来；
- 组织中台核心团队，从相关系统或业务单元抽调——用起来；
- 根据公司业务战略，制定中台迭代计划——持续用。
从业务、组织入手，看需要什么样的共享中心，这是第一步。
同时，也要调研企业IT项目重复建设的情况，从业务、技术两方面入手。
比如滴滴打车，他有一个出行中台，根据快车、拼车、优享、出租车等不同场景的需求，他们抽象出乘客、司机、计费、订单、接驾送架等共享中心。滴滴给客户体验可能是一个APP打车服务而已，但是其不同的叫车服务，背后都是独立运营团队，但是打车服务的共性也是很明显的。
团队成员的组成非常重要，因为做中台不仅需要了解中台的概念，更要对现有系统熟悉，不然最后肯定是鸡同鸭讲。
因为就像有人质问的，我一个表加一个API解决的事情，为什么要调用你那么多的服务才能搞定。所以，中台团队里一定要有一些现有产品团队的人，并且是那些对现有产品深入了解和思考的人。
前面两个是解决做出来，用起来的问题。但是，中台是深入贴合企业业务架构变动的，所以“持续用”是中台必须面对的问题。
有些工具性项目，可能就是几个月或者几年的生命周期，但是中台是要和企业共同发展的。
就像阿里说的，需要业务的滋养，然后反过来再促进业务的成长。
对复杂度的控制是设计工作的本质。
系统的目的是实现特定功能来解决问题，而架构的目的是给系统提供一个蓝图，中台架构就是如此。
中台系统持久性的生命力，来源其架构设计的前瞻性，而前瞻性的核心就是找到所服务的业务架构中的慢变量。比如公司的营销策略是快变量，但是其库存是慢变量。
而一切企业业务架构的核心慢变量，就是公司的业务战略。业务战略，也是基于企业对市场趋势的预测和公司现有情况做的目标集合。
下图为作者之前做完中台项目后的第一时间体会总结，功能大家参考.
本文总结
- 中台不是万能的，不是包治百病；它只是根据企业架构的中IT架构的一种选择，其灵魂是业务架构。
- 中台尤其自己的理论基础，成功的中台项目是量变到质变的产物，非一日之功。
- 中台不追求极致，它追求合理、合适，在CAP中找到一个平衡。
- 中台落地，一定要结合企业自身业务架构和需求为基础。
#相关阅读
#专栏作家
侠之大者，微信公众号：侠之大者（ID：xzdzkamil），人人都是产品经理专栏作家。关注互联网金融和企业信息化转型。
本文原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。Tips: Until now, everytime you want to store your article, we will help you store it in Filecoin network. In the future, you can store it in Filecoin network using your own filecoin.
Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: