1. 什么是中台

任何一个软件系统都是通过帮助客户解决问题来实现价值的。针对不同的需求会建立不同的软件项目。这些软件项目包含客户端的应用和后台管理配置的应用。久而久之就形成了固定的“前台”和“后台”系统，而且大家都在乐此不疲地开发着类似的业务系统。但是，时间一长大家就发现了，这些系统中有一些部分大同小异，在做第二个项目的时候并不用将所有的功能重写，可以把之前项目中那些共有的模块拿出来，稍作修改就可以在新项目中应用了。

当系统大到一定的程度，就开始拆分，做服务化，形成了一个个的微服务，这个时候系统的高可用、服务稳定性有了很大提升。看起来已经是很好的架构了，那么有什么问题呢？

从公司的层面看，看到的就是一个个“烟囱”。

• “产品烟囱”。不同产品线之间的功能、定位相同。比如商品模块，商城系统有商品模块、自营系统也是商品模块、团购系统又有自己的商品模块。这些模块的功能和定位是相同的。
• “系统烟囱”。做开发的都有一个特点，“自己写的代码，用着才放心”，别人写的代码不愿意用，所以就会造成重复开发。
• “数据烟囱”。虽然数据是会使用同一个库表，但是数据的统计和定义，每个系统之间又有所不同。比如“每日订单总数”这个指标，有的按交易口径、有的按支付口径、有的按发货口径，数据统计结果就会不一样。
• “组织烟囱”。指的就是部门墙，有部门划分就会有部门墙，这很正常，但是如果部门墙太厚，扯皮的问题就会很严重。

京东的一位技术专家曾说过，“为什么要建中台？就是要拆掉‘烟囱’”。一句话就道破了中台建设的本质：建中台的过程，就是拆“烟囱”的过程。

抽象和解耦是软件开发铁律，同样也适用于中台系统。中台系统就是将“后台”系统中那些针对技术，业务，组织的通用“模块/服务”从原来固定的项目中抽离出来，并且使之能够成为一个自治的服务提供给更多的“前台”使用。

中台就是“前台”和“后台”之间联动的齿轮，也是：

• 调节器：前台业务变化快，后台系统相对比较稳定，中台就是他们中间的速度调节器。
• 加速器：新业务上马，接入中台即刻享受服务，不用 0 开始。
• 稳定器：前台业务多如牛毛，后台数据排山倒海，而中台提供各式各样的接口对接两者使用户享受稳定可靠的服务。

2. 中台的分类

中台是一种能力的抽象，这种能力可以是业务能力，技术能力，数据能力甚至是组织能力。我们可以从不同的维度对其进行分类。

中台分为如下几类：

• 业务中台
• 技术中台
• 数据中台
• 组织中台

2.1. 业务中台

业务是根本，特别是用户的核心业务。对于中台来说需要针对业务进行颗粒度划分，将业务的公共需求组合成服务，比如电商公司，客户，商品，物流，支付就是公共需要，比如汽车制造商，用户，车辆，订单，交付都是公共需求。将这些公共业务组合成统一的业务服务，供各个业务单元使用。

如果业务发生变化需要对上述服务进行拆解，例如：将结算中心拆解成支付服务和核销服务。这样的分类和拆解是为了更好的支持前台，给前台业务提供更多的可能性，从而为用户组合出更多的使用场景。

2.2. 技术中台

作为技术人员接触过最多的就是技术中台，通常我们会将服务进行拆解通过微服务的方式重新组织。每个微服务都是自我治理的，通过服务注册，服务网关，服务跟踪的方式让他们形成一个整体。

技术中台的划分通常分为两个维度，

第一个是基础服务，这些服务针对整个系统来说相对通用，如：安全认证，权限管理，流程引擎，日志，消息，通知等等。这些组件通常与业务关联度不大，属于每个应用都需要使用的功能。

第二个就是业务服务，这些服务都针对每个业务模块做划分，通常这些服务会根据业务的变化或者增量进行更新或者横向扩展。

2.3. 数据中台

数据的获取通常需要经过数据采集，数据清洗/过滤，数据存储，数据归档几个步骤，最后才能通过数据服务的形式展现给用户。特别是针对客户端来说，同时通过数据中台提供的服务来获取数据的。数据中台会根据不同的业务场景，生成不同的数据服务，满足客户的需要。

2.4. 组织中台

中台是需要人来实现的，如何组织好这些人就显得尤为重要了。如果要谈谈组织中台，那么就要先说说下面几种组织结构。

职能型：

每个部门各司其职，虽然都是一个老板管，但是部门之间的界限明确。每次有了项目就从各个部门抽调人员，当项目完成以后人员都回到各自的部门当中。

如果再有新的项目就再次抽调。这种方式沟通成本高，责权不清，出现问题以后容易踢皮球，对用户需求的反应相对较慢。

矩阵型：

随着互联网的兴起，矩阵型的组织结构也悄然兴起。把人员从原来的部门中完全剥离出来成立专门的项目，并且指定项目经理。

人员汇报的线路也从原来的部门经理换成了项目经理。而项目经理又对 CTO 直接负责，这样的结构相对简单，实用性较强，避开了职能型组织结构的一些缺点。

产品型：

随着产品意识的不断提升，人们不再拘泥于之前的矩阵型组织结构了，于是加入了产品和产品经理，更重要的是把客户也纳入到组织当中。

让客户参与产品决策，验收测试，增加用户的参与感，做到产品为客户所用。用户自己设计，测试出来的产品他想说不好都难。

随着组织中台的不断发展，我们的组织结构也慢慢从职能型向矩阵型，产品型进行过渡。

3. 中台的作用

大家既然对中台有了一定的了解，那我们再从两个维度来看看中台的作用。虽然上面已经介绍了很多关乎作用的例子，但是我们还是希望从两个维度来归纳总结一下。

3.1. 业务方面的作用

快速切入市场

在中台出现之前，我们进入每个行业是比较困难的。在了解业务的基础上需要搭建基础的业务模块。现在不需要了，有了中台策略的加持即使对一些行业不太了解也能够从容应对。

在 BAT 中已经有染指汽车制造，航空航天等专业性很强的行业了，靠的就是中台能力的输出。

专业人员融入系统

有了中台系统，那么就离不开行业中的专业人员。行业中的专业人员，协助中台系统打磨各个业务模块，通过 PASS 平台打造行业自身的应用。让业务和技术更好的融合，产生化学作用。

定义平台规则

现在阿里的钉钉就把用户，服务提供商，经销商都拉到了一个平台上了。通过阿里平台的能力，将钉钉打造成企业服务的中台，让多方从中受益。

3.2. 技术方面的作用

服务重用

不要重复造轮子是我们始终面对的问题，中台的初衷就是抽离通用的部分，让更多人能够享受他们。

服务进化

技术会跟随业务的进化而进化，每一次进化都是一次技术的沉淀。以前这些技术进化是不可见的，现在新的项目也可以通过中台系统享受这些技术的进化。

快速响应

由于中台系统针对服务进行颗粒化处理，让每个服务都有独立性，可以针对业务的需求对服务进行横向扩展，从而提高服务的响应时间。

数据积累

长年累月的数据积累，特别是对业务数据的积累，能够帮助我们带来商业价值。

提高效率

不用从无到有去搭建整个项目架构，也大大缩短了给用户的交付时间，高效的组织结构也促进了交付质量，提高了用户的满意度。

4. 如何建立自己公司的中台

不管是阿里的“⼤中台，⼩前台”战略，还是华为的“⼤平台炮火支撑精兵作战”战略，仿佛都离我们很远。

有人说：“中台系统就是大公司的事情，我们做好自己手上的项目就好了。”这话对也不对！

中台系统确实需要具备一定规模以后才能产生，只有项目足够多，行业足够丰富，资源充足的情况下可以实行。这些都是中小公司无法做到的，但是，作为我们可以利用中台策略的思维来优化我们的开发，产品，项目甚至是组织。

• 从业务方面，我们是否能够把自己专精行业的业务进行一个模块划分，让用户可以自由选择需要的业务模块，提高我们业务适配的灵活性。
• 从技术方面，我们是否能够总结一下哪些模块，服务可以从系统中解耦出来成为单独的服务，甚至可以单独部署做到真正的自治。以后搭建技术框架的时候就好像搭积木一样方便可靠。
• 从组织方面，由康威定理可以得出什么样的组织结构直接影响这个组织结构生产的软件。

我们是否还在遵循传统的职能型的方式在推进项目。是否可以考虑以客户为中心的开发模式，让开发人员更加贴近客户，为客户创造价值。

只有充分通用的业务，才适合沉淀到中台，否则中台只会成为业务发展的瓶颈。

中台负责人不能只想着抢地盘，不属于自己的范围不能大包大揽，要保持克制。

5. 中台建设的难点

中台建设难，并不是难在技术上，主要难在两个方面：

第一，组织。如上面的观点，建中台的过程，就是拆“烟囱”的过程。很多“烟囱”需要合并，最简单的办法就是把这两个相同产品部门合并，这就涉及到组织的变动了，如果没有高层的支持，就会很难，因为你动到别人的“地盘”了，别人会跟你拼命。

第二，思维。思维分成两个角度：服务提供方、服务调用方。

服务提供方，就需要把自己的工作范围扩大，具备“中台思维”，也就是自己提供的服务不仅是给自己用的，还要给其它团队用，要兼顾所有调用方，要做好能力的沉淀，提供好支持。

服务调用方，不能想要什么服务就自己建，要先考虑是不是已经有现成的服务可以调用，如果有就要去调用，如果不满足要求，就要去推动服务提供方完善服务，这点也是开发人员抵触的，害怕去推动，不愿去“麻烦”别人。

先有“中台思维”，才有“中台系统”

知道了问题所在，就可以针对性的寻找解决办法。

组织层面。要获得高层的支持，解决好合并组织带来的人员之间的矛盾，这些都要安排妥当。不要因为问题棘手，而选择故意躲避，问题始终存在，而且随时可能爆发。

思维层面。给技术人员宣导“中台思维”，即：服务调用方要考虑充分使用现有的服务，不要自己去写。服务提供方，要兼顾“小前台”们的需求，提供好中台服务。

有了组织、思维方面的支撑，建立中台系统才是事半功倍、水到渠成的事情。

6. 中台适用场景

从0到1的阶段，没有必要搭建中台。

从0到1的创业型公司，首要目的是生存下去，以最快的速度打造出产品，证明自身的市场价值。

这个时候，让项目野蛮生长才是最好的选择。如果不慌不忙地先去搭建中台，恐怕中台还没搭建好，公司早就饿死了。

从1到N的阶段，适合搭建中台。

当企业有了一定规模，产品得到了市场的认可，这时候公司的首要目的不再是活下去，而是活的更好。

这个时候，趁着项目复杂度还不是特别高，可以考虑把各项目的通用部分下沉，组建中台，以方便后续新项目的尝试和旧项目的迭代。

从N到N+1的阶段，搭建中台势在必行。

当企业已经有了很大的规模，各种产品、服务、部门错综复杂，这时候做架构调整会比较痛苦。

但是长痛不如短痛，为了项目的长期发展，还是需要尽早调整架构，实现平台化，以免日后越来越难以维护。

7. 参考资料

https://mp.weixin.qq.com/s/_olM0DZsaC0ju4kQG5XVwg

https://zhuanlan.zhihu.com/p/75223466

https://mp.weixin.qq.com/s/1xeCc_68Ao7cb83aboD0tg

https://mp.weixin.qq.com/s/QsucaskL4F4-KEaqAtYsxw