基本概念

元模型设计原则

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

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

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

1. 限制元模型中组件（Component，即本文语境中的实体）和引用类型（Reference Type）的数量：
   1. 对实体和引用类型的数量要保守，控制企业架构元模型的复杂度至关重要。假设你使用15个实体定义一个领域元模型来描述Cloud Service，此时是清晰明了的；如果你需要进一步描述Cloud Service如何支撑应用、应用如何支撑业务流程、业务流程如何形成商业产品和服务，此时就需要跨领域元模型，如果每个领域都是15个实体，此时60个实体之间要建立关系和查询能力，会变得异常复杂；未来降低这种复杂度，就需要进行一定程度的抽象。
   2. 避免过度具体化或过度抽象化。
2. 简化和整合标准以满足需求：
   1. 在参考多个建模标准之前，请了解多个建模标准中的重叠部分，每个标准都是面向一个特定领域的，例如BPMN用于业务流程建模，UML用于软件工程建模，ITIL用于IT运维建模，ERD用于数据建模等。
   2. 在必要时消除多个标准中的重复部分和简化标准。
3. 定义多个业务、IT团队共同的语言：
   1. 理解不同的部门、团队可能对相同的概念使用不同的术语，例如Dynamics CRM、Application、Deployment Package表达的是一个意思。
   2. 使用例子来描述概念的异同处。
4. 使用层次机构来组织架构中的架构元素：
   1. 在架构中为架构元素构建层级结构，使得架构时可以从不同层次来描述此元素，如图1和图2所示。
   2. 根据时间的推移及时刷新层级结构。
   图1 应用分类（An Application taxonomy）
   
   图2 位置分类（A Location taxonomy）
   
5. 确保高阶概念（High-Level）和低阶概念（Low-Level）的匹配：
   1. 理解哪些实体是高阶概念、哪些是低阶设计，如业务能力（Business Capability）或者价值流（Value Stream）被认为是高阶概念，功能（Function）或者业务流程（Business Process）被认为是低阶概念。
   2. 检查高阶概念的实体和关系，在低阶概念中对应的一致性。构建企业架构模型需要的是一个持续的过程，在高阶概念和低阶概念模型之间相互检查，寻找差距（gaps）和脱节（disconnects），持续的协调一致。
   3. 体系结构模型的顶层（高阶概念）的目的是聚合细节（低阶概念），而不是消除细节；建议先从低阶概念设计开始，根据业务和IT的工作逐步抽象高阶概念。
6. 在使用抽象实体类型需注意：
   1. 使用抽象实体类型对其他实体类型进行分类。
   2. 如果使用不当，抽象实体类型可能会降低您进行影响分析或建立可追溯性的能力。

   举例：部门A使用Outlook，其可以定义为“Organization A- Uses - Outlook”；部门B使用Gmail，其可以定义为“Organization - Uses - Gmail”；如果将Outlook和Gmail抽象为TechnologyService实体，其值为Email，则部门A和B使用的都是Email服务，无法直接得出使用的邮件服务的差异。

7. 最完美的元模型是持续演进的：
   1. 建立一个有合理信心的内核模型（Core），但不要害怕扩展实验。
   2. 根据用户反馈、技术演进和这七个原则来不停演进企业架构元模型。

元模型概述

FabricMetamodelV2.0内核和扩展实体如图3所示。

图3 FabricMetamodelV2.0概览

FabricMetamodelV2.0内核中包括如下的一些实体：

• 行政单元（AdministrationUnit）：行政单元指按照各行业固有的行政管理结构来划分、具备行政管理职责的单位。如政府的省/市/区、企业的集团/分支机构、法人实体等。
• 行政领域（AdministrationDomain）：在企业组织范围内，行政领域指基于向外部和内部客户提供的商品或服务的主要子结构，如零售、物流、云计算服务等；在政府领域内，行政领域指政府各职能领域，如工商、公安、卫检等。
• 用户（User）：数据资产管理和运营用户旅程中的个人参与方，如数据管家、数据分析师、数据普查员等。
• 空间（Space）：用于描述数据分析师的工作空间，此空间为一个逻辑概念，空间中涵盖了“数据分析师团队、团队拥有的数据底座、有访问权限的数据资产、数据开发工具、数据应用”等关联概念。
• 主题域分组（SubjectAreaGroup）：公司顶层信息分类，通过数据视角体现公司最高层关注的业务领域。
• 主题域（SubjectArea）：互不重叠数据的高层面的分类，用于管理下一级的业务对象。
• 业务对象（BusinessObject）：业务领域重要的人、事、物，承载了业务运作和管理涉及的重要信息。
• 逻辑数据实体（LogicalEntity）：具有一定逻辑关系的数据属性的集合。
• 属性（Attribute）：描述业务对象的数据特征，是数据最基本的单元。
• 数据标准（DataStandard）：定义组织层面需共同遵守的属性层数据含义和业务规则，是组织层面对某个数据的共同理解，这些理解一旦确定下来，就应作为组织层面的标准在组织内被共同遵守。
• 应用（Application）：应用是数据资产运营枢纽中对IT系统的统称，包括文件应用、业务系统应用、企业应用、数据仓库应用等。
• 数据平台实例（DataPlatformInstance）：数据源是元数据的来源。包括以下几类来源：关系型数据库(比如MySQL、Oracle)、对象存储(比如华为云OBS)、企业应用(比如金碟ERP)、BI软件(比如四方伟业BI、帆软BI)、大数据存储(比如Hive、HDFS)、消息队列(比如kafka)、ETL工具(比如AWS Glue)、时序数据库(比如influx)等。数据源又称数据平台实例。
• 数据集（DataSet）：代表了数据的集合，通常指数据库中的表/视图、流处理系统中的流、数据湖系统中以文件或文件夹形式存在的数据集合等。
• 数据集容器（Container）：包括一组DataSet的逻辑库。
• 数据集字段（SchemaField）：数据集中的每一列字段对应一个数据集字段。

FabricMetamodelV2.0扩展中包括如下的一些实体：

• 团队（Group）：数据资产管理和运营用户旅程中的团队参与方。
• 报表（Report）：以特定格式展现数据的一种可视化报告，能直观地展现业务分析结果，用于支撑业务决策。
• 报表分组（ReportGroup）：对报表的分类信息。
• 卡片（Card）：报表由多个可视化组件组成，一个可视化组件称为卡片。

主要的实体联接的描述如下：

• 兼容FabricMetamodelV1.0的信息架构管理的实体联接：
  • 信息架构L1-L5层元素间的实体联接：
    • “属性-被包含-逻辑数据实体”：描述信息架构中L5层属性和L4层逻辑实体的关系。
    • “逻辑数据实体-被包含-业务对象”：描述信息架构中L4层逻辑数据实体和L3层业务对象的关系。
    • “业务对象-被包含-主题域”：描述信息架构中L3层业务对象和L2层主题域的关系。
    • “主题域-被包含-主题域分组”：描述信息架构中L2层主题域和L1层主题域分组的关系。
  • 信息架构和用户之间的实体联接：
    • “主题域分组-关联于-团队”：描述的是信息架构委员会团队管理所有主题域分组、领域数据管家团队管理本领域主题域的场景。
    • “主题域分组-被拥有-用户”：描述的是数据Owner管理主题域分组的场景。
    • “主题域-被拥有-用户”：描述的是数据Owner作为主题域数据主人的场景。
    • “业务对象/逻辑数据实体-被管理-用户”：描述的是数据管家管理业务对象/逻辑数据实体的场景。
    • “业务对象/逻辑数据实体-被拥有-用户”：描述的是数据Owner管理业务对象/逻辑实体的场景。
  • 信息架构和数据集之间的实体联接：
    • “数据集-关联于-逻辑数据实体”：描述的是多个物理存在的数据集，关联到一个逻辑数据实体进行管理的场景。比如一张物理表在源业务系统、业务系统备库、数据湖、数据仓库中存在了多次，则其被注册到一个逻辑数据实体中。逻辑数据实体中的属性是从管理维度定义的最重要的数据资产属性，和数据集字段可能存在不完全一致的情况。
    • “数据集-关联于-业务对象”：此关系是在未定义“逻辑数据实体”时引入的，当前已经失效，将在FabricMetamodelV2.1中删除。
• 兼容FabricMetamodelV1.0的数据普查的实体联接：
  • 数据普查L1-L5层元素间的实体联接：
    • “数据集-被包含-数据容器”：描述数据库的逻辑库（如Schema）包含多个数据集的场景。
    • “数据集-被包含-数据平台实例”：描述数据集存储在哪个数据平台实例的场景。
    • “数据平台实例-关联于-应用”：描述业务系统关联数据平台实例的场景。
    • “应用-关联于-行政领域”：描述此业务系统是哪一个业务领域建设的场景。
    • “行政领域-被包含-行政单元”：描述是业务领域是哪一级组织（如集团、分公司）的场景。
• 兼容FabricMetamodelV1.0的RDBMS的实体联接：
  • “数据集字段-被包含-数据集”：描述的是数据集（物理表/视图）包括哪些字段的场景。
  • “数据集-被包含-数据集容器”：描述的是逻辑库中包括哪些数据集（物理表/视图）的场景。
  • “数据集-被包含-数据平台实例”：描述的是数据集（物理表/视图）实际存储在哪个数据平台实例的场景。
  • RDBMS元模型中CWM元模型中如下元素尚未兼容：
    • 唯一键
    • 主键
    • 外键
    • 存储过程
    • 索引/索引字段
    • 触发器
• 分析师360中管理数据消费的实体联接：
  • “空间-被拥有-用户”：描述的是空间Owner拥有工作空间的场景，当前空间中成员信息没有保存在元模型中。
  • “数据集-被消费-报表”：描述的是物理表被BI报表应用所消费的场景。
  • “报表-被拥有-用户”：描述的是报表是由哪个数据分析师创建、开发和发布的场景。
  • “报表-被包含-报表分组”：描述的是BI报表进行分组管理的场景。
  • “报表分组-被包含-工作空间”：描述的是工作空间中由数据分析师开发了多个BI报表的场景。
• 数据管家360中管理数据普查的实体联接：
  • “数据集-被拥有-用户”：描述的是数据Owner作为数据集数据主人的场景。
  • “数据集-被管理-用户”：描述的是数据管家作为数据集管理者的场景。

元模型详述

ABM进行元模型建模后的画布视图，其描述了所有的实体联接，并支撑如下核心功能：

• 数据普查目录：使用“用户、行政单元、行政领域、应用、数据平台实例、数据容器、数据集、数据集字段”实体。
• 数据资产目录：使用“用户、主题域分组、主题域、业务对象、逻辑数据实体、属性、数据标准、数据平台实例、数据容器、数据集、数据集字段”实体。
• 分析师360：使用“团队、用户、空间、报表、报表分组、数据集”实体。

图4 枢纽元模型V2.0

业务类扩展

在FabricMetamodelV1.0功能的基础上，V2.0增加了业务类扩展，增加了“空间、报表、报表分组、卡片”实体，支撑了分析师360功能如下功能的实现：

• 空间Owner管理空间、报表分组。
• 数据分析师团队共享各自独立开发的报表。
• BI报表工具从数据集实体获得元数据。

当前尚未对报表中卡片的元数据实现管理，因此“卡片”实体尚未使用。

架构编码

在ABM平台对于FabricMetamodel包的编码定义如下：

• 元模型架构编码：Metamodel3。
• 架构类型：业务架构。

• 架构名称：Fabric Metamodel V2.0。
• GraphQL名称：Metamodel3。

技术模型

技术模型又称技术元数据。技术元数据是结构化处理后的数据，提供了有关数据的技术细节（字段、数据库表结构、API描述、消息描述、文件描述等），方便数据库对数据进行识别、存储、传输和交换，例如MySQL数据库技术元数据等。

业务模型

业务模型又称业务元数据。业务元数据是用于描述业务侧的元数据，主要关注数据的业务内容和业务条件，例如有哪些业务范围、业务过程、业务发生主体、业务事件，业务规则等。

数据资产信息架构

系统预置模型架构，用于管理整个企业、工厂、部门等组织的一个核心业务模型。面向业务，是数据资产清单，信息架构是公司管理信息资产的分类。

行业模板信息架构包

也可简称行业模板，是用于描述和存储特定领域总结出来具有通用意义的数据模型。“数据模型”定义数据、以及数据间的关系，通过对特定领域内的概念、实体、实体间的关系进行描述，以期得到可以在该领域内通用和泛化的数据模型。

多个行业模板构成行业模板市场，行业模板市场中的行业模板可以用户间共享。