中台战略是企业数字化转型过程中的一个热门话题。说到中台转型，企业大多对标阿里巴巴。
2015年阿里巴巴提出了“大中台，小前台”的中台战略，提出之初阿里有近 4 亿用户，为超过 1000万各类企业提供服务，业务种类繁多，业务之间相互网状依赖。同时，阿里部门也越来越多，分工越来越细，沟通过多，相互依赖，创新成本非常高，对业务响应也越来越慢。阿里需要找到能够对外界变化快速反应，整合阿里各种基础能力，高效支撑业务创新的机制。
相信很多公司或多或少都遇到过类似的问题，或者随着企业规模越来越大，也正面临着同样的问题。
很多IT人员在谈论中台时说：“我们在系统建设之初就已将产品、用户、权限、客户等公共模块独立成了共享的平台了，这不是中台吗？”也有很多人对中台提出质疑：“中台是个怪名词，它不就是平台吗？”
我们先了解一下阿里业务中台的发展历程。
阿里中台从业务中台和数据中台开始，后来发展出移动中台、技术中台、研发中台等。
（图片参考：2018云栖大会上海峰会）
“阿里业务中台的前身是共享平台，原来的共享平台更多的被当作资源团队，承接各个业务方的需求，为业务方在基础服务上做定制开发。”
看到这里是不是似曾相识呢。有的企业十多年前就已经完成了大一统的集中式系统拆分，将公共能力和核心能力分开建设，解决了公共模块重复投入和重复建设的问题。有的企业共享平台建设时间甚至比阿里还要早，但并没有发展成为像阿里一样的中台。
同样的起点，为什么结果会不一样？
阿里这十年经历了光速发展，同时业务领域快速扩张也增加了业务的复杂性，这种业务发展也只有像阿里这样的互联网企业才会遇到。可以说：业务的发展和复杂性推动了阿里中台的诞生。
我们再进一步来了解阿里业务中台的目标。
“业务中台是把核心服务链路 (会员、商品、交易、营销、店铺、资金结算等) 整体当作一个平台产品来做，为前端业务提供的是业务解决方案，而不是彼此独立的系统。”
这也是我们为什么可以在闲鱼上能直接登录淘宝、支付宝，在刷微博时也能流畅的跳转到淘宝和天猫店铺的原因。您是否感受到了这种跨平台融合能力的强大呢？
这种能力有别于竖井式的系统建设方式。有的企业IT人员说：“我们系统很多，功能很强大，所有业务点都有系统支持，但为什么业务人员总抱怨系统做的不够好？”。
抛开商业模式的原因，问题根源很有可能出在系统的共享、联通和融合能力上。由于企业缺乏整体规划，整体建设目标不够明确，加上天然的组织架构和业务边界，很自然的出现了明显的系统边界，难以支持企业级业务能力的快速融合，不能快速响应企业级的业务和商业模式创新，对前台一线业务支持也不够好，最终影响企业的发展。这种问题在业务领域分布广泛的集团级企业可能会表现得更加明显。
平台化只是将部分公共模块独立为共享平台。虽然平台通过API接口或者数据共享对外提供公共服务，解决了重复建设的问题，但由于这类平台并没有与企业内其他平台或应用实现页面、业务流程和数据从前端到后端企业级的全面融合，没有将核心业务服务链路作为一个整体方案考虑，各平台仍然是独立和分离的，本质上仍然为竖井式建设模式。
共享平台虽然解决了公共能力复用的问题，但离中台的目标还有一段距离！
中台到底是什么？“一千个读者就有一千个哈姆雷特”，业内提法很多。
先听听阿里业务平台负责人玄难老师说说中台是什么？
“中台是一个基础的理念和架构，我们要把所有的基础服务用中台的思路建设，进行联通，共同支持上端的业务。业务中台更多的是支持在线业务，数据中台提供了基础数据处理能力和很多的数据产品给所有业务方去用。业务中台、数据中台、算法中台等等一起提供对上层业务的支撑。”
再听听ThoughtWorks王健老师对中台的定义：
“中台是企业级能力复用平台。”
“中台(无论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应力困境，弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的矛盾，提供一个中间层来适配前台与后台的配速问题，沉淀能力，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应力。”
我们提炼几个中台的关键词：“共享、联通、融合和创新”。联通是前台以及中台之间的联通，融合是前台流程和数据的融合，以共享的方式支持前端一线业务发展和创新。
中台首先体现的是一种企业级的能力，它提供的是一套企业级的整体解决方案，解决小到企业、集团、大到生态圈的能力共享、联通和融合的问题，支持业务和商业模式创新。通过平台联通和数据融合为用户提供一致的体验，更敏捷的支撑前台一线业务。
中台源于平台，但中台与平台比，它更多的体现在一种理念的转变，它更主要体现在三个关键能力上：
1. 对前台业务的快速响应能力；
2. 企业级能力的复用能力；
3. 从前台、中台到后台的设计研发、页面操作、流程服务和数据的无缝联通和融合能力。
其中最关键的是第3点：企业级的无缝联通和融合能力，尤其对于集团化的超大企业而言，这一点至关重要。
传统企业有别于互联网企业，阿里、腾讯等公司是互联网生态圈的创造者和流量入口，传统企业作为生态圈种群中的个体，除了需要做好原有的传统渠道业务外，还需要融入互联网生态圈，其商业模式、个体能力、与其他个体共生的能力决定了它的发展潜力。
相对互联网企业而言，传统企业的渠道应用更多样化，有面向内部人员的柜台类应用、面向外部用户的互联网电商及移动APP类应用。这些应用面向的用户和场景可能不同，但其功能类似，基本涵盖了核心业务能力。此外，传统企业也会将部分核心应用的页面或API服务能力开放给生态圈第三方，相互借力发展。
为了适应不同业务和渠道的发展，过去很多企业的做法是开发很多独立的应用或APP。但由于IT系统建设初期没有企业级的整体规划，平台之间融合不好，导致用户体验不好，关键的是用户也并不想装那么多APP！
为了提高用户体验，实现统一运营，很多企业开始缩减APP数量，通过一个APP集成企业内所有能力，联通前台所有核心业务链路。
由于传统企业的商业模式和IT系统建设发展的历程与互联网企业不完全一样，因此传统企业的中台建设策略与阿里中台战略也应该有所差异。
由于渠道多样化，传统企业不仅要将通用能力中台化（对应领域驱动设计的通用域或支撑域），以实现通用能力的沉淀、共享和复用。还需要将核心能力中台化（对应领域驱动设计的核心域），以满足不同渠道的核心业务能力复用的需求，避免传统核心和互联网不同渠道应用出现“后端双核心、前端两张皮”的问题。这属于业务中台的范畴，需解决核心业务链路的联通和不同渠道服务共享的问题。
通用能力中台和核心能力中台
除了核心业务链路的联通和服务共享，还需要解决系统微服务分拆后的数据孤岛、数据融合和业务创新的问题。这属于数据中台的范畴。采用分布式架构后更应关注微服务拆分后的数据融合。
在中台设计和规划时，需要整体考虑企业内前台、中台以及后台应用的协同，实现不同渠道应用的前端页面、流程和服务的共享，实现核心业务链路的联通以及前台流程和数据的融合，支持业务和商业模式的创新。
中台转型要做到：前台流程融合、中台服务共享、数据融合创新。
分布式和云原生等开源技术的逐步成熟，阿里、腾讯等互联网企业也从互联网业务主战场转型为面向企业的2B技术能力输出。这些成熟的云计算技术将为传统企业中台战略转型赋能，也为传统企业中台建设的技术路线选择提供了多种可能。
1. 先谈谈前台
传统企业早期系统有不少是基于业务领域或组织架构来建设的，每个系统都有自己的前端，相互独立，用户操作是竖井式，需要登录多个系统才能完成完整的业务流程。
竖井式系统
中台后的前台建设要有一套综合考虑业务边界、流程和平台的整体解决方案，实现各不同中台前端操作、流程和界面的联通和融合。不管后端有多少个中台，前端用户感受只有一个前台！
前端操作、流程和界面的联通和融合
前台设计中可以借鉴微前端的设计思想，在企业内不仅实现前端解耦和复用，还可以根据核心链路和业务流程，通过对微前端页面的动态组合和流程编排，实现前台业务的融合。
前端页面可自然融合到不同终端和渠道应用核心业务链路中，实现前端页面、流程和功能复用。相关设计思路我会在“如何实现前台的融合”章节中讲到。
2. 再说说中台
这里只讨论业务中台和数据中台。
传统企业核心业务大多基于集中式架构开发，单体系统存在扩展性和弹性伸缩能力差的问题，无法适应忽高忽低的互联网业务场景。而数据类应用也多数通过ETL工具抽取数据实现数据建模、统计和报表分析功能，但由于数据时效和融合能力不够，再加上传统数据类应用本来不是为前端而生，难以快速响应前端一线业务。
业务中台的建设可采用领域驱动设计方法，通过领域建模，将可复用的公共能力从各单体剥离，沉淀并组合，采用微服务架构模式，建设成为可共享的通用能力中台。同样的将核心能力采用微服务架构模式，建设成为可面向不同渠道和场景的可复用的核心能力中台。业务中台面向前台、第三方和其它中台提供API服务，实现通用能力和核心能力的复用。
面向前台、第三方和其它中台提供API服务
需要记住一点：在将传统集中式单体按业务职责和能力细分为微服务，建设中台的过程中，会产生越来越多独立部署的微服务。虽然提升了应用弹性和高可用能力，但由于微服务的物理隔离，原来一些系统内的调用会变成跨微服务调用，再加上前后端分离，微服务拆分会导致数据进一步分离，增加企业级应用集成的难度。
如果没有合适的设计和指导思想，处理不好前台、中台和后台的关系，将会进一步加剧前台流程和数据的孤岛化和碎片化。
数据中台的主要目标是打通数据孤岛，实现业务融合和创新，包括三大主要职能：一是完成企业全域数据的采集与存储，实现各不同业务类别中台数据的汇总和集中管理。二是按照标准的数据规范或数据模型，将数据按照不同主题域或场景进行加工和处理，形成面向不同主题和场景的数据应用，如客户视图、代理人视图、渠道视图、机构视图等不同数据体系。三是建立业务需求驱动的数据体系，基于各个维度的数据，深度萃取数据价值，支持业务和商业模式的创新。
数据中台的建设可分为三步走。第一步实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题。第二步实现企业级实时或非实时全维度数据的深度融合、加工和共享。第三步萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程。
数据中台不仅限于分析型场景，也适用于交易型场景。它可以建立在数据仓库或数据平台之上，将数据服务化之后提供给业务系统。基于数据库日志捕获的技术，使数据的时效性大大提升，可为交易型场景提供很好的支撑。
数据中台主要完成数据的融合和加工，萃取数据业务价值，支持业务创新，对外提供数据共享服务。
3. 顺带说说后台
很多人提到中台时自然会问：“既然有前台和中台，是否有后台？那后台的职责是什么呢？”。
我们来看一下阿里对前台、中台和后台的定位。
前台主要面向客户以及终端销售者，实现营销推广以及交易转化。
中台主要面向运营人员，完成运营支撑。
后台主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，如采购、人力、财务和OA等系统。
为了实现内部的管理要求，很多人习惯性将这些管理要求嵌入到核心业务流程中。而一般来说这类内控管理需求对权限、管控规则和流程等要求都比较高，但是大部分管理人员只是参与了某个局部业务环节的审核。这类复杂的管理需求，会凭空增加不同渠道应用前台界面和核心流程的融合难度以及软件开发的复杂度。
在设计流程审核和管理类功能时，可以考虑按角色或岗位进行功能聚合。将复杂的管理需求从通用的核心业务链路中剥离，参考小程序的建设模式，通过特定程序入口嵌入前台APP或应用中。
管理需求从前台核心业务链路剥离后，前台应用将具有更好的通用性，可更容易的实现各渠道前台界面和流程的融合。一个前台应用或APP可以无差别的同时面向外部互联网用户和内部业务人员，从而促进传统渠道与互联网渠道应用前台的融合。
4. 小结
企业的中台转型不只是中台的工作，需要整体考虑前台、中台和后台的协同、共享、联通和融合。
前台通过页面和流程共享实现不同渠道应用之间前台融合，中台通过API实现服务共享。
通过前台、业务中台和数据中台的融合实现传统应用与互联网应用的融合，解决“后端双核心、前端两张皮”的问题。
能力复用了，前台流程和数据融合了才能更好的支持业务的融合和商业模式的创新。
为什么要单独来说前台的融合呢？因为前台的融合对企业级的业务融合非常重要！
中台通过微服务实现了后端应用的解耦，提高了应用的弹性伸缩能力。但中台化的过程中也会将单体应用拆分出许多的微服务，前台团队将会面对多个微服务团队。如何实现不同中台的前台融合？前台应用如何正确的连接和拼装这些服务？不是一件很容易的事情。
为解决前台与中台的集成以及前台页面和流程的融合，我们借鉴微前端设计思想。在前端设计时，对齐微服务功能和职责，按照领域模型和微服务边界，构建与微服务前端功能相对应的可以独立部署、完全自治、松耦合的页面聚合，每个聚合只负责特定的 UI 元素和特定的功能。一个完成特定微服务前端功能的页面聚合就是一个微前端。
微前端与微服务集成后可形成从前端到中台可独立开发、测试、部署和运维的并且功能自包含的微前端业务组件。微前端除了可以实现前端页面的解耦外，还可实现前端页面的复用，这也与中台服务复用理念是一脉相承。
在微前端之上还有一个企业级的前台应用，它可以是一个企业级的移动APP，也可以是PC端应用，按照正确的业务逻辑和流程能够编排和动态加载企业内所有微前端页面，完成企业内核心业务链路的融合，给用户提供一致体验。
通用能力微前端大多作为共享的页面和功能，其功能入口一般常驻前台APP中，如购物车、商品、会员以及支付等功能。核心能力微前端主要完成核心业务前端功能，一般会根据业务类型动态加载对应业务的微前端页面。比如：可以根据商品类型，加载核心业务微前端录单页面。在完成所有保单录入后，加载订单共享微前端页面，完成订单生成。订单生成后，加载支付共享微前端页面完成支付等等。共享微前端可在不同渠道前台实现复用。
微前端在前台的融合
企业级的核心业务链路在企业级前台中实现，它可以根据业务逻辑动态编排和加载各中台的微前端页面，完成企业级核心业务链路，在企业级前台实现各不同中台能力的融合。
中台的页面、流程和功能在其对应的微前端中实现，它是一个功能和流程自包含的前端业务组件。微前端页面和功能根据企业前台应用的整体业务逻辑和流程动态融入到核心业务链路中。
微前端和微服务集成后形成可复用的业务组件。不管是核心微前端还是通用微前端，均可在不同的企业级前台应用实现复用，从而实现不同中台的前台页面、流程和功能的共享、联通和融合。
用技术语言总结就是：“前台聚合，中台解耦，数据融合，业务创新”。先有共享、后有联通、再有创新。
推荐阅读
