终于有人把前台、中台、后台都讲明白了( 二 )


核心能力中台设计时 , 需充分释放出极强的快速适应不同业务场景和渠道的企业核心能力 , 从而在面向不同渠道和客户时 , 能够快速灵活地持续发挥出企业的核心竞争力优势 。
而通用能力则可通过抽象和标准化设计 , 让其具有更强的业务融合和企业级组合与支撑能力 , 通过企业主应用联通各个不同业务板块 , 发挥企业业务、数据和流程的黏合剂作用 。
业务中台落地后的微服务可以向前端、第三方和其他中台提供API服务 , 实现通用能力和核心能力复用 , 如图1-4所示 。
终于有人把前台、中台、后台都讲明白了
本文插图
▲图1-4 微服务对外的服务方式
有一点需要注意:在将传统集中式单体应用按业务职责和能力细分为微服务 , 以及建设中台的过程中 , 会产生越来越多的独立部署的微服务 。
这样做虽然提升了应用弹性伸缩和高可用能力 , 但由于微服务之间运行的物理隔离 , 微服务拆分会导致数据的进一步分离 。 原来单体系统的一些内部调用也会变成跨微服务调用 , 再加上前后端分离设计后 , 还要完成前后端应用集成 , 这样会增加企业级应用集成的难度 。
如果没有合适的设计方法和指导思想 , 处理不好前台、中台和后台的关系 , 将会进一步加剧前台业务和数据的孤岛化、碎片化 。
2. 数据中台
为了打通数据孤岛 , 通过数据智能化实现业务和数据融合以及商业模式创新 , 支持在线数据服务 , 支持业务中台和前台的精细化数字化运营 , 企业需要同步建设数据中台 。 数据中台的主要目标如下 。

  • 一是完成企业全域数据的采集与存储 , 实现不同业务类别中台数据的集中管理 。
  • 二是按照标准的数据规范或数据模型 , 基于不同主题域或场景对数据进行加工和处理 , 形成面向不同主题和场景的数据应用 , 比如客户视图、代理人视图、渠道视图、机构视图等不同的数据服务体系 。
  • 三是建立数据驱动的运营体系 , 基于各个维度的数据 , 萃取数据价值 , 组合企业各种能力 , 支持业务智能化和商业模式的创新 , 实现精细的数字化运营 。
相应地 , 数据中台的建设就可分为三步 。
  • 第一步 , 实现各中台业务数据的汇集 , 解决数据孤岛和初级数据共享问题 。
  • 第二步 , 实现企业级实时或非实时全维度数据的深度融合、加工和共享 。
  • 第三步 , 萃取数据价值 , 支持业务创新 , 加速从数据转换为业务价值的过程 。
数据中台可以建立在数据仓库或数据平台之上 , 将数据服务化之后提供给中台或者前台应用 。 与数据平台相比 , 数据中台不仅服务于分析型场景 , 还更多服务于交易型业务场景 , 为前台业务提供数据智能服务 。 基于数据库日志捕获的技术 , 使得数据获取的时效性大大提升 , 这样就可以为数据中台的交易型场景提供很好的支撑 。
综上 , 数据中台主要完成数据的融合和加工 , 通过数据智能化 , 实现智能化的业务和流程创新;通过萃取数据业务价值 , 提供数据服务 , 最终实现数字化运营 。
03 后台
后台主要面向企业内部运营和后台管理人员 。 对于后台 , 为了实现内部的管理要求 , 很多人总会习惯将一些管理流程嵌入核心业务链路中 。 而这类内控管理类的需求对权限、管控规则和流程等要求一般都比较严格 , 但是大部分管理人员只是参与了某个局部业务环节的审核 。
这些复杂的管理需求 , 会凭空增加不同渠道应用的前台界面与核心流程的融合难度以及软件开发的复杂度 。
在设计流程审核和管理类功能的时候 , 其实我们可以考虑按角色或岗位进行功能聚合 , 将一些复杂的管理需求从通用的核心业务链路中剥离 , 通过特定程序入口嵌入前台App或应用中 , 专门供后台管理人员使用 。 而对于中台与后台的数据交互则可以采用事件驱动的异步化的数据最终一致性模式实现数据复制 , 减轻中台业务压力 。