认识中台

在阿里巴巴成功完成中台战略转型后，很多大型企业对标阿里开启了中台数字化战略转型。很多人看到了中台带来的好处，但也有不少人对中台提出了质疑。

中台到底是什么？传统企业应该如何做中台？中台和平台的关系是什么？

总之，每个人心里都有自己认为的中台。

作为中台，它需要将通用的、可复用的业务能力沉淀到中台，实现企业级能力的复用。而从企业架构的角度来讲，业务中台更偏向于业务架构，因此企业在进行中台建设时首先要从业务领域出发，考虑如何按照可复用的原则进行领域分解，完成中台领域建模。

然后，我们需要考虑如何完成中台落地。现在中台落地的技术手段和架构有很多种，微服务架构是目前公认的最佳实践。在中台微服务落地时会面临微服务应该如何拆分和设计的问题。

中台本质上是企业的业务模型，而微服务则是中台领域模型系统落地时的一种架构实现方式。这两个问题一前一后，对于任何一家企业来说，都是一个不小的挑战。那是否有好的方法来指导中台领域建模和微服务拆分及设计呢？

答案是肯定的！

那就是DDD。DDD虽然在2003年就已被提出，但它与微服务及中台设计的结合，却是一个很新的领域。

DDD包含战略设计和战术设计两个阶段。通过战略设计可以完成中台业务边界划分和领域建模，然后将领域模型作为战术设计的输入，完成微服务设计。

DDD、微服务与中台都强调从业务领域出发。DDD可以同时指导中台领域建模和微服务设计，是中台领域建模和微服务设计的最佳指导方法，而微服务是中台的最佳技术实践。三者呈铁三角关系。

数字化中台初步认识与建设策略

阿里巴巴的中台战略最早从业务中台和数据中台开始，采用业务和数据中台相结合的双中台建设模式。后来又有人提出了各种各样的其他中台，比如技术中台、AI中台等，不一而足。

其实不少企业在很多年前就已经有了建设大平台的实践经验。在中台被热议的当下，相信你一定听过很多对中台的质疑声。

比如，有人说：“中台就是个怪名词，它不就是已经做了好多年的平台吗？”

确实！中台源于平台，但它的战略高度要高于平台。

平台是中台吗？

在阿里巴巴完美落地中台战略后，很多企业开始与阿里的中台对标。其中有不少企业在十多年前就完成了大一统的集中式系统拆分，实现了从传统大单体应用向大平台的演进，他们也按照业务领域将公共能力和核心能力分开建设，解决了公共功能模块重复投入和重复建设的问题。

那这是不是阿里所说的中台呢？在回答这个问题之前，我们不妨先了解一下阿里的中台到底是什么样的。

阿里业务中台的前身是共享平台，而原来的共享平台更多是被当作资源团队，承接各业务方的需求，并为业务方在基础服务上做定制开发。阿里业务中台的目标是把核心服务链路（会员、商品、交易、营销、店铺、资金结算等）整体当作一个平台产品来做，为前端业务提供的是业务解决方案，而不是彼此独立的系统。这种能力有别于传统的烟囱式的系统建设方式[…]

有些企业的IT人员说：“我们系统很多，功能很强大，所有业务点都有系统支持，但为什么业务人员总抱怨系统做得不够好，业务响应不够快呢？”

其实这是一个很多企业都在讨论的、应用“可用”与“好用”的话题。抛开商业模式的原因，问题根源很有可能出在系统的共享、联通和融合能力上。在进行应用建设时，有些人可能会站在部门或个人利益的角度，特别强调和关注应用的局部“可用”，却忽略了企业级业务和流程的整体“好用”。

有的企业由于缺乏总体规划，应用建设目标不够明确，加上天然的组织架构、数据和业务边界，很自然地就出现了明显的系统边界和系统重复建设的问题，难以支持企业级业务能力的快速融合，不能快速响应企业级业务和商业模式创新，对前台一线业务支持和融合也不够好，难以在前台形成一致的用户体验，最终影响企业业务发展。这种问题在业务领域分布广泛的大型集团级企业可能会更加突出。而对于大型企业而言，要想解决从“可用”到“好用”的问题，其实还有很长的路要走。

下面我们来分析一下传统企业大平台战略和阿里中台战略的主要差异。

传统企业的很多平台只是将部分通用的公共能力独立为共享平台。这类平台虽然可以通过API或者以数据服务的形式对外提供共享服务，解决系统重复建设的问题，但它们并没有与企业内的其他平台或应用实现从前端到后端的页面、业务流程和数据的全面融合，没有将企业核心业务服务链路作为企业级解决方案来考虑。各平台仍然是分离且独立的，本质上仍然是烟囱式建设模式。

可见，项目级的平台虽然解决了公共能力复用的问题，但与企业级中台的建设目标显然还有一定差距！

中台到底是什么

中台到底是什么

一千个读者就有一千个哈姆雷特”，用这句话形容技术圈对中台的理解再合适不过了。这也说明了大家对中台的定位和理解还存在很大的争议。

我们先看一下阿里对中台的定义：“中台是一个基础的理念和架构，我们要用中台的思想建设、联通所有基础服务，共同支持上端的业务。业务中台更多的是支持在线业务，数据中台则提供基础数据处理能力和很多的数据产品供所有业务方使用。即由业务中台、数据中台、算法中台等一起提供对上层业务的支撑。”

再看一下ThoughtWorks对中台的定义：“中台是企业级能力复用平台。”

综上，我们可以提炼出几个关于中台的关键词：共享、联通、融合和创新。联通是前台以及中台之间各业务板块的联通，融合是前台企业级业务流程和数据的融合，并以共享的方式支持前台一线业务的发展和创新。

我认为，中台首先体现的是一种企业级的能力，它提供的是一套企业级的整体解决方案，解决小到企业、集团，大到生态圈的能力共享、业务联通和融合的问题，支持业务和商业模式创新。通过平台联通、业务和数据融合，为前台用户提供一致体验，更敏捷地支撑前台一线业务。

中台来源于平台，但与平台相比，中台更多是一种理念的转变，它主要体现在这三个关键能力上。

1）对前台业务的快速响应能力。

2）企业级的复用能力。

3）从前台、中台到后台的设计、研发、页面操作、流程、服务和数据的无缝联通、融合能力。

其中最关键的是业务快速响应能力和企业级无缝联通及融合能力，尤其是对于跨业经营的超大型企业来说，这种能力至关重要。

传统企业中台的建设策略

与传统企业不同，拥有流量入口的超大型互联企业是互联网生态圈的创造者，而传统企业只是生态圈种群中的个体，除了需要做好原有的传统渠道业务外，还需要融入互联网生态圈，其商业模式、个体能力，以及与其他个体共生的能力决定了它的发展潜力。

相对互联网企业而言，传统企业的渠道应用更加多样化，有面向内部人员的门店类应用、面向外部用户的互联网电商以及移动App类应用。这些应用面向的用户和场景可能不同，但其功能与产品同质化严重，基本涵盖了企业的核心业务能力。此外，传统企业也会将部分核心应用的页面或API服务能力开放给生态圈第三方，实现业务的优势互补，相互借力发展

为了适应不同业务和渠道的发展，过去很多企业的做法是开发很多相互独立的应用或App。但由于IT系统建设初期并没有企业级的整体规划，平台之间融合不好，直接影响了用户体验，归根结底是用户并不想安装那么多App。

为了提升用户体验，实现统一运营，很多企业开始缩减App的数量，在一个App中集成企业内的所有能力，联通前台所有的核心业务链路。

由于传统企业的商业模式和IT系统建设发展的历程与互联网企业不是完全一样的，因此传统企业的中台建设策略与阿里中台战略也会有所差异，中台需要共享的内容也不太一样。但是传统企业的中台建设策略与阿里的中台建设策略基本相同，都需要从业务中台和数据中台这种双中台的模式开始建设

我们来分析一下企业中台的能力建设过程。企业中台业务能力建设一般会经历“分”和“合”两个过程。通过将企业可复用的能力沉淀，形成多个不同业务领域职责单一的中台领域模型，然后对这些不同类型的中台业务能力进行组合和编排，形成企业级业务能力，从而在企业领域模型的“稳”和商业模式与业务流程的“变”中找到最佳平衡。

“分”的主要目标是通过业务领域边界划分和微服务拆分，建立稳定的、单一职能的领域模型，让业务和应用具有更强的扩展和复用能力。但分不是目的，而是手段，是根据单一职责原则实现业务能力的复用和高内聚。分的过程主要发生在业务中台，在完成业务领域和微服务拆分后，降低了应用建设的复杂度，使业务和应用具有更强的扩展能力和稳定性。

在完成业务能力拆分后，我们还需要对这些拆分后的、稳定的、可复用的核心领域能力进行组合、编排和融合，形成企业级能力，从而灵活快速地适配外部业务和流程以及商业模式的变化，这是“合”的过程。

“合”包括业务融合和数据融合。业务融合主要作用在前台，实现企业不同业务板块能力的联通、组装和整合，实现企业级业务流程的融合，提供一致的前台用户体验。而数据融合则主要作用在数据中台，实现企业不同业务板块数据的汇集、集成、智能分析和商业模式创新等，为企业前台业务提供统一的智能化数据服务。

在进行业务领域划分和中台设计时，由于渠道多样化，传统企业不仅要将通用能力中台化，以实现通用能力的沉淀、共享和复用（这里的通用能力对应DDD的通用子域或支撑子域），还需要将核心能力中台化，以满足不同渠道的核心业务能力共享和复用的需求，避免传统核心和移动互联等不同渠道应用之间出现“后端双核心、前端两张皮”的问题（这里的核心能力对应DDD的核心子域）。

上述这些都属于业务中台的范畴，需要我们解决核心业务链路的联通和不同渠道服务复用的问题。

除此之外，我们还需要解决微服务拆分后的数据孤岛、数据融合和业务创新等问题，这就属于数据中台的范畴了，尤其是当我们采用分布式微服务架构以后，就更应该关注微服务拆分后的数据融合和共享问题了。

综上，在中台设计和规划时，我们需要整体考虑企业内前台、中台以及后台应用的协同，实现不同渠道应用的前端页面、流程和服务的共享，还有核心业务链路的联通以及前台流程和数据的融合、共享，以支持前台一线业务和商业模式创新。

如何实现前、中、后台的协同

很多人提到中台时自然会问：“既然有中台，那是否有前台和后台？它们各自的职责又是什么呢？”

我们来看一下阿里巴巴对前台、中台和后台职责的定位。前台主要面向客户以及终端销售者，实现营销推广以及交易转换。中台主要面向运营人员，完成运营支撑。后台主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，比如采购、人力、财务和OA等系统。

企业级能力往往是前台、中台、后台协同作战能力的体现。如果把业务中台比作陆军、火箭军和空军等专业军种，主要发挥单一军种的战术专业能力，那么前台就是作战部队，它会根据前线战场的实时作战需求，快速完成不同职能业务中台能力的组合和调度，实现不同业务板块能力的融合，形成强大的组合打击能力完成精准打击，获得最大企业效能。而数据中台就是信息情报中心和联合作战总指挥部，是企业智能化的大脑，它能够汇集各类一线作战板块的数据和信息完成数据分析，制定战略和战术计划，完成不同业务中台能力的智能调度和组合，为前台作战部队提供快速数据和情报服务。后台就是后勤部队，它们不直接面向前台业务，主要提供企业后端支撑和管理能力。

前台

传统企业的早期系统有不少是基于业务领域或企业组织架构来建设的，每个系统都有自己的前端界面和后端业务逻辑，不同系统之间相互独立。用户操作是竖井式，有时一笔业务需要登录多个系统才能完成完整的业务流程

完成中台建设后，进行前台建设时，需要一套企业级整体解决方案，以实现各种不同中台的前端操作、流程和界面的组合、联通和融合。不管后端有多少个中台，前端用户感受到的始终只有一个前台

在前台设计时，我们可以借鉴微前端的设计思想，通过企业级主应用与微前端应用集成，不仅可以实现前端页面逻辑的解耦和页面级服务的复用，还可以根据企业核心业务链路和业务流程，通过对不同业务板块微前端页面的动态组合和编排，实现企业级前台业务的融合。

微前端页面还可以融合到不同终端和渠道应用的核心业务链路中，实现前端页面、流程和功能的组合和复用，也可以满足场景化的销售要求，实现微前端应用的灵活快速发布。

中台

传统企业的核心业务大多是基于集中式架构开发的。这种集中式单体系统，一般都存在扩展能力弱、弹性伸缩能力差的问题，无法适应突发高频访问的互联网业务场景。同时，传统企业数据类应用大多通过ETL工具抽取数据以实现数据建模、统计和报表分析功能。这种传统的数据仓库处理模式往往会存在数据时效性问题，再加上传统数据类应用主要面向企业管理和决策分析，并不是为前台而生的，因此难以快速响应前台一线业务的数据服务要求。

所以，在企业数字化转型时，需要同时解决传统的业务和数据应用建设的问题，采用双中台模式同步建设业务中台和数据中台。

业务中台

业务中台的建设可采用DDD方法，通过领域建模，将可复用的公共能力从各个单体中剥离、沉淀并组合。采用微服务架构，建设成为可共享的通用能力中台。通用能力中台更强调标准化和抽象能力，面向企业所有业务领域实现能力复用。同样地，我们也可以通过微服务架构将核心能力建设成可以面向不同渠道和场景的可复用的核心能力中台。

核心能力中台设计时，需充分释放出极强的快速适应不同业务场景和渠道的企业核心能力，从而在面向不同渠道和客户时，能够快速灵活地持续发挥出企业的核心竞争力优势。而通用能力则可通过抽象和标准化设计，让其具有更强的业务融合和企业级组合与支撑能力，通过企业主应用联通各个不同业务板块，发挥企业业务、数据和流程的黏合剂作用。

业务中台落地后的微服务可以向前端、第三方和其他中台提供API服务，实现通用能力和核心能力复用

有一点需要注意：在将传统集中式单体应用按业务职责和能力细分为微服务，以及建设中台的过程中，会产生越来越多的独立部署的微服务。这样做虽然提升了应用弹性伸缩和高可用能力，但由于微服务之间运行的物理隔离，微服务拆分会导致数据的进一步分离。原来单体系统的一些内部调用也会变成跨微服务调用，再加上前后端分离设计后，还要完成前后端应用集成，这样会增加企业级应用集成的难度。

如果没有合适的设计方法和指导思想，处理不好前台、中台和后台的关系，将会进一步加剧前台业务和数据的孤岛化、碎片化。

数据中台

为了打通数据孤岛，通过数据智能化实现业务和数据融合以及商业模式创新，支持在线数据服务，支持业务中台和前台的精细化数字化运营，企业需要同步建设数据中台。数据中台的主要目标如下。

一是完成企业全域数据的采集与存储，实现不同业务类别中台数据的集中管理。

二是按照标准的数据规范或数据模型，基于不同主题域或场景对数据进行加工和处理，形成面向不同主题和场景的数据应用，比如客户视图、代理人视图、渠道视图、机构视图等不同的数据服务体系。

三是建立数据驱动的运营体系，基于各个维度的数据，萃取数据价值，组合企业各种能力，支持业务智能化和商业模式的创新，实现精细的数字化运营。

相应地，数据中台的建设就可分为三步。

第一步，实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题。

第二步，实现企业级实时或非实时全维度数据的深度融合、加工和共享。

第三步，萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程。

数据中台可以建立在数据仓库或数据平台之上，将数据服务化之后提供给中台或者前台应用。与数据平台相比，数据中台不仅服务于分析型场景，还更多服务于交易型业务场景，为前台业务提供数据智能服务。基于数据库日志捕获的技术，使得数据获取的时效性大大提升，这样就可以为数据中台的交易型场景提供很好的支撑。

综上，数据中台主要完成数据的融合和加工，通过数据智能化，实现智能化的业务和流程创新；通过萃取数据业务价值，提供数据服务，最终实现数字化运营。

后台

后台主要面向企业内部运营和后台管理人员。对于后台，为了实现内部的管理要求，很多人总会习惯将一些管理流程嵌入核心业务链路中。而这类内控管理类的需求对权限、管控规则和流程等要求一般都比较严格，但是大部分管理人员只是参与了某个局部业务环节的审核。这些复杂的管理需求，会凭空增加不同渠道应用的前台界面与核心流程的融合难度以及软件开发的复杂度。

在设计流程审核和管理类功能的时候，其实我们可以考虑按角色或岗位进行功能聚合，将一些复杂的管理需求从通用的核心业务链路中剥离，通过特定程序入口嵌入前台App或应用中，专门供后台管理人员使用。而对于中台与后台的数据交互则可以采用事件驱动的异步化的数据最终一致性模式实现数据复制，减轻中台业务压力。

当管理需求从前台核心业务链路剥离后，前台应用将会具有更好的通用性，可以更容易地实现各渠道前台界面和流程的融合。前台应用或App就可以无差别地同时面向外部客户和内部销售以及其他业务人员，从而促进传统渠道与互联网渠道业务模型的统一和前台应用的融合。

小结

阿里的中台战略起源于平台，所以中台和平台两者本质上有很多共通的地方，目前其实也没有量化的区分指标。如果要说它们之间的主要区别的话，中台设计时会站在企业高度，更多从业务领域出发进行抽象和标准化设计，形成企业级的整体解决方案，实现企业级业务能力的复用。所以，其实我们不必纠结它到底是中台还是平台，而是要看它是否是站在了企业级高度，抽象成了企业级解决方案，真正实现了企业级能力复用。

传统企业在商业模式、发展历程以及企业文化等方面，与互联网企业相比存在很大的差异。在实施中台战略转型时，需要根据自身业务现状和企业具体情况深思熟虑，找到自身的根本诉求和首要重点解决的问题，制定战略目标，分步骤、有计划地推进。

企业的数字化中台战略转型不只是中台的工作，需要我们整体考虑前台、中台和后台的协同、共享、联通与融合。前台通过页面和流程共享，可以实现不同渠道应用之间的业务融合。中台通过API实现业务能力服务复用。而前台、业务中台和数据中台的融合，可以实现传统应用与移动互联应用和业务模型的融合，解决“后端双核心、前端两张皮”的问题。

只有实现了业务、流程和数据的融合，以及业务能力的复用，才能更好地支持业务和商业模式的创新。