业务架构精简元模型

说到企业架构(EA)，最权威的标准文件就是Togaf了。
Togaf中，把企业架构分为业务架构、数据架构、应用架构和技术架构。其中的业务架构，是指导后面3个架构的，是业务的高级模型。即使现在流行敏捷开发，但业务架构还是要先设计出来，作为敏捷的”框架“或”蓝图“。敏捷开发通过迭代形成的业务模型是业务架构的细节。
下图是Togaf中业务架构的”元模型“，即主要组件及其之间的关系。理解了”元模型“，业务架构就入门了：

Togaf的元模型好在给出了比较全的组件，特别是组件之间的关系比较详细。但是（重点来了：）），有些组件说得比较多，如上图红色的目标等；有些说得比较少，或者缺失，如计划、状态等；有的关联不全面，如产品仅和流程关联，未和职能关联，那么没有中间产品吗？另外还有有罗列之嫌，未对这些组件分出层次。
下图是我在咨询工作中总结出来的”业务架构精简元模型“：

首先，把组件分成了2个层次：知识层和行为层。知识层是企业中的各种规章制度、标准、模板等。行为层是企业对制度的落实和执行。
其次，补充了计划、状态组件；把数据从数据架构提升，作为业务架构的一部分。
第三，产品、服务、资源和目标等概念抽像为制品；把流程和职能抽象为流程；去除了不在同一抽象颗粒度的组件如度量、合约等。
通过这样的重构，层内和层间组件之间的关系更清晰，做到了”高内聚、低耦合“。

知识层和行为层之间存在着对应关系：计划是流程的实例，事件是状态的体现，而制品是数据的载体。

行为层的计划和事件在关于事件驱动和工业4.0的CPS体系结构的博文中有描述，这里就不重复了。这里重点说明一下知识层的组件。

流程：描述活动及其之间的关系。建模工具是流程图，如BPMN, EPC, UML活动图等
数据：描述数据实体及其之间的关系。建模工具是实体关系图（ER图）、UML的类图等
状态：描述活动和数据之间的关系。建模工具是数据流图，数学模型是Petrinet

知识层的总体逻辑是：流程产生数据，数据反映业务状态，状态决定了下一步的流程。

这里相对不太被重视的是状态。状态是数据实体在流程活动、步骤作用下发生变化的阶段性结果。是业务表单和业务对象的状态控制了活动和流程的执行，落实到行为层就是制品的状态控制了计划项执行的先后关系（前后置关系）。

这样就产生了一种重要”自动“关联：把传统计划管理中计划项之间前后置关系之间关联到到业务对象（制品）的技术状态，而不再是脱离技术的人为规定，也不再需要现场的生产经理或项目经理录入生产进度。当技术的状态能即时地反馈到计划层面后，就便于在管理层面进行半自动化、自动化地决策。决策的效率和准确率就大为提高，缓解了“领导”的压力。

那么传统的业务规则在哪里？行为层事件的组合反映的是业务状态，状态决定了要匹配什么样的规则，规则定义了要采取的下一步活动。

按工业4.0的信息物理系统(CPS)的观点，我们的精简元模型中的行为层对应的是CPS中的信息层，是其物理层的”元模型“，因为信息层决定了物理层的行为。而我们模型中知识层决定了行为层，所以又是行为层的“元模型”，是“元模型”的“元模型”。

精简元模型是选择关键的、抽象的、最小可行集的组件构成的，中应用中还需要有更细的分解或者纳入相关的组件，从而形成更完整的业务逻辑。下图结合精简元模型和战略地图，给出了企业业务中主要分解结构（BS-Breakdown Structure）之间的关键关系：

简单解释一下:
上图的核心是流程层面，是整个战略地图的黏合层。其中项目管理、日常运行和能力建设的工作分解结构（WBS）都是企业的工作计划，而计划是流程BpBS的实例化。
流程需要资源层提供输入。资源层包括技术TBS，资源RBS, 组织OBS等；
流程的输出是产品（制品）PBS，是客户能看到的，是为客户服务的。
流程的结果是要有良性财务成果，可接受的成本结构CBS，这样企业才能持续经营。