你真地需要一个中台吗？

如果中台是一个解决方案，那么它要解决的问题是什么？为什么阿里构建的中台取得了成功，而很多传统企业构建和规划中台的过程中会碰到各种问题，本质上有什么不同？

必须承认，中台在国内技术圈子里的火爆程度，已经不亚于当年敏捷和微服务的火爆程度。现在任何一个和技术相关的讨论群中，早晚话题都会转向中台。关于中台大家的定义也各自不同。这半年多以来，我们参与过几个有关中台的讨论和项目合作，在这个过程中我们也不停地在问自己：“这个企业真的需要一个中台吗？”在某一个讨论架构的微信群当中，看到某位前辈提出一个终极问题：“如果中台是一个解决方案，那么它要解决的问题是什么？”

我们曾经想过中台的出现是为了提升企业IT能力的复用率；打通数据壁垒；提升应用的TTM（上市时间）等。但是这些问题的提出，背后又是要解决什么问题？为什么阿里构建的中台取得了成功成为了行业标杆，而在很多传统企业构建中台的规划和建设过程中，总是会遇到这样或那样的问题？阿里和这些企业有什么不同？

问题累积多了，就需要一次系统的梳理。在几次同事以及业界同行的讨论之后，关于中台的形象在我们的脑海中逐渐明晰。对于要不要构建一个中台，以及如何构建一个中台，也有了比较清晰的思路。不如我们就从中台构建的本质和原则谈起。

我们认为企业构建自己的中台，需要遵循三个原则：

1.Strategic Initiative Over Tactic Initiative 战略举措胜于战术举措

首先，当企业在构建自己中台之前，先要确定自己的中台转型能否达到战略举措的高度。所谓战略举措，意味着企业内部（包含业务和技术）一致认为要解决前文提到的三个典型问题（提升IT能力复用率、打通数据壁垒、提升应用TTM）当中的一个或者几个。同时，要对问题的优先级达成重要的共识。问题域及其优先级，决定了企业中台构建原则的不同，以及构建过程中角色和职能分工上的不同。一旦企业确立了中台转型的战略方向，那么企业的业务和技术部分都要遵循这样的战略。

战略目标要有阶段性的定义和检查。如果我们回头看阿里业务中台的案例，我们会发现阿里共享业务事业部的出现，是集团为了应对淘宝和天猫发展需要的战略举措。而在2015年阿里做出的中台战略转型，也同样是一次大刀阔斧的战略转型。这样的转型意味着对于整个企业来说新的组织结构、新的合作方式、新的角色与职责边界的确立。同样，在阿里的案例当中，在聚划算出现之前，由于缺少组织的战略方向引领的时候，“共享业务事业部”的价值和地位同样非常尴尬：构建出来的服务没人用，而前台业务团队所提出的差异化需求都需要在中台承载，导致中台部门工作强度和压力都非常巨大（参见《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》的1.1节）。

相似的，在过去的十几二十年当中，很多业界企业的IT部门都曾经做过的“中台化”化或者“平台化”转型，但如果这一转型过程没有得到组织的战略的支持，没有拉通业务和技术的公司级的决策过程，那么转型就很难将转型拉到战略的高度，很多情况下，即使一个中台或者平台被构建出来，最终都在业务部门的层层压力之下，变得形同虚设，企业架构的转型被迫延迟或搁浅。

2. Business Decision Over Technical Decision 业务决策胜于技术决策

让我们再回到阿里的中台构建之初。首先我们看到，阿里中台的前身：共享业务事业部，是一个业务部门。这一点在企业构建自己的中台的时候，有意或无意的在忽略这一点。阿里和许多传统企业不同，作为一家互联网公司，其最大的特点是“技术即业务”。技术和业务作为有机的整体，技术架构的重构的实质是业务本身的重构。

对于传统企业的分类法来说，最简单的就是把一个组织分为“业务团队”和“技术团队”两个部分。我们之前合作过的金融、保险、房地产、物流、汽车制造等诸多企业，业务团队和IT团队是有着清晰的边界和合作模式的。而如果谈战略转型的话，这些企业业务的战略转型，和IT的战略转型可以是异步的，甚至完全不是一件事。

如果我们认同中台战略改变的是企业的业务形态以及业务的交付形态，那么很显然的，要不要建中台、中台的构建原则以及基本交付形态，应当是一个业务决策而并非一个技术决策。业务团队围绕自己的发展目标和战略，来决定是否需要一个类似于阿里的“共享业务事业部”的业务团队，来重新对企业或者企业集团级的业务来做重新的治理或者赋能。进而，当业务中台部门构建成功之后，定义了自己的职责和规划，以及中台的业务和应用之间的协作关系、交付策略之后，技术上可以构建一个业务中台，来支撑全部前台的业务发展需要。在这个模式下，业务先行是中台发展的关键前提。

当我们认知了中台的业务本质之后，不难发现，现在很多企业的中台构建过程，都是由企业的IT部门或者技术团队发起或者主导的。在这种模式下，中台化的业务发展模式尚未明确，IT团队构建的中台，因为缺少业务的战略方向和输入，一般都会从企业的IT治理、提升复用的角度来考虑中台的价值。而站在这个角度，就需要去向业务团队和前台的应用团队解释清楚“中台和前台的合作模式是什么？”以及“哪些能力在中台承载？哪些能力放在前台承载？”这些听起来很耳熟的诉求，其实反映了现在技术主导的业务中台构建过程的尴尬状况。

而对于技术含量更为集中的数据中台和算法中台，虽然目前并没有受到到业务过多的约束，但可以预见当IT构建的数据中台缺少领域专家和数据科学家的参与，同样难以在长期给企业的业务带来价值。我目前辅导的一个数据仓库团队，因为对于财务业务领域知识的不熟悉，导致在特性交付的时候一直在疲于应付业务团队的各种诉求，无法有效的针对客户来做需求的分析和引导。如果我们把数据仓库换成了数据中台，由于要提供具有前瞻性的业务洞见，中台对业务领域专家和数据科学家的要求会变得更高而不是更低。如果数据中台的建设是业务决策而不是技术决策，业务的洞见和诉求会在第一时间融入到中台的建设过程中来，中台的价值风险也会相应降低。

3. Empowerment Over Governance 赋能胜于治理

自从企业构建了IT部门和团队，IT作为企业的成本中心，治理一直都是核心的职责和组织目标。治理的目标总体上是为了控制IT投入成本、提升IT构建效率，进而目标可以衍生出“降低成本、提升复用率、提升IT流程的标准化程度”等多种形态。

在过去10年的企业IT转型的过程中不难发现，控制成本和提升业务响应力是站在同一个天平两端的完全不同的需求。10年前，企业在苦苦思考敏捷转型能为自己降低多少IT研发成本；5年前，企业也在思考微服务架构的引入可以为自己降低多少IT投入。慢慢的，企业终于醒悟到，敏捷和微服务都是在为高响应力，而不是在为低成本服务。到了今天，“可以复用的企业级能力”又一次看起来符合了降低企业IT投入的目标，但是作为企业业务的发展需要来看，高响应力的组织级目标远远没有褪色。如果中台不能契合这一目标的话，相信最终被抛弃的不是业务或者用户，而是IT架构本身。

我们再来观察阿里这种“技术即业务”的组织——治理其实仅仅是一种表象。通过业务主流程的标准化和中台化，前台的新业务会更快速地被构建出来，而不再需要新业务团队从头到尾完整地构建一遍其他业务部门已经构建过的业务。这时，治理的目标基本上已经完全退让给了赋能这一更大的目标。这样就实现了我在前面提到过了企业希望通过构建中台来解决的第三个问题：“加速应用开发的TTM”。

最近几年，企业在提业务赋能的同时，一定会谈到要通过平台来构建一个更大的合作生态。我们看到国外的同行们在做企业架构转型的时候，提到的也更多的是“平台”而不是“中台”。今天我还在一个讨论组里看到了关于平台和中台的异同点的讨论。简而言之，平台面向生态和赋能，中台更多的面向治理。之所以中台在国内大火，某种意义上是因为国内企业的IT团队仍然在为自己的“成本中心”的定位寻找新的价值点。

跟着前面的思路，如果企业构建自己的平台或者中台，是作为一种战略出发的，并且是由业务团队主导的构建过程，那么这样的中台所要承载的使命，也必然远远大于一个“成本中心”所负担的使命。淡化治理、强化赋能的思路，可以使得企业在构建中台的过程中，更多的关注这一战略举措所带来的业务收益，而不会仅仅的关注到降低了多少IT成本；更多地关注野心勃勃的应用团队面向客户的需求来构建新的业务特性，而不是仅仅关注到团队使用了多少中台标准化的能力。

以上，是我当前关于企业构建中台的思考。我们从构建原则开始讲起，最终梳理下来，发现关于中台建设我的一个核心观点是：

在一个还没有实现“技术即业务”的企业当中，构建中台是一个需要通过企业战略引领、业务部门拉动、以构建生态为主要愿景的IT架构建设过程。如果这样的前提条件暂时不能满足，IT部门与其投资来构建一个颇具业务争议性的中台，不如回归到平台的本质——通过平台技术来打通交付瓶颈、构建开发者社区和生态、提供数据自服务平台以赋能业务自主挖掘洞见、通过构建实验平台来加速企业规模化创新的脚步、以及构建企业级用户触点平台以提供统一的用户交互体验。这五个方面其实是ThoughtWorks所提出的数字化平台战略的主要内容。这五个平台都既可以由业务发起，也可以由技术部门发起。最终被赋能的一定是业务和用户。

反过来，如果你的企业已经被认为是一个“技术即业务”的技术型公司，我认为，中台确实是适合你的。站在这个基础之上，我们可以再来讨论一下，如何正确的构建一个企业的中台，以及如何实施面向中台的战略转型。

作者