|终于有人把前台、中台、后台都讲明白了

导读：很多人提到中台时自然会问：“既然有中台，那是否有前台和后台？它们各自的职责又是什么呢？”本文为你详细解答。
作者：欧创新邓頔
来源：华章科技

本文插图

我们来看一下阿里巴巴对前台、中台和后台职责的定位。

前台主要面向客户以及终端销售者，实现营销推广以及交易转换。
中台主要面向运营人员，完成运营支撑。
后台主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，比如采购、人力、财务和OA等系统。

企业级能力往往是前台、中台、后台协同作战能力的体现。
如果把业务中台比作陆军、火箭军和空军等专业军种，主要发挥单一军种的战术专业能力，那么前台就是作战部队，它会根据前线战场的实时作战需求，快速完成不同职能业务中台能力的组合和调度，实现不同业务板块能力的融合，形成强大的组合打击能力完成精准打击，获得最大企业效能。
而数据中台就是信息情报中心和联合作战总指挥部，是企业智能化的大脑，它能够汇集各类一线作战板块的数据和信息完成数据分析，制定战略和战术计划，完成不同业务中台能力的智能调度和组合，为前台作战部队提供快速数据和情报服务。
后台就是后勤部队，它们不直接面向前台业务，主要提供企业后端支撑和管理能力。
下面分别展开详细介绍。
01 前台
传统企业的早期系统有不少是基于业务领域或企业组织架构来建设的，每个系统都有自己的前端界面和后端业务逻辑，不同系统之间相互独立。用户操作是竖井式，有时一笔业务需要登录多个系统才能完成完整的业务流程，如图1-2所示。

本文插图

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

本文插图

▲图1-3 前台业务的融合
在前台设计时，我们可以借鉴微前端的设计思想，通过企业级主应用与微前端应用集成，不仅可以实现前端页面逻辑的解耦和页面级服务的复用，还可以根据企业核心业务链路和业务流程，通过对不同业务板块微前端页面的动态组合和编排，实现企业级前台业务的融合。
微前端页面还可以融合到不同终端和渠道应用的核心业务链路中，实现前端页面、流程和功能的组合和复用，也可以满足场景化的销售要求，实现微前端应用的灵活快速发布。
02 中台
传统企业的核心业务大多是基于集中式架构开发的。这种集中式单体系统，一般都存在扩展能力弱、弹性伸缩能力差的问题，无法适应突发高频访问的互联网业务场景。同时，传统企业数据类应用大多通过ETL工具抽取数据以实现数据建模、统计和报表分析功能。
这种传统的数据仓库处理模式往往会存在数据时效性问题，再加上传统数据类应用主要面向企业管理和决策分析，并不是为前台而生的，因此难以快速响应前台一线业务的数据服务要求。
所以，在企业数字化转型时，需要同时解决传统的业务和数据应用建设的问题，采用双中台模式同步建设业务中台和数据中台。
1. 业务中台
业务中台的建设可采用DDD（Domain Driven Design ，领域驱动设计）方法，通过领域建模，将可复用的公共能力从各个单体中剥离、沉淀并组合。采用微服务架构，建设成为可共享的通用能力中台。通用能力中台更强调标准化和抽象能力，面向企业所有业务领域实现能力复用。同样地，我们也可以通过微服务架构将核心能力建设成可以面向不同渠道和场景的可复用的核心能力中台。
核心能力中台设计时，需充分释放出极强的快速适应不同业务场景和渠道的企业核心能力，从而在面向不同渠道和客户时，能够快速灵活地持续发挥出企业的核心竞争力优势。
而通用能力则可通过抽象和标准化设计，让其具有更强的业务融合和企业级组合与支撑能力，通过企业主应用联通各个不同业务板块，发挥企业业务、数据和流程的黏合剂作用。
业务中台落地后的微服务可以向前端、第三方和其他中台提供API服务，实现通用能力和核心能力复用，如图1-4所示。

本文插图

▲图1-4 微服务对外的服务方式
有一点需要注意：在将传统集中式单体应用按业务职责和能力细分为微服务，以及建设中台的过程中，会产生越来越多的独立部署的微服务。
这样做虽然提升了应用弹性伸缩和高可用能力，但由于微服务之间运行的物理隔离，微服务拆分会导致数据的进一步分离。原来单体系统的一些内部调用也会变成跨微服务调用，再加上前后端分离设计后，还要完成前后端应用集成，这样会增加企业级应用集成的难度。
如果没有合适的设计方法和指导思想，处理不好前台、中台和后台的关系，将会进一步加剧前台业务和数据的孤岛化、碎片化。
2. 数据中台
为了打通数据孤岛，通过数据智能化实现业务和数据融合以及商业模式创新，支持在线数据服务，支持业务中台和前台的精细化数字化运营，企业需要同步建设数据中台。数据中台的主要目标如下。

一是完成企业全域数据的采集与存储，实现不同业务类别中台数据的集中管理。
二是按照标准的数据规范或数据模型，基于不同主题域或场景对数据进行加工和处理，形成面向不同主题和场景的数据应用，比如客户视图、代理人视图、渠道视图、机构视图等不同的数据服务体系。
三是建立数据驱动的运营体系，基于各个维度的数据，萃取数据价值，组合企业各种能力，支持业务智能化和商业模式的创新，实现精细的数字化运营。

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

第一步，实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题。
第二步，实现企业级实时或非实时全维度数据的深度融合、加工和共享。
第三步，萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程。

数据中台可以建立在数据仓库或数据平台之上，将数据服务化之后提供给中台或者前台应用。与数据平台相比，数据中台不仅服务于分析型场景，还更多服务于交易型业务场景，为前台业务提供数据智能服务。基于数据库日志捕获的技术，使得数据获取的时效性大大提升，这样就可以为数据中台的交易型场景提供很好的支撑。
综上，数据中台主要完成数据的融合和加工，通过数据智能化，实现智能化的业务和流程创新；通过萃取数据业务价值，提供数据服务，最终实现数字化运营。
03 后台
后台主要面向企业内部运营和后台管理人员。对于后台，为了实现内部的管理要求，很多人总会习惯将一些管理流程嵌入核心业务链路中。而这类内控管理类的需求对权限、管控规则和流程等要求一般都比较严格，但是大部分管理人员只是参与了某个局部业务环节的审核。
这些复杂的管理需求，会凭空增加不同渠道应用的前台界面与核心流程的融合难度以及软件开发的复杂度。
在设计流程审核和管理类功能的时候，其实我们可以考虑按角色或岗位进行功能聚合，将一些复杂的管理需求从通用的核心业务链路中剥离，通过特定程序入口嵌入前台App或应用中，专门供后台管理人员使用。而对于中台与后台的数据交互则可以采用事件驱动的异步化的数据最终一致性模式实现数据复制，减轻中台业务压力。
当管理需求从前台核心业务链路剥离后，前台应用将会具有更好的通用性，可以更容易地实现各渠道前台界面和流程的融合。前台应用或App就可以无差别地同时面向外部客户和内部销售以及其他业务人员，从而促进传统渠道与互联网渠道业务模型的统一和前台应用的融合。
关于作者：欧创新，某大型保险公司架构师，拥有十多年的软件架构设计经验。热衷于DDD、中台和分布式微服务架构设计。在DDD、中台和分布式微服务架构设计方面有深厚的积累，擅长分布式微服务架构设计。
邓頔，某大型保险公司高级工程师，全国青年岗位能手。致力于基于DDD的企业级中台微服务架构改造实践，精通前端开发相关技术栈，拥有丰富的企业级微前端实战经验。
本文摘编自《中台架构与实现：基于DDD和微服务》，经出版方授权发布。