转发读者平和老师的实践总结：B 业务架构阶段

参考资料：《聚合架构》

付晓岩老师的《聚合架构》是2021年9月出版的，他也在很多渠道做了多次分享，但是我总是听不懂。

2023年初，我把付老师公开分享的60节视频课程反复观看，对比原书做读书笔记，忽然有一天就看懂了这套三角形，那时是热泪盈眶的

。初闻不知曲中意，再闻已是曲中人。作者是业务岗位出身，从内向外总结，业务->构件->文化->架构->工程管理，打造了适合自身的方法论，好大的一盘棋！我个人的成长则是完全相反的过程，我的第一份工作就是SAP ABAP Consultant，学习历程则是代码->数据->项目管理->领导力->架构->构件。

当年一直不明白SAP为啥把实施工程师叫顾问，这个头衔也被研发中心其他产品线的小伙伴取笑过，其实是自己一直没领会SAP的对专职人员的角色定位。component这个词经常出现在文档里，我却视而不见，例如SD-BF-PR表示Sales&Distribution-BasicFuction-Pricing&Conditions，行为与数据的结合即为组件。

我的读后感简述如下：

• 整本书逻辑严谨，充满了哲科的味道；
• 说“人话”，不局里局气，不堆砌大词儿；
• 体系覆盖面很大，读者要有足够交叉学科知识的储备；

下面，我们进入实战，参考聚合架构的方法去编写业务架构工件。

第一步 流程的进一步细化 参考了BPMN的标准，需要明确：泳道、任务的先后顺序、路由条件。

其中的“检查配货计划”任务是一个比较大的任务，其下层需要做子流程，其实也是对程序的模块化指导：

“销售执行”和“检查配货计划”都对应PCF中的活动，里边的节点对应PCF中的任务？这里我是有困惑的，还需要去研究一下流程架构这个知识体系。也许，不同知识体系的工件之间并不一定存在明确的对照关系，中医的肾与西医的肾是一个东西吗？

这时形成的流程图，肯定不准确、不详尽，无法支持系统开发，但必须要有，就是一个靶子。 然后，需要将价值流阶段、业务能力抽象出来，尽管这两个工件在聚合架构里没有明确的主张，我还是觉得它俩对快速理解业务很有帮助，与干系人进行高阶拉齐的时候，总不能拿着流程图讲细节吧。在SAP的EAM中明确呈现了Business Processes、Value Streams、Business Capabilities的工件。先做到能力无遗漏，然后就是流程里如何编排、调整、优化了。这里我省略了目录，直接用了图。目录其实是非常重要的，比如书的目录、数据资产的目录。

第二步 概念模型设计 从这里开始，我们进入了数据模型设计，遵从了《聚合架构》的方法，将业务架构与数据架构一起做设计。可能跟我的技术出身背景有关，我对ER模型有执念，不尽早看到心里就不安稳，就像我的一个河北同学每顿饭如果吃不到馒头，就感觉没吃饱。

2018年数据治理最火热的时候，我通过系统的学习发现这件事情不好做，就是因为很多系统连像样的数据模型都拿不出来，治表不治里的事情，价值很难体现的。Datalau的数据治理思路，也是从数据模型设计入手，从源头入手。问渠哪得清如许，为有源头活水来。

参考了经典《数据建模》，这里也有我在做集团级BI项目时养成的习惯，维度、指标的定义都要用文字明确写下来，目的也是为了统一语言。“如何”一定要考虑全面，数据流全靠它在支撑，其它的概念把关键的例举出来就可以，实体太多的话，在图上显得乱。如果要用指标体系设计的思路来做类比，此处只关注原子指标，后续阶段再考虑衍生指标和复合指标。

流程工件与数据模型概念实体间没有必然的对照关系，我把这个抽象的过程叫做“涌现”。最终形成的概念模型如下图，我的ER建模是刚学的，可能有不准确的地方，仅供参考：

第三步 业务构件设计

设计过程完全遵从《聚合架构》的方法，但是呈现形式换成了目录，因为在实际中也不可能在流程图上装下那么多东西，付老师应该只是为了讲解设计过程。在某个复杂问题上，为了讨论、清晰呈现，也可以画出图来，TOGAF把它叫做view，例如建筑师视图、装修工视图、房屋中介视图。

当我们得到了这样一个目录后，开发工作的人员分工其实就已经做出来了，而且任何后期变更都已经被控制在组件内部了，有点SOA的味道，不怕甲方作妖。业务活动或者流程就可以通过业务组件的任意编排去实现，这就是所谓的组装式。数据治理的第一个难点就是数据认责，这里也在业务侧和技术侧都做了明确，业务构件即职能，就是组织内业务部门的划分依据。

例如批次智能推荐、可用量检查，可以以业务规则的组件形式被独立出来，便于扩展为新技术的应用场景，如AI。

第四步 逻辑模型设计

数据架构师和开发经理此时应该入场，进行系统的详细设计，瀑布式或者敏捷式按需确定，应该交付详细、准确的用户操作手册和逻辑模型。

这里其实可以开始应用架构的设计工作了。

总结

经过以上的解构、重构，积极意义如下：

• 干系人充分理解系统设计蓝图，确保与战略对齐，有助于收益的实现；
• 扎实的架构工件，有利于项目团队成员达成一致，避免了设计偏差和变更；
• 知识被保留在组织内部，确保了系统的可持续演化；

至此，我的知识体系构建基本完成，把野路子进行了标准化改造。学习的过程很烧脑，黑暗隧道的尽头，终于看到了光！