多数情况下，这些冲突会造就缺乏合适的技术领导力的混乱团队。结果如何？做出来的软件系统看起来一团乱，也不符合非功能需求等关键的架构驱动力。
架构是改变起来很困难或者成本很高的东西，跟那些你不能用一个下午就轻松完成重构的、大的或者“主要”的决策有关。它包括核心技术选择，全面的高层次结构（全局）以及对如何解决各种复杂、高风险、关键问题的理解，等等。软件架构很重要 。
大型预先设计通常涵盖了这些对架构的顾虑，但往往想得太多。有一个技巧来区分哪些是重要的：定义一个高层次结构，设定愿景，这很重要；在开始编码之前，绘制无数个类的详图，则多半不重要。搞清楚如何解决怪异的性能需求很重要，搞清楚每个数据库字段的长度就不太重要。
敏捷和架构并不冲突。与其盲目听从别人的指点，软件团队更应剔除炒作，理解技术领导力的方式 ，在其独特的环境下量化所需的预先设计 。
考虑架构的驱动力不需要花很长时间，却能为软件设计的其他部分提供一个开始。当然，这并不意味着架构不应该更改，特别是当你开始编写代码、获得反馈后。关键在于你现在有了一个框架和一定的工作范围，能为团队提供一些经常需要的愿景和指导。我的经验是小方向有大用场。