第12章：H阶段：架构变更管理
本章着眼于建立管理新架构变更的程序。
12.1 目标
H阶段的目标是：
- 确保保持架构开发周期
- 确保架构治理框架得到执行
- 确保企业架构能力满足当前要求
12.2 输入
本节定义了阶段H的输入。
12.2.1 企业外部参考资料
- 架构参考资料（见TOGAF标准——架构内容）
12.2.2 非架构输入
- 架构工作请求（见TOGAF标准——架构内容）
12.2.3 架构输入
■ 企业架构的组织模型（见TOGAF标准——架构内容），包括：
— 受影响组织的范围
— 成熟度评估、差距和解决方法
— 架构团队的角色和职责
— 建筑工作的限制
— 所需预算
— 治理和支持战略
■ 定制的架构框架（见TOGAF标准——架构内容），包括：
— 量身定制的架构方法
— 量身定制的架构内容（可交付成果和工件）
— 已配置和部署的工具
■ 架构工作说明书（见TOGAF标准——架构内容）
■ 架构愿景（见TOGAF标准——架构内容）
H阶段：架构变更管理
输入
■ 架构库（见TOGAF标准——架构内容），包括：
— 可重复使用的构建块
— 公开可用的参考模型
— 特定组织的参考模型
— 组织标准
■ 架构定义文档（见TOGAF标准——架构内容）
■ 架构需求规范（见TOGAF标准——架构内容），包括：
— Gapanalys的 结果 （来自 业务、 数据、 应用程序 和 技术架构）
— 建筑要求
■ 架构路线图（见TOGAF标准——架构内容）
■ 变更请求（见TOGAF标准——架构内容）——技术变更：
— 新技术报告
— 资产管理成本降低举措
— 技术撤回报告
— 标准倡议
■ 变更请求（参见TOGAF标准——架构内容）——业务变更：
— 业务发展
— 业务例外
— 商业创新
— 商业技术创新
— 战略变革发展
■ 变更请求（见TOGAF标准——架构内容）——从经验教训中总结
■ 实施治理模型（见TOGAF标准——架构内容）
■ 架构合同（已签署）（见TOGAF标准——企业架构能力和治理）
■ 合规性评估（见TOGAF标准——架构内容）
■ 实施和迁移计划（见TOGAF标准——架构内容）
12.3 步骤
H阶段所涉及的详细程度将取决于整体架构工作的范围和目标。
H阶段的步骤顺序以及正式开始和完成的时间应根据既定的架构治理适应当前的情况。
H阶段的步骤如下：
- 建立价值实现过程（见第12.3.1节）
- 部署监控工具（见第12.3.2节）
- 管理风险（见第12.3.3节）
- 提供架构变更管理分析（见第12.3.4节）
- 制定变更要求以实现绩效目标（见第12.3.5节）
- 管理治理流程（见第12.3.6节）
- 启动流程以实施变更（见第12.3.7节）
12.3.1 建立价值实现过程
影响业务项目，利用企业架构实现价值（结果）。
12.3.2 部署监控工具
确保部署和应用了监控工具，以实现以下功能：
- 监控可能影响基线架构的技术变更
- 监控可能影响基线架构的业务变化
- 业务价值跟踪；例如，确定业务目标价值指标的投资评估方法
- 监控企业架构能力成熟度
- 跟踪和评估资产管理计划
- 跟踪服务质量（QoS）性能和使用情况
- 确定并跟踪业务连续性要求
12.3.3 管理风险
管理企业架构风险，并为IT战略提供建议。
12.3.4 为架构变更管理提供分析
提供架构变更管理分析：
- 分析性能
- 通过服务管理进行企业架构绩效评估
- 评估变更请求和报告，以确保满足客户的预期价值实现和服务水平协议（SLA）期望
- 对企业架构的性能进行差距分析
- 确保变更管理请求符合企业架构治理和框架
12.3.5 制定变更要求以实现绩效目标
就变更要求提出建议，以实现绩效目标和职位发展。
12.3.6 管理治理流程
管理架构的治理流程和框架：
- 安排建筑委员会（或其他管理委员会）会议
- 召开架构委员会会议，以决定如何处理变更（技术、业务和豁免）
12.3.7 启动实施变革的流程
激活架构流程以实施变更：
- 提出新的建筑工作申请和投资申请
- 确保在此阶段实施的任何更改都被捕获并记录在架构存储库中
12.4 输出
H阶段的输出可能包括但不限于：
- 架构更新（用于维护更改）
- 架构框架和原则的更改（用于维护更改）
- 新的架构工作请求（请参阅TOGAF标准——架构内容），以进入另一个周期（有关重大更改）
- 架构工作说明书（见TOGAF标准——架构内容），必要时进行更新
- 架构合同（见TOGAF标准——企业架构能力和治理），必要时进行更新
- 合规性评估（见TOGAF标准——架构内容），必要时进行更新
12.5 方法
架构变更管理过程的目标是确保架构实现其最初的目标业务价值。这包括以连贯和架构化的方式管理架构的更改。
这个过程通常会提供对治理请求、技术新发展和业务环境变化等事物的持续监控。当识别出变更时，变更管理将决定是否正式启动新的架构演化周期。
此外，架构变更管理过程旨在将已实施的企业架构建立并支持为动态架构；也就是说，它具有灵活性，可以快速发展以应对技术和商业环境的变化。监控业务增长和衰退是这一阶段的一个关键方面。企业架构的使用是架构开发周期中最重要的部分。企业往往只剩下一个企业架构，它适用于昨天的组织，但可能无法提供足够的能力来满足今天和明天的企业需求。在许多情况下，架构仍然适合，但它们背后的解决方案可能不适合，需要进行一些更改。
企业架构师需要了解这些变更要求，并将其视为架构不断更新的重要组成部分。容量测量和规划建议是这一阶段的一个关键方面。虽然该架构的构建是为了在该企业架构的生命周期内提供具有商定容量的稳态业务架构，但需要不断评估使用量的增长或下降，以确保实现最大的业务价值。
例如，一些解决方案架构可能不适合大幅扩展，比如10倍，或者其他解决方案在扩展时可能更经济。虽然架构规范可能不会改变，但解决方案或其操作环境可能会改变。
如果绩效管理和报告已通过以下方式内置到工作产品中。在前面的阶段，那么这个阶段是为了确保这些阶段的有效性。如果需要额外的监控或报告，那么
这个阶段将处理这些变化。
价值和变更管理流程一旦建立，将决定：
- 部署后允许企业架构或其部分更改的情况，以及更改的过程
- 重新启动架构开发周期以开发新架构的情况
架构变更管理过程与企业的架构治理过程以及架构功能和企业业务用户之间的架构合同（见TOGAF标准——企业架构能力和治理）的管理密切相关。在H阶段，治理机构必须制定标准，以判断变更请求是否只需要架构更新，或者是否需要启动新的ADM周期。
避免“缓慢优雅”尤为重要，治理机构还必须继续寻找与业务价值直接相关的变更。架构合规性报告应说明更改是否符合当前架构。如果它不符合规定，可以在有正当理由的情况下给予豁免。
如果变更对架构有很大影响，那么应该定义一个管理其影响的策略。建立这些标准的指导方针很难规定，因为许多公司接受风险的方式不同，但随着ADM的实施，治理机构的成熟度将提高，标准将针对具体需求变得清晰。
12.5.1 变革的驱动因素
到目前为止，开发企业架构的主要目的是战略方向和自上而下的架构和项目生成，以实现企业能力。然而，企业架构并不是在真空中运作的。通常，现有的基础设施和业务已经在提供价值。基于修改现有基础设施以增强功能，也可能有自下而上的变革驱动因素。企业架构在一定程度上通过自上而下的战略方法改变了这一范式，尽管增量的交付使等式变得更加复杂。
有三种方法可以改变必须整合的现有基础设施：
- 自上而下的战略性变革，以增强或创造新的能力（资本）
- 自下而上的更改，以纠正或增强运营管理下基础设施的能力（运营和维护）
- 以前交付的项目增量在运营管理方面的经验，但仍由正在进行的项目交付
治理层必须处理这些变更请求的协调，此外，还需要一个经验教训流程，以解决最近交付的增量
问题，并对正在设计和规划的目标架构进行更改。
吸取经验教训的过程确保了错误只犯一次，不会再犯。它们可以来自任何地方和任何人，涵盖任
何级别的企业架构的任何方面（战略、企业架构定义、过渡或项目）。通常，与企业架构相关的
课程可能是组织中其他地方学到的课程的间接结果。
架构委员会（参见TOGAF标准——企业架构能力和治理）评估和批准变更请求（RFC）。RFC通常是对已知问题的响应，但也可以包括改进。架构委员会在处理RFC时面临的一个挑战是确定是否应该批准它，或者过渡架构中的项目是否会解决这个问题。
在评估项目或解决方案是否适合架构时，也可能存在创新解决方案或RFC推动架构变化的情况。
此外，架构变更请求有许多与技术相关的驱动因素。例如：
- 新技术报告
- 资产管理成本降低
- 技术撤回
- 标准倡议
这种类型的变更请求通常主要通过企业的变更管理和架构治理流程进行管理。
此外，架构变更还有业务驱动因素，包括：
- 一切照旧的发展
- 业务例外
- 商业创新
- 商业技术创新
- 战略变革
这种类型的变更请求通常会导致架构的完全重新开发，或者至少是架构开发周期的一部分的迭代，
如下所述。
12.5.2 企业架构变更管理流程
企业架构变更管理过程需要确定如何管理变更、应用什么技术以及使用什么方法。该过程还需要
一个过滤功能，以确定架构开发过程的哪些阶段受到需求的影响。例如，仅影响迁移的更改在架
构开发阶段可能不感兴趣。
有许多有效的变革管理方法，以及可用于管理变革的各种管理技术和方法；例如，PRINCE2等项目管理方法、ITIL等服务管理方法、Catalyst等管理咨询方法等等。
已在某一领域实施变更管理流程的企业架构（例如，在系统开发或项目管理中）很可能能够使其适应架构的使用。
以下描述了一种变更管理方法，特别是为了支持动态的企业架构，如果目前没有类似的流程，可
以考虑使用该架构。
该方法基于将所需的架构更改分为三类之一：
- 简化变更：简化变更通常可以通过变更管理技术来处理
- 增量变更：增量变更可能能够通过变更管理技术进行处理，也可能需要部分重新架构，具体取决于变更的性质（指南见第12.5.3节）
- 重新架构更改：重新架构更改需要将整个架构再次经历架构开发周期
看待这三个选择的另一种方式是，对架构的简化更改通常是由减少投资的要求驱动的；增量变化
是由从现有投资中获得额外价值的要求驱动的；而重新架构的变化是由增加投资以创造新的开发
价值的需求驱动的。
为了确定更改是简化、增量还是重新架构，需要进行以下活动：
- 登记可能影响架构的所有事件
- 架构任务的资源分配和管理
- 负责架构资源的流程或角色必须评估应该做什么
- 影响评估
12.5.3 维护与架构重新设计指南
一个好的指导方针是：
- 如果变更影响两个或多个利益相关者，则可能需要重新设计架构并重新进入ADM
- 如果变更只影响一个利益相关者，那么它更有可能成为变更管理的候选者
- 如果在豁免下可以允许变更，那么它更有可能成为变更管理的候选者
- 如果对业务战略的影响很大，那么可能需要重新设计整个企业架构，从而采用重新架构的方法
- 如果新技术或标准出现，那么可能需要更新技术架构，但不需要更新整个企业架构，因此需要进行渐进式更改
- 如果更改是在基础设施级别进行的，例如，将十个系统减少或更改为一个系统，这可能不会改变物理层以上的架构，但会改变技术架构的基线描述；这将是通过变更管理技术处理的简化变更。特别是，在以下情况下，可能需要刷新周期（部分或完全重新架构）：
- 基础架构需要与业务战略重新对齐
- 需要对架构部署中使用的组件和指导方针进行实质性更改
- 产品架构中使用的重要标准发生了变化，对最终用户产生了重大影响；例如，监管变化
如果需要刷新周期，则必须发出新的架构工作请求（以进入另一个周期）。