運用TOGAF ADM 的技術架構

在此階段中我們需要理解

• 當我們開發技術架構時怎麼運用技術服務和技術組件的分類以及ABB的任務
• 在架構定義文件(Architecture Definition Document)以及架構需求規範(Architecture Requirements Specification)中，技術架構的組件有哪些

技術架構的目標

1. 發展技術架構的"目標架構"，並以技術服務和技術組件達成Phase A到C的架構願景、業務目標、資料與應用程式建構區塊的交付，並解決架構作業聲明與解決利害關係人的問題。
2. 根據現行與目標技術架構製作"多個待選的架構路線圖"

技術架構的輸入

• 架構作業請求
• 能力評估
• 溝通計劃
• 企業架構的組織模型
• 量身定做的架構框架
• 技術原則（如果有的話）
• 架構作業聲明
• 架構願景
• 架構儲存庫
• 架構定義文件的草稿
  — 現行業務架構(詳細)
  — 目標業務架構(詳細)
  — 現行資料架構(詳細)
  — 目標資料架構(詳細)
  — 現行應用程式架構(詳細)
  — 目標應用程序架構(詳細)
  — 現行技術架構(初步)
  — 目標技術架構(初步)
• 架構需求規範的草稿
  — 差距分析結果
  — 相關得技術需求
• 架構路線圖的業務架構、資料與應用程式架構組件

什麼是技術原則

技術原則應該是準備階段(Preliminary Phase)製定的整個架構原則的一部分。 下表總結了來自TOAGF Part III架構原則的技術原則範例。

技術架構的步驟

步驟1: 選擇要參考的模型，觀點與工具

• 如果有現有的參考模型可以在之後對架構進行建模
• 哪些利害關係人需要對此的觀點
• 任何用於取得和建模流程的工具

審視與檢驗技術原則。 根據業務驅動因素、利害關係人及其問題，從架構儲存庫中選擇相關的技術架構資源（參考模型、模式等）。 選擇相關的技術架構觀點，使企業架構師能夠展示利害關係人關注的問題是如何在技術架構中得到解決的。 結合所觀點，確定用於擷取、建模和分析的適當工具和技術。

技術架構所產生的目錄(Catalog)、矩陣(Matrices)與圖表(Diagrams)

目錄是企業在架構儲存庫的核心資產。 它們本質上是分層的，是擷取metamodel entity的分解以及跨相關模型實體的分解（如，從平台服務到邏輯技術組件再到實體技術組件）。

而技術架構應該建立的技術目錄如下:

• 根據現有技術目錄和在應用程式架構階段進行的應用分析，收集正在使用的產品/解決方案清單
• 如果現有產品/解決方案無法滿足應用程式架構中的需求，則通過檢查所需功能並滿足所需標準的產品來擴大產品/解決方案清單
• 如果合適，根據選定的分類法對產品/解決方案進行分類，根據需要擴展模型以適應正在使用的技術產品的分類
• 如果企業已經有技術標準，則將這些標準應用於技術組件目錄以獲得符合技術標準的現行視圖

根據利害關係人的需求，圖表是從一組不同的角度(觀點)來呈現技術架構。 這個作業提供了平台需求和託管需求之間的連接，因為單一應用程式可能需要運行於多個環境中以支持本地存取、開發生命週期和託管要求。

對於主要的現行應用程式或應用程式平台，製作一個堆棧圖(stack diagram)來顯示硬體、操作系統、軟體基礎設施和打包的應用程序是如何組合的。 如果可以，擴展軟體分發(software distribution)的應用程序架構圖以顯呈現應用程式如何對映到技術平台。 為每個環境製作一個軟硬體基礎設施的邏輯圖，顯示環境的內容和組件之間的邏輯通訊。 在可用的情況下，收集有關已部署基礎設施的能力信息。 對於每個環境，製作網路基礎設施的物理圖，例如路由器、交換機、防火牆。 在可用的情況下，收集有關網路基礎設施的能力信息。

TOGAF 標準建議我們在 Phase D考慮下表中呈現的目錄、矩陣和圖表，並在第 IV 部分Content Metamodel中提供有關其結構的指導。

步驟2: 發展現行技術架構描述

要有一個適當的詳細程度，現行的架構是什麼?

步驟3: 發展目標架構描述

要有一個適當的詳細程度，未來的架構是什麼?這個架構要能實現架構願景、業務目標與目標資訊系統架構。

建立目標系統的架構模型的一個關鍵過程是建構區塊的概念化。 ABB描述了所需的功能以及如何在沒有細節(配置或詳細設計)的情況下實現它。 這些在TOGAF第 IV 部分“Building Blocks and the ADM”中有描述了定義建構區塊的方法，以及使用它們建立架構模型的一些通用指南。

在需要開發新架構模型以滿足利害關係人的問題，使用步驟 1 中確定的模型作為建立新架構內容以描述目標架構的指南。

步驟4: 進行差距分析(Gap analysis)

• 驗證架構模型的一致性和準確性
• 驗證模型是否支持架構願景
• 驗證模型是否支持原則、目標和約束
• 對於每個觀點，注意前後的變化
• 使用差距分析確定現行和目標之間的差距

步驟5: 定義待選的路線圖組件

• 根據現行，目標與差距分析，定義出要執行的作業
• 在時間軸(timeline)上確定作業的優先等級
• 粗略的想法，因為兩個階段專門用於完成此路線圖

初始技術架構路線圖將用作素材，以支援在Phase E中更詳細地定義路線圖。

步驟6: 解決整個架構面貌(Architecture Landscape)的影響

• 技術架構是否會對任何先前存在的架構產生影響？
• 或者是否有任何影響該技術架構的外部變化？
• 技術架構是否會對任何計劃中或進行中的專案產生影響？
• 或者是否有任何計劃中或進行中的專案影響此技術架構？

步驟7: 進行利害關係人審查

根據我們的溝通計劃以及我們在步驟 一中確定的利害關係人觀點，
對利害關係人傳達將進行的計劃。每個領域按順序排列 — Business、 Data/Application、Technology，僅在必要時修改。

步驟8: 確定技術架構

為每個建構區塊(Building Block)選擇標準，盡可能多地重複使用從架構儲存庫中選擇的參考模型。 完整記錄每個建構區塊，然後根據業務目標對整體架構進行最終交叉檢查； 在架構文件中記錄建構區塊決策的基本原理。 記錄最終需求可追溯性報告。 在架構存儲庫中記錄架構的最終對映。 從選定的建構區塊中，確定可以重複使用的建構區塊(作業實踐、角色、業務關係、職位描述等)並通過架構存儲庫發布。

步驟9: 建立架構定義文件

• 定義最終將會出現在企業連續體中的建構建塊(Building Block)
• 每個領域按順序排列 — Business、 Data/Application、Technology

技術架構的產出

1. 架構定義文件的草稿(現行與目標的1.0版本，解決從主要利害關係人的觀點在乎的關注點)
2. 架構需求規範的草稿(差距分析的結果，技術需求，按BDAT領個別產出)
3. 架構儲存庫中的技術架構組件
4. 架構作業聲明(如果有更新的話)
5. 經驗證的技術原則或是新的技術原則

關於技術架構的架構定義文件中的組件

• 現行技術架構(如果有的話)
• 目標技術架構:
  — 技術組件及其與資訊系統的關係
  — 技術平台及其分解，顯示實現特定技術“堆棧(stack)”所需的技術組合
  — 將所需技術分組到IT環境中的環境和位置（例如，開發、生產）
  — 跨技術組件的預期處理負載和負載分配
  — 實體(網路)通信
  — 硬體和網路規格
• 與解決利害關係人的問題所產生觀點的相對應視圖

關於技術架構的架構需求規範中的組件

• 差距分析的結果
• 更新的技術需求

總結

這個階段記錄了技術架構，它將構成後續實施和遷移作業的基礎，包括軟硬體和通訊技術、它們之間的關係和環境，以及管理其設計和發展的原則。