现代化企业架构转型案例- 业务建模驱动平台工具(重塑世界观-XX第78期)

一、背景介绍

二、平台工具的价值

企业架构转型是整个企业联动几乎所有环节的复杂工程，工具的引入是效率与质量的有力保障，可以统一大家的流程规范和工作模式，支持业务的灵活配置和敏捷创新，从价值指标设定-价值需求拆解-价值链路设计-价值能力开发-价值能力可视化-价值验证一体化的价值链路，最终形成可复用的企业价值资产。

三、平台工具的设计

由于业务建模平台是支撑整个业务建模的过程，所以从宏观到微观是整个链路的拆解，从业务战略->业务架构->IT架构，所以我们需要进行一体化平台管控和各个能力打通。比如笔者公司基于如下几个板块进行实践，可视化管理平台（需求设计、建模设计、设计和代码相关联）、基础组件管理平台（数据实体、属性模型管理）、外包空间管理平台（云IDE，云权限空间），旨在期望通过战略的落地，一体化平台从需求到交付到价值验证的整个闭环过程。

3.1、业务域&业务身份管理

在现代化企业架构框架白皮书中，我们可以看到元模型中的业务架构中基于业务身份进行后置流程的串联。

3.1.1、职能型中台化结构

如果您的公司属于偏中大型的公司在中台体系下，更多的是职能型部门结构，产品线并未实现闭环，所以笔者的公司当时启动公司级的整个业务域梳理活动，从业务上进行系统产品的归堆，从而形成相对独立闭环的一级域、二级域、三级域。然后基于不同的产品职能部门进行业务身份的区分和注册管理。

3.1.2、产品线型垂直闭环结构

如果您的公司属于初创型公司，更多的是偏产品线部门结构，产品实现闭环，那么我们可以基于产品线进行划分。

无论哪种方式，我们的目标其实都是在基于业务进行企业架构的业务模型梳理。

3.2、业务需求管理

该部分主要是旨在将需求与模型对应，准确表达业务需求，还原业务本质。笔者公司会将需求文档平台打通以及支持通过零售的人-货-场进行价值点拆解，从而更好的可视化BRD/MRD，同时也去除传统需求文档随着项目交换更替丢失的风险。

3.3、构建一体化工具链路平台

随着DevOps到BizDevOps的理念演进，未来趋势会更多偏向于业务-开发-运维一体化方向演进，逐步打通一体化工具链路平台是不可或缺的一部分。

4、一体化工具链路平台的设计

从业务建模到DDD概念映射关系，更好的引导研发同学的IT系统实施落地。笔者公司采用的推广的B-PaaS理论建模方法，本质上没有太多差别，建模方法可以参考专栏中之前提到的建模理论和方法。

4.1、业务建模与IT系统对接

在业务建模中，通过业务领域中的活动任务拆解，从而映射到应用层的服务能力、基于业务身份识别标准化的流程编排，进行业务编排领域层的领域服务进而操作业务对象实体和属性，最终完成远程RPC调用/数据库/缓存等基础设施的行为存储。

4.2、BizDevOps化

我们之前提到为构建一体化平台工具链路，我们旨在期望从业务-开发-运维一体化，所以在从业务建模这块开始进行产品建模、数据建模、流程建模，笔者公司采用的是三个故事（价值故事、用户故事、领域故事）、2个平面（业务平面、数据平面）来完成的上述产品、数据、流程三个建模；然后结合一体化平台进行需求管理和流水线CICD相结合，最终替代客户需求的文档形式，形成企业架构资产。

4.3、测试系统和能力集成

由于上述我们已经需求和流水线相结合，所以最终我们需要将系统测试对接。通过流程模型和产品模型作为测试/用例设计的输入。

这块笔者公司目前结合扩展点和流量录制的方式也在期望能够在更多场景上进行仿真测试，以期望缓解测试的资源和提升测试的效率。

4.4、产品工厂组装（保持中立）

笔者公司曾经提出过Retail as a Service，也就是零售即服务（RaaS），通过标准化零售商城的产品进行标品售卖，但是随着两年多的商业化产品，曾经也探讨过这里面的深水区，业务流程复杂的产品本身不适合进行标准化产品售卖，然而基于模块化的业务进行积木式的搭建、裁剪、自由组合可能会成为一种非常好的方向。这里面需要从顶层设计之初，到整个公司部门的协同，再到最终基础设施边界划分清晰、夯实整个模块化的底座基础，往往这里更比较适合技术型驱动的公司或者对于稳定成熟的法律法规业务的公司，如果互联网业务公司随着业务的不断变化，整日为生存空间考虑的公司基本上是不会投入到这里太大的成本，所以最终基础底座不会特别扎实，从而影响后面整个公司的上层设施。所以基于以上，笔者对此保持中立看法，还需要结合公司业务场景进行考虑。（以下贴上参考资料图，作为一个参考案例）

4.5、数据中台的链路打通

5、参考资料

- 文章中的图片主要参考中电信业务建模平台介绍

- 文章中的部分图片参考现代化企业架构白皮书

-《现代化企业架构的建模与PaaS化》专栏