元模型架构设计方法论

一、元模型定义

“元模型（Meta Model）又称“模型的模型”，通常用于定义模型中具有哪些基本元素、元素之间的关系或者关系表示，是比模型抽象度更高的模型表示或者模型定义。之前介绍过的DoDAF就是一种以元模型为核心的架构构建方法。TOGAF也定义了自己的内容元模型，以表明业务架构、应用架构、数据架构和技术架构的核心内容及相互之间的关系。

元模型体现了方法论的架构观，即方法论是如何理解设计对象的。这一定义源自笔者对“世界观”的理解，所谓“世界观”就是基于对世界的观察而形成的对世界的观念，也即对世界的理解。根据观察，如果认为地球是绕着太阳转的，对应的世界观就是“日心说”；如果认为太阳是绕着地球转的，对应的世界观就是“地心说”。“世界观”通常不是一个观点，而是一组相互关联的观点体系。

“当我们思考设计对象的架构时也是如此，架构观就是基于对设计对象的观察而形成的对设计对象的理解。观察都需要视角，架构观主要受观察视角的影响，对于架构设计而言，基础的视角就是侧重于分析设计对象的结构、关系、演进原则，架构师可以从这几个点出发去理解所有设计对象。基于此形成的架构观，就是反映了设计对象的结构、内外部关系以及演进原则的一组观点体系。

基于该观念，架构高阶元模型如图4-1所示。”

“这个高阶元模型说明，事物都是由不同的构件组成的，构件之间具有相互联系，事物拥有或者可以为其设计作用于其构件的规律，架构设计的任务就是处理好这些关键点。

以高阶元模型为基础，可以产生各种实例的元模型，比如TOGAF内容元模型、FSDM的九大领域、DoDAF元模型、价值链高阶模型等，这些都可以归类为这一高阶元模型的元模型实例，图3-1，也是一个元模型实例。这有些类似“道生一、一生二、二生三”的逻辑，“道”就是架构观，“一”就是架构高阶元模型，二、三就是元模型实例。在本章中提出的企业架构元模型也属于高阶元模型的一种实例。

以上思想中，其实我在以前的文章中也有提到过，其实事务的本质来源于元素+元素关系，而在世界法则中更多的是人、事、物之间的联系。

二、元模型框架

“以高阶元模型的抽象结构为指导，本书基于笔者的实践与思考，采用了面向数字化生态、面向战略、面向构件的思路，以业务架构为核心构建了企业架构的元模型，以明确企业架构设计的核心要素及其关系。该企业架构元模型如图4-2所示。

图4-2中的战略元模型、组织元模型、业务元模型和业务构件元模型都属于业务架构元模型。按照笔者观点，这是传统业务架构与数据架构融合后的业务架构，应用架构元模型承接业务架构元模型，技术架构元模型实现应用架构元模型并在一定程度上受到业务架构元模型的约束。

“图中标记了五角星的元素，为该元模型相较以往的方法论重点改良的元素。未标注连线的元素之间可以通过其共同连接的元素传递连接关系，比如“组织元模型”中“岗位”执行“业务服务”，“业务服务”活动于“空间”，可以认为“岗位”也是活动于“空间”的，这种关系与数据建模中数据实体之间的关系类似，毕竟元模型本身也可以视为一种数据模型。4.3节将分别介绍元模型的各个组成部分。”

2.1、战略元模型&组织元模型

“战略是企业发展的方向性指导，也是凝聚企业力量的关键，很多互联网企业都非常重视自身战略管理能力的建设，尤其是会影响企业文化的愿景、价值观等的能力。

“根据TOGAF的定义，企业是具有相同目标的一系列组织的集合。这是一个外延很宽的定义，并非特指通常认为的生产性、经营性企业。根据这个定义，企业其实本就没有内外部之分，而是一个目标导向的非固化集合体，很有今天常说的生态型、开放型企业的意味。”

2.2、业务元模型&业务构件元模型

“业务是企业实际的价值创造过程，是岗位通过一定的服务方式为用户（含内部）实现价值的过程。在某些行业中，这个过程可能很长，比如医疗行业为慢性病患者提供的治疗服务；而在另一些行业，这个过程可能非常短暂，比如互联网内容服务商提供的短视频服务。但是抽象来讲，所有的业务都是由用户、岗位、规则、服务、数据和空间等元素组织起来的。这些内容加起来，更像是今天大家常提及的“场景”，“场景”其实是一个影视剧术语，指在一定的时间、空间（主要是空间）内发生的一定的任务行动或因人物关系而构成的具体生活画面。

“1）业务规则。业务规则是由岗位制定的，是业务服务过程中必须遵守的约定，既包括常见的业务制度，如银行中大量的内部经营管理制度，也包括产品服务承诺，比如快递送达时间的承诺，以及数字化产品中经常出现的算法规则，比如用户画像到产品推荐过程中的各种算法，这些算法并没有被抽象成制度，但实际上比制度的可执行性、约束力更强。业务规则一旦形成，也会形成对岗位的约束。

2）业务活动。业务活动通常是由岗位遵循一定的业务规则执行的业务过程。从抽象角度讲，企业对外的营销活动、产品服务、售后服务、监管报送等，企业内部的战略制定、落实监督、目标制定、目标考核、架构设计、方法论研究等都属于业务活动。业务活动的服务对象可以是外部用户，也可以是内部岗位，业务活动总是在一定的空间中进行的。

“业务活动会生产或消费（经常同时进行）业务对象。业务活动可以根据需要聚合成业务领域，也即，业务领域实际上是多个业务活动的聚类。从抽象角度讲，如果一个领域内的多个活动可以“无缝”连接，那一个业务领域实际上就是一个很长的、端到端的业务活动。经常有读者询问笔者关于业务领域的定义原则，在笔者看来，业务领域其实不需要特别明确的定义，它是业务活动的灵活聚合，类似组织单元与岗位的关系，细分的业务活动和业务对象是相对稳定的，业务领域可以根据战略、组织单元和对用户的理解进行灵活的定义与调整。

3）业务对象。业务对象指的是高阶逻辑级的数据模型，除了常见的申请表、报告单、用户信息等业务对象外，业务经验、架构设计成果、方法论等业务知识也都属于业务对象。面向数字化转型，笔者认为，一切业务服务最好都能产生可数据化的业务对象，

“业务活动与业务对象的关系识别就是实现“一切业务数据化，一切数据业务化”的起点。知识服务是企业转变成知识型企业所必须建立的业务活动，所以，知识也是很重要的业务对象。严格来说，“愿景、价值观”“战略”“战略能力”也属于业务对象，”

“但考虑到上述元素的重要性以及让元模型更容易理解等因素，我们将它们与业务对象分开描述。

业务对象（Business Object，BO）一词在软件设计中也指对数据进行检索和处理的组件，包含状态与行为两部分，但是笔者本处使用该词仅指业务人员对业务处理对象的认知，是数据模型建立初期的识别过程的产物，是用于后续细化数据实体的输入。

业务对象也有聚合能力，可以向上聚合成更高阶的业务对象主题域，而是否要执行这一聚合则是可选项，执行聚合通常是指为了更好地确认业务对象之间的关系和业务对象识别的完整性。”

“业务构件是业务架构中构件设计的关键，是提炼用于组装业务服务的基础元素。”

“1）业务构件。业务活动可以发生一定的变化，与支持活动的基础能力相比，业务活动是不够稳定且可变的，如同岗位与组织之间的关系。业务构件是对业务行为和业务数据的“封装”，战略能力通过岗位传递到岗位执行的业务活动上，进而沉淀在业务构件中包含的业务能力上。业务构件可以按照业务活动的需要进行组装，这是对业务的结构化。业务构件可以聚合成业务组件，聚合的依据则是不同业务构件包含的业务数据之间的业务关系。这种定义要遵从业务的理解，其表达也应是业务人员可以理解的。业务构件的设计要尽可能减少行为重叠，行为重叠会造成资源浪费。但在实际业务中，完全不重叠可能较难实现。尽可能避免数据重叠，数据重叠会造成耦合，并向开发侧传递数据一致性问题。业务构件应尽可能被技术人员以系统化的方式实现，但并非所有业务构件都可以实现系统化。

2）业务任务。业务任务是实现业务预想结果所必须执行的一系列动作，可以固化成一段操作过程、一个具体的操作动作或一连串软件行为。业务任务在执行过程中会消费或产生一定的业务数据，无论是否是由业务系统支持的执行过程。可能有一些业务行为不易数据化，比如与用户共情，但是不应放弃以数据进行描述的努力。业务规则也可以被直接实现为业务行为，比如特定风控规则的实现会表现为针对特定场景的风控行为。

“3）业务数据。业务数据是对业务对象状态以及业务任务执行过程与结果的描述。业务数据可以组成业务对象，这意味着不同的业务对象可能具有部分相同的业务数据。业务对象是概念级的数据模型，而业务数据是逻辑级的数据模型。业务数据应当具备企业级的唯一性，以满足数据标准化的要求，建议遵从三范式的要求。业务数据可以聚合成主题域，以表现具有一定联系的数据集合，并为业务构件的聚类提供判断依据。”

2.3、业务架构元模型

“业务架构设计是结构化分析、设计企业整体业务能力的过程，包括了对战略、组织、业务、构件的分析与连接。本书提出的业务架构元模型所代表的业务架构设计模式并非全新的、颠覆性的业务架构设计模式，依然是在传统企业架构方法论上的演进，其自身的特点主要集中体现在对业务的深入构件设计上，这是实现真正的构件开发模式的基础。以往的构件开发实践（模块化、SOA、微服务等）在业务侧的分析不足，更多聚焦在技术侧的设计，缺少对业务人员结构化思维的培养和对业务自身的构件设计。如果业务自身没有很好地进行构件设计，通常技术侧也不会产生好的构件设计。”

2.4、应用架构元模型

“应用架构是业务架构与技术架构的连接环节，业务的结构化分析成果通过应用架构转化为逻辑服务、逻辑数据并由技术架构最终实现。经过应用架构设计，业务需求转化为技术需求，尤其是功能性需求，因此元模型也聚焦于功能性需求的连接上。应用架构元模型如图4-8所示。

1）逻辑功能。逻辑功能是根据业务任务设计的，逻辑功能会生产或消费一定的逻辑数据，因为是面向系统设计的，所以逻辑功能必须生产或消费逻辑数据。逻辑功能会组成应用构件。业务任务与逻辑功能之间可以不是严格的一对一关系，但考虑到整体能力地图的清晰性，应该尽可能保持业务能力对逻辑功能的一对一、一对多关系（以一对一关系为主，一对多关系主要是考虑实现的制约）；应尽可能减少业务能力对逻辑功能的多对一关系，这种关系意味着业务构件的边界重叠。

“2）逻辑数据。逻辑数据同样是逻辑级数据模型，但是考虑到设计实现，与业务数据相比，可以适当进行“降范”，考虑派生数据等，并允许一定程度上的冗余，但这不意味着无限放开冗余，而是在考虑设计必要性时放开。主题域由业务数据聚合而成，逻辑数据是“降范”的业务数据，因而不再考虑通过聚合的方式定义这一层级的主题域。

3）应用构件。应用构件是对逻辑功能和逻辑数据的“封装”，是技术层面设计的“积木块”，是构件设计在技术侧的体现。应用构件的设计要以业务构件为指导，尽可能保持一致，以确保业务侧对业务构件的可组装预期能够顺利过渡到技术侧对应用构件的可调用设计。应用构件可以聚合成应用组件（相当于逻辑子系统），组件可以辅助开发任务的分工。组件可以再聚合成应用架构的分层，但是应用架构的分层无须在元模型层级展现。”

“4）应用编排。业务活动通常是经过一定的过程来实现的，在业务侧，笔者将其定义为业务活动对业务构件的组装；在技术侧，笔者将其定义为应用编排对应用构件的调用。应用编排反映了技术侧对业务活动过程的实现，但需要注意的是，业务活动的范围可能大于应用编排，这意味着存在线上线下协同的场景。此外，应用编排也有可能出现不同层级的调用，也即，应用编排可能调用其他应用编排，这通常意味着更大范围的业务活动之间的组合。但是，考虑到应用的不稳定性，设计过于复杂的应用间调用需要慎重。”

2.5、技术架构元模型

“技术架构是对应用架构的物理实现。技术架构本身是非常复杂的，但是考虑到元模型面向的是企业中业务和技术两侧，因此技术架构中对元模型要素进行了高度简化。技术架构元模型如图4-9所示。

1）物理构件。物理构件是应用构件的物理实现，物理构件也包含功能和数据，但是技术架构并非本元模型的重点关注内容，因此无须在元模型层级详细展现。物理构件可以聚合成物理组件。

2）技术平台。技术平台用于实现物理构件（或者聚合后的物理组件），可以基于特定技术类型建立平台，如人工智能、区块链、大数据等平台；也可以基于语言类型划分业务功能平台，如C语言、Java语言等平台；也可以基于特定目的建立平台，如监控平台、任务调度平台等。技术平台还可以聚类成技术架构的分层，但技术架构的分层属于聚合元素，无须在元模型层级展现。”

“出于对数字化转型的特殊考虑，虚拟空间构建技术是未来技术发展的焦点，因此，战略元模型中的“空间”元素越过了“应用架构元模型”，直接对应到了“技术架构元模型”中的“技术平台”上，这也反应了业务架构与技术架构之间的联系方式。搭建虚拟空间需要的技术平台应该在企业实力允许的情况下，以战略级的发展要求进行尝试。

2.6、元模型中的关键链条

“构件设计并非只是技术侧的问题，而是需要业务与技术两侧的共同努力，因此，从业务架构开始，有一条关键链条影响着构件设计的最终实现效果，如图4-10所示。

“这个关键链条上元素定义的一致性或者说映射关系的清晰性决定了构件设计的最终效果，以往的企业架构设计或者软件设计没有很好地解决从战略分析开始到最后技术实现方面的一致性问题。元模型并不意味着软件设计会被复杂化，因为无论采用何种策略进行软件开发，最终开发结果都会映射到这些元素上，而难以令人满意的开发结果往往会缺少该链条中的某些元素，或者没有做好某些元素的设计。我们没有任何理由忽略这些设计元素，任何对这些元素的忽略最终都会导致技术债务。同样，元模型也不意味着软件设计会大幅度简化，而是更加清楚地展示了重要的元素及其关系，加强架构师、开发人员对设计重点的关注，提供一个更有效率的分析路径。

从这个链条上看，详细分解战略能力、标准化岗位设计、持续优化业务流程、标准化管理企业数据、与业务保持一定程度的一致性去设计应用构件，是实现高效的构件开发的必要条件，这也是其他开发模式不可忽略的要素。当然，这并不意味着没有对这些元素的万全设计，就不能进行软件开发，而是应当通过元模型使我们对架构关键点的认识更清晰，知道有哪些“坑”需要持续去填，也知道填“坑”的意义。”

三、元模型框架治理原则

“1.总体原则

1）尽可能遵循康威定律，以弥合组织与系统之间存在的差异。

2）在总体上尽可能考虑基于构件的设计，以便扩展。

3）企业架构的分析过程中尽可能保持行为（业务）与数据的强关联。

4）企业架构设计尽可能保持简洁，突出关键要素，不要在企业复杂度上额外叠加架构复杂度。

5）企业架构设计本身不会替代需求分析，不必增加过多细节。

6）企业架构设计最终要形成企业能力地图，因此企业架构与业务系统的实现和演进过程紧密相关，业务系统的实现和演进都应基于企业架构设计进行。

2.操作性原则

1）业务架构必须可以被业务人员理解并认可，因为这是对业务的结构化过程。

2）业务架构面向的是企业全部业务，因此，业务架构范围可以大于应用架构范围。

3）愿景应当具有一定的用户指向。

4）价值观必须是由企业领导者带头实践的。

11）为了支持组织单元的灵活性，岗位必须相对具有更好的稳定性，岗位必须承载战略能力并且容易被识别，以支持对组织单元的灵活聚合。

12）业务规则最好能够进行适度的抽象和剥离，以便与业务活动、业务任务进行结合和调整。

13）业务活动设计应保持内聚性和可聚合能力，需要关注活动颗粒度，并与业务对象紧密结合。

14）业务活动可以聚合成业务领域，这将保持业务领域的灵活性。

15）业务构件应当同时包含业务任务和业务数据，这样的构件才是独立而完整的。

16）业务构件设计应当减少构件之间业务能力的重叠，避免构件之间业务数据的重叠。

17）业务构件可以聚合成业务组件，聚类主要依据其包含的业务数据对应的业务关系。

18）业务构件应尽可能被系统化实现。

19）战略能力最终应当沉淀在业务任务和业务数据上。

20）业务数据必须具有企业级的唯一性定义，应尽可能将业务对象数据化。

21）业务任务到逻辑功能应尽可能保持一对一或一对多关系（以一对一关系为主，一对多关系主要是考虑实现的制约），尽可能减少逻辑功能到业务能力的一对多关系。

22）逻辑数据允许“降范”设计，但是不意味着无限放开。

23）应用构件的设计应尽可能与业务构件保持一致。

24）应用之间可以互相调用，但设计复杂的应用间调用应当慎重，设计应用间调用时要考虑被调用对象的变化是否需要传给调用者，如不需要，意味着不做应用间调用更合适。”

四、参考资料

- 聚合架构 面向数字生态的构件化企业架构