作者：道格·克勞福德（DougGrawford）
好的架構師能夠將複雜性降低到最低限度，他在解決方案中給出的抽象，應該能夠爲更高的層次提供堅實基礎，同時，還應該能足夠務實地應付未來的變化。
優秀的架構師能夠深刻理解變化帶來的影響，這種影響不僅限於彼此隔離的軟件模塊之間，而且包括人與人之間，以及系統與系統之間。
變化有多種不同的表現形式：
- 功能需求的變化。
- 可擴展性需求的演進。
- 系統接口被修改。
- 團隊人員流動。
- ……
軟件項目中變化的廣度和複雜性，是無法提前看得清楚，企圖事前消解所有潛在衝突（bump）是徒勞無功的。但是，在確定沿途遭的衝突和項目成敗之間的關係中，架構師扮演着關鍵角色。
管理變化並非架構師的的職責，但架構師要確保變化是可控的。
舉例而言，高展分佈式的解決方案，橫跨了許多應用程序，依賴多種中間件（middleware）將各個部分膠合在一起。如果沒有對依賴集（set of dependencies）進行準確跟蹤或以某種可視化模型表現出來，業務流程的變化可能會造成重大的危害。如果變化會影響數據或破壞現有接口，其對下游的影響會尤爲巨大。另個，現存的長時間運行中的有狀態事務（long-running stateful transaction），在老版本流程下也必須要能成功完成。
這上例子可能有點極端，但高度集成的解決方案現在是主流。架構師需要在可用的集成標準、框架和模式中做出選擇，這個例子無疑可以說明這點。爲了能給客戶提供一貫的支持，理解這些外圍系統的變化將帶來的潛在影響，顯得至關重要。
幸運的是，有許多工具和技術可以用心鹹輕變化的影響：
- 進行小規模的增量漸變。
- 構建可重複運行的測試用例，並經常運行。
- 讓測試用例更易編寫。
- 跟蹤好依賴關係。
- 系統性（systematically）的行動，根據反饋信息作出進一步反應。
- 自動化重複的任務。
架構師必須評估變化對項目範圍、時間和預算各個方面產生的影響，並準備好花較多時間在那些受影響最大的區域，即“沿途的衝突（a bump in the road）”上。通過衡量風險（measuring risk），可以知道該把寶貴時間花在哪裏。
降低複雜性很重要，但降低複雜性並不等於簡化處理。務必清楚認識解決方案中變化的類型和將來帶來的影響，對中長期而言，這樣做帶來的回報是無法估量的。