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 步驟
在當前階段中所要執行的各個步驟歸納如下：
- 建立價值實現過程
- 部署監測工具
- 管理風險
- 為架構變更管理提供分析
- 開發變更需求來迎合性能目標
- 管理治理過程
- 激活實施變更的過程