对产品经理来说懂中台架构很重要

　　很多地方都在说中台，很多公司都在建中台。那么，究竟需不需要中台，怎么建中台？产品经理首先要想清楚。
　　中台其本质是企业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中找到一个平衡。
　　中台落地，一定要结合企业自身业务架构和需求为基础。
　　#相关阅读#
　　《对产品经理来说，懂业务架构很重要！》
　　《对产品经理来说，懂业务很重要！》
　　《对产品经理来说，懂企业架构很重要！》
　　《对产品经理来说，计划管理很重要！》