運用TOGAF ADM的資訊系統架構
在此階段企業架構師所需考量的是 — 根據每個企業所需的架構要求來決定實施資料架構(Data Architecture)與應用程式架構(Application Architecture)的順序與方法。
目標
- 發展能夠達成架構願景與業務架構的目標資訊系統(Data與Application)的”目標架構”，並且此目標架構是能處理架構作業聲明與解決利害關係人的問題。
- 根據現行與目標資訊系統架構製作”多個待選的架構路線圖”
此階段的輸入/步驟/產出將會在以下個別以Data Architecture與Application Architecture章節個別講述。
資訊系統架構: 資料架構(Data Architecture)
在資料架構的章節我們將會理解它的輸入是甚麼與甚麼是資料原則。在處理步驟中我們要考量的參考模型、觀點與工具如何選擇。也能理解其產出的主要元素會包括:
- 架構定義文件(Architecture Definition Document)中的資料架構組件
- 架構規範文件(Architecture Requirements Specification)中的資料架構組件
資料架構的目標
- 發展能夠達成架構願景與業務架構的資料架構的”目標架構”，並且此目標架構是能處理架構作業聲明與解決利害關係人的問題。
- 根據現行與目標資料架構製作”多個待選的架構路線圖”
資料架構的輸入
- 架構作業請求
- 能力評估
- 溝通計劃
- 企業架構的組織模型
- 客製的架構框架
- 資料原則（如果有的話）
- 架構作業聲明
- 架構願景
- 架構儲存庫
- 架構定義文件的草稿
— 現行業務架構(詳細)
— 目標業務架構(詳細)
— 現行資料架構(初步)
— 目標資料架構(初步)
— 現行應用程式架構(初步或詳細)
— 目標應用程序架構(初步或詳細)
— 現行技術架構(初步)
— 目標技術架構(初步) - 架構需求規範的草稿
— 差距分析結果
— 相關得技術需求 - 架構路線圖的業務架構組件
什麼是資料原則?
資料原則應該是準備階段(Preliminary Phase)製定的整個架構原則的一部分。 下表總結了來自TOAGF Part III架構原則的資料原則範例。
資料架構的步驟
步驟1: 選擇要參考的模型，觀點與工具
- 如果有現有的參考模型可以在之後對架構進行建模
- 哪些利害關係人需要對此的觀點
- 任何用於取得和建模流程的工具
在審查和驗證資料原則後，根據業務驅動因素、利害關係人、問題點和業務架構，從架構存儲庫中選擇相關的資料架構資源（參考模型、模式等）。 此外，選擇相關的資料架構觀點； 例如，資料的利害關係人（監管機構、使用者、產生者、擁有者、稽核者等）、各種時間維度（即時的、有報告周期的、事件點等）、位置； 業務流程; 上述的意思是，那些使企業架構師能夠展示如何在資料架構中利害關關係人關注的問題。 然後，結合所選擇的觀點，確定用於資料擷取、建模和分析的適當工具和技術。
哪麼我們如何決定整體的建模流程呢?
對於每個觀點，使用選擇的工具或方法支持所需特定視圖所需的模型。 資料模型的範例包括DoDAF 邏輯資料模型、ARTS 資料模型、PODS資料模型PPDM協會資料模型和 Energistics Epicenter 資料模型。 確認所有利害關係人的問題都已得到解決。 如果不是，則創建新模型來解決沒有涵蓋到的問題，或擴充現有模型。
TOGAF建議的開發資料架構流程如下：
- 從現有的業務架構和應用程式架構素材中收集資料相關模型
- 合理化資料需求並與任何現有的企業資料目錄和模型保持一致； 這允許開發資料清單和實體關係模型
- 通過將資料與業務服務、業務功能、訪問權限和應用程式相關聯，更新和開發跨架構的矩陣
- 通過檢查資料的建立、分發、遷移、保護和歸檔方式來闡述資料架構視圖
TOGAF 標準提供了用於開發資料架構的目錄(catalogs)、矩陣(matrices)和圖表(diagrams)的定義。 目錄擷取企業核心資產的清單。 矩陣顯示模型實體之間的核心關係。 圖表從一組不同的角度(觀點)呈現資訊架構資訊。
TOGAF 標準建議在Phase C中考量下表 中顯示的目錄、矩陣和圖表，並在TOAGF Part IV “內容元模型(Content Metamodel)”中提供有關其結構的指導。
有了目錄、矩陣和圖表，就應該形式化(formalizing)聚焦於資料需求的目標架構來完成建模。 企業架構師應該確定架構要滿足的需求類型。 這些需求可能與資料領域相關，可能會提供對應用程式和技術架構的需求輸入，或者可能會提供詳細的指導以反映在設計和實施過程中。
步驟2: 發展現行架構描述
要有一個適當的詳細程度，現行的資料架構是什麼?
在目標資料架構所需的範圍內開發現有資料架構的現有描述。 要定義的範圍和詳細程度將取決於現有資料元素可能被轉移到目標資料架構中的程度，以及是否存在任何現有架構描述。 在可能的情況下，根據架構確定相關的資料架構建構區塊。 在需要開發新架構模型以滿足利害關係人的問題，使用步驟 1 中選定的模型作為建立新內容來描述現行架構的指南。
步驟3: 發展目標架構描述
要有一個適當的詳細程度，未來的架構是什麼?
在支援架構願景和目標業務架構所需的範圍內為資料架構開發目標描述。 要定義的範圍和詳細程度將取決於資料元素與目標架構的相關性，以及是否存在架構描述。 在可能的情況下，根據架構確定相關的資料架構建構區塊。 在需要開發新架構模型以滿足利害關係人的關注點，使用步驟 1 中選定的模型作為建立新內容來描述目標架構的指南。
步驟4: 進行差距分析(Gap analysis)
- 驗證資料架構模型的一致性和準確性
- 驗證資料模型是否支持架構願景
- 驗證模型是否支持原則、目標和約束
- 對於每個觀點，注意前後的變化
- 使用差距分析確定現行和目標之間的差距
步驟5: 定義待選的路線圖組件
- 根據現行，目標與差距分析，定義出要執行的作業
- 在時間軸(timeline)上確定作業的優先等級
- 粗略的想法，因為兩個階段專門用於完成此路線圖
在建立現行架構、目標架構和差距分析之後，需要資料架構路線圖來確定未來階段活動的優先等級。 這個初始資料架構路線圖將用於支援Phase E中更詳細地定義綜合的跨學科路線圖。
步驟6: 解決整個架構面貌(Architecture Landscape)的影響
- 新資料架構是否會對任何先前存在的架構產生影響？
- 近期的變更是否影響資料架構?
- 或者是否有任何影響該資料架構的外部變化？
- 新資料架構是否會對任何計劃中或進行中的專案產生影響？
- 或者是否有任何計劃中或進行中的專案影響此資料架構？
步驟7: 進行利害關係人審查
根據提議的資料架構檢查架構專案的最初動機和架構作業聲明。 進行衝擊分析，以確定業務和應用程序架構(Business and Application Architectures)可能需要根據資料架構的變化（例如表單/流程、應用程式或資料庫系統的更改）進行任何範圍的變更。 如果影響很大，則可能需要重新審視業務和應用程式架構。
根據資料架構的變化，確定應用程式架構(如果已先開發)可能需要更改的任何範圍，或者確定對即將設計的應用程式架構的約束。 如果影響很大，則可能適合對應用程式架構進行快速迭代。確定對要設計的技術架構的任何限制，只在必要時改進提議的資料架構。
步驟8: 確認資料架構
為每個建構區塊(Building Block)選擇標準，盡可能重複使用從架構儲存庫中選擇的參考模型。 完整記錄每個建構區塊，然後根據業務需求對整體架構進行最終交叉檢查； 在架構文件中記錄建構區塊決策的基本原理。 記錄最終需求可追溯性報告。 在架構存儲庫中記錄架構的最終對映。 從選定的建構區塊中，確定那些有可能可被重複使用的建構區塊，並將它們發佈到架構存儲庫中。
步驟9: 建立架構定義文件
定義最終將會出現在企業連續體中的建構建塊(Building Block)。在架構定義文件中記錄建構建塊決策的基本原理。 準備架構定義文件的資料架構部分。 將文件發送給相關利害關係人審閱，並納入反饋。
資料架構的產出
- 架構定義文件的草稿(現行與目標的1.0版本，解決從主要利害關係人的觀點在乎的關注點)
- 架構需求規範的草稿(差距分析的結果，技術需求，按BDAT領域個別產出)
- 架構路線圖的資料架構組件
- 驗證過的資料原則，或者是有新的資料原則
- 更新的架構願景(這些階段的作業可能會修改原始計畫，更新的架構作業聲明，經過驗證的架構原則)
資料架構的產出 — 架構定義文件的組件
與資料架構相關的架構定義文件中應解決的議題如下：
- 現行的資料架構(如果合用的話)
— 目標資料架構，包括業務資料、邏輯資料和資料管理流程模型，以及資料實體/業務功能矩陣(Data Entity/Business Function matrix) - 為解決主要利害關係人關注點所產生的觀點並有相對應的資料架構視圖
資料架構的產出 — 架構需求規範的組件
在Phase C中資料架構需要有的架構需求有:
- 差距分析結果
- 資料互操作性要求（例如 JSON schema、資安政策）
- 業務架構(Business Architecture)可能需要變更以符合資料架構更改的範圍
- 下一階段的技術架構(Technology Architecture)的約束條件
- 更新的業務要求
- 更新的應用程序要求
資料架構小結
Phase C的資料架構部分定義了支援業務所需的資料類型和來源，並以利害關係人可以理解的方式進行。 架構團隊應考慮現有的相關資料模型，例如 ARTS 和 POSC 模型。
資訊系統架構: 應用程式架構(Application Architecture)
本節中我們將可以理解甚麼是應用程式原則(Application Principles)，另外在有哪些考量會影響我們將選擇的參考模式、觀點與工具。最後我們一樣看到此一階段的產出: 架構定義文件(Architecture Definition Document)與架構需求規範(Architecture Requirements Specification)以及其組件。
應用程式架構的目標
- 發展能夠達成架構願景與業務架構的應用程式架構的”目標架構”，並且此目標架構是能處理架構作業聲明與解決利害關係人的關注點(問題)。
- 根據現行與目標資料架構製作”多個待選的架構路線圖”
應用程式架構的輸入
- 架構作業請求
- 能力評估
- 溝通計劃
- 企業架構的組織模型
- 客製的架構框架
- 應用程式原則（如果有的話）
- 架構作業聲明
- 架構願景
- 架構儲存庫
- 架構定義文件的草稿
— 現行業務架構(詳細)
— 目標業務架構(詳細)
— 現行應用程式架構(初步)
— 目標應用程式架構(初步)
— 現行資料架構(初步或詳細)
— 目標資料架構(初步或詳細)
— 現行技術架構(初步)
— 目標技術架構(初步) - 架構需求規範的草稿
— 差距分析結果
— 相關的技術需求 - 架構路線圖的業務架構組件
什麼是應用程式原則?
應用程式原則應該是準備階段(Preliminary Phase)製定的整個架構原則的一部分。 下表總結了來自TOAGF Part III架構原則的應用程式原則範例。
應用程式架構的步驟
步驟1: 選擇要參考的模型，觀點與工具
- 如果有現有的參考模型可以在之後對架構進行建模
- 哪些利害關係人需要對此的觀點
- 任何用於取得和建模流程的工具
在審查和驗證應用程式原則後，根據業務驅動因素、利害關係人、關注點和業務架構，從架構存儲庫中選擇相關的應用程式架構資源（參考模型、模式等）。 此外，選擇相關的應用程式架構觀點； 例如，應用程式的利害關係人、與應用程式的功能和個人使用者相關的觀點等。 上述的意思是，那些使企業架構師能夠展示如何在應用程式架構中利害關關係人關注的問題。 然後，結合所選擇的觀點，確定用於應用程式架構的擷取、建模和分析的適當工具和技術。
哪麼我們如何決定整體的建模流程呢?
對於每個觀點，使用選用的工具或方法支持所需特定視圖所需的模型。 應用程式模型的範例包括來自 TM 論壇和OMG 的模型。 確認所有利害關係人的關注點都已得到解決。 如果不是，則創建新模型來解決沒有涵蓋到的問題，或擴充現有模型。
TOGAF建議的開發應用程式架構流程如下：
- 根據現行應用程序組合、需求是什麼以及業務架構範圍，了解所需的應用程式或應用程序程式的清單
- 將複雜的應用程式分解為兩個或多個應用程式來簡化它們
- 確保應用程式定義集內部是一致的，通過盡可能刪除重複的功能，並將相似的應用程序合併為一個
- 識別邏輯應用程式和最合適的物理應用程式
- 通過將應用程式與業務服務、業務功能、資料、流程等相關聯，開發跨架構的矩陣。
- 通過檢查應用程式的功能、擷取"整合、遷移、開發和操作問題"，詳細闡述一組應用程序架構視圖
TOGAF 標準提供了用於開發應用程式架構的目錄(catalogs)、矩陣(matrices)和圖表(diagrams)的定義。 目錄擷取企業核心資產的清單。 矩陣顯示模型實體之間的核心關係。 圖表從一組不同的角度(觀點)呈現資訊架構資訊。
TOGAF 標準建議在Phase C中考量下表 中顯示的目錄、矩陣和圖表，並在TOAGF Part IV “內容元模型(Content Metamodel)”中提供有關其結構的指導。
有了目錄、矩陣和圖表，就應該形式化(formalizing)聚焦於應用程式需求的目標架構來完成建模。 企業架構師應該確定架構要滿足的需求類型。 這些需求可能與應用程式領域相關，可能會提供對資料和技術架構的需求輸入，或者可能會提供詳細的指導以反映在設計和實施過程中。
步驟2: 發展現行架構描述
要有一個適當的詳細程度，現行的資料架構是什麼?
在應用程式資料架構所需的範圍內開發現有應用程式架構的現有描述。 要定義的範圍和詳細程度將取決於現有應用程式可能被轉移到目標應用程式中的程度，以及是否存在任何現有架構描述。 在可能的情況下，根據架構確定相關的應用程式架構建構區塊。 在需要開發新架構模型以滿足利害關係人的問題，使用步驟 1 中選定的模型作為建立新內容來描述現行架構的指南。
步驟3: 發展目標架構描述
要有一個適當的詳細程度，未來的架構是什麼?
在支援架構願景、目標業務架構和目標資料架構所需的範圍內，為應用程序架構開發目標描述。 要定義的範圍和詳細程度將取決於應用程式元素與實現目標架構願景的相關性，以及是否存在架構描述。 在可能的情況下，利用架構存儲庫確定相關的應用程序架構建構區塊。 在需要開發新架構模型以滿足利害關係人的關注點，使用步驟 1 中選定的模型作為建立新內容來描述目標架構的指南。
步驟4: 進行差距分析(Gap analysis)
- 驗證資料架構模型的一致性和準確性
- 驗證資料模型是否支持架構願景
- 驗證模型是否支持原則、目標和約束
- 對於每個觀點，注意前後的變化
- 使用差距分析確定現行和目標之間的差距
步驟5: 定義待選的路線圖組件
- 根據現行，目標與差距分析，定義出要執行的作業
- 在時間軸(timeline)上確定作業的優先等級
- 粗略的想法，因為兩個階段專門用於完成此路線圖
在建立現行架構、目標架構和差距分析之後，需要應用程式架構路線圖來確定未來階段活動的優先等級。 這個初始應用程式架構路線圖將用於支援Phase E中更詳細地定義綜合的跨學科路線圖。
步驟6: 解決整個架構面貌(Architecture Landscape)的影響
- 新應用程式架構是否會對任何先前存在的架構產生影響？
- 近期的變更是否影響應用程式架構?
- 或者是否有任何影響該應用程式架構的外部變化？
- 新應用程式架構是否會對任何計劃中或進行中的專案產生影響？
- 或者是否有任何計劃中或進行中的專案影響此應用程式架構？
步驟7: 進行利害關係人審查
根據提議的應用程式架構檢查架構專案的最初動機和架構作業聲明。 進行衝擊分析，以確定業務和應用程序架構(如業務實踐)可能需要根據應用程式架構的變化（例如表單/流程、應用程式或資料庫系統的更改）進行變更的任何範圍。 如果影響很大，則可能需要重新審視業務和應用程式架構。 最後，確定對要設計的技術架構（尤其是基礎架構）的任何限制。
步驟8: 確認應用程式架構
為每個建構區塊(Building Block)選擇標準，盡可能重複使用從架構儲存庫中選擇的參考模型。 完整記錄每個建構區塊，然後根據業務需求對整體架構進行最終交叉檢查； 在架構文件中記錄建構區塊決策的基本原理。 記錄最終需求可追溯性報告。 在架構存儲庫中記錄架構的最終對映。 從選定的建構區塊中，確定那些有可能可被重複使用的建構區塊，並將它們發佈到架構存儲庫中。
步驟9: 建立架構定義文件
定義最終將會出現在企業連續體中的建構建塊(Building Block)。在架構定義文件中記錄建構建塊決策的基本原理。 準備架構定義文件的資料架構部分。 將文件發送給相關利害關係人審閱，並納入反饋。
應用程式架構的產出
- 架構定義文件的草稿(現行與目標的1.0版本，解決從主要利害關係人的觀點在乎的關注點)
- 架構需求規範的草稿(差距分析的結果，技術需求，按BDAT領域個別產出)
- 架構路線圖的應用程式架構組件
- 驗證過的應用程式原則，或者是有新的應用程式原則
- 更新的架構願景(這些階段的作業可能會修改原始計畫，更新的架構作業聲明，經過驗證的架構原則)
應用程式架構的產出 — 架構定義文件的組件
與資料架構相關的架構定義文件中應解決的議題如下：
- 現行的應用程式架構(如果合用的話)
- 目標應用程式架構
— Process systems model
— Place systems model
— Time systems model
— People systems model - 為解決主要利害關係人關注點所產生的觀點並有相對應的應用程式架構視圖
應用程式架構的產出 — 架構需求規範的組件
在Phase C中應用程式架構需要有的架構需求有:
- 差距分析結果
- 應用程式互操作性要求
- 適用於ADM演進的相關技術要求
- 下一階段的技術架構(Technology Architecture)的約束條件
- 更新的業務要求
- 更新的應用程序要求
小節
此階段定義處理資料和支持業務所需的應用程式類型。 目標是定義相關應用程式的種類以及這些應用程式需要做什麼。 這些應用程式不是電腦系統，而是為管理資料和支援業務功能的邏輯功能組。 因此，應在不參考特定技術的情況下定義應用程式及其功能。 這是因為應用程式應該是穩定的，而用於實現它們的技術可能不穩定。
Phase C: 資訊系統架構的總結
此階段記錄了企業 IT 系統的基本結構，體現在主要類型的資訊(也就是資料)和處理資訊的應用程式、它們之間的關係和環境，以及管理它們的設計和演進的原則。 這個階段涉及資料和應用程序架構的某種組合，可以順序或同時開發，而這這需要進行一些迭代以確保一致性。
