在現實中，你必須回答「多少預先設計是足夠的「，我建議實踐架構一個軟件系統。找到或創建一個中小型軟件項目的場景，制定一個很短的高層次需求（功能和非功能）集合來描述。這可以是一個你已經參與工作過的已有系統，或者是跟你的領域不相關的新東西，比如我在自己的培訓課程上用的金融風險系統。有了這個，再要求兩組（每組2~3人）或更多的人通過選擇一些技術，做一些設計，繪製一些用於交流願景的圖，找出一個解決方案。為這個活動規劃好時間（比如90分鐘），然後主持一個開放的評審會議，對每個解決方案提出以下類型的問題。
- 架構會管用嗎？如果不管用，為什麼？
- 所有關鍵的風險都已被識別了嗎？
- 架構是否過於簡單？是否過於複雜？
- 架構是否有效地交流過？
- 圖的哪些地方是受人喜歡的？哪些可以改進？
- 細節是否太多？細節是否足夠？
- 你能把這作為起點交給你的團隊嗎？
- 控制是否太多？指導是否不足？
- 你對已做出或推遲的技術決策的程度滿意嗎？
把這個練習看作一種架構演練5 ，不過你要進行一次評審，主要集中在你所經歷的過程以及產出，而不僅僅是架構本身。記錄你的發現，嘗試為將來處理軟件設計流程提煉出一套指導。商定要深入多少細節並包含示例，商定圖表表示法並包含好的圖表示例，確定你自己的環境中的通用約束，等等。如果可能的話，記住這些指導，反覆練習，看看它如何帶來改變。通常一天足夠進行幾次包含設計/溝通/評審週期的練習。
5 http://blogs.tedneward.com/2010/06/17/Architectural+Katas.aspx
沒有一模一樣的軟件團隊。留出一天，在你自己的環境中實踐軟件的設計流程，這會為你將來應對這一流程提供一個一致的起點，幫助你在適當的語境中搞清楚究竟什麼樣的預先設計對你和你的團隊而言「恰如其分」。實踐軟件設計流程還有一個額外的好處，它是培訓和指導其他人的好方法。你在追求一個人人都能扮演軟件架構角色的自組織團隊嗎？