企業架構框架如TOGAF（開放群組架構框架）傳統上與詳細規劃、大量文件編製以及長期願景規劃相關聯。相反地，敏捷方法論則強調迭代交付、適應性與客戶反饋。對許多組織而言，整合這兩種截然不同的方法會產生摩擦。 perceived衝突在於架構治理的需求與快速迭代願望之間的張力。
本指南探討組織如何在敏捷環境中成功應用TOGAF原則。我們將檢視實際策略，以將架構開發方法（ADM）與迭代開發週期對齊，確保結構支援彈性而非造成阻礙。透過理解兩種框架的細微差異，領導者能夠建立既穩健又對變革具有回應能力的系統。
🧩 理解核心框架
要有效整合，我們必須首先理解每種方法的根本性質，而不依賴流行用語。
🏛️ TOGAF架構開發方法
TOGAF提供了一種結構化的方法，用於設計、規劃、實施與管理企業資訊架構。此框架的核心是ADM循環，包含多個階段：
- 階段A：架構願景 – 確定範圍與利害關係人需求。
- 階段B：業務架構 – 定義業務策略與流程。
- 階段C：資訊系統架構 – 涵蓋資料與應用架構。
- 階段D：技術架構 – 定義基礎設施與技術標準。
- 階段E：機會與解決方案 – 規劃實施路徑圖。
- 階段F：遷移規劃 – 排列轉移步驟。
- 階段G：實施治理 – 確保解決方案符合設計。
- 階段H：架構變更管理 – 管理架構的變更。
傳統上，此循環被視為線性或半線性，通常需要在實施開始前完成全部定義。這正是與敏捷方法產生摩擦之處。
⚡ 敏捷思維
敏捷不僅是一組實務；它是一種以敏捷宣言為核心的思維模式。關鍵原則包括：
- 個人與互動勝於流程與工具。
- 可運作的軟體勝於全面的文件。
- 客戶協作勝於合約談判。
- 回應變更勝於遵循計畫。
敏捷團隊通常以短週期（衝刺）工作，以交付可運作的增量。他們依賴持續的反饋來調整產品方向。在這種背景下，僵化的架構計畫可能會延緩價值交付。
🤝 整合挑戰
將 TOGAF 與敏捷結合的主要挑戰在於時間範圍與規劃細節的差異。TOGAF 通常從企業層面著眼於數年，而敏捷則以數週或數月為單位運作。如果架構過於僵化，會抑制團隊調整方向的能力；若過於鬆散，組織則可能面臨技術負債與碎片化的風險。
以下是衝突通常發生的領域：
| 面向 | TOGAF 關注點 | 敏捷關注點 | 潛在衝突 |
|---|---|---|---|
| 規劃 | 長期路線圖 | 短期衝刺待辦事項 | 需要多少未來的細節？ |
| 文件 | 完整的模型 | 可運作的軟體 | 文件的開銷是否合理？ |
| 決策 | 集中式治理 | 去中心化所有權 | 誰批准變更？ |
| 變更 | 受控的演進 | 擁抱適應 | 如何管理偏移？ |
認識到這些差異，使架構師能夠設計出一種混合模型，尊重雙方的優勢。
🔄 為敏捷週期調整 ADM
架構開發方法無需放棄，反而可以使其具備迭代性。『迭代式 ADM』的概念允許架構工作與開發工作並行進行，而非完全前置。
🌱 迭代式架構願景
階段 A（願景）不應僅是一次性事件。在敏捷環境中，願景應被視為一份活文件。它提供方向指引，但同時允許根據市場反饋進行調整。架構師與產品負責人合作，確保願景與產品路線圖一致。
關鍵行動包括：
- 定義保持不變的高階原則。
- 識別不可妥協的限制條件（安全性、合規性）。
- 將願景分解為可執行的架構巨作。
🏗️ 即時架構定義
在傳統模型中，所有四個領域（業務、資料、應用程式、技術）都會在開發開始前完全定義。敏捷方法建議僅定義繼續前進所必需的內容。這通常稱為「即時」架構。
例如：
- Sprint 1-3：專注於業務架構與高階應用程式邏輯。
- Sprint 4-6：隨著特定資料實體的需求出現，逐步優化資料架構。
- Sprint 7+：詳細規劃部署環境的技術架構。
這種方法可減少浪費。架構師不會花時間去建模那些可能在迭代過程中被捨棄的組件。
🏗️ 架構跑道
此整合中一個關鍵概念是「架構跑道」。此術語指的是必須建立以支援未來功能開發的技術基礎設施與架構原則。若無跑道，開發人員可能必須在功能Sprint中間停下來，建立基礎組件，進而造成延遲。
維持健康跑道的方法包括：
- 識別促成因素：確定哪些技術工作是為了實現未來業務價值所必需的。
- 配置容量：為架構促成因素保留一部分Sprint容量（例如20%）。
- 自動化標準：使用基礎設施即程式碼來強制執行技術標準，避免手動審查的瓶頸。
這確保敏捷團隊能擁有所需的工具與框架，無需等待大型架構專案完成。
🛡️ 輕量級治理
敏捷環境中的治理必須輕量級。過於嚴苛的審批流程會扼殺進展動能。目標是在不造成瓶頸的情況下確保合規性與品質。
📝 架構決策紀錄（ADRs）
取代龐大的架構文件，組織可使用架構決策紀錄。ADR會記錄一項重要的架構決策及其背景與後果。這是一份輕量級文件，存放於程式碼倉儲中。
ADRs的優點包括：
- 可追溯性：數個月或數年後仍能知道當初做出該決策的原因。
- 合作：團隊成員可以輕鬆地審查並對決策發表意見。
- 透明度： 決策歷史對所有人開放。
🔍 架構審查委員會
傳統的架構審查委員會（ARB）可能成為瓶頸。在敏捷環境中，ARB 應扮演諮詢機構的角色，而非守門人。審查應在關鍵里程碑時進行，而非每個迭代都進行。
考慮以下調整：
- 聚焦風險： 僅審查可能影響企業的高風險決策。
- 異步審查： 允許架構師異步提供反饋，以避免排程衝突。
- 同儕審查： 鼓勵開發人員在正式的 ARB 審查前互相審查架構合規性。
👥 角色與職責
成功的整合需要明確的角色定義。傳統的「資深架構師」角色通常需要演變為更分散的模式。
🧑💼 企業架構師
企業架構師專注於長期願景。他們定義指導組織的標準、原則與模式。他們確保不同團隊不會建立彼此不相容的孤島。
🧑💻 系統架構師
系統架構師更靠近開發團隊。他們將企業原則轉化為特定解決方案的具體技術設計。他們在高階策略與程式碼之間扮演橋樑的角色。
🏃♂️ 敏捷架構師
某些組織會將架構師直接嵌入敏捷團隊。這些人員協助團隊做出符合整體戰略的決策，同時維持開發速度。他們參與迭代規劃與待辦事項精煉。
🧭 產品負責人
產品負責人代表商業價值。他們與架構師合作，確保技術限制能在商業目標的脈絡中被理解。他們將架構推動因素與使用者故事一同優先排序。
🚧 常見陷阱，應避免
即使有穩固的計畫，若忽略特定陷阱，整合仍可能失敗。意識到這些常見錯誤可節省大量時間與資源。
- 過度設計： 為每種可能的未來情境設計，會導致系統臃腫。應以可擴展性為考量，針對當前需求進行設計。
- 設計不足： 忽略架構限制會導致技術負債變得難以管理。確保非功能需求（效能、安全性）得到處理。
- 溝通落差： 架構師和開發人員經常使用不同的語言。使用團隊所有人都能理解的圖示和模型。
- 忽視技術債項： 敏捷團隊經常將功能優先於重構。建立一項規則，規定每個迭代中必須有部分時間用來處理技術債項。
- 工具過載： 不要依賴需要培訓的複雜建模工具。保持文件簡潔，並與開發流程緊密整合。
📊 衡量成功
你如何知道整合是否有效？你需要能反映架構健康狀況與交付速度的指標。
📈 架構健康指標
- 合規率： 遵循既定標準的解決方案所佔比例。
- 技術債項比率： 重構工作與新功能工作之間的比率。
- 可重用性： 在不同專案中使用的共用組件數量。
🚀 交付指標
- 前置時間： 從構想至部署的時間。
- 部署頻率： 代碼發布的頻率。
- 變更失敗率： 引發失敗的部署所佔比例。
透過追蹤這些指標，領導層可以根據數據做出決策，判斷應在架構上投入資源，或何處可放寬限制。
🤔 常見問題
❓ TOGAF 能否與 Scrum 搭配使用？
可以。ADM 各階段可對應至 Sprint 循環。例如，B 階段與 C 階段可透過一系列 Sprint 來探討。關鍵在於將 ADM 視為一個探索循環，而非線性的瀑布模式。
❓ 需要多少文件？
文件應足以維護系統，但不宜過多。一張紙就能容納的圖示，通常比五十頁的文件更佳。專注於能增加價值、有助於維護的文件。
❓ 如果業務需求在迭代中途發生變更該怎麼辦？
這正是敏捷的核心原則。架構必須具備足夠的彈性以應對變更。使用抽象層與介面來解耦組件，使某區域的變更不會導致整個系統崩潰。
❓ 我們是否需要像 SAFe 這樣的獨立敏捷框架？
不一定。雖然像SAFe（擴展敏捷框架）之類的框架為大型組織提供了結構，但TOGAF可以在不採用完整框架的情況下進行調整。選擇取決於組織的規模和複雜性。
❓ 我們該如何處理遺留系統？
遺留系統通常需要不同的處理方式。您可能需要建立一種「絞殺榕」模式，即在遺留系統周圍逐步構建新功能，以逐漸取代它。TOGAF有助於規劃從遺留狀態到目標狀態的過渡。
🔍 重點要點
將TOGAF與敏捷方法整合，並非要在二者之間做出取捨。而是要在結構與敏捷性之間找到平衡。透過使架構開發方法具備迭代性、採用輕量級治理，並明確定義角色，組織可以同時實現穩定性與速度。
成功取決於溝通、彈性以及對目標的共同理解。當架構團隊與開發團隊作為夥伴合作時，結果將是一個能夠適應市場變化的韌性企業，同時不犧牲品質或合規性。
從小處著手。在一個團隊中試點該方法。衡量結果。調整流程。重複執行。這種對架構本身的迭代方法，正反映了它所致力於支持的敏捷哲學。
