有关韩信点兵下一句什么情况?

　　文希望你能清楚平台与中台的主要差异是什么，中台到底是什么，传统企业的中台建设策略是否应该和阿里一样等内容。

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

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

　　阿里业务中台的前身是共享平台，而原来的共享平台更多是被当作资源团队，承接各业务方的需求，并为业务方在基础服务上做定制开发。

　　阿里业务中台的目标是把核心服务链路（会员、商品、交易、营销、店铺、资金结算等）整体当作一个平台产品来做，为前端业务提供的是业务解决方案，而不是彼此独立的系统。这种能力有别于传统的烟囱式的系统建设方式。

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

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

　　有的企业由于缺乏总体规划，应用建设目标不够明确，加上天然的组织架构、数据和业务边界，很自然地就出现了明显的系统边界和系统重复建设的问题，难以支持企业级业务能力的快速融合，不能快速响应企业级业务和商业模式创新，对前台一线业务支持和融合也不够好，难以在前台形成一致的用户体验，最终影响企业业务发展。

　　这种问题在业务领域分布广泛的大型集团级企业可能会更加突出。而对于大型企业而言，要想解决从“可用”到“好用”的问题，其实还有很长的路要走。

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

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

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

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

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

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

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

　　相对互联网企业而言，传统企业的渠道应用更加多样化，有面向内部人员的门店类应用、面向外部用户的互联网电商以及移动App类应用。这些应用面向的用户和场景可能不同，但其功能与产品同质化严重，基本涵盖了企业的核心业务能力。

　　此外，传统企业也会将部分核心应用的页面或API服务能力开放给生态圈第三方，实现业务的优势互补，相互借力发展。

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

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

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

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

　　“分”的主要目标是通过业务领域边界划分和微服务拆分，建立稳定的、单一职能的领域模型，让业务和应用具有更强的扩展和复用能力。但分不是目的，而是手段，是根据单一职责原则实现业务能力的复用和高内聚。

　　分的过程主要发生在业务中台，在完成业务领域和微服务拆分后，降低了应用建设的复杂度，使业务和应用具有更强的扩展能力和稳定性。

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

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

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

　　对于相同的核心业务领域，传统核心应用和移动互联应用分别采用不同的技术栈重复建设，出现传统应用和移动互联应用两个核心。而两者在前端技术栈和展现方式又完全不同，无法复用。

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

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

　　关于作者：欧创新，某大型保险公司架构师，拥有十多年的软件架构设计经验。热衷于DDD、中台和分布式微服务架构设计。在DDD、中台和分布式微服务架构设计方面有深厚的积累，擅长分布式微服务架构设计。

　　邓頔，某大型保险公司高级工程师，全国青年岗位能手。致力于基于DDD的企业级中台微服务架构改造实践，精通前端开发相关技术栈，拥有丰富的企业级微前端实战经验。

　　推荐语：资深架构师撰写，系统阐述基于DDD的中台和微服务建设方法论，深刻揭示中台从领域建模到微服务落地完整过程。返回搜狐，查看更多