企业架构与元模型：如何建立统一的架构语言
企业架构涉及业务、应用、数据、技术和安全等多个架构域，不同架构域包含大量能力、流程、系统、数据实体、技术组件和安全对象。如果这些对象缺少统一定义，即使形成了大量架构图、清单和文档，也很难真正建立跨架构域的关联关系。
企业架构元模型的作用，就是从企业整体视角统一定义“架构中有哪些对象、对象具有哪些属性、对象之间存在什么关系”，形成企业架构共同遵循的基础语言。在此基础上，再根据不同设计和管理场景形成目录、矩阵、图形和文档等架构制品，使不同专业、不同项目形成的架构成果能够按照统一规则进行表达、关联和治理。
一、为什么企业架构首先需要建立元模型
企业架构设计涉及不同专业和不同层级。业务人员关注业务能力、业务流程和业务对象，应用人员关注应用系统、应用模块和功能，数据人员关注概念实体、逻辑实体和物理实体，技术人员则关注技术能力、技术组件和部署环境。如果每个专业都按照自己的理解定义对象，就容易出现同一概念名称不同、同一名称含义不同以及对象关系不一致等问题。
因此，在开展具体架构设计之前，需要首先建立统一的企业架构元模型，对企业架构中的核心对象及其关系形成共同定义。
元模型可以理解为企业架构的“基础语言规则”。它不描述某一个具体系统，而是规定企业架构中允许使用哪些类型的对象、每类对象需要记录哪些属性，以及不同对象之间可以建立哪些关系。例如，可以统一规定什么是业务能力、什么是应用模块、什么是逻辑实体，以及业务能力与应用功能、应用功能与数据实体之间应如何建立关系。
有了统一元模型，不同专业形成的架构成果才能建立在同一套概念体系之上，为后续跨域设计、架构分析和架构治理提供基础。
二、企业架构元模型包含哪些核心内容
企业架构元模型通常由架构对象、对象属性和对象关系构成，并按照业务、应用、数据、技术和安全等架构域形成相互关联的整体。
业务架构可以定义业务能力、价值流、业务流程、业务步骤、业务角色、业务对象和业务规则等对象；应用架构可以定义应用域、应用组、应用模块、功能项、应用系统和应用服务等对象；数据架构可以定义数据域、概念实体、逻辑实体、物理实体和数据属性等对象；技术架构可以定义技术分类、技术能力、技术组件、技术平台和部署节点等对象；安全架构则可以定义安全域、安全策略、安全控制措施和安全标准等对象。
仅仅定义对象还不够，还需要进一步明确每类对象具有哪些属性。例如应用模块可以具有名称、编码、所属应用、建设状态等属性，逻辑实体可以具有名称、编码、所属概念实体等属性，技术组件可以具有技术分类、版本和生命周期状态等属性。
元模型还需要定义对象之间的关系。例如业务流程实现业务能力，应用功能支撑业务流程或业务步骤，应用系统提供相应功能，功能使用数据实体，应用部署于相应技术环境。通过这些关系，可以把原本分散的业务、应用、数据和技术对象连接起来。
因此，元模型真正解决的不是“有哪些表”，而是企业架构中的对象、属性和关系按照什么规则进行统一表达。
三、元模型如何连接不同架构域
企业架构元模型的价值不仅在于统一每个架构域内部的概念，更重要的是建立不同架构域之间的关联关系。
例如，从一个业务流程出发，可以进一步关联执行该流程的业务角色、流程涉及的业务对象以及支撑流程的应用功能；应用功能可以继续关联所属应用模块、应用系统以及使用的数据实体；应用系统又可以关联其运行所依赖的技术平台和技术组件。
这样，业务、应用、数据和技术架构就不再是相互独立的几套设计成果，而能够通过元模型形成完整的关联链路。
当某个业务流程发生变化时，可以沿着元模型关系分析可能受到影响的应用功能和应用系统；当某个应用系统调整时，也可以进一步追溯其涉及的业务能力、数据实体和技术资源。
因此，元模型既是统一架构语言的基础，也是开展跨域追溯、影响分析和架构一致性检查的重要基础。
图1 企业架构元模型的五域对象与跨域关联
四、什么是企业架构制品
元模型定义了企业架构“使用什么语言”，但实际开展架构设计时，还需要通过具体载体表达这些架构信息，这些载体就是企业架构制品。
架构制品可以根据不同使用目的形成目录、矩阵、图形和文档等不同形式。目录类制品主要记录某一类架构对象及其属性，例如业务能力清单、应用模块清单、数据实体清单和技术组件清单；矩阵类制品主要记录不同对象之间的对应关系，例如业务应用矩阵、应用与数据关系矩阵；图形类制品主要用于展示业务流程、应用交互、数据流转和技术部署等结构与关系；文档类制品则用于记录架构原则、标准、设计说明和架构决策等内容。
因此，元模型和架构制品并不是两个并列且相互独立的概念。元模型定义对象、属性和关系，架构制品则按照具体设计场景选择这些对象、属性和关系进行组合和呈现。
例如，元模型规定“应用模块”“功能项”以及二者之间的包含关系，具体项目可以在应用模块清单中记录应用模块，在功能项清单中记录功能项，再通过相关矩阵或架构图展示二者之间的关系。不同制品虽然表现形式不同，但底层遵循的是同一套元模型。
五、如何建立统一的架构制品体系
架构制品不应随着项目需要临时设计，而应在统一元模型基础上形成相对稳定的制品体系。
首先需要明确企业架构设计和治理过程中需要哪些制品，以及每项制品用于解决什么问题。例如现状盘点需要目录类制品，跨域关系分析需要矩阵类制品，方案设计需要架构图和设计文档，架构治理则需要标准、原则和评审记录。
在此基础上，应建立结构化的企业架构制品清单，对每种制品记录其核心用途、适用阶段、更新频率、责任主体、存储形式，同时根据实际管理需要记录依赖关系和版本信息。这样可以明确每项制品为什么建立、在哪个阶段使用、由谁维护以及如何持续更新。
对于制品之间存在依赖关系的情况，也应建立相应关联。例如业务能力发生调整后，可能同时影响业务能力地图、业务应用矩阵以及相关应用设计制品。通过建立制品依赖关系，可以在架构变更时进一步判断需要同步更新哪些成果。
因此，完整的架构制品体系不仅是一张“交付物清单”，还应形成制品定义、使用、更新和维护的管理机制。
六、如何根据架构演进扩展元模型和制品
企业架构元模型不是一成不变的。当企业的业务模式、技术体系和架构设计方法发生变化时，元模型也需要相应扩展。
例如，企业在推进中台建设后，需要进一步将中台服务作为可管理的架构对象。此时首先应判断现有元模型是否能够完整描述中台服务；如果不能，则需要扩展相应对象和属性，而不是只在某一张Excel中临时增加字段。
在已有制品基础上，可以增加中台服务类型、关联业务能力、关联应用模块、关联数据实体、服务等级、负责人等字段，使中台服务不仅能够记录自身基本信息，还能够与业务、应用和数据对象建立关系。在需要统一管理中台服务时，还可以进一步建立中台服务目录，使中台能力能够作为正式架构资产纳入企业架构体系。
同样，随着AI进入企业架构，模型服务、智能体、知识服务等新的架构对象也可以按照相同思路进行处理：首先判断它们是否属于需要长期管理的架构对象，再扩展元模型中的对象、属性和关系，最后同步调整相应架构制品。
这种方式能够避免每出现一种新技术就单独建立一套互不关联的管理表，而是通过元模型持续扩展企业架构语言。
七、如何保证元模型和架构制品长期一致
元模型一旦成为企业架构的统一语言，就需要建立相应的治理机制。首先应统一对象名称、编码规则、属性定义和关系口径，并明确哪些属性必填、哪些属性具有固定取值范围以及哪些对象之间允许建立关系。
元模型发生变化时，还需要同步分析对现有架构制品的影响。例如新增一种架构对象后，需要判断哪些目录、矩阵和图形需要增加相应内容；某个对象的关键属性发生调整后，也需要同步更新使用该属性的制品模板。
与此同时，架构制品也应纳入版本管理。新增、调整和废止制品时，应记录变更原因、生效时间和影响范围，并明确责任主体。这样才能避免元模型已经更新，但项目仍然使用旧模板开展设计的问题。
因此，元模型治理与制品治理应形成联动：元模型负责维护统一架构语言，制品体系负责保证这种语言在实际架构工作中被正确使用。
八、如何推动企业架构元模型落地
元模型建设的最终目的不是形成一份概念定义文件，而是让它真正成为企业架构设计和治理的基础。
落地时可以先选择典型业务域，对已有业务、应用、数据、技术和安全架构成果进行盘点，将现有架构对象映射到统一元模型，识别其中存在的同义对象、重复对象、关系缺失和属性不一致等问题。
随后按照统一元模型调整相应架构制品，使目录、矩阵、图形和文档中的架构对象能够保持一致，并通过实际项目验证对象定义、属性设计和关系设计是否合理。
经过验证的元模型和制品体系，应进一步嵌入架构规划、项目设计、架构评审和架构运营全过程。项目按照统一元模型开展设计，架构制品按照统一模板形成，评审过程中检查对象和关系是否符合元模型要求，运行过程中再根据实际变化持续更新架构资产。
最终形成“元模型定义统一架构语言—架构制品承载架构语言—项目设计产生架构实例—架构治理持续维护和优化”的完整机制。这样，企业架构才能从分散的图表和文档逐步转变为结构统一、关系明确、可以持续积累和复用的架构资产体系。
图2 元模型、架构制品、项目实例与持续治理闭环
参考来源
[1] The Open Group. TOGAF Standard, 10th Edition.
[2] The Open Group. ArchiMate 3.2 Specification.
[3] ISO/IEC/IEEE 42010:2022. Systems and software engineering — Architecture description.
[4] 华为企业架构与变革管理部：《华为数字化转型之道》，机械工业出版社。