進入企業架構主管的角色，需要從戰術執行轉變為戰略監督的思維模式。在TOGAF架構中，架構開發方法（ADM）提供了一種結構化的方法，然而對於剛接觸此領域的新手而言，需求分析階段往往成為一個障礙。需求分析不僅僅是收集需求清單，更在於建立業務目標與技術能力之間清晰且可追溯的連結。當此連結薄弱時，整個架構計畫將面臨偏離組織價值的風險。
本指南針對TOGAF需求分析過程中常見的錯誤進行說明。透過理解這些陷阱，新任主管能更精準地應對ADM循環的複雜性。本指南的重點在於實際應用、利害關係人參與，以及架構資料庫的結構完整性。
🔍 TOGAF中需求分析的基礎
在TOGAF中，需求分析涵蓋多個階段，尤以階段A（架構願景）、階段B（業務架構）、階段C（資訊系統架構）與階段D（技術架構）為主。每個階段都會引入特定類型的需求，這些需求必須被捕捉、驗證並持續維護。
有效的分析依賴於三大核心支柱：
- 業務需求：由組織策略所定義的高階目標與限制。
- 利害關係人關注事項：對架構產生影響的個人或團體所持有的特定利益。
- 非功能性需求：如效能、安全性與可靠性等品質屬性。
未能區分這些類別，經常導致範圍蔓延與架構偏移。新任主管必須在進入設計階段前，確保需求資料庫正確填入內容。
❌ 錯誤一：忽略利害關係人背景與權力動態
最常見的錯誤之一，是在需求收集過程中將所有利害關係人視為同等重要。事實上，組織內各成員的影響力與興趣程度差異極大。主管可能花數小時訪談一位中階經理，卻忽略了關鍵決策者未發言。
影響
當關鍵利害關係人未在早期被識別，其關切事項往往直到專案後期才被發現。這導致必須返工，因架構必須調整以符合原先未明言的需求。此外，也可能導致架構計畫缺乏支持，進而造成資源被撤回。
修正策略
為避免此問題，應在架構願景階段初期建立完整的利害關係人地圖。該地圖應根據利害關係人的權力與興趣進行分類。
- 高權力、高興趣：密切參與並嚴格管理期望。
- 高權力、低興趣：透過提供高階更新保持滿意。
- 低權力、高興趣：保持資訊透明，防止誤解。
- 低權力、低興趣：以最少努力監控即可。
不要假設職位頭銜代表其影響力。在某些組織中，技術主管對執行的影響力可能超過名義上的部門主管。訪談必須設計得當，以揭露這些隱藏的權力動態。
❌ 錯誤二：混淆需求與解決方案
新任主管常陷入將解決方案當作需求的陷阱。例如，利害關係人可能說：「我們需要一套新的資料庫系統。」若架構師將此記錄為需求，分析過程便會在真正理解需求前，就對該特定技術產生偏頗。
影響
這種過早的承諾會限制解決方案的空間。架構可能鎖定一種已不再可行的技術，或是一種無法滿足基本業務需求的技術。這也會產生技術負債，因為架構被迫支援特定工具，而非功能性能力。
修正策略
應用「為什麼」技巧。每次提出解決方案時，都應問為什麼需要這個解決方案。
- 利益相關者： “我們需要一個雲端儲存解決方案。”
- 架構師： “這是在支援哪種業務能力？”
- 利益相關者： “我們需要安全地與合作夥伴分享大型檔案。”
- 架構師： “所以需求是安全的檔案傳輸，而非特定的雲端儲存。”
應記錄基礎能力（安全檔案傳輸），而非所提出的工具。這能在ADM週期的後續階段，靈活選擇最佳技術。
❌ 錯誤 3：忽視非功能性需求（NFR）
功能性需求描述系統做什麼，非功能性需求描述系統如何運作。新任主管常重視「做什麼」而忽略「如何做」，假設性能與安全將由實作團隊處理。
影響
未明確定義非功能性需求的架構，通常在負載下失敗，或容易遭受安全漏洞。合規性要求，如資料存放地或審計追蹤，也屬於非功能性需求。若在分析階段遺漏這些，後續將無法獲得法律或合規委員會的批准。
修正策略
建立一套標準的非功能性需求類別，每個架構專案都必須處理。常見類別包括：
- 效能： 回應時間、吞吐量與延遲。
- 安全性： 身份驗證、授權與加密標準。
- 可靠性： 可用性目標與災難復原能力。
- 可擴展性： 處理資料或使用者增長的能力。
- 可維護性： 更新與修補的便利性。
這些需求應盡可能量化。例如不要只說「快速性能」，而應明確指出「95%的交易必須在200毫秒內完成」。量化可消除模糊性，並讓後續能進行客觀測試。
❌ 錯誤 4：需求之間的追溯性不足
追溯性指的是將需求追溯至其來源，並向前連結至滿足該需求的設計元件的能力。若無此能力，便無法確定特定的設計決策是否真正解決了商業需求。
造成的影響
當追溯性喪失時，架構便成為一個黑箱。審計人員無法驗證合規性。變更管理人員無法評估修改的影響，因為他們不清楚哪些需求受到影響。這導致出現「隱形架構」，未記錄的應急方案大量滋生。
修正策略
建立需求資料庫。這是一個結構化的資料庫或文件管理系統，其中每個需求都會被分配一個唯一的識別碼（例如：REQ-BUS-001）。
針對每一項需求，應維持以下連結：
- 來源：是哪位利害關係人或商業目標所提出的？
- 依賴關係：哪些其他需求必須先滿足？
- 滿足情況：哪個架構構件或設計元件滿足此需求？
- 狀態：此需求是否已被接受、拒絕或延後？
在 ADM 循環期間定期審查此資料庫。若某項需求未連結至任何設計元件，應標示為未滿足。若某設計元件未連結至任何需求，則應列入刪除候選名單，以降低複雜度。
❌ 錯誤 5：跳過基準分析
基準代表組織架構的現狀。許多領導者在未充分記錄現有能力、缺口與技術負債的情況下，便急於定義目標狀態。
造成的影響
若無基準，便無法衡量進展。遷移策略將淪為猜測。你可能無意中設計出依賴已不存在或即將停用能力的目標狀態，導致遷移計畫失敗。
修正策略
對現有環境進行全面清點。這並不需要對每一台伺服器進行完整審計，但必須掌握以下方面的高階視圖：
- 應用系統：目前正在使用的系統有哪些？
- 基礎設施：哪些硬體或雲端資源支援這些系統？
- 流程：目前的工作實際是如何進行的？
- 資料：關鍵資訊存放於何處？
記錄已知的限制和痛點。這些將成為新架構的推動力。如果現有系統運行緩慢，新架構必須明確解決性能瓶頸問題。如果某個流程是手動的，新架構應致力於實現自動化。
📊 常見錯誤與最佳實踐的對比
為了直觀展示無效分析與穩健架構規劃之間的差異，請考慮以下對比表格。
| 領域 | 常見錯誤 | 最佳實踐 |
|---|---|---|
| 利益相關者 | 對所有人一視同仁地進行訪談 | 分析權力與興趣；優先接觸關鍵決策者 |
| 需求 | 記錄提出的解決方案 | 記錄背後的業務需求與能力 |
| 品質屬性 | 忽略性能與安全性 | 早期定義可量化的非功能需求 |
| 可追溯性 | 未連結的需求與設計 | 使用具有唯一ID和雙向連結的儲存庫 |
| 現狀 | 急於達成目標狀態 | 記錄基線以識別差距與遷移路徑 |
| 文件化 | 使用非正式筆記 | 維護正式的架構儲存庫 |
🔗 將分析整合至ADM循環中
需求分析並非一次性事件。它是一個貫穿ADM循環的迭代過程。隨著架構的演進，可能會出現新的需求，而舊的需求也可能變得過時。
階段A：架構願景
在此階段，主要關注高階業務需求與利益相關者的關切。目標是定義專案範圍以及將指導架構的原則。
階段B與C：業務與資訊系統
在此階段收集詳細的業務需求。定義資料與應用程式的功能需求。這正是業務能力與IT能力之間區別變得至關重要的時刻。
階段 D：技術架構
技術需求被進一步細化。非功能性需求（NFR）被詳細指定。基線技術堆疊將被分析，以確定哪些部分可以重用。
階段 E 至 H：實施與治理
需求將根據已實施的解決方案進行驗證。識別出差距，並管理變更請求。需求資料庫將更新，以反映實際建成的狀態。
🛠️ 新任主管的溝通協議
技術準確性僅是戰鬥的一半。溝通確保分析結果能在整個組織中被理解並接受。
- 使用視覺模型：圖表通常比文字更有效。使用流程圖或能力地圖來闡明需求。
- 定義術語：確保所有利益相關者對關鍵術語的含義達成共識。「可用性」對 IT 和運營部門而言意義不同。
- 定期審查：安排定期的需求審查會議。不要等到專案結束才驗證需求清單。
- 反饋迴路：建立機制，讓利益相關者可以在不打亂整個流程的情況下提出需求變更請求。
🚦 信心滿滿地向前邁進
通往有效架構的道路由明確的需求鋪成。透過避免常見的陷阱，如解決方案偏見、不良的利益相關者對應關係，以及被忽視的可追蹤性，新任主管可以建立具韌性且與業務策略一致的架構。TOGAF 框架提供結構，但分析師的紀律才真正創造價值。
專注於業務成果，而非技術本身。確保每一項需求都有明確目的，並與設計元素相關聯。嚴格維護需求資料庫。這些實務將在架構團隊與組織其他部分之間建立信任基礎。
請記住，架構是一段旅程，而非終點。需求分析階段確定了方向。若方向清晰，旅程將更順暢；若方向模糊，團隊將迷失。請投入時間，從一開始就把它做對。
