华为云首页用户手册

开天集成工作台 MSSI-基本概念:元模型设计原则

时间：2024-10-22 09:04:29

开天集成工作台 MSSI 应用模型

元模型设计原则

企业架构元模型的核心目的是“Organize、Analyze、Communicate”：

Organize：组织是指将企业中流程、业务能力、应用、技术、人等组成企业架构的元素形成一张完整的视图。在元模型设计方法中，是利用适当的抽象方法，来将类似概念抽象，这样在看企业架构的时候，能够看到最关键的组成要素，而不是陷入细节。
Analyze：分析是指能够使用企业架构元数据去回答关键的业务问题。在元模型设计方法中，需要将元素合理的进行组织，以方便查询关键的元数据，来回答这些业务问题。
Communicate：沟通是指能够让受众清晰易懂理解企业架构的关键元素。比如如果一个元模型中定义了dashboard，受众要能够理解其含义是仪表盘。元模型是企业架构师向受众讲述架构故事的一种媒介，如果一些有价值的见解被模糊的概念或者晦涩的技术所掩盖，那么受众将很难获得有价值的决策信息。

元模型设计的七个原则，以帮助企业架构师设计比较好的元模型

限制元模型中组件（Component，即本文语境中的实体）和引用类型（Reference Type）的数量：
1. 对实体和引用类型的数量要保守，控制企业架构元模型的复杂度至关重要。假设你使用15个实体定义一个领域元模型来描述Cloud Service，此时是清晰明了的；如果你需要进一步描述Cloud Service如何支撑应用、应用如何支撑业务流程、业务流程如何形成商业产品和服务，此时就需要跨领域元模型，如果每个领域都是15个实体，此时60个实体之间要建立关系和查询能力，会变得异常复杂；未来降低这种复杂度，就需要进行一定程度的抽象。
2. 避免过度具体化或过度抽象化。
简化和整合标准以满足需求：
1. 在参考多个建模标准之前，请了解多个建模标准中的重叠部分，每个标准都是面向一个特定领域的，例如BPMN用于业务流程建模，UML用于软件工程建模，ITIL用于IT运维建模，ERD用于数据建模等。
2. 在必要时消除多个标准中的重复部分和简化标准。
定义多个业务、IT团队共同的语言：
1. 理解不同的部门、团队可能对相同的概念使用不同的术语，例如Dynamics CRM、Application、Deployment Package表达的是一个意思。
2. 使用例子来描述概念的异同处。
使用层次机构来组织架构中的架构元素：
1. 在架构中为架构元素构建层级结构，使得架构时可以从不同层次来描述此元素，如图1和图2所示。
2. 根据时间的推移及时刷新层级结构。
图1 应用分类（An Application taxonomy）

图2 位置分类（A Location taxonomy）
确保高阶概念（High-Level）和低阶概念（Low-Level）的匹配：
1. 理解哪些实体是高阶概念、哪些是低阶设计，如业务能力（Business Capability）或者价值流（Value Stream）被认为是高阶概念，功能（Function）或者业务流程（Business Process）被认为是低阶概念。
2. 检查高阶概念的实体和关系，在低阶概念中对应的一致性。构建企业架构模型需要的是一个持续的过程，在高阶概念和低阶概念模型之间相互检查，寻找差距（gaps）和脱节（disconnects），持续的协调一致。
3. 体系结构模型的顶层（高阶概念）的目的是聚合细节（低阶概念），而不是消除细节；建议先从低阶概念设计开始，根据业务和IT的工作逐步抽象高阶概念。
在使用抽象实体类型需注意：
1. 使用抽象实体类型对其他实体类型进行分类。
2. 如果使用不当，抽象实体类型可能会降低您进行影响分析或建立可追溯性的能力。
举例：部门A使用Outlook，其可以定义为“Organization A- Uses - Outlook”；部门B使用Gmail，其可以定义为“Organization - Uses - Gmail”；如果将Outlook和Gmail抽象为TechnologyService实体，其值为Email，则部门A和B使用的都是Email服务，无法直接得出使用的邮件服务的差异。
最完美的元模型是持续演进的：
1. 建立一个有合理信心的内核模型（Core），但不要害怕扩展实验。
2. 根据用户反馈、技术演进和这七个原则来不停演进企业架构元模型。