开篇
如果要谈企业架构治理就得先说企业战略。企业战略是企业为实现其商业目标选择的目标，以及为了达到目标的路径与手段。由于企业的一切活动都是围绕商业展开的，同时商业活动的不断发展需要IT的支持。因此可以将企业战略分为：业务战略和 IT 战略。
业务战略是我们经常提起的，它描述了明确的商业目标，并且为其制定了长期的规划(大约 3-5 年)。
IT 战略是根据业务战略而制定的与IT基础设置、软/硬件服务/产品相关的战略。它由不同项目计划组成，利用信息技术协助企业完成业务战略。IT战略需要与业务战略保持同步，将企业的IT能力赋能给企业的商业活动，从而完成企业的战略目标。
无论是业务战略还是IT战略无疑都是服务于公司治理的。公司治理是指影响公司的方向和业绩表现的各类参与者(股东;经理班子;董事会;职工、顾客、供应商、债权人;政府、社区、公众等)之间的关系，涉及主要参与者的权利、责任和影响，以及在决定公司的方向、战略、业绩表现时能做什么和应该做什么。
有了IT战略就需要对其构建、评估和实施，只有这样才能将其IT战略与业务战略紧密对齐，保证战略发展的方向一致、步调一致。因此，IT治理就应运而生了，它是用来处理业务焦点和 IT 管理之间的联系， IT 治理是流程、实践、规则和关系的组合。
光有IT治理来解决企业IT战略落地的问题似乎还不够，因为要让IT战略与业务战略对齐并且融合并不是IT 部门或者IT 内部结构能够解决的问题，需要调动公司其他的部门、资源和力量来完成。因此，就提出了企业架构治理(EAG，Enterprise Architecture Governance)的概念。
企业架构治理 (EAG)是行使经济、政治和行政权力来管理企业架构的开发和实施。它是组织结构和流程的集合，组织通过它控制其部署的 IT 解决方案，以确保IT战略与企业架构愿景、原则和标准保持一致。
上面提到了几个概念注入公司治理、业务战略、IT战略、IT治理，企业架构治理(EAG)等等，这里用一张图将它们的关系梳理一下。
图 1公司治理、业务战略、IT战略关系图
如图1 所示，从上往下看公司治理在图的顶端，它代表公司参与者的利益，决定公司的方向、战略、业绩。业务战略和IT战略都是为了支撑公司治理而存在的，业务战略决定了公司的商业发展路径和手段，因此IT战略需要主动向业务战略对齐，保持步调一致。由于IT 战略是顶层架构需要具体的实施细则，因此会包含IT治理和企业架构治理(EAG)两个部分。
IT治理是整合企业中的IT 能力用来构建、评估、实施IT 战略的。但是只有IT能力是无法实现IT战略的，还需要整个企业中的其他资源，因此就有了企业架构治理(EAG)，它会去整合整个企业中的其他资源，完成企业架构的开发和实施。从紫色区域整合了IT能力和企业资源可以看出来，它是IT能力与组织、流程等相关资源的粘合剂，它会行使企业中经济、政治和行政权力来管理企业架构的开发和实施。
本文的重点放在企业架构治理(EAG)，后简称为EAG。EAG会包括企业结构和一组政策、流程和程序，企业可以通过这些政策、流程和程序控制其部署的 IT 解决方案，以确保它们与企业架构愿景、原则和标准保持一致。
EAG治理不仅是 CIO 和 IT主管的责任，也需要业务部门主管以及企业架构师、领域架构师、业务专家和其他人员参与，这也是为什么上文中说到的需要整合企业内的资源。
如果没有很好的执行EAG，就无法保持业务战略和 IT战略 的一致性，这种不协调也会影响到公司战略的实现。
本文会对EAG进行定义，并描述其框架，然后针对框架的组成部分进行逐一讲解。
EAG定义与架构
EA 是一项持续性的活动，其中EAG是一个过程，有助于管理和维护组织的架构，围绕企业战略并且保证业务战略和 IT战略 的一致性。EAG确保企业中的所有元素(人员、部门、IT 系统、应用程序)相互协调并服从IT战略的发展。
EAG 治理的目标是：
1. 确保IT战略对应的实施计划被采纳和遵守。
2. 确保决策过程与企业架构保持一致。
3. 为所有利益相关者提供架构上的保证。
4. 保持企业的相关性以满足不断变化的需求。
为了实现上述目的EAG引入了一些元素，并且通过EAG模型让这些元素产生联系，互相影响互相推动从而达到EAG的目标。为了能够全面地理解EAG 架构，通过一张图来描述架构以及组件之间的关系。
如图2 所示，我们从右下角蓝色部分开始，企业架构组织(Enterprise Architecture Organization)由企业架构审核委员会(EARB)和能力中心(Competency Centre)组成，他们会根据EA 架构定义、开发、维护、管理、发布企业架构的设计。这些设计的形式多种多样，我们统称为 企业架构分类(EA Framework Taxonomy)，后文称为EA 分类。
EA分类也就是绿色的部分，它主要用来维护EA中的定义、规则、协议，这些分类会根据不同的IT 策略进行调整，同时可以保存到企业架构存储库中(EA Repository)。同时这些EA的分类用来标准化和优化治理流程(Governing Process)，这也就是左上角的橙色部分。
治理流程是用来实施具体EAG 过程的，它需要企业架构的其他领域的引导和驱动，这样EAG才能适合EA的不同领域。换句话说即便是通过专家团队定义的EA分类形成的治理流程，也需要适应企业的不同领域需要，说白了就是要从一般到特殊。让通用的治理流程适应具体的领域需求。同时企业架构组织也会对企业架构中不同的领域进行支持。
图 2 EAG 架构以及组件之间的关系
上面说了EAG 架构中组件之间的关系，这里用一句话总结。企业架构组织是由企业中的一群人组织而成，它包括EARB(企业架构审查委员会)和能力中心，他们会定义、开发、维护、管理、发布EA分类以及支持企业架构的其他领域，定义出来的EA分类可以保存到企业架构存储库中，并且可以用来标准化和优化治理流程，有企业架构组织所支持的企业架构的其他领域也可以引导和驱动治理流程的完成，而治理流程就是具体处理企业架构执行的过程。
也就是企业中的一帮大神，定义了一套规则，将这套规则应用到流程中，让流程能够应用到企业的各个领域中。
下面我们就来逐个介绍每个组件的意义和作用。其顺序如下：
EA 组织结构->EA分类->EA 治理流程->EA 存储库
企业架构的其他领域需要根据具体企业进行区分和讲解，这里不展开说明。
EA组织结构
企业架构组织帮助企业开发并支持企业架构 (EA) 的设计、审查、执行和治理功能。它需要担负与EAG相关的职能，从三个方面来描述：
- EA 框架：建立一套标准、程序和操作协议，用于指导决策信息技术的采用、重用、报告和报废。包括指导原则、方法、程序、指标、最佳实践和参考模型。
- EA 治理：建立一个跨组织、多学科的架构审查委员会 (EARB)，得到企业 IT 执行管理层的支持，负责监督技术治理战略和框架定义的实施。
- EA 合规性：定义 EA 合规策略并制定一套一致的、可重复的流程以确保该 EA 合规策略。建立正确的组织职责和结构，以支持架构治理过程和需求的报告。
在EAG 架构中谈到了EA组织结构会为EA流程提供指导和特征描述，会通过EA 分类的方式应用到EA流程中。需要保证如下几个原则：
- 标准化：制定和推广企业范围的 IT 标准。
- 一致性：实现所需级别的信息、流程和应用程序集成以及互操作性。
- 重用：在设计、实施和产品组合级别实现 IT 资产重用和优势的策略以及支持能力。
- 质量：提供满足业务功能和技术要求的解决方案，以及确保解决方案质量的生命周期管理流程。
- 成本效益和效率：通过可重复的决策治理流程实现标准、重用和质量的一致优势，从而降低总解决方案生命周期成本，并更好地实现 IT 投资。
EA 小组负责整体架构规划和监督，包括审查技术计划、建立标准和指南、为企业范围的技术计划提供定向输入以及审查技术收购。通常，EA 首席架构师向 CIO 报告，EA 小组为 IT 领导提供指导支持。
我们通过一张图来描述EA组织结构的包含要素以及对应的关系，如图3 所示，先从Enterprise IT Leadership(企业IT领导) 开始，它在垂直方向会与Enterprise Architecture Review Board(EA 审查委员会)关联，在对其进行领导的同时，也会接受委员会的建议和指导，从而帮助推进EAG的进程，毕竟需要它去调动公司的其他资源进行横向沟通。
说到横向沟通它会与Program Management Office (项目管理办公室)保持密切合作，任何的EAG的EA 流程需要实施都离不开Program Management Office的推进。然后Technology Office(技术办公室)、Enterprise Architecture Review Board(EA 审查委员会)和 EA Competency Center(EA 能力中心)形成了一个EA Architecture Group(EA架构小组)，这是一个虚拟的组织，因此用虚线将它们框起来。
他们三者需要合作完成EAG 中定义EA 分类的大部分工作，Enterprise Architecture Review Board(EA 审查委员会) 是这个虚拟团队的核心，他负责对每个小组的产出物进行审核、指导以及监管，同时也会和Enterprise IT Leadership(企业IT领导)不断同步，从而保持向着正确的方向推进工作。同时Enterprise Architecture Review Board(EA 审查委员会)还有一个职责就是与企业不同领域的专家保持联系，从而保证开发出的流程标准能够适用于不同的领域。EA Competency Center(EA 能力中心)在水平方向也会连接Other IT Competency Centers(其他的IT能力中心)，以便不断观察科技和行业的变化，让自身的能力得以扩展。
图 3： EA 组织架构图
上面对EA 组织架构的元素以及它们之间的关系进行了描述，这里对几个重点组织的工作范围和内容进行进一步地了解。
企业 IT 领导委员会：由 CIO 和业务主管在内的管理人员组成，将定义企业战略要素，并与项目管理办公室和 EARB 协调，将这些要素转化为程序要素(EA 分类)。以下是企业 IT 领导委员会的职责：
- 与 CIO 一起管理业务组合
- 与 CIO 一起制定业务战略
- 制定企业战略方向和优先级
- 与 EA 其他的工作组合作，在项目组合中进行尽职调查
技术办公室：创建EA元素(业务模型、应用程序架构、数据架构、基础设施等)，提出EA流程以及EA 生命周期流程。它的产出物会作为EA 分类的重要组成部分。
EA 审查委员会：由架构师组成，主要参与架构审查、项目优先级和批准、供应商评估和流程审查。
EA 能力中心：密切关注市场中的新技术发展，并确定由此为企业产生的商业价值。它会协助将旧系统迁移到新技术平台上，并且提供对应的流程和迁移方法。这是通过使用特定技术带来的商业价值。
在典型的 IT 决策框架中有许多组织结构模型。企业通常会根据不同的决策框架使用不同的组织架构模型。具体分为集中式、分散式和联合架构模型。
集中式架构
如图4 所示，位于上方的Organization Enterprise Architecture是中央架构团队的权威，负责定义EAG进程中的框架和指南，其他的Business Unit 遵循中央架构团队的规定并予以执行。此模型定义了要在整个企业统一的参考架构和开发标准。
图 4：集中治理模型
从技能和开销的角度来看，集中式模型是经济的，但对于建立客户关系、培养 IT 员工的业务知识帮助都不大，通过这种模式定制架构解决方案从而适应多变的业务需求就显得比较困难.
分散式架构
如图5所示，最上层的Organization 针对不同的Business Unit 分配对应的管理权限，将管理的权限分布到不同的Business Unit上面从而适应不同的业务模式。因此，分散式架构模型也是分布式模型。在分散式模型中，解决方案架构与特定的业务线保持一致，通过Business Unit 中的架构师向对应的业务线进行报告。这是为了促进管理办公室 (PMO) 和企业执行委员会(EARB)之间更好地协调工作。
分散式架构使业务线对 IT 架构具有最大的控制权，并使 IT 服务交付与业务需求紧密结合。分散式架构模型面临的主要挑战是难以在业务领域单元之间实施架构一致性，从而导致 IT 资产组合分散且可能出现不一致。在实现企业范围内的流程、信息和应用程序方面会遇到挑战。此外，还存在潜在的 IT 能力冗余，跨域优势有限等问题。也就是能力和资源分散了，增加了IT架构的灵活性，同时也带来了无法统一标准，资源冗余的问题。
图 5：去中心化架构模型
联合架构
在联合模型中，企业 IT 架构中央单元(例如 CIO/CTO 办公室)主要负责架构、通用基础架构和服务以及整个企业通用的标准和框架。每个业务领域都对自身领域的标准和资源决策负责。业务域和应用程序 IT 设计汇总到业务域进行管理。
如图6 所示，最上面的Organization 相当于企业IT架构的中央单元，它对具体的业务单元Business Unit执行治理工作，每个Business Unit 对其所在的业务线进行管理，并且分别向中央单元进行工作汇报。
图 6联合治理模型
联合架构模型让企业整体框架与具体业务领域之间保持良好的关系，也让 IT 与业务需求保持了一致。
企业架构审查委员会 (EARB)
说完了EA 组织结构以及对应的三种架构模式，再把目光放到组织中最重要的组成部分：企业架构审查委员会(EARB)。EARB负责与企业中各个组织进行沟通，并且由CIO 担任EARB的主席。
企业架构审查委员会负责处理信息管理架构的计划，根据预期的业务成果，对计划需要实施的行为进行审查。
企业架构审查委员会通常负责实现以下目标：
- 创建、管理和拥有企业架构
- 让企业子架构之间保持一致性
- 保持企业架构的灵活性
- 满足不断变化的业务需求
- 利用新技术
- 保证企业架构的合规性
- 提高架构的成熟度
- 确保架构的开发原则
- 为架构更改提供决策基础
- 识别可重用组件
架构委员会的日常工作是：
- 定期开会，保持信息沟通
- 管理和实施架构的有效性和一致性
- 解决歧义、问题、冲突
- 为实施团队提供建议、指导和信息
- 验证报告的服务水平、成本等
其治理职责是：
- 通过共识和授权发布架构的接受和批准
- 提供控制机制以确保架构的有效实施
- 建立和维护架构的实施，并维系架构战略目标和业务战略目标之间的联系
- 通过政策更新识别架构和规划活动的分歧，从而进行调整
EARB 结构和环境
企业架构审查委员会通过各种活动支持 EA 组织实施 IT 战略，例如：
- EA 框架的定义和 EA 元素的治理
- 定义和持续改进架构管理流程
- 定义项目的架构验收标准
- 审查架构变更、处理偏差
- 查看 EA 指标和 EA 一致性报告
- 确保架构组件与业务保持一致
- 保证IT 项目架构的复用性
图7表示 ARB 的结构及其环境，
图 7企业架构审查委员会和相关环境
如图7 所示，Enterprise Architecture( EA 工作组)将与 IT 项目团队、IT PMO 和 IT 领导层(IT Leadership)密切合作。IT 领导层为 IT 职能部门提供业务目标的战略方向。EA 工作组和 EARB 将负责确保所有 IT 项目都符合战略方向。他们将与项目团队密切合作，在选择、确定优先级和执行项目时提供治理并确保遵守标准和原则。EA 工作组的一项关键活动是为项目团队提供架构咨询和审查。EA 工作组将与 IT PMO 密切合作，提供最佳实践建议和项目治理。IT 领导委员会审查 EARB 的决定。同时，CIO 是决策的最终权威，并有权最终审查/修改决策。
EA 分类
说完了企业架构审查委员会之后，就要谈谈这个委员会的产出物，也就是EA 分类。EA 分类是对一些规则、协议、指标、流程的定义，因此它是一个统称，实际上是在EAG架构中需要用到的要素的集合。由于这种特性，EA分类也被理解为定义术语的集合，这些术语的定义是为了让组件和架构概念结构更加清晰。每个术语都可以理解为EAG 架构中的一个要素，我们把这些要素通过一张图展开说明。
如图8所示，最上方的EA Governance 的部分包含了Arch Types(架构类型)、Model & Structure(模型与结构)以及Linkage to IT Governance(与IT 治理之间的关系)。最重要的部分也就是下面的 EA Framework Taxonomy(EA 框架分类)，也就是我们所说的EA 分类，这里将这些要素分成三类，每类包含一个或者多个要素，也就是说每个分类就是要素的集合，这个分类称为组件，包括Foundational(基础组件)、Supporting(支撑组件)以及Canonical(规范组件)。在最下方会和Architecture Domains and Linkages(架构领域以及联系)保持关联性， 在架构领域中就包含了具体的Business(业务)、Data(数据)、Application(应用)、Technology(技术)，这些都会给EA 分类中要素的制定提供基础的保证。
图 8 EA 分类要素
在上图中我们介绍了EA 分类所处的位置和基本分类，这里对分类要素进行详细的描述：
Foundational(基础组件)：基于行业事实、企业 IT 环境和文化，为支持组件要素和规范组件要素提供基础。其分类结构由 EAG管理，它与 IT Governance 相关联。Guiding Principles(指导原则)是该领域的关键要素。
Supporting(支持组件)：基于Foundation组件、行业实践、企业文化和IT环境的指导原则。Metrics(指标)、Best Practices(最佳实践)、Methodologies(方法论)、Approaches(方法)和Protocols(协议)是该领域的关键要素。
Canonical(规范组件)：基于参考架构、IT 流程和架构标准中的行业事实定义，以及企业的支持框架组件。Standards(标准)、Blue Prints(蓝图)、Processes(流程)是该领域的关键要素。
下面列出了关键概念和术语的具体定义。
EA 治理流程
有了EARB通过与其他部门、组织、领域合作生成对应的EA 分类，这些分类按照分组将对应的要素进行整合，然后EARB将这些要素进行输出，然后将其应用到EA 流程中。那么说完了EARB 和 EA分类之后就来到应用EA分类的EA治理流程的部分了。
EA治理流程主要用来维护EAG的执行流程，如果说把EAG的执行流程理解为一个生命周期的话，那么这个生命周期过程会应用于实施技术解决方案中。下面列出五个主要过程/流程：
- 架构文档流程
- 架构审查流程
- 架构沟通过程
- 架构合规流程
- 架构框架活力过程
架构文档流程
EA 框架阐明了组织的业务和技术架构，为产品和合规性提供了对应分类。该文档流程为企业确定技术解决方案提供了丰富的信息。企业和领域架构师负责企业架构的开发和验证。
架构文档流程描述了开发和维护 EA 框架的过程。
架构文档流程提供了创建初始技术架构框架所需的步骤，并由其他架构生命周期流程触发，包括：
- 架构框架活力过程
- 在架构合规过程中生成的请求
- 记录架构审查过程的结果
架构审查流程
IT 项目审查是 EARB 提供的核心功能或服务之一，以帮助实现以下目标：
- 遵循企业级 IT 指导原则 – EA 合规性
- 确保与企业 IT 生态系统的一致性
- 在企业范围内促进IT组件复用
- 确保架构的可操作性
- 确保所有架构决策都是合理的
- 降低项目失败风险
- 测量和监控其他风险
- 不断更新和交流 EA 的分类元素
以下步骤描述了 EARB 审查整个企业的项目，包括：
- 企业范围转型的项目
- 偏离 EA 路线图和方向的项目
- 不限于单个部门的项目
- 关键任务项目
- 对业务至关重要的项目
架构沟通过程
架构沟通流程确保 EA 框架内容及时准确地沟通。如果没有彻底的沟通过程，企业架构就只是一个文档，也就是一个框架，没有提供实质的内容。
所有人都有权访问最新版本的企业架构文档和蓝图。构建机制向所有人传递文档以及更新信息。企业架构的充分沟通在确保企业活动、EA 框架、企业战略计划同步方面起着至关重要的作用。
每当企业架构由于架构审查、架构活力或架构文档过程而发生显著变化时，需要及时将信息传达给架构受众。
架构沟通是一组沟通“文档”，可以将企业架构信息传播给架构受众成员。
架构合规流程
架构合规流程描述了企业对产品以及组件进行差异化调整的流程。从企业的角度来看，合规流程是管理信息技术适当以及合理的方法。
架构合规流程的关键触发因素如下：
- 项目团队需要解决任何内部工具、技术或解决方案出现的问题。
- 项目团队也需要控制项目预算。
- 提供技术领域的单一产品的解决方案。
- 对于没有使用的新/复杂技术的架构进行申请。
架构合规流程的审核结果是架构框架活力流程的输入。合规流程由三个子流程组成，包括：
- 请求架构协助
- 确定技术选项
- 创建架构差异业务案例
架构框架活力过程
架构框架活力过程是用来确保EA 框架内容的准确性和及时性。为确保企业架构活力，从业务战略要素、IT 战略要素和增强建议的角度对 EA 框架进行了审查。能够让顾问为业务战略和 IT 战略提供意见。
当业务战略、 IT 战略发生明显转变时，就需要进行架构框架审查。EA 框架审查应至少每隔一到两年进行一次。
例行审查已记录的 EA 框架过程由子过程组成，从而对架构更新进行确定、记录和申请。
以下三个事件导致 EA 框架发生变化：
- EARB 的建议
- 架构框架元素增强
- 提供给 CTO 的业务战略转变
- 提供给 CTO 的 IT 战略转变
EA 存储库
聊完了EA治理有流程之后，就谈到了EA存储库，它是用来存储EARB生成的EA分类信息。用来捕获、存储、构建和分析与企业架构有关的信息，并将信息呈现给企业利益相关者。并通过捕获重要的企业环境以及跨业务、信息、技术和解决方案架构的内容开发和分析功能，为战略决策制定提供支持。
EA 工具通过捕获重要的企业环境以及跨业务、信息、技术和解决方案架构的内容开发和分析功能，为战略决策提供支持。
它帮助利益相关者分析和优化企业架构内容，包括业务战略、组织结构、业务流程/任务和活动、信息流、应用程序和技术基础设施。
EA 工具包含以下功能特性：
- 建模能力
- 框架和标准支持
- 创建、导入模型
- 强大而灵活的存储库和数据模型
- 易用性
- 为集成多企业提供工具
- 影响企业领域各个层面的能力
- 满足需求的管理功能，例如安全、审计、控制、协作、配置和版本控制
未来研究方向
前面通过EAG的架构描绘了EAG每个组件的功能以及之间的关系，这都是从理论角度在描述如何进行EAG。但是方法论始终只是参考，着眼当下，企业架构师需要根据企业情况有预见性地建立协作模型，并且采取以结果为驱动的架构方法。
在最近一份关于 2022 年企业架构未来的研究报告中，Gartner 预测，现代企业架构和技术创新领导者将在未来十年发挥作用。企业架构师必须在以下方面扩展他们的角色和技能，
- 支持业务和 IT 的战略规划
- 专注于商业生态系统中的数字技术
- 学习并采用云、微服务、API 管理和 DevOps 等下一代技术。
- 增强综合业务和技术技能，在未来十年发挥作用
- 采用不同的工具来分析不断变化的计划、进行中的项目和现有资产随着时间推移的状态的相互关系和相互依赖关系
此外，企业架构师需要参与技术创新，敏捷的架构开发方式。
结论
设计良好的企业架构治理结构可以降低 IT 成本和风险、加速决策制定和交付。它确保投资决策从启动到实施都与 EA 保持一致。
治理是任何变革计划的重要组成部分，EA 也不例外。治理为各种利益相关者提供了一个定期交互和维护企业架构的平台。如果没有充分的治理，企业架构将仍然是一个理论概念，无法提供所需的业务收益。
EAG在现代EA中的作用总结如下：
- 不要专注于当前状态架构，要放眼未来架构发展
- 继续将 EA 程序推进到下一个成熟度级别
- 了解组织的业务战略、业务模型和目标，并确定 EA 如何帮助实现业务价值
- 不要被 EA 框架、行业参考模型、治理和 EA 工具扰乱心智，还是要专注企业自身的EAG
- 对 EA 程序采用持续创新的方法，完善每个迭代的工作
- 不要在不了解用例和功能的情况下购买 EA 工具
作者介绍
崔皓，51CTO社区编辑，资深架构师，拥有18年的软件开发和架构经验，10年分布式架构经验。曾任惠普技术专家。乐于分享，撰写了很多热门技术文章，阅读量超过60万。《分布式架构原理与实践》作者。
