TOGAF 的架構開發方法（ADM）迴圈，不像 Zachman 框架，提供了一套更具操作性的流程，引導企業逐步實施架構變革。ADM 迴圈的核心概念是根據業務、應用、資訊和技術（BAIT）模型，從業務問題出發，逐步推導到技術方案的選擇。這個過程強調選項評估和需求驗證，確保技術架構與業務目標一致。TOGAF 的迭代方法和持續改進的理念，讓企業架構更具靈活性，能適應快速變化的市場環境。此外，文章也探討瞭如何利用 IT4IT 價值流來整合業務、系統和技術架構，以及如何在企業架構中實踐敏捷方法和變更管理。
以 TOGAF 提升企業架構指導力
Zachman 框架提供了對企業運作的深入洞察，但它在指導如何實踐企業架構方面存在侷限性，缺乏逐步實施架構的具體方法。相較之下，TOGAF 是一個更全面的框架。
TOGAF 的核心要素是 Architecture Development Method（ADM）迴圈。這個迴圈反映了 TOGAF 將架構視為一項持續活動的理念。
ADM 迴圈的核心概念
如同 Zachman，TOGAF 首先關注企業業務的整體目標，然後定義資訊系統的邏輯模型，最後選擇支援這些業務模型的技術。TOGAF 採用經典的 BAIT 模型：業務（Business）、應用（Application）、資訊（Information）和技術（Technology）。
TOGAF 的推理邏輯如下：
- 需要解決什麼業務問題？
- 需要什麼介面（應用程式）來存取解決業務問題所需的資訊？
- 需要什麼資訊來解決業務問題？
- 什麼技術能夠最佳地支援資訊的存取和分析，以最佳化的方式解決業務問題？
在這個推理過程中，我們可以看到有多種選擇需要被評估。這正是架構的核心：提供選項、分析選項並選擇最佳方案來解決問題。TOGAF 透過不斷參照需求來幫助做出這些選擇，這是 ADM 的核心。
詳細步驟
- 定義需求：明確需要解決的問題和目標。
- 評估機會和方案：識別可能的解決方案並評估其可行性。
- 實施轉型：定義如何從當前狀態轉變到目標狀態，並管理這個轉型過程。
- 治理架構：確保解決方案的架構持續符合企業的整體目標。
TOGAF 中的技術架構開發
在 TOGAF 中，技術架構的開發始於設定基線，接著考慮不同的視角和相應的選項來制定解決方案。然後，選擇合適的建構模組並根據業務需求進行驗證。同時，必須進行差距分析，以確保解決方案真正符合需求並提供預期的價值。
Zachman 與 TOGAF 的比較
Zachman 主張對企業進行極為詳細的規劃，將其視為企業的藍圖。然而，在快速變化的數位生態系統中，這種方法可能會導致過多的時間花費在檔案和維護上，而不是實際推動業務變革。
TOGAF 提供了一種更靈活的方法，強調迭代和持續改進。這使得企業能夠根據實際需求調整和最佳化其架構。
企業架構的不同視角
在實踐中，可以採用兩種主要方法來處理企業架構：
垂直劃分：將企業劃分為不同的垂直領域，每個領域都有自己的企業架構。這種方法的挑戰在於如何整合不同領域之間的架構，以服務於整個企業。
水平劃分：在整個企業層面捕捉 BAIT 領域，並將其作為「超級領域」。這種方法的挑戰在於如何使整體企業架構適應不同業務領域的特定需求。
程式碼範例與解析
def calculate_gap_analysis(current_state, target_state):
"""
計算當前狀態與目標狀態之間的差距
:param current_state: 當前狀態的描述
:param target_state: 目標狀態的描述
:return: 差距分析的結果
"""
# 省略具體實作細節
pass
# 使用範例
current_state = "當前系統狀態"
target_state = "目標系統狀態"
gap_analysis_result = calculate_gap_analysis(current_state, target_state)
print(gap_analysis_result)
內容解密：
此範例程式碼展示了一個簡化的差距分析函式，用於比較當前狀態與目標狀態之間的差異。在實際應用中，這個函式需要根據具體的業務需求和資料進行擴充套件和定製。關鍵步驟包括：
- 定義當前狀態和目標狀態的描述方式。
- 實作比較邏輯，以量化或質性評估兩者之間的差距。
- 輸出差距分析結果，用於指導後續的架構調整和最佳化。
為何企業需要架構（Enterprise Architecture）
在現代企業中，架構扮演著至關重要的角色。企業架構（EA）不僅僅是一種技術實踐，更是一種商業策略的實踐。企業架構幫助企業將其願景、策略和目標轉化為具體的系統、流程和技術架構。這種轉化過程需要考慮多個視角和觀點，並將其轉化為具體的成果，引導解決方案的組成。
企業架構的敏捷性
現代企業架構（EA）需要是一個敏捷的過程，能夠快速考慮企業內外部的多種視角和觀點。這意味著企業架構不能是一次性的，而是一個持續迭代和改進的過程。為了避免過度詳細和從一開始就追求完美的陷阱，我們應該定義一個目標架構（Target Architecture），作為北極星（North Star）來引導我們。
目標架構的定義
目標架構是企業未來狀態的藍圖，根據企業的使命和目標定義。它與現有的“as-is”狀態相對應，被稱為“to-be”狀態或未來運作模式（Future Mode of Operation）。企業需要為不同的業務部門定義不同的目標架構例項（Architecture Instances），每一個例項都必須包含各利益相關者的目標和關注點。
驗證架構例項
每一個架構例項都必須根據整體的目標架構或北極星進行驗證。主要問題是：它是否為企業帶來整體價值？企業架構在本質上是演進式的，業務需求會不斷變化，但整體的目標架構或北極星不會頻繁變化，它們允許在底層業務、資訊和技術架構中逐步採用變化。
使用IT4IT成熟現代架構
IT4IT是The Open Group提供的一個框架，用於幫助企業將IT架構與業務架構相匹配，特別是在數位轉型的背景下。IT4IT透過價值流（Value Streams）來實作這一目標，主要有四個價值流：
IT價值鏈
- 策略到投資組合（Strategy to Portfolio, S2P）：管理業務策略與IT投資組合之間的對齊。
- 需求到佈署（Requirement to Deploy, R2D）：定義建置和佈署IT服務的需求，注重可重複使用性、敏捷性和跨IT部門的協作。
- 請求到實作（Request to Fulfill, R2F）：最佳化向使用者交付服務的過程，專注於使用者經驗。
- 檢測到修正（Detect to Correct, D2C）：與IT服務管理（ITSM）整合，支援服務層級監控、問題檢測和修復，以維護使用者的價值。
IT4IT透過這些價值流，幫助企業整合業務、系統和技術架構，從而真正為業務增加價值。它強調了數位產品和服務的生命週期管理，不僅僅是交付產品，還包括對產品的管理和服務品質。
圖表翻譯：
此圖示展示了IT4IT中的四個主要價值流，分別是策略到投資組合（S2P）、需求到佈署（R2D）、請求到實作（R2F）和檢測到修正（D2C）。這些價值流共同構成了IT價值鏈，用於管理和最佳化IT服務的交付和維護。
內容解密：
上述段落詳細介紹了企業架構在現代企業中的重要性，以及如何透過TOGAF和IT4IT等框架來實作有效的企業架構管理。特別強調了目標架構的定義、驗證和迭代的重要性，以及IT4IT在數位轉型中的作用。接下來的章節將繼續探討相關主題，提供更多實踐性的指導。
為何企業需要企業架構
從TOGAF到Open Agile Architecture
企業架構（EA）是現代企業運作的核心，幫助企業從現有的營運模式（IST或基線）轉變為未來的營運模式（SOLL）。The Open Group的架構開發方法（ADM）有助於定義實作不同架構的步驟，以滿足企業的需求和整體戰略。
然而，傳統的框架，如Zachman和TOGAF，試圖捕捉整個企業的架構，可能導致架構變得靜態且難以管理。現代企業需要能夠快速適應變化、市場需求和客戶要求的架構。為此，The Open Group發布了新的框架：Open Agile Architecture（O-AA）。
浮動架構與O-AA
O-AA旨在解決現代企業面臨的挑戰，尤其是API驅動的架構。企業已成為生態系統，需要一個能夠與外部元件互動的架構。O-AA強調客戶中心，認為企業架構應該圍繞客戶需求設計。
O-AA定義了數位企業的特點：
- 應用數位技術改變企業戰略、產品或服務，以及客戶體驗
- 改變營運模式以實作數位轉型
- 敏捷企業能夠快速感知環境變化並果斷行動
O-AA提出了成為敏捷企業的要求：
- 消除孤島，實作跨學科協作，專注於為客戶創造最佳結果
- 團隊必須具備自主決策的能力，能夠發現機會並快速識別和分類別風險
O-AA中的接觸點
O-AA強調接觸點（touchpoints）的重要性，這些接觸點是定義架構的關鍵。如圖1-11所示，O-AA將客戶置於架構的中心，企業架構完全以客戶為中心。
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title O-AA中的接觸點
rectangle "接觸點" as node1
rectangle "API" as node2
rectangle "資料" as node3
node1 --> node2
node2 --> node3
@enduml圖表翻譯： 此圖示展示了O-AA中客戶、企業系統和外部元件之間的關係。客戶透過接觸點與企業系統互動，而企業系統則透過API與外部元件連線。
架構願景
在定義企業架構之前，需要制定架構願景。架構願景是TOGAF中的第一階段，描述了企業架構的目的和方向。它包含了架構宣告（為什麼需要企業架構）和業務、資訊系統和技術架構的方向。
制定架構願景的重要性
架構願景是架構師的「電梯演講」，解釋了擁有企業架構的目的。雖然企業的使命、戰略和目標可能已經在其他地方記錄，但仍需要評估和驗證這些檔案，以作為制定業務架構的起點。
def create_architecture_vision(mission, strategy, goals):
# 定義架構願景
vision = {
'mission': mission,
'strategy': strategy,
'goals': goals
}
return vision
# 範例用法
mission = "為客戶提供最佳服務"
strategy = "透過數位轉型實作業務增長"
goals = ["提高客戶滿意度", "增加收入"]
vision = create_architecture_vision(mission, strategy, goals)
print(vision)
內容解密：
此Python函式create_architecture_vision用於建立一個包含使命、戰略和目標的架構願景。其中：
mission代表企業的使命宣告strategy代表企業的整體戰略goals代表企業的具體目標 該函式傳回一個包含這些元素的字典，用於定義架構願景。
為何企業需要企業架構
策略與變革的挑戰
企業在制定策略時，必須考慮到市場和客戶需求的變化。以一家串流服務公司為例，其使命可能是成為全球領先的奇幻電影串流服務。為了實作這一目標，公司可能會收購一家頂級內容製作公司。然而，如果大眾突然對這類別內容失去興趣，公司就面臨著嚴峻的挑戰。
生態週期（Ecocycles）模型
為應對這種變化，企業可以使用生態週期模型。這個模型有助於區分、規劃和優先考慮行動，同時讓所有利益相關者參與進來，以應對不斷變化的商務環境。生態週期模型經常用於敏捷/Scrum開發中，提供了一個指導框架，幫助團隊向前推進。
生態週期的過程包括：
- 在誕生階段加速成長
- 在成熟階段延長生命或提高效率
- 在創造性破壞階段消除無生產力的部分
- 在更新階段透過連線團隊成員來推動創新
生態週期的規劃
此圖示呈現了生態週期的不同階段及其相互關係。
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title 生態週期的規劃
rectangle "加速成長" as node1
rectangle "成熟" as node2
rectangle "創造性破壞" as node3
rectangle "更新" as node4
rectangle "創新" as node5
node1 --> node2
node2 --> node3
node3 --> node4
node4 --> node5
@enduml圖表翻譯： 此圖示展示了生態週期的五個階段，從誕生階段的加速成長到更新階段的創新，每個階段都有其特定的目標和任務。
貧困陷阱與僵化
企業在發展過程中可能會遇到兩種極端的情況：貧困陷阱和僵化。貧困陷阱是指企業中有很多創意，但缺乏長官力和方向來將這些創意轉化為實際的解決方案。另一方面，僵化是指企業過度執著於舊有的想法和習慣，而這些想法和習慣已經不再對企業的目標有所貢獻。
制定架構願景
為瞭解決這些問題，企業需要制定一個清晰的架構願景。這包括：
- 識別變革驅動因素（業務目標、業務原則、架構原則）
- 識別目標
- 識別利益相關者並評估他們的關切
- 評估約束條件
內容解密：
在制定架構願景時，企業需要考慮到變革驅動因素、目標、利益相關者和約束條件等多個方面。這需要收集和分析大量的資訊，以確保架構願景能夠有效地指導企業的發展。
蒐集業務需求
蒐集業務需求是企業架構（EA）中的一個關鍵步驟。企業需要設定正確的目標和目標，並收集相關的需求。需求不僅僅是一個願望清單，而是指導企業發展的關鍵因素。
蒐集需求的最佳實踐
- 設定明確的目標和目標
- 識別相關的利益相關者和使用者
- 驗證每一個需求
程式碼範例：需求蒐集流程
def gather_requirements():
# 設定目標和目標
goals = set_goals()
# 識別利益相關者和使用者
stakeholders = identify_stakeholders()
# 蒐集和驗證需求
requirements = []
for stakeholder in stakeholders:
requirements.extend(collect_requirements(stakeholder))
# 驗證需求
validated_requirements = validate_requirements(requirements)
return validated_requirements
#### 內容解密：
此程式碼範例展示瞭如何透過設定目標、識別利益相關者、蒐集和驗證需求來蒐集業務需求。其中，`set_goals`函式用於設定目標，`identify_stakeholders`函式用於識別利益相關者，`collect_requirements`函式用於蒐集需求，`validate_requirements`函式用於驗證需求。
價值驅動因素
在現代企業中，客戶是核心。因此，企業需要關注那些能夠為客戶帶來價值的需求。價值驅動因素可以包括經濟價值、可持續性和易用性等方面。
為什麼企業需要企業架構
客戶導向的企業轉型
企業正在經歷一場戲劇性的轉變，大多數企業已經或正在轉型為客戶導向的組織。客戶對產品的設計、生產和交付產生了巨大的影響。客戶體驗透過調查和網路上的評分等方式，不斷被捕捉並轉化為客戶滿意度分數。
嵌入式客戶模式
更高層次的客戶參與是嵌入式客戶，即客戶成為企業的一部分。企業的部門、單位和團隊直接與客戶互動，以改進產品和服務，甚至是產品或服務的一部分。這需要企業進行完全不同的設定。團隊不僅直接與客戶互動，而且是自組織的，並被授權做出決定。在極端情況下，團隊甚至可以獲得客戶支付的薪水。企業現在變成了一個由微型企業組成的網路組織。這種模式是否有效？中國家電製造商海爾已經透過「人單合一」模式證明瞭這一點，在這種模式下，團隊被完全授權經營自己的業務。
三種企業模式的差異
圖1-13展示了三種企業模式的差異，最後一種模式是圍繞微型企業組織的。
此圖示展示了客戶互動方式的變化。
客戶導向和嵌入式客戶模式的優勢
客戶導向和嵌入式客戶模式在收集業務需求方面具有明顯的優勢。這些需求必須來自客戶：客戶之聲必須是主導。沒有客戶，企業就無法生存。必須主動收集需求。最大的陷阱是架構師假設自己代表客戶之聲。另一個陷阱是認為一旦收集了需求，這些需求就不會改變。客戶體驗會變化，需求也會隨之變化。收集需求必須持續且積極地進行。
客戶需求範例
- 品質
- 服務
- 交付
- 選擇
- 永續性
- 安全
- 價格
然而，這還不夠，我們必須使這些需求變得SMART（具體、可衡量、可達成、相關、有時限）。例如：
- 客戶希望多快收到貨？
- 什麼是高品質？
- 客戶想要哪些選項？
- 如果產品由50%的可再生材料製成，這是否足以聲稱它是永續的？
所有這些引數都驅動著為客戶創造的價值，從而影響用於實作該價值的架構。價格實際上主要由生產成本和客戶對產品或服務的價值評估決定。
為什麼需要企業架構和變更管理
我們已經確認任何業務都需要企業架構，並且研究了一些可以幫助我們應對現代企業挑戰的框架。同時，我們也討論瞭如何利用客戶之聲收集需求。現在，我們準備開始起草現代企業架構。但是，還有一件事我們必須建立，因為我們的架構肯定會隨著時間而改變。因此，我們需要變更管理。事實上，這是關鍵。
變更管理的重要性
現代企業正在處理日益增加的複雜性，需要敏捷和動態，隨時準備好進行變革。因此，良好的變更管理至關重要。
許多公司已經採用DevOps作為新的工作方式。DevOps的黃金法則是「你構建它，你執行它」，將責任轉移到業務單位和團隊內。這些團隊對產品和服務的開發和營運負有端對端的責任。「你構建它，你執行它」也意味著「你打破它，你修復它」。一個常見的誤解是這只關乎技術和工具。當然，自動化在DevOps中扮演著重要的角色，但它主要關乎團隊的心態和技能。然而，很多時候團隊真的被孤立起來，可以決定一切——從他們在持續整合/持續佈署（CI/CD）管道中使用的工具，直到工作方式。這對企業來說可能成為一種風險。
DevOps與企業架構和變更管理
DevOps並不意味著企業不需要企業架構，也肯定不意味著不需要變更管理。變更管理與功能管理不同。DevOps團隊將負責發布具有新功能的產品和服務。但是，這些新功能從何而來？答案是來自需求。
由於我們已經瞭解到需求來自不同的利益相關者，並且會有多種不同的觀點，因此架構師應該根據整體業務策略來驗證需求的影響。換句話說，一個新功能是否增加了價值？開發新功能的影響是什麼？需要哪些資源，成本是多少，價值驅動因素是什麼？產品開發和發布需要從架構的角度進行控制，使其與業務目標保持一致。這將提高團隊對開發和發布中的每一個選擇都會帶來後果的認識。而企業應該更好地準備好了解這些後果是什麼。
變更控制需考慮的因素
變更控制需要考慮以下幾個方面：
- 範圍
- 時間
- 資源
- 風險
- 利益相關者的觀點
- 成本
- 品質
只有綜合考慮這些因素，才能有效地進行變更管理，確保企業能夠在不斷變化的市場環境中保持競爭力。
