多數情況下，這些衝突會造就缺乏合適的技術領導力的混亂團隊。結果如何？做出來的軟件系統看起來一團亂，也不符合非功能需求等關鍵的架構驅動力。
架構是改變起來很困難或者成本很高的東西，跟那些你不能用一個下午就輕鬆完成重構的、大的或者「主要」的決策有關。它包括核心技術選擇，全面的高層次結構（全局）以及對如何解決各種複雜、高風險、關鍵問題的理解，等等。軟件架構很重要 。
大型預先設計通常涵蓋了這些對架構的顧慮，但往往想得太多。有一個技巧來區分哪些是重要的：定義一個高層次結構，設定願景，這很重要；在開始編碼之前，繪製無數個類的詳圖，則多半不重要。搞清楚如何解決怪異的性能需求很重要，搞清楚每個數據庫字段的長度就不太重要。
敏捷和架構並不衝突。與其盲目聽從別人的指點，軟件團隊更應剔除炒作，理解技術領導力的方式 ，在其獨特的環境下量化所需的預先設計 。
考慮架構的驅動力不需要花很長時間，卻能為軟件設計的其他部分提供一個開始。當然，這並不意味著架構不應該更改，特別是當你開始編寫代碼、獲得反饋後。關鍵在於你現在有了一個框架和一定的工作範圍，能為團隊提供一些經常需要的願景和指導。我的經驗是小方向有大用場。