3. 架構交付物（Architecture Deliverables）
架構交付物是在整個架構開發方法循環過程中所產生或被使用的契約性且正規化的企業架構內容，因而其與企業架構開發方法有着緊密的聯系。本章將針對這些架構交付物以及他們與架構開發方法各階段之間的關系進行闡述，不過需要注意的是，本章節的內容只是為了提供一個關於架構交付物的內容概括，由於企業中可能存在着符合其自身需要的項目和過程管理方法，因而企業也可以根據自己的實際情況對這些交付物進行改造和定制。首先，我們先來審視一下架構交付物與企業架構開發方法各階段之間的對應關系（注意，下表采用了簡稱來標示各企業架構開發方法階段，具體的對應關系請參照前面企業架構開發方法部分的內容和圖示）：
| 架構交付物 |
作為輸出的階段 |
作為輸入的階段 |
| 架構構建塊 （Architecture Building Blocks） |
F，H |
A，B，C，D |
| 架構合同 （Architecture Contract） |
F |
G |
| 架構定義文檔 （Architecture Definition Document） |
B，C，D |
C，D，E，F，G，H |
| 架構原則 （Architecture Principles） |
預備階段，A， B，C，D |
預備階段，A，B，C，D，E，F，G，H |
| 架構資源庫 （Architecture Repository） |
預備階段 |
預備階段，A， B，C，D，E，F，G，H， 需求管理 |
| 架構需求 （Architecture Requirements） |
B，C，D，E，F，需求管理 |
C，D，需求管理 |
| 架構路線圖 （Architecture Roadmap） |
B，C，D，E，F |
C，D，E，F，G，H |
| 架構願景 （Architecture Vision） |
A |
B，C，D，E，F，G，H，需求管理 |
| 業務原則、目標和驅動力 （Business Principles,Business Goals,and Business Drivers） |
預備階段，A，B |
A，B |
| 能力評估 （Capability Assessment） |
A，E |
B，C，D，E，F |
| 變更請求 （Change Request） |
H |
|
| 溝通計划 （Communications Plan） |
A |
B，C，D，E，F |
| 合規評估 （Compliance Assessment） |
G |
H |
| 實施和遷移計划 （Implementation and Migration Plan） |
E，F |
F |
| 實施治理模型 （Implementation Governance Model） |
F |
G，H |
| 企業組織架構模型 （Organizational Model for Enterprise Architecture） |
預備階段 |
預備階段，A， B，C，D，E，F，G，H，需求管理 |
| 架構工作要求書 （Request for Architecture Wor k） |
預備階段，F |
A，G |
| 需求影響評估 （Requirements Impact Assessment） |
H，需求管理 |
需求管理 |
| 解決方案構建塊 （Solution Building Blocks） |
G |
A，B，C，D |
| 架構工作說明書 （Statement of Architecture Work） |
A，B，C，D |
B，C，D，E，F，G，H，需求管理 |
| 定制的企業架構框架 （Tailored Architecture Framework） |
預備階段，A |
預備階段， A， B，C，D，E，F，G，H，需求管理 |
| 過渡架構 （Transition Architecture） |
E，F |
G，H |
3.1 架構構建塊
構建塊是企業架構過程的最終目標之一，它是企業對於各個層面上（業務、應用、數據以及技術等）的可重用部件的抽象。對於架構構建塊來說，它的內容側重於對構建塊的需求進行描述，就像軟件開發中的接口一樣，架構構建塊並不涉及具體的實現方式，而只是描述了構建塊所需要達成的功能。用於描述架構構建塊的文檔和模型存儲在企業架構資源庫之中，而企業架構開發過程正是對企業中各種客觀存在的或計划中的可重用模塊進行抽象建模，並最終將這些內容存儲到企業架構資源庫之中（或對其內容進行更新）。關於架構構建塊的具體內容在后面將會有更加詳細的描述。
3.2 架構合同
3.2.1 目標
架構合同是企業架構開發團隊與贊助團隊之間關於架構的交付、質量和適用性的聯合協定，而為了成功實現這一協定則需要企業進行有效的架構治理。通過實現一個用於合同管理的治理方法，企業將會確保：
- 對組織中所有架構相關活動的完整性檢查、變更、決策和審計進行持續監督的系統。
- 現存或正在開發的架構得以貫徹組織的原則、標准和需求。
- 明確架構在開發和實現的各個方面中的風險，這些方面涵蓋了關於可接受的標准、策略、技術和產品的內部開發，以及架構的運營層面，從而使得組織可以在一個具有彈性的環境中繼續其業務。
- 一系列流程和實踐，用於確定關於所有架構制品的開發和使用的責任和規則。
- 對於為合同負責的治理組織、他們的權限級別以及在其治理之下的架構范圍有一個正式的理解。
3.2.2 內容
- 架構設計和開發合同的內容一般包括：
- 介紹和背景
- 協議性質
- 架構范圍
- 架構以及戰略原則和需求
- 一致性需求
- 架構開發和管理流程，以及相關角色
- 目標架構評測標准
- 定義的交付階段
- 按照優先級排序的聯合工作計划
- 時間窗口（Time windows）
- 架構交付和業務指標
- 業務用戶的架構合同一般包括：
- 介紹和背景
- 協議性質
- 范圍
- 戰略需求
- 一致性需求
- 架構采用者
- 時間窗口
- 架構業務指標
- 服務架構（包括服務水平協議（SLA：Service Level Agreement））
3.3 架構定義文檔
3.3.1 目標
架構定義文檔是一個包含在整個項目中所產生的各種制品的可交付容器。它跨越所有的架構領域（業務、數據、應用和技術），並可用於檢閱架構的所有相關狀態（當前態、中間態和目標態）。架構定義文檔對架構需求文檔在如下方面進行互補：
- 架構定義文檔提供了一個解決方案的定性視圖，用於溝通架構師的意圖。
- 架構需求說明提供了一個解決方案的定量視圖，用於聲明在架構實現過程中必須遵守的可測量的標准。
3.3.2 內容
架構定義文檔內容一般包括：
- 范圍
- 目標、階段目標和約束
- 架構原則
- 基線架構
- 架構模型（針對每個被建模的狀態）：
- 業務架構模型
- 數據架構模型
- 應用架構模型
- 技術架構模型
- 架構方法的基本原理和理由
- 架構資源庫內容映射：
- 架構情景映射
- 參考模型映射
- 標准映射
- 重用評估
- 差距分析結果
- 影響評估
3.4 架構原則
3.4.1 目標
是通用的規則和指南，一般是不會進行更改的。這些原則知會並支持一個組織用以實現其任務的方法。它是用於定義和指導組織從價值到行為和結果的一系列結構化思路中的一員。
3.4.2 內容
架構原則一般包括如下幾個層面的內容（其具體內容請參看TOGAF標准相關內容）：
- 業務原則
- 數據原則
- 應用原則
- 技術原則
3.5 架構資源庫
3.5.1 目標
架構資源庫在企業中充當了對於所有架構相關項目進行存儲的區域。它允許各個項目管理他們的交付物，定位可重用資產，並對干系人以及其他有興趣者進行信息發布。
3.5.2 內容
架構資源庫的內容包括如下幾個方面（其具體內容請參看TOGAF標准相關內容）：
- 架構框架
- 標准信息庫
- 架構情景
- 參考架構
- 治理日志
3.6 架構需求說明
3.6.1 目標
架構需求說明提供了一組量化的描述，用於概括為了使一個項目的實現與架構相符合所必須做的事情。架構需求說明一般會形成一個實施契約，或是更詳細的架構定義契約中的主要組件。
3.6.2 內容
架構需求說明的內容通常包括：
- 成功評測標准
- 架構需求描述
- 業務服務契約
- 應用服務契約
- 實施導則
- 實施說明
- 實施標准
- 互操作需求
- 約束
- 假設
3.7 架構路線圖
3.7.1 目標
架構路線圖列舉出各個變化增量，並把他們放到時間軸之上，從而展示了從當前架構到目標架構的演進過程。架構路線圖是遷移架構的重要組件，並在架構開發方法的B、C、D、E、F階段中以增量的方式開發出來。
3.7.2 內容
架構路線圖的內容包括：
- 項目列表：
- 每個涉及到的項目的名稱、描述和目標
- 用於實現所建議的架構的項目列表，並按照優先級進行了排序
- 基於時間的遷移規划：
- 遷移的效益
- 針對各種遷移選擇的成本估算
- 實施建議：
- 用於衡量項目有效性的評估准則
- 風險和問題
- 解決方案構建塊的描述和模型
3.8 架構願景
3.8.1 目標
架構願景是在項目生命周期早期創建的，它提供了一個高階的對於最終架構產品的期望視圖，目的是為了在一開始就對架構應該達到的期望結果形成一致意見，從而使得在之后的過程中架構師能夠關注於切實可行的關鍵領域。通過提供一份關於整體架構定義的內容摘要，架構願景對於干系人之間按溝通也提供了一定的支持。
3.8.2 內容
架構願景的內容通常包括：
- 問題描述：
- 干系人以及他們的關注點
- 需要解決的問題/場景列表
- 詳細目標描述
- 環境和流程模型：
- 流程描述
- 涉及到環境的流程步驟
- 涉及到人員的流程步驟
- 信息流
- 執行者以及他們擔當的角色和責任：
- 人員方面的執行者和角色
- 計算機方面的執行者和角色
- 需求
- 所產生的架構模型：
- 約束
- IT原則
- 支持流程的架構
- 映射到架構之上的需求
3.9 業務原則、目標和驅動力
3.9.1 目標
業務原則、目標和驅動力通過描述企業的需要和工作方式為架構工作提供了背景。此外，許多處於架構原則考慮之外的因素對架構的開發也有着重要的影響。
3.9.2 內容
由於不同的組織有着不同的特性，因而關於架構業務背景的內容將會各不相同，企業應該根據各自的情況定義這部分內容。
3.10 能力評估
3.10.1 目標
在做一份詳細的架構定義之前，對企業的當前和目標的能力水平有一個清晰的認識是非常有價值的。對於能力評估，我們可以在如下幾個層面進行考慮：
- 企業整體的能力水平是什么？企業希望在何處增強或優化其能力？用於支持企業期望發展的架構關注領域是什么？
- 企業中的IT功能的能力或成熟度水平是什么？就設計管理、操作管理、技術和組織架構而言，進行架構項目最可能的影響都有哪些？為了與企業文化和IT部門的能力相適應，架構項目所需的正規化和詳細度的最適宜水平是什么？
- 企業架構功能的能力和成熟度是什么？當前存在的架構資產有哪些？這些資產是否被一直維護，並且是否還准確？什么樣的標准和參考模型需要被考慮進去？是否在這些在架構項目中有可能創建可重用資產？
- 能力欠缺存在於何處？為了達成目標能力而需要進行轉型的業務范圍是什么？在對基本能力欠缺考慮之上的轉換風險、文化壁壘以及其他方面考慮都有哪些？
3.10.2 內容
能力評估的內容通常包括：
- 業務能力評估：
- 業務能力
- 針對每項能力性能水平的基線狀態評估
- 針對每項能力性能水平的未來狀態期望
- 針對每項能力如何實現的基線狀態評估
- 針對每項能力將會被如何實現的期望
- IT能力評估：
- 變更流程的基線和目標成熟度水平
- 運營流程的基線和目標成熟度水平
- 基線能力以及容量評估
- 針對由於架構項目的執行而對IT組織所可能產生的影響的評估
- 架構成熟度評估：
- 架構治理流程、組織、角色和責任
- 架構技能評估
- 架構資源庫中的情景定義的深度、廣度和質量
- 架構資源庫中的標准定義的深度、廣度和質量
- 架構資源庫中的參考模型的深度、廣度和質量
- 針對可重用潛力的評估
- 業務轉型准備度評估：
- 准備度因素
- 對於每個准備度因素的願景
- 針對當前和目標准備度的評級
- 與准備度相關的風險
3.11 變更請求
3.11.1 目標
在架構的實現過程中，在一切清晰之前，原來的架構定義和需求很可能不適合或不足以達成解決方案的實現。在這種情況下，對實施項目進行調整使之與建議的架構方法發生偏離，或請求架構范圍擴展是必需的行為。另外，很多外部因素（例如，市場因素、業務策略變化以及新技術機會）也會為擴展及優化架構提供新的機會。在以上這些環境下，一個變更請求可以被提出，用以開始一個新的架構工作周期。
3.11.2 內容
變更請求的內容通常包括：
- 對於所建議的變更的描述
- 對於所建議的變更的理由
- 對於所建議的變更的影響評估
- 針對相關特定需求的引用
- 迄今需求所涉及的干系人的優先級
- 重新審視這些需求的各階段描述
- 對需求優先級進行排序的階段
- 調查和修正需求的優先級階段的結果
- 對於需求管理的建議
- 資源庫引用編號
3.12 溝通計划
3.12.1 目標
企業架構包含大量的復雜且相互關聯的信息。有效地與適當的人在適當的時間針對目標信息進行交流是成功建設企業架構的重要因素。開發溝通計划可以使這些交流通過一種可計划、可管理的方式進行。
3.12.2 內容
溝通計划的內容通常包括：
- 針對干系人的識別，並根據溝通需求進行分組
- 明確溝通需求、與架構願景相關的關鍵消息、溝通風險和關鍵成功因素（CSFs：Critical Success Factors）
- 明確用來與干系人進行溝通的機制，並允許其對架構信息的訪問
- 制定溝通時間表。該時間表展示了溝通將在何時何地進行，以及在何種干系人組之間進行
3.13 合規評估
3.13.1 目標
一旦一個架構被定義了出來，就必須在整個實施過程中對其進行治理，從而保證原先的架構願景可以被適當的實現，並且實現中的經驗教訓也可以反饋到架構過程中。針對實施項目進行周期性的合規檢查為重新審核項目過程，並保證設計和實施符合企業策略和架構目標，提供了一種有益的機制。
3.13.2 內容
合規評估的內容通常包括：
- 項目進程和狀態的概覽
- 項目架構/設計概覽
- 完整的架構清單：
- 硬件和操作系統清單
- 軟件服務和中間件清單
- 應用清單
- 信息管理清單
- 安全清單
- 系統管理清單
- 系統工程清單
- 方法和工具清單
3.14 實施和遷移計划
3.14.1 目標
通過過渡框架的描述為解決方案的實施提供一個日程表，包括實施的時間、成本、資源、收益和里程碑。
3.14.2 內容
實施和遷移計划的內容通常包括：
- 實施和遷移戰略：
- 戰略實施方向
- 實施排序方法
- 與其他管理框架的交互：
- 架構與業務規划相協調的方法
- 整合架構的方法
- 架構與項目管理相協調的方法
- 架構與運營管理相協調的方法
- 項目章程：
- 項目所能交付的能力
- 所包含的工作包
- 業務價值
- 風險、問題、假設和依賴關系
- 實施規划：
- 由實施分解出來的各個階段和工作流
- 為各階段和工作流進行工作包分配
- 里程碑和時間要求
- 工作分解結構
- 資源需求和成本
3.15 實施治理模型
3.15.1 目標
一旦一個架構被定義，在整個實施過程中就需要對用於實現架構的過渡框架進行治理。在已經建立了架構功能的組織中可能已經存在了一個治理框架，但是對於特定的過程、組織、角色、責任和度量來說，需要根據項目進行具體的定義。
3.15.2 內容
實施治理模型的內容通常包括：
- 治理流程
- 治理組織結構
- 治理角色和相應職責
- 治理檢查點和成功與失敗標准
3.16 企業組織架構模型
3.16.1 目標
為了一個架構框架能夠被成功地使用，它必須在企業中獲得正確的組織、角色和責任的支持。特別重要的是，對不同企業架構參與者之間邊界的定義，以及針對跨邊界關系的治理。
3.16.2 內容
企業組織架構模型的內容通常包括：
- 受影響的組織的范圍
- 成熟度評估、差距和決議方法
- 架構團隊的角色和責任
- 針對架構工作的約束
- 資金預算需求
- 治理和支持策略
3.17 架構工作要求書
3.17.1 目標
由贊助組織交付給架構組織的用於啟動架構開發工作的文檔。架構工作要求書可以產生於預備階段，可以是經過批准的架構變化請求的結果，或者是源於遷移計划對架構工作的參考。
3.17.2 內容
架構工作要求書的內容通常包括：
- 組織贊助者
- 組織的任務說明
- 業務目標（以及變更）
- 業務的戰略規划
- 時間限制
- 業務環境的變化
- 組織方面的約束
- 預算信息以及財務約束
- 外部約束以及業務約束
- 當前業務系統描述
- 當前架構/IT系統描述
- 開發組織的描述
- 開發組織可用資源的描述
3.18 需求影響評估
3.18.1 目標
在整個架構開發方法過程中，總會有新的與架構相關的信息被收集起來。當這些信息被收集后，對架構在當前某方面有影響的新因素也經常會顯現出來。需求影響評估就是用來對當前架構需求進行評估，闡明需要進行的變更以及這些變更所帶來的影響。
3.18.2 內容
需求影響評估的內容通常包括：
- 對於具體需求的引用
- 迄今需求的相關干系人優先級
- 進行重審的各個階段
- 進行需求優先級排序的階段
- 調查和修正需求的優先級階段的結果
- 關於需求管理的建議
- 資源庫引用編號
3.19 解決方案構建塊
與架構構建塊相類似，解決方案構建塊也是存儲於架構資源庫中的構建塊的一種，不過它的內容更傾向於在實現層面對企業中的可重用構建塊進行描述。可以說，架構構建塊定義了構建塊的需求，而解決方案構建塊則是此需求在具體實現技術層面的映射。關於解決方案構建塊的具體內容請參閱后面的內容。
3.20 架構工作說明書
3.20.1 目標
架構工作說明書定義了用於完成一個架構項目的方法和范圍，它也是用於評測架構項目是否被成功執行的典型文檔，並且它也形成了架構服務提供者和使用者之間的合同協議的基礎。
3.20.2 內容
架構工作說明書的內容通常包括：
- 架構工作標題說明
- 項目申請和背景
- 項目描述和范圍
- 架構願景的概括
- 管理辦法
- 范圍變更程序
- 角色、責任和交付物
- 驗收標准和程序
- 項目計划和日程安排
- 針對架構連續體的支持
- 簽字批准
3.21 定制的架構框架
3.21.1 目標
TOGAF提供了一個行業的標准架構框架，但是要在一個架構項目中對其進行有效地使用，則必須在兩個層面上進行定制。首先，需要對TOGAF模型進行定制，使得它可以融入到企業之中。此種定制包括將TOGAF模型整合入企業的項目和過程管理框架、術語定制、展示方式開發、架構工具的選擇、配置和部署等方面之中。任何被采用的框架的形式和詳細程度應該與企業的其他背景元素相適應，例如文化、干系人、企業架構的商業模型以及當前架構能力的水平。一旦針對框架完成了上面的定制，企業就需要為具體的架構項目做進一步的框架定制，而在這一層面的定制中，企業需要選擇適當的架構交付物和架構制品來滿足項目和干系人的需要。
3.21.2 內容
定制的架構框架的內容通常包括：
- 定制架構的方法
- 定制架構的內容（架構交付物和架構制品）
- 配置和部署工具
- 治理模型和其他框架的接口：
- 企業架構管理框架
- 能力管理框架
- 項目組合管理框架
- 項目管理框架
- 運營管理框架
3.22 過渡架構
3.22.1 目標
過渡架構展示了企業的增量狀態，並反映從當前架構到目標架構的過渡過程。過渡架構被用來將單獨的工作包和項目組合為可管理的項目組合和程序，用於描述每個階段的業務價值。
3.22.2 內容
過渡架構的內容通常包括：
- 機會組合描述：
- 綜合的差距、解決方案和依賴關系評估
- 機會描述
- 收益評估
- 能力和能力增量
- 互操作性和共存的需求
- 工作包組合描述：
- 工作包描述（名稱、描述、目標和交付物）
- 功能性需求
- 依賴關系
- 與機會之間的關系
- 與架構定義文檔和架構需求說明之間的關系
- 里程碑和里程碑過渡架構：
- 過渡狀態描述
- 每個過渡狀態的業務架構
- 每個過渡狀態的數據架構
- 每個過渡狀態的應用架構
- 每個過渡狀態的技術架構
- 實施因素評估和推導矩陣（ImplementationFactor Assessment and Deduction Matrix：用於記錄將會影響架構實施和遷移計划的各個因素。此矩陣包括在制定遷移計划時需要考慮的各個因素、它們的描述，以及由此而推斷出的在制定計划時需要考慮的行動或約束）：
- 風險
- 問題
- 假設
- 依賴
- 行動
- 綜合差距、解決方案和依賴矩陣（Consolidated Gaps，Solutions，and Dependencies matrix：此矩陣使架構師可以對在各領域架構差距分析結果中明確的差距進行分組，並評估潛在的解決方案，以及這些方案與差距之間的依賴關系）：
- 架構領域
- 差距
- 潛在解決方案
- 依賴關系