距离上一篇知乎文章已经相隔将近4年有余。之所以隔了这么久，主要是因为18年之后进入了某大厂开始工作，工作内容及其繁重，故一直没有时间继续写点什么。幸得最近有一丝清闲，同时这两年也有幸参与该厂建设中台系统，有了一些感悟，就准备留下一些自己的思考，也算对这段工作的一个小结。

什么是中台

在参与中台系统建设的整个过程中，我一直都在想，到底什么是中台？接触中台的概念无非来源于两个小故事，一个就是游戏公司Supercell，另外一个就是美军作战模式。但是概念上到底什么是中台呢？

中台，互联网术语，一般应用于大型企业。一般是指搭建一个灵活快速应对变化的架构，快速实现前端提的需求，避免重复建设，达到提高工作效率目的。

这是百度百科中对中台的定义，但是总感觉过于抽象，后来我发现如下的定义，

企业级能力复用平台

这个定义来源于洞见的一个系列文章，虽然简短，但是个人感觉定义的非常准确。拆开对这句话进行一个解释，

「企业级」定义了中台的范围，区分开了单系统的服务化与微服务。
「能力」定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在。
「复用」定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上。

这里面复用其实是一个非常重要的概念，同时也是衡量中台“好“、”坏“的一个标准，试想如果你建设了一个中台，又无法评价这个中台建设的好坏，这必然会带来一系列问题。那么这个评价“好“、”坏“的指标就往往会来源于”复用“这一概念。我们当时建设的时候，也是利用这一个指标来对中台进行评价。有了评价标准，那么自然也就有了建设目标，这是顺理成章的事情。

「平台」定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑。

另外一个经常被想到的问题就是中台和平台有什么区别，我理解平台更多地是面向生态和赋能，而中台更多的是面向治理。

为什么需要中台

解释清楚了什么是中台后，接下来的问题就是为什么需要中台？

企业前台、后台存在需求矛盾时，为了满足前台的快速迭代需求和后台的稳定性需求，中台概念应运而生，核心是当前台需求来临时，中台能快速的进行响应，从而提升研发效率，降低创新成本，提高工作效率。

这里同样是百度百科对中台价值的一个表述，更进一步讲，中台就是为了解决三个典型问题（提升IT能力复用率、打通数据壁垒、提升应用TTM）。我个人的理解就是”低成本的快“。这也符合对中台的定义。

就具体情况而言，当时我们公司的业务是一套系统支撑了多个业务线的业务，每个业务线自然而然的就都在这个超级巨无霸的系统上进行”建设“，结果可想而知。经过长时间的建设后，这个系统充满了大量的”面条“逻辑，"烟囱"遍地都是，后续系统维护成本与风险都成指数级上升。针对这一问题，中台化似乎是一个合理的解决方案，故决定进行架构调整，将原有的系统升级为中台系统。

中台建设过程中遇到的问题

在系统中台化的建设过程中，我们又遇到了各种各样的问题，这些问题的发现与解决，也是让我收获颇多，而且感觉中台似乎没有想象中的那么”美好“。

能力地图

整个系统之前是基于解决方案的方式建设的，故系统内部随处可见的重复逻辑与定制逻辑。那么第一步就是对这些业务逻辑进行梳理。基于中台的概念，最核心的部分就是能力，故我们首先梳理出一些能力，并且将不同应用之间的”能力“进行串联，组成了能力地图。这张地图最终也就成为了整个中台建设的目标和路线图。然而在梳理的过程中，我们遇到很多问题。比如什么是能力，能力的粒度是多大，能力如何进行抽象。

对于能力的定义其实有很多种，我们摒弃了对能力确切定义的争议，基于现有系统和现有业务逻辑框架，更多地是从人为直觉上进行了划分，当然这部分也有逻辑思考的内容。虽然可能不是那么”精准“，但是至少是可行的完成了划分。其实我个人觉得所谓的能力很难定义出一个精准的边界出来，可以先基于分类，比如技术能力、业务能力、数据能力，又比如基于业务类型或者业务的组织进行划分，当然这完全基于自身公司组织和业务形态进行适应性的选择。这样基本就解决了能力定义与粒度或者说边界划分的问题。

接下来为了能够让前台系统快速应用，能力也需要进一步进行抽象。抽象在系统架构设计领域好像是老生常谈的一个问题，大家往往就一句这个地方要抽象一下，好像就解决了抽象问题，但其实抽象的落地往往是一件非常困难的事情，这个困难来源于现有系统的业务复杂性和未知。当设计人员足够的了解到了系统的复杂性之后，才能从复杂的逻辑内部找到相关性，以此为基础寻找出抽象简化之道。或许通过不懈的努力可以大致了解之前系统的复杂性全貌，进行一个有效的抽象，但是”未知“往往会是遇到的一个劲敌。我们的业务因为涉及到全球范围的业务，所以面对了大量的未知，各个国家的政策法规，各个国家的用户习惯，各个国家的基础建设，基本上都是各不相同，试想让一个人或者一个团队了解这些所有的知识细节是何其的困难。而且，除了业务内容涉及的范围广，因为整个系统支撑了多个业务线，所以业务场景也非常的多，每个业务场景所需要的能力成熟度又是千差万别。可以想到，这个能力的抽象之路必然是冗长而又复杂的过程，这也不难想到为什么之前整个系统中充满了大量的”面条“逻辑。

组织关系

组织关系又可以称之为生产关系，在整个中台建设的过程中，生产关系的变革也充满了挑战。

分工

由于之前所有业务逻辑都在一个大系统之上，故所有开发人员都在一个team中工作。但是随着架构的调整，按照中台设计的逻辑自然分出了前台技术团队和中台技术团队。这样的分工本身是符合中台架构设计逻辑的，但是随之而来的问题就是边界怎么划分？一个业务需求来了，到底是中台做呢还是前台完成？两个团队因为业务功能的划分、架构的设计、甚至是运维的责任人而争吵不休。结果就是这种划分并没有有效的提高研发效率，反而形成了大量的内耗，有时甚至演变成了”政治“游戏。这让我想起了电影笑傲江湖中的一句台词。

江湖派别，满口道理，只不过是一场权力游戏。

承载力

由于团队的拆分，原有中台的团队人员往往会减少，但是其工作压力反而可能会大大增加。为什么呢？首先，一般前台的技术团队会有多个小团队对口不同的业务线，那么在业务的视角看来似乎增加了很多生产力，故每个业务线疯狂的提出各种各样的需求。但是这些需求到了中台之后，往往就是几个人在承载，如果组织没有协调各个业务线需求优先级的能力，那么这个中台团队将会被这些需求压得死死的。其次，由于核心系统都在中台团队手中，大量的运维工作，比如监控、发布和应急等等都是由中台团队完成。最后，由于组织的变动和人员的流动，同时核心的业务逻辑也在中台，中台的团队还要肩负起知识传播的责任，包括大量的日常咨询，这也占据了中台团队的大量的精力。当然有人说，你把文档写好不就行了么。什么是好的文档，文档的维护成本，文档表达的有限性，有多少人会去仔细阅读文档，有人讲和看文档我会选择哪个？这些问题其实解决起来都是有一定难度的。

在以上这些事情的压力下，中台团队还要抽出精力去抽象和建设自己的中台能力，往往事情没做多少，反而整个中台团队都被压得喘不过来气，最终也就产生多前台由于中台资源竞争产生大量矛盾。

评价标准

随着投入了大量的资源进行中台建设，随之而来就会产生一个问题，那就是中台有什么价值，值得投入这么多资源么？那么中台给业务的感觉是什么？由于上面所述的这些问题，业务的需求推进缓慢，所有的资源瓶颈都在中台；中台抽象不足，每次业务需求都有很多开发工作量。这似乎和当初建设中台是为了低成本的快有很大的出入。中台团队为了自保，提出了一些比如”业务自助率“的KPI来彰显自身的价值，但是从结果上来看，不尽如人意。这也就是我之前所说的评价标准对于中台很重要，因为没有一个合理的评价标准，往往很难看到中台存在的价值，甚至反而成了瓶颈和内耗的关键点。

思考

• 很多架构设计看上去很美好，但是如果没有与之匹配的组织关系或者说是生产力，往往得到的结果会和当初的理想大相径庭。
• 必须认识到中台的建设是一个长期和动态的过程。如上文所述，对业务的理解和对未知的探索是一个长期而又漫长的过程，同时也是随着业务的不断发展而不断更替的过程。而且，也要容忍一段时间内，业务的能力是存在于前台的，随着业务的成熟会有一个能力动态下沉的过程。
• 建设的过程存在业务与技术建设之间的矛盾。或者说是”短期战术目标与长期战略目标的矛盾“。具体的讲就是中台建设的长期性与短期业务的需求之间的矛盾，业务不满意，技术建设的目标也无法完成。
• 需要有产品化的思维，中台的建设绝对不能以解决方案的模式进行建设，要有清晰的用户定位和用户划分。同时，还能明确自身的SLA，提供用户运营与用户售后的能力。

参考文章：

个人感觉这一套中台系列的文章还是很有见地，本文的很多内容也参考这个系列的文章，有兴趣的可以看看。