认识达内从这里开始

我们在前几期的文章中给大家简单介绍了企业中台搭建需要用到的一些开发技术等内容，而本文我们就再来了解一下，企业前中后台协同应用方法分享。

1.前台

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

中台后的前台建设要有一套综合考虑业务边界、流程和平台的整体解决方案，以实现各不同中台前端操作、流程和界面的联通、融合。不管后端有多少个中台，前端用户感受到的就是只有一个前台。

在前台设计中我们可以借鉴微前端的设计思想，在企业内不仅实现前端解耦和复用，还可以根据核心链路和业务流程，通过对微前端页面的动态组合和流程编排，实现前台业务的融合。

前端页面可以很自然地融合到不同的终端和渠道应用核心业务链路中，实现前端页面、流程和功能复用。

2.中台

传统企业的核心业务大多是基于集中式架构开发的，而单体系统存在扩展性和弹性伸缩能力差的问题，因此无法适应忽高忽低的互联网业务场景。而数据类应用也多数通过ETL工具抽取数据实现数据建模、统计和报表分析功能，但由于数据时效和融合能力不够，再加上传统数据类应用本来就不是为前端而生的，因此难以快速响应前端一线业务。

业务中台的建设可采用领域驱动设计方法，通过领域建模，将可复用的公共能力从各个单体剥离，沉淀并组合，采用微服务架构模式，建设成为可共享的通用能力中台。

同样的，我们可以将核心能力用微服务架构模式，建设成为可面向不同渠道和场景的可复用的核心能力中台。业务中台向前台、三方和其它中台提供API服务，实现通用能力和核心能力的复用。

在将传统的集中式单体应用按照业务职责和能力进行微服务拆分，构建中台的过程中，会产生越来越多独立部署的微服务。这种做法虽然提升了应用的弹性和高可用性，但由于微服务的物理隔离，原本系统内部的调用变成了跨微服务的调用。再加上前后端的分离，微服务的拆分导致数据进一步分离，增加了企业级应用集成的难度。

如果没有合适的设计和指导思想，无法妥善处理前台、中台和后台之间的关系，将会进一步加剧前台流程和数据的孤岛化和碎片化。

数据中台的主要目标是打通数据孤岛，实现业务的融合和创新，包括以下三个主要职能：

完成企业范围内的数据采集和存储，实现各个不同业务中台数据的汇总和集中管理。

根据标准的数据规范或数据模型，对数据进行加工和处理，形成面向不同主题和场景的数据应用，例如客户视图、代理人视图、渠道视图、机构视图等不同的数据体系。

建立以业务需求为驱动的数据体系，深度挖掘数据的价值，支持业务和商业模式的创新。

相应地，数据中台的建设可以分为三个步骤：

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

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

三步是挖掘数据的价值，支持业务创新，加快将数据转化为业务价值的过程。

数据中台不仅适用于分析型场景，也适用于交易型场景。它可以建立在数据仓库或数据平台之上，将数据服务化后提供给业务系统。借助基于数据库日志捕获的技术，数据的时效性大大提升，从而为交易型场景提供良好的支持。

综上所述，数据中台的主要任务是实现数据的融合和加工，挖掘数据的业务价值，并支持业务创新，同时向外部提供数据共享服务。

3.后台

很多人在提到中台时常会问：“既然有前台和中台，那是否有后台，后台的职责又是什么?”

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

前台主要面向客户和终端销售者，实现营销推广和交易转化。

中台主要面向运营人员，提供运营支撑。

后台主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，例如采购、人力资源、财务和OA等系统。

对于后台而言，为了满足内部管理需求，许多人习惯将这些管理要求嵌入到核心业务流程中。然而，通常情况下，这类内部控制管理需求对于权限、管控规则和流程等方面的要求都较高，但大部分管理人员只是参与某个局部业务环节的审核。这种复杂的管理需求会增加不同渠道应用前台界面和核心流程的融合难度，并增加软件开发的复杂性。

在设计流程审核和管理类功能时，我们可以考虑按照角色或岗位进行功能聚合，将复杂的管理需求从通用的核心业务链路中剥离出来。可以借鉴小程序的建设模式，通过特定的程序入口嵌入前台应用或APP中。

将管理需求从前台核心业务链路中剥离后，前台应用将具有更好的通用性，更容易实现各个渠道前台界面和流程的融合。一个前台应用或APP可以无差别地面向外部互联网用户和内部业务人员，从而促进传统渠道和互联网渠道应用前台的融合。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。