《白话中台战略》已经写了三篇，尤其是第一篇“白话中台战略（一）：中台是个什么鬼？”收到了很多朋友的反馈。写白话这个系列主要是想通过写文章来驱动自己思考，并希望可以和更多人一起交流和探讨中台这个话题。
幸运的是，确实有很多朋友给我留言来表达自己的想法，我摘出来一个具有代表性的：
“互联网的企业就是爱炒概念。本来很明白的东西，被他们一包装，就变得高深莫测了。我理解中台，就是敏捷响应机制…是一种思维或者理念…企业根据自己的实际情况落实就行。”
对于这位同学的观点我很赞同，中台本身就是一个比较抽象的概念，很多时候我们被那个“中”字困住了，整天在前与中，中与后的具体差别和评判标准上纠结不已。
但是，就像“看板”不是“我们看到的那个板子”一样，“中台”也不一定就是代表“处于中间平台”，这两个字作为一个整体，代表了一种新的思维和理念。在最新一期的 ThoughtWorks 技术雷达讨论阶段，中国区的同学就把“ZhongTai”作为一个独立的技术点提交，并没有做意译，就像“Kanban”一样。
那这种新的思维和理念到底是什么呢？“中台”的背后到底意味着什么？有没有价值？价值何在？这也我一直在不断询问自己的问题。
要想搞清楚这些问题，我认为一个关键点就是看我们是否能够给“中台”这个相对抽象的概念找到一个清晰的定义，因为只有通过定义才能让抽象的概念清晰化，从而明确边界、体现价值。
废话不多说，回到“中台”，如果让我给出一个定义，目前我认为最贴切的应该是：
中台就是“企业级能力复用平台”。
很简单，有点失望是不是？但是为了找到一个靠谱的定义，我几乎花了快两年的时间，期间有各种各样的定义曾浮现出来，但至少到目前为止，只有这个定义我觉得最贴切、最简单、也最准确，它能解释几乎所有我碰到的关于中台的问题，例如：
为什么会有那么多中台，像上文提到业务中台，数据中台，搜索中台，移动中台，哪些才是中台，哪些是蹭热点的？
中台与前台的划分原则是什么？
中台化与平台化的区别是什么？
中台化和服务化的区别是什么？
中台该怎么建设？
等等……
这 9 个字看起来简单，重要的是其背后对「中台」价值的阐释，下面就让我为大家一一拆解来看。
企业级
首先，中台一定是企业级的，这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围，甚至可以是跨企业，例如现在同样火爆的生态的概念。按照徐昊（ThoughtWorks 中国区 CTO）的说法，更贴切的叫法应该是“多前台产品团队”，这里为了简单我还是用企业级来代表。
当做中台建设的时候，一定是跳出单条业务线站在企业整体视角来审视业务全景，寻找可复用的能力进行沉淀，从而希望通过能力的复用一方面消除数据孤岛业务孤岛，一方面支撑企业级规模化创新，助力企业变革，滋生生态。
所以虽然中台的建设过程虽然可以自下而上，以点及面。但驱动力一定是自上而下的，全局视角的，并且需要一定的顶层设计。这也解释了为什么在企业中推动中台建设的往往都是跨业务部门，例如 CIO 级别领导或是企业的战略规划部门，因为只有这些横跨多条业务线的角色和组织，才会去经常反思与推动企业级的能力复用问题。
这一点也引出了中台建设的一个关键难点，就是组织架构的调整和演进以及利益的重新分配，这是技术所不能解决的，也是中台建设的最强阻力，这个我打算在后续的文章里详细阐述。
同时企业级也是区分企业中台化与应用系统服务化的关键点，简而言之中台化是企业级、是全局视角，服务化更多是系统级、是局部视角。
所以从中台的兴起与爆发可以看到一种趋势，就是越来越多的企业无论是由于企业运营效率的原因还是由于创新发展的需要，对于企业全局视角跨业务线的能力沉淀都提高到了前所未有的战略高度。
能力
提到中台，最常听到的一个词就是“能力”。可能是因为能力这个词足够简单，又有着足够的包容度与宽度。
企业的能力可能包含多个维度，常见的例如计算能力，技术能力，业务能力，数据能力，AI 能力，运营能力，研发能力……其中大部分的能力还可以继续细化和二次展开，从而形成一张多维度的企业能力网。
我在上一篇白话中台战略 -2 中台到底长啥样？中已经举了一些常见的例子，这里就不赘述了。
可以说，中台就是企业所有可以被“多前台产品团队”复用能力的载体。
这里有一个经常碰到的问题，就是对于某一家企业来讲，你说了有这么多种不同类型的能力，到底哪些能力才是我们企业需要的？哪些是值得中台化的？优先级又怎么划分？
这个问题比较大，也很难有一个统一的答案。我们 ThoughtWorks 现在的做法是通过一系列 Workshop，从业务、数据、技术三个方面切入，通过一系列方法，结合企业愿景，市场定位和数字化现状，跨越多条业务线，试图将企业需要的能力和可复用的能力识别出来，并为落地做好规划和准备。
这些会在后续写到中台如何落地的文章时再详细展开。
复用
讲到这儿，相信大家一定有一个疑惑，无论是说企业级，多前台产品团队，还是讲能力沉淀，都不是什么新话题。很多企业组件化，服务化，平台化搞了好多年，那“中台”到底有哪些新的启发？
我的答案就是对于“复用”的关注被提高到了一个前所未有的高度。
虽然我们一直讲“去重复用”讲了很多年，但仔细想想，大多平台化建设会将重点放在“去重”（消除重复）上，而对于“复用”则没有足够的关注。
很多企业都号称已经建成了各种各样成熟的平台，但是我们问心自问一下，有多少平台是业务驱动的？有多少前台产品团队又是自愿将自己的产品接入到平台上的？有多少平台建设者是在真正关注前台产品团队的平台用户体验？
“去重”讲的更多是向后看，是技术驱动的；“复用”讲的更多是向前看，是业务驱动和用户驱动的。
所以“去重”与“复用”虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情，目的不同，难度也不同，做到“去重”已然非常困难，关注“复用”的就更是寥寥无几，所以：
- 复用是中台更加关注的目标；
- 可复用性和易复用性是衡量中台建设好坏的重要指标；
- 业务响应力和业务满意度也才是考核中台建设进度的重要标准。
而实现更好的复用，常常改进的方向有两个方面：
- 一方面将更高抽象（例如业务模式级别）的通用业务逻辑通过抽象后下沉到中台，这样前台就会更轻，学习成本和开发维护成本更低，越能更快的适应业务变化；缺点是，抽象级别越高，越难被复用，需要架构师对于各业务有深入的理解和非常强的抽象能力。
- 另一方面就是通过对于中台能力的 SaaS 化包装，减少前台团队发现中台能力和使用中台能力的阻力，甚至通过自助式（Self-Service）的方式就快速定位和使用中台能力。目前很多企业在尝试的内部 API 集市或是数据商店就是在这方面的努力和尝试。
平台
这里的平台主要是区别于大单体的应用或是系统。
传统的企业数字化规划更多的是围绕业务架构，应用架构和数据架构展开。产出也是一个个基于应用和系统的数字化建设规划，例如要采购或是自建哪些具体的系统，例如 ERP、CRM 等。
当然这个过程并没有什么问题，可以理解此时这些独立的系统就承载了企业的各种能力，由于企业各业务线统一使用一个应用或系统，也自然实现了能力的复用。
但问题常常出现在两个方面：
- 一个是大单体系统的业务响应力有限，缺少柔性，当业务发展到一定阶段后，必然产生大量定制化需求，随着内部定制化模块的比例逐渐上升，响应力成指数下降，成为业务的瓶颈点。
- 另一个则是系统间的打通通常比较困难，容易形成业务孤岛和数据孤岛；
所以越来越多的企业开始像互联网学习，以平台化的方式重塑企业 IT 架构，从而对于业务提供足够的柔性，来满足对于业务的快速响应和复用的需求。
总结
企业级能力复用平台这个定义虽然看起来简单，但经过这么长时间对于中台的实践与思考，我觉得如上文所述的这个定义背后所代表的意义是目前对中台价值的最贴切的阐释：
- 企业级定义了中台的范围，区分开了单系统的服务化与微服务；
- 能力定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
- 复用定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上；
- 平台定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细力度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑。
有了定义后，如何建中台的思路也就豁然开朗：如果说中台是「企业级能力复用平台」的话，那中台化就是「利用平台化手段发现、沉淀与复用企业级能力的过程」，再回头看看这两年做的事情，确实也都在围绕着这些展开。
这就是我对中台的定义，如果你有不同观点或是意见，欢迎留言一起探讨。
最新评论