上面很多答案都不难得到认同，但是“恰如其分”仍处于两个极端之间的灰色地带。关键是架构代表了重大的决策，而衡量重要性的则是改变的成本。换句话说，就是修改起来真的很昂贵，也真的需要尽早做对的东西。举个例子，高性能、高可伸缩性、高安全性和高可用性等质量一般需要尽早融入基础中，因为它们很难安插到已有的代码库中。重大的决策也包括那些你不能用一个下午就轻松完成重构的东西，比如整体结构、核心技术的选择、“架构”模式、核心框架等。
暂时回到RUP，它使用了“架构上重要”这个术语，建议你应该找出什么可能对你的架构重要。什么可能是重要的？嗯，任何改变成本高、复杂（比如棘手的非功能需求或约束）或新的东西。在现实中，如果你没把这些事做对，它们就会有高于正常风险的后果。重要的元素往往也是主观的，会根据团队的经验有所变化，这一点值得铭记。
在这里你有的就是一种软件开发方法，它使你可以为了构建向前发展的充分基础而关注什么是有风险的。无论什么方法学，识别架构上重要的元素及其相应的风险，都应该应用到所有的软件项目。如果你需要引入一个架构冲刺，某些敏捷布道者会说“你错了”，然而一些敏捷项目已经引入了一个“冲刺零”来做这件事。我说，你需要做任何基于你自己的语境、对你管用的。
尽管所有这些提供了一些指导，然而“多少才是恰如其分”这个问题的答案却要“看情况”，因为每个软件团队都不一样。有些团队更有经验，有些需要更多指导；有些一直在一起工作，有些频繁地轮换和变动；有些软件系统有大量必要的复杂性，等等。那么你需要做多少架构？我说，你需要做到“恰如其分”，以便做到以下几点，不管软件架构角色是由一个人扮演还是团队内共享这些都适用。
结构
是什么 ：理解主要的结构元素，以及它们如何基于架构驱动力组合在一起。
- 怎么做 ：设计并分解为容器和组件。
风险
- 是什么 ：识别和缓解最高优先级的风险。
- 怎么做 ：风险风暴和具体的实验4 。
4 http://www.agilemodeling.com/essays/agileArchitecture.htm#ProveIt
愿景
- 是什么 ：创建并交流团队展开工作的愿景。
- 怎么做 ：语境、容器和组件图。
这个软件架构实践的最小集合将为你提供支撑软件交付的其余部分的坚实基础。有些架构通常确实需要预先完成；但是有些则不是，还能够自然地演化。关键在于找准强制性和演化设计的分界线。