TOGAF架构开发方法（ADM）之架构变更管理阶段
TOGAF架构开发方法（ADM）之架构变更管理阶段
1.10 架构变更管理（Architecture Change Management）
企业架构开发方法各阶段——架构变更管理
1.10.1 目标
本阶段的目标是：
- 确保基线架构持续符合当前实际。
- 评估架构性能，并对变更提出建议。
- 评估在之前阶段制定的框架和原则的变化。
- 为实施治理阶段建立的新的企业架构基线建立架构变更管理流程。
- 将架构和运营的业务价值最大化。
- 运用治理框架。
1.10.2 方法
架构变更管里流程的目标是保证架构能够达成其目标业务价值，并且这一过程还着眼于将原本静态的企业架构建设成为一个动态的架构，使其具有足够的灵活性来对技术和业务环境的改变来进行快速地适应性演进。为了达成这些目标，架构变更管理过程往往针对治理请求、技术上的进步以及业务环境的变化进行持续的监督，同时当这些变更被识别出来后，这一过程还需要对是否启动一个新的架构演进循环而做出决定。由此可见，这一阶段的中心思想就是监督并明确企业所处环境的变更，并据此做出适当的架构变更决策。在变更的监督和明确过程中我们需要注意如下几个方面：
- 监督业务的消长是这一阶段的一个重要方面。针对企业架构的使用也是架构开发循环中的最重要的一环。在企业中，当前架构支持下的业务虽然能够满足当前的需要，但是对于未来的情况却不一定适用。并且在多数情况下，架构即便能够跟得上变化并始终保持适用，但各种用于对其进行实现的解决方案却不一定可以，因而针对他们的变更也是必要的。企业架构师需要了解这些变更需求，并把他们当作架构持续更新的一个重要组成部分来进行考虑。
- 容量评测和针对规划的建议是这一阶段的另外一个重要方面。虽然企业架构提供了一个稳定的业务架构，且此业务架构在企业架构生命周期中所提供的能力也是大家所共识的，但是对其使用的增加或减少还是需要被持续监督下去，从而保证最大业务价值的获取。例如，在企业当前状态下，当前的架构和解决方案能够满足需要，但是如果企业规模扩大一个量级后，其他的解决方案却可能更加经济有效。
需要注意的是，如果性能管理和汇报已经在之前的几个阶段中被加入到工作产品序列之中，那么在此阶段中，组织就需要保证其有效性，而如果还存在其他需要被监督和汇报的需求，那么这一阶段还需要对这些变化进行处理。
在架构变更管理阶段，治理机构还需要建立各种指标，用于判断对于一个变更请求来说，是采用架构更新措施，还是启动一个新的架构开发循环。在这些标准的制定过程中，企业需要注意避免“完美蠕行”（Creeping elegance）病症，并且治理机构也必须持续寻找与业务价值直接相关的各种变更。架构合规评估报告需要表明一个变更是否与当前架构相适应，如不适应则需要表述其理由，而如果这一变更对架构具有很大的影响，则一个用于管理其影响的策略需要被制定出来。就像不同的企业能够接受不同程度的风险一样，为这些评估标准的制定建立统一的实施指南是非常困难的，但随着架构开发方法的不断实践，治理机构的成熟度水平会日渐提高，这些标准也会根据特定的需求而逐渐清晰起来。
变更驱动力
架构开发的主要目标是将企业的战略目标经由企业架构和各实现项目的捏合最终实现企业自身能力的提升，但在这一过程中，起重要作用的企业架构并不是凭空产生的，在它的周围总是存在着一系列正在创造价值（也许效率不是最优）并等待被整合的基础设施和业务，而针对他们的整合变更，以及外界环境对他们的变更需求，都在企业架构的演进过程中充当了驱动力。一般来讲，有三种方式来对这些将要被整合的基础设施进行变更：
- 来自于战略层面自上而下的变更，用于增强或创建新的能力。
- 来自于下面的自下而上的变更，用于修正或更新运营管理中各基础设施的能力。
- 在项目进展过程中产生的经验。
这些变更在企业架构开发过程中一般以架构变更请求的形式进行提交，因而上面这些变更的将会形成一系列错综复杂的架构变更请求。对待这些变更请求，治理行为是必不可少的，并且一个吸取经验教训的过程也是必要的。这一吸取经验教训的过程的目标是避免已经发生错误的重犯，它将对在进展过程中发现的问题进行解决，并对目标架构进行更改，从而使企业架构一直处于正确的方向之上。
架构委员会（Architecture Board）需要对这些架构申请（RFC：Requests for Change）进行评估和批准，而在这一过程中，架构委员会所面临的一大挑战是判断一个变更请求是否需要被批准，并进一步引起针对架构规划的变更，或者这一申请是否可以由过渡架构中的某个实现项目来解决（即这一变更已经处在未来的规划之中）。
除了上面针对来源的区分，架构变更还可以从技术和业务两个角度来进行分类。技术相关的变更驱动力可以是新技术的产生、资产管理成本缩减、技术退出以及新标准的倡议等。业务相关的驱动力则可以是日常业务开发、业务异常、业务革新、业务技术革新和战略变更等。对于技术方面的驱动力，主要通过企业变更管理和架构治理流程来进行管理，而对于业务方面的驱动力，则往往会导致新一轮的架构开发，或者至少是针对架构开发循环某一部分的迭代。
企业架构变更管理过程
企业架构变更管理过程需要确定各个变更如何被管理，以及在此过程中所采用何种技术和方法。除此之外，这一过程还需要具备一个用于明确哪个架构开发阶段受到影响的过滤功能（例如，仅对迁移方面产生影响的变更就不需要影响到架构开发相关的各阶段）。在当前存在着多种管理变更的方法和技术，例如：
- 项目管理方法，例如PRINCE2。
- 服务管理方法，例如ITIL。
- 管理咨询方法，例如Catalyst。
除了这些方法，TOGAF还推荐了一种用于管理变更的方法。该方法对于架构变更按照如下原则进行了分类：
- 简化变更（Simplification Change）：通常采用变更管理技术进行处理的变更。此种类型的变更通常来源于一个减少投资的需求。
- 增量变更（Incremental Change）：一个增量变更可以通过变更管理技术来进行处理，也可能需要对架构进行部分重建。此种类型的变更通常来源于在现存投资中获得额外价值的需求。
- 重新架构变更（Re-architecting Change）：此种变更需要通过架构开发循环对整个架构进行重建。此种类型的变更通常来源于为了创建新的价值而增加投资的需求。
为了分辨出一个变更属于上述哪种类型，组织可以借助于如下的步骤：
- 对所有可能影响架构的事件进行注册记录。
- 为各个架构任务进行资源分配和管理。
- 对架构资源进行负责的角色或流程需要对所做的事情进行评估。
- 对影响进行评估。
维护vs架构重新设计
如下的原则可以帮助企业来判断针对一个变更所要采用的处理方式是针对架构的维护还是对架构重新设计：
- 如果变更影响了两个或两个以上的干系人，那么这个变更很可能会需要一个架构的重新设计和新的架构开发循环。
- 如果变更只影响了一个干系人，那么这个变更很可能会成为变更管理的候选目标。
- 如果变更在一个特许之下能获得批准，那么这个变更很可能会成为变更管理的候选目标。
例如：
- 如果变更对业务战略有着很大的影响，那么整个企业架构可能会被重建。
- 如果一个新的技术或标准出现了，那么技术架构（而不是整个架构）可能会被要求进行刷新。
- 如果变更出现在一个基础设施层面，那么此物理层之上的架构将不会受到影响，但技术架构的基线描述将会受到影响。此种变更属于需要借助于变更管理技术的简化类型的变更。
除了上述原则，需要特别注意的是，在如下的情况中，组织需要针对部分或全部架构进行一个刷新循环（如果组织确定要进行该刷新循环，那么一个新的架构工作要求书需要被制定出来）：
- 基础架构需要与业务战略相校准。
- 在架构的部署过程中所使用的组件和实施指南需要进行重大变更。
- 在产品架构中使用的重要标准需要进行变更，并且对用户有着很大的影响。
1.10.3 输入与输出
在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：
| 输 入 |
参考资料 |
架构参考资料 |
| 非架构性输入 |
架构工作要求书 |
|
| 架构性输入 |
企业架构组织模型，包括：
|
|
| 定制的架构框架，包括：
|
||
| 架构工作说明书 |
||
| 架构愿景 |
||
| 架构资源库，包括：
|
||
| 架构定义文档 |
||
| 架构需求说明，包括：
|
||
| 架构路线图 |
||
| 变更请求—技术变更：
|
||
| 变更请求—业务变更：
|
||
| 变更请求—来源于经验教训 |
||
| 过渡架构 |
||
| 实施治理模型 |
||
| 架构契约 |
||
| 合规评估 |
||
| 实施和迁移计划 |
||
| 输 出 |
架构的各种更新 |
|
| 架构框架和原则变更 |
||
| 新的架构工作要求书，用于转移到另一个架构开发循环 |
||
| 架构工作说明书（必要时更新） |
||
| 架构契约（必要时更新） |
||
| 合规评估（必要时更新） |
||
1.10.4 步骤
在当前阶段中所要执行的各个步骤归纳如下：
- 建立价值实现过程
- 部署监测工具
- 管理风险
- 为架构变更管理提供分析
- 开发变更需求来迎合性能目标
- 管理治理过程
- 激活实施变更的过程