上面很多答案都不難得到認同，但是「恰如其分」仍處於兩個極端之間的灰色地帶。關鍵是架構代表了重大的決策，而衡量重要性的則是改變的成本。換句話說，就是修改起來真的很昂貴，也真的需要盡早做對的東西。舉個例子，高性能、高可伸縮性、高安全性和高可用性等質量一般需要盡早融入基礎中，因為它們很難安插到已有的代碼庫中。重大的決策也包括那些你不能用一個下午就輕鬆完成重構的東西，比如整體結構、核心技術的選擇、「架構」模式、核心框架等。
暫時回到RUP，它使用了「架構上重要」這個術語，建議你應該找出什麼可能對你的架構重要。什麼可能是重要的？嗯，任何改變成本高、複雜（比如棘手的非功能需求或約束）或新的東西。在現實中，如果你沒把這些事做對，它們就會有高於正常風險的後果。重要的元素往往也是主觀的，會根據團隊的經驗有所變化，這一點值得銘記。
在這裡你有的就是一種軟件開發方法，它使你可以為了構建向前發展的充分基礎而關注什麼是有風險的。無論什麼方法學，識別架構上重要的元素及其相應的風險，都應該應用到所有的軟件項目。如果你需要引入一個架構衝刺，某些敏捷布道者會說「你錯了」，然而一些敏捷項目已經引入了一個「衝刺零」來做這件事。我說，你需要做任何基於你自己的語境、對你管用的。
儘管所有這些提供了一些指導，然而「多少才是恰如其分」這個問題的答案卻要「看情況」，因為每個軟件團隊都不一樣。有些團隊更有經驗，有些需要更多指導；有些一直在一起工作，有些頻繁地輪換和變動；有些軟件系統有大量必要的複雜性，等等。那麼你需要做多少架構？我說，你需要做到「恰如其分」，以便做到以下幾點，不管軟件架構角色是由一個人扮演還是團隊內共享這些都適用。
結構
是什麼 ：理解主要的結構元素，以及它們如何基於架構驅動力組合在一起。
- 怎麼做 ：設計並分解為容器和組件。
風險
- 是什麼 ：識別和緩解最高優先級的風險。
- 怎麼做 ：風險風暴和具體的實驗4 。
4 http://www.agilemodeling.com/essays/agileArchitecture.htm#ProveIt
願景
- 是什麼 ：創建並交流團隊展開工作的願景。
- 怎麼做 ：語境、容器和組件圖。
這個軟件架構實踐的最小集合將為你提供支撐軟件交付的其餘部分的堅實基礎。有些架構通常確實需要預先完成；但是有些則不是，還能夠自然地演化。關鍵在於找準強制性和演化設計的分界線。