重點摘要#
- 好的架構師降低複雜性，偉大的架構師理解變化的影響 – 不僅在軟體模組中，還在人與系統之間
- 架構師的角色不是管理變化，而是確保變化是可管理的
- 變化的廣度和複雜性無法事先完全預見，但架構師可以決定這些變化是否會使專案崩潰
- 降低複雜性很重要，但降低複雜性不等於簡單性
詳細內容#
變化的多種面向#
變化可以以多種形式出現：
- 功能需求改變
- 擴展性需求演進
- 系統介面被修改
- 團隊成員來來去去
- 還有更多 ⋯
架構師的角色不是管理變化，而是確保變化是可管理的（change is manageable）。
分散式系統中的變化影響#
以一個高度分散式的解決方案為例，它跨越多個應用程式並依賴各種中介軟體來黏合各部分。業務流程的一個變化可能造成嚴重的影響，如果依賴關係沒有被正確追蹤或以視覺化模型準確呈現的話。當變化影響到資料模型、破壞現有介面，而現有的長時間執行的有狀態交易必須在舊版本下完成時，影響尤其顯著。
緩解變化影響的工具和技術#
- 進行小規模、漸進式的變更
- 建立可重複的測試案例，並經常執行
- 讓建立測試案例更容易
- 追蹤依賴關係
- 系統性地行動和回應
- 自動化重複性任務
風險評估#
架構師必須估計專案範圍、時間和預算各方面的變化風險，並準備在影響最大的區域投入更多時間。衡量風險是了解應該把寶貴時間花在哪裡的有用工具。
降低複雜性很重要，但降低複雜性不等於簡單性。理解變化的類型和影響對你的解決方案帶來的回報，在中長期來看是不可估量的。
— By Doug Crawford