没有中台，但有微服务和 PaaS，一样吗？

不是所有业务都必须进行中台化，也不是所有中台建设都是一个充满矛盾的过程，优秀的微服务设计和完美的 PaaS 架构与中台也还是有所差异的。本文，InfoQ 采访了 ThoughtWorks 首席咨询师王健，听他分享中台建设的实施路径。

中台、微服务和 PaaS

一个概念代表一个新的边界。如果边界的定义不清楚，很多事情是没办法继续聊下去的。有关中台的基本概念已经有了很多介绍，大部分企业对于中台建设已经有了初步想法和规划，无论是解决数据孤岛问题、还是提高快速创新能力，中台都是可选的解决方案。然而，面对这些问题，企业最先想到的解决方案往往是相对轻量级的 PaaS 和微服务等解决方案，也不乏有人将 PaaS 平台称之为“中台”，但这三者之间其实是有差异的，搞清楚彼此之间的区别才可能选择出最适合自己的解决方案。

“那是我第一次帮助企业规划与建设中台，最开始我以为就是搭建微服务，后来才发现并不是这样的，微服务架构并不能解决这些问题，而这个过程让我多了很多思考”，王健如是说道：“最后，我发现当我们谈微服务时，我们更多关注的是技术架构层面的问题，而中台则往往处理的是企业架构问题。”

微服务架构通常采用前后端分离方式，按照一定的规则拆分为多个可以独立运行、独立开发、独立部署、独立运维的微服务或者页面聚合，从而满足业务快速变化及分布式多团队并行开发的需求，还可实现前端页面的复用，做到“一次开发，多端复用”，这也与中台服务的共享理念非常类似。所以，很多企业在进行中台实践时会将两者混淆。

从使用者的角度来看，大部分的微服务架构都是在支撑一个前台，而中台解决的是企业级能力复用，而这种能力复用一定是多前台、跨部门的。当然，微服务中也会提到复用问题，但这种复用一般指的是组件级别的复用，并未达到企业级的层面。一般而言，一个业务中台会同时抽调多个前台业务中可共享的能力，最终统一支持多个前台业务。

简单讲就是：中台不一定非得采用微服务架构，能够达到多前台能力复用的目标即可；而微服务架构也不一定要同时支持多前台应用，单应用的微服务化其实更多见。

那么，中台与PaaS又有什么区别呢？有观点认为中台与 PaaS 的区别只是一个定义在云上，一个定义在本地，但王健认为，更确切的说中台介于 PaaS 与 SaaS 之间，这里的 PaaS 更多是指技术的 PaaS 平台，与这类平台相比，中台更靠近业务，包含更多的业务属性，而与最靠近业务的 SaaS 相比，又具备更大的灵活性，所以也有很多的企业将中台比作 APaaS（Application PaaS）或是 BPaaS（Business PaaS）。

理论上，从业务的视角，如果 SaaS 能比较好的解决问题，那还是可以优先选择 SaaS。因为 SaaS 对于业务的封装会更加的成型，但缺点也是对于业务的支持过于固化，虽然可以通过配置化实现多条业务线的个性化需求，但仍然灵活性有限。

SaaS 的问题在于抽象层次很高，需要业务之间有很强的一致性，对业务的支持不够灵活，这也就有了中台的用武之地。中台比 SaaS 的抽象层次低一些，但更具灵活性，中台在纯技术的 PaaS 与纯业务的 SaaS 中找到一个比较好的平衡点，兼顾灵活性与业务封装，对于业务的创新支持更好。所以我们看到国外出现的一些新的 Headleass Commerce（无头电商），从思路上也和中台有着一些异曲同工之妙。

总结来看，中台就是一个企业级能力复用平台。王健补充道，企业级定义了中台的范围，区分开了单系统的服务化与微服务；能力定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；复用定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上；平台定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细力度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑。

中台建设的必要性

如今，有关中台建设的文章越来越多，很多企业也希望可以建设中台，但这件事情并非短时间内就可以建设完成。在之前的文章中，我们也曾提到，建设中台，企业可能还需要考虑组织架构的调整，既然牵扯的事情如此之多，中台建设是否还有必要呢？

当一个人说“这个东西这么贵，我们真的需要么？”的时候，这个人大抵是不想要的；当一个人说“这个东西这么贵，能不能便宜点？”的时候，这个人还是想要的，只是希望以更加优惠的条件得到。——王健

很多时候，建设中台也是如此，当企业在思考“我们真的需要么”时，大抵是并未想清楚中台建设的价值。确实，中台这个概念如今热度极高，但也并不是所有企业都必须从现在开始搭建中台，也并不是所有的系统、所有功能都一定要搬到中台上，这是可以进行取舍的，比如一些功能比较固定的财务系统，可能不需要那么着急地接入中台。从本质上来说，大家常说，中台是一把手工程，但并不是只解决了一把手对于企业未来发展的焦虑。

“中台建设的前期可能没有给业务带来多大帮助，反而制造了很多问题，如果没有 CIO、CTO 甚至 CEO，或者技术委员会、战略规划部门等的支持，很难进行，可能原来想做一个业务中台，后来因为无法撬动业务，数据也拿不到，最终的建设效果就会大打折扣”，王健进一步补充道，“如果这时领导层没有驱动力帮助继续推进这件事情，这个中台推也不是，不推也不是，因此我认为中台建设应该是一个自上而下的顶层设计与驱动过程。”

但中台并不是仅仅解决了一把手的焦虑。对于普通研发人员而言，很难站在一定的高度去做一个”看十年、做一年“的规划，特别是当一件事和眼前的 KPI 难以达成平衡时。但是，当团队成员发现无论如何加班都很难满足业务团队的诉求，一旦团队发生人员流动就很难进行维护时，就需要思考是不是需要将日常能力沉淀下来，而不是简单的从一套代码 copy 出另一套代码来支撑新的产品。

虽然，公司可以砍掉部分产品来缓解研发团队的焦虑，但其实真正困难的不是决定做什么，而是决定不做什么， 这种决策其实比做中台更加困难。此外，作为一家成熟的公司，一定是需要有能够形成合力的产品矩阵来支撑整个公司战略推进的，所以多产品并行是公司发展到一定阶段的必然选择，而做中台也绝不是站在其中某一个产品的角度来解决问题，而是站在多产品协同的角度来看公司的战略发展。

当研发人员出现上述问题时，中台就不单单是为了解决一把手对于企业未来生存和发展的焦虑，而确实是可以解决企业现阶段发展过程中所遇到的问题的，中台建设的必要性也就凸显出来了。

中台建设方法论

很早之前，ThoughtWorks 就开始研究并落地中台建设的方法论，王健调侃道：“那个时候，我们是被客户推着走的，可以理解为是以客户为中心，因为市场需要才做的这件事情。我也不觉得在众多方法论中一定要分出优劣，最终可以更好地解决客户的实际问题就可以了。”

在 ThoughtWorks，这套中台建设的方法论弥补了传统企业架构方法对于创新和平台化的一些相关问题。王健解释道，一是创新的问题，传统的 EA 架构更多是基于现有架构流程的梳理，但中台更多是支撑业务创新，为以后的业务发展做支撑，这就是创新的问题；二是平台化的问题，就是传统的企业架构方法更多是解决信息化时代如何通过应用架构和技术架构的设计来适应企业的业务架构的问题，但是对于如何做平台化，并没有足够的方法支撑。

如果一家企业从零开始建设中台，ThoughtWorks 给出了如上的中台规划实施路径。在实施之前，需要进行大量的前提调研分析，比如企业战略分析、行业趋势分析、客户研究、业务线调研与分析、IT 资产盘点、领域分析。在前期后台完成的情况下，可以开始进行企业架构设计，这时就需要定义企业新的业务架构，新的以中台为基础的分层应用架构和新的企业级技术架构体系标准。

在产品设计阶段，企业需要排列项目优先级，定义第一优先级的项目范围与工作计划，设定项目的价值交付目标并进行路线图规划。如果企业希望先突破单个业务，也可以先梳理该单个业务的逻辑，并将该业务先迁移至中台试运行。

在开发运营阶段，企业就需要建设中台的基础设施，设定中台的技术规范和中台化、服务化的产品研发流程，并配合敏捷软件开发与产品重构来开展。最后，检查架构守护机制、审计架构实现现状，并提出架构改进建议。

王健表示，ThoughtWorks 会将这套方法论进行持续不断地打磨，在这个过程中融入其他好的方法，再进行优化。上述是一家企业进行中台建设比较完整的过程，如果企业希望从其中的每一个步骤开始，也是可以的。对于目标行业，王健提到了两点考虑因素：一是整个行业真正在向前发展，而不是炒概念；二是持续聚焦在某几个行业可以对业务具备充分的了解，可以让企业在业务积累上不断产生优势。

结束语

总结下来，王健认为，中台的本质是面向用户与创新的新兴平台型企业架构；中台战略是一个战略问题，需要战略决心与战略耐心并存；中台建设从企业战略出发， 自上而下结合全盘考虑；中台建设需要技术升级与组织升级配合，需要顶层设计与驱动，也要达成全员共识；最后，中台建设依附于成熟的技术支撑和方法论引导，才可以少走弯路，实现弯道超车。