可惜，许多团队把“大局”上的技术技能看作一种不必要的邪恶，而不是重要的补充，可能是因为他们过去深受大型预先设计之害。有些人也过于渴望“敏捷”，以至于忽略软件开发流程的其他方面。接踵而至的是混乱而非自组织，这样的团队也面临着需要更直接的领导方式的挑战。毕竟，他们在努力变得敏捷。单个点负责项目的技术层面，也跟他们对敏捷团队的想象相冲突。这种冲突使人认为敏捷和架构是对立的：你只能拥有其中一个。与敏捷对立的不是架构，而是大型预先设计。
敏捷软件项目仍然需要架构，因为那些围绕复杂非功能需求和约束的棘手问题不会消失，只是对架构角色的执行不同。
集体代码所有制，每个人都要能在架构的层次上工作，因此每个人某种程度上都是架构师。还不是自组织阶段的团队如果试图跑太快，就会陷入挣扎。尽管人们的愿望是变得敏捷，集体代码所有制和架构角色的分配都有可能阻碍混乱的团队，而不是帮助他们。混乱的团队需要更直接的领导方式，单个点负责软件项目的技术层面，将使他们受益。换句话说，他们会受益于一个人负责软件架构的角色。理想的话，这个人会指导别人，让他们也能以这个角色产生帮助。
软件架构师要一个还是多个？一个人承担责任还是团队共同分担？不论敏捷与否，软件架构的角色都是存在的。只有所处语境会告诉你正确的答案。