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