在现实中，你必须回答“多少预先设计是足够的“，我建议实践架构一个软件系统。找到或创建一个中小型软件项目的场景，制定一个很短的高层次需求（功能和非功能）集合来描述。这可以是一个你已经参与工作过的已有系统，或者是跟你的领域不相关的新东西，比如我在自己的培训课程上用的金融风险系统。有了这个，再要求两组（每组2~3人）或更多的人通过选择一些技术，做一些设计，绘制一些用于交流愿景的图，找出一个解决方案。为这个活动规划好时间（比如90分钟），然后主持一个开放的评审会议，对每个解决方案提出以下类型的问题。
- 架构会管用吗？如果不管用，为什么？
- 所有关键的风险都已被识别了吗？
- 架构是否过于简单？是否过于复杂？
- 架构是否有效地交流过？
- 图的哪些地方是受人喜欢的？哪些可以改进？
- 细节是否太多？细节是否足够？
- 你能把这作为起点交给你的团队吗？
- 控制是否太多？指导是否不足？
- 你对已做出或推迟的技术决策的程度满意吗？
把这个练习看作一种架构演练5 ，不过你要进行一次评审，主要集中在你所经历的过程以及产出，而不仅仅是架构本身。记录你的发现，尝试为将来处理软件设计流程提炼出一套指导。商定要深入多少细节并包含示例，商定图表表示法并包含好的图表示例，确定你自己的环境中的通用约束，等等。如果可能的话，记住这些指导，反复练习，看看它如何带来改变。通常一天足够进行几次包含设计/沟通/评审周期的练习。
5 http://blogs.tedneward.com/2010/06/17/Architectural+Katas.aspx
没有一模一样的软件团队。留出一天，在你自己的环境中实践软件的设计流程，这会为你将来应对这一流程提供一个一致的起点，帮助你在适当的语境中搞清楚究竟什么样的预先设计对你和你的团队而言“恰如其分”。实践软件设计流程还有一个额外的好处，它是培训和指导其他人的好方法。你在追求一个人人都能扮演软件架构角色的自组织团队吗？