在軟件開發方面，架構設計的作用不可諱言。中培偉業《軟件系統詳細設計最佳實踐》培訓專家張老師指出，在傳統開發方法中，架構設計是圍繞著設計文檔展開的。具體實施過程有如下特點：

l 預先設計。在實際開發工作開始前，少數架構師們需要用相當長的一段時間來進行架構設計和詳細設計，力求得到一個具有高度可擴展性的良好架構。產出為“概要設計文檔”和“詳細設計文檔”。根據項目規模，這個過程一般持續數周、數月甚至數年不等

l 短暫評估。架構師產出的設計文檔要經過架構設計評審委員會或類似組織的評審，這個過程一般持續數天

l 依據設計進行實現。經過評審的設計會交到開發者手中，進行實際的編程實現，這個過程往往以數月，甚至數年來計算。

思考傳統架構設計方法，我們不禁要提出這樣的問題：

為什么傳統開發方法會如此重視前期預先架構設計，以至于希望在實際開發前把架構設計做到盡善盡美？

答案在于，在傳統的概念中，一旦設計成型，架構是很難調整的。例如，傳統的軟件工程教科書中都會討論“架構調整的成本”問題：如果在設計中實現一次修改的成本為1；在實現過程中相同修改的成本就是5～10；在測試、部署階段，同樣的修改成本將上升到50～100；維護階段同樣修改的成本更是成指數曲線上升。

這種策略存在一個根本問題：軟件的“擴展”究竟會如何發生是很難預計的。面對這一困境，傳統開發方法的解決方案是繼續增加預先設計的時間和人力，但往往收效甚微。

傳統設計困境分析

傳統預先設計方法惡性循環的原因有三點，對應上述實施過程的特點：

l 設計和實現脫節。設計評審團專家一般不參與實際的軟件開發?；诮涷灥脑O計一方面無法得到實現的驗證；另一方面，當需求發生變更時，無法隨之演進。

l 評估的可靠性有限。對預先設計評估的只能基于已知的需求，而系統的可擴展性是在應對變更的需求時體現出來的，因此評估具有很大的局限性

l 實現者缺少對預先設計進行修改的支持。當預先設計不能滿足實際需求時，開發者或者修改設計，或者置需求變更不理，繼續沿預先設計開發。忽視需求變更的結果只能是系統無法滿足應用（而開發者也可以將責任推到架構師身上）；如果開發者根據需求修改設計，則預先設計不但事實上已經成為浪費，而且已有的設計和實現往往更成會增加修改的難度。原因在于，如果預先設計的擴展性沒有用到，則這些額外的擴展性帶來的對當前需求無用的復雜性，這些復雜性增加了理解、修改系統的難度。