今天是双 11, 阿里提出的中台概念和战略很好的支撑了阿里电商平台的敏捷快速响应和高并发访问能力, 也可以说是阿里电商平台的一次成功数字化转型. 而对于企业中台, 在我博客前面很多文章都专门提到过, 基本是每过一段时间, 自己也会对企业中台进行重新思考.
首先我再整理下我原来提到过的一些关于企业中台的观点
1. 企业中台是企业共性业务能力的下沉, 体现的是业务能力可复用和灵活组合
2. 企业中台区别传统的 IaaS 和 PaaS 平台, 更多是一个业务平台, 包括了业务中台和数据中台
3. 中台构建本身参考了微服务架构思想, 并基于业务高内聚进行了微服务化并提供能力
对于一个专业细分的业务领域而言, 软件企业要做的就是将对业务领域的多年经验和理解沉淀到业务中台, 形成可复用的各个业务中台能力中心, 然后为上层灵活多变的各类应用提供服务能力. 由于沉淀了业务理解形成通用化, 可复用的业务模型, 那么这个能力被不会轻易被模仿 .
简单来说技术平台 业务中台 前台应用, 三者的占比大致应该为 3:5:2 的关系. 也就是说强大的业务中台建立后, 产品化程度可以达到 80% 左右 , 而且能够快速的应对前台应用的开发和定制. 这样项目团队灵活, 敏捷, 低成本快速交付的目标才能达到.
而今天当我重新再谈企业中台的时候, 可以理解为:
业务平台 + 能力开放平台 构成了企业中台 , 即业务平台各微服务模块化后的业务中心首先提供可复用的业务能力 API 接口, 然后这些接口能力再通过能力开放平台开放出去并统一管理.
如何来构建企业的业务中台?
每个企业在进行数字化转型的时候一定会思考如何将企业业务数据化, 而构建企业中台是企业核心业务数据化的一个最佳方式. 企业中台构建的真正的困难在于并不是全新构建一个新的 IT 架构体系, 而是需要结合传统已有的 IT 架构体系, 来转型到一个企业中台 + 灵活前台的新架构体系. 既要能够适应性的业务需求, 又要能够兼容老的业务功能, 这才是构建中台最困难的地方.
在前面谈企业微服务架构转型的时候我也谈到过, 企业转型的步骤和可行的一些逐步迁移方式, 今天再重新进行下整理和说明, 重点还是围绕数据维度来进行.
其一: 迁移核心基础主数据, 形成各个中台中心
主数据在企业内应用相当广泛, 在构建企业中台的时候可以考虑先迁移和新构建各个基础主数据中心, 提供共性基础主数据服务能力. 如我们常说的用户中心, 人员中心, 供应商中心, 物料中心, 客户中心等, 首先将这些基础主数据迁移出来独立进行构建, 然后提供共享服务 API 接口.
其二: 迁移核心动态共享数据, 形成各中台中心
在基础数据迁移后, 后续就可以考虑迁移各个核心动态数据, 形成各中台中心, 类似的包括了项目, 合同, 订单等, 这些共享数据在传统的业务系统架构下往往会被多个业务系统所使用, 而在迁移后形成独立的微服务模块并提供共享服务能力, 前台的应用模块再根据实际需求进行消费和使用.
其三: 识别和剥离共性的业务规则, 形成独立的规则中心 (可选)
在基础主数据和核心动态数据分别识别和规划为不同的中台微服务模块后, 剩下的就是要识别共享的业务规则处理, 形成规则类处理中心. 规则本身可复用往往是中台层构建最难的一块.
其四: 基于已有的各个中台模块, 剥离原有业务系统的外围配套功能, 形成独立的微服务模块
在前面几个步骤, 关键的中台层数据能力形成后, 我们就可以开始考虑逐步的剥离原有业务系统的各个业务功能模块, 形成独立的微服务. 比如对于传统供应链系统, 可以逐步将招投标, 采购请购等模块进行剥离, 形成独立的微服务模块. 要明白这些外围模块最终都是形成真正生效的数据写入到中台各中心, 类似合格供应商, 物料, 采购订单等. 这个步骤必须要在前面几个步骤完成后再进行, 即外围功能剥离为独立模块后需要调用前面各个中台中心提供的 API 接口能力进行功能构建.
来源: http://www.tuicool.com/articles/22uAN3v