不同于典型的软件开发者，软件架构角色 需要通才。这肯定是在软件项目起航阶段掌舵的角色，包括管理非功能性需求，整理出对上下文和环境因素敏感的软件设计。但也要不断地转向，因为你选择的航线可能需要在途中调整。毕竟，敏捷方法已经向我们展示了，不一定预先就有（或需要）所有的信息。
创建一个最初的愿景，交流，并在整个软件开发的声明周期中潜在地演化它，这些对一个成功的软件项目是必需的。单是这个原因，让某人来创建这个愿景，然后让另一个团队去（试着）交付，就毫无意义。当这种事情发生时，初始的设计方案本质上就成了在架构师和开发团队中传递的指挥棒。这很低效，甚至无效，文档交换也意味着很多与创建愿景相关的决策上下文也丢失了。祈祷开发团队永远不需要问任何关于设计或其意图的问题吧！
真正的自组织团队不会有这样的问题，但大多数团队还没有成熟到那个程度。在整个交付中，要有人负责大局，同时为保证软件顺利交付承担责任。软件开发不是接力运动，顺利交付也不是“实现细节”。