参与紧密的协作

　　他不会单独完成设计和技术上的决策；这些决策是与团队共同协作完成的。他拥有开放的心态，并且坚定认为自己不是全知全能的万事通，而且不会对自己的主意保有盲目的保守心态。当团队坐在一起进行头脑风暴时，就会产生最好的主意；任何人都可能提供好的想法和有价值的见识。开放和诚实的沟通可以帮助人们基于更好的信息做出更好的决策。敏捷架构师是一个善于与人打交道的人，他对任何人都充满敬意，并且会利用每一个机会向别人学习。他会促进共识的形成，并欢迎团队中每一个人为解决方案做出贡献。

　　如果业务发起者在解释完项目的目标之后，架构师马上就可以提出一个解决方案，那么这个架构师也许不是一个真正的架构师。

　　做坚定的指导者

　　他经常与团队一起工作，来提升团队的决策制定能力。根本上，这可以帮助架构师更好地利用大家的智慧，而不是成为项目中单一的决策制定者。通过指导团队使用新的技术、为技术架构构建并提供支持，他与团队可以更好地形成协作与互利关系。他可以确保团队不会因为缺少某些经验或是对某些技术感到不适而简单地拒绝一种设计方案。如果真的发生了类似情况，他会为团队弥补中间的隔阂，从而让大家可以做出更加明智的决策。

　　正如Martin Fowler 指出：“这指出了如下这条基本原则：一个架构师的价值与其所做出的决策数目成反比。”

　　做熟练的协调者

　　敏捷团队中包括技能熟练、富有激情的团队成员。对于设计决策、实现功能的最佳方式、开发流程的改进措施，团队中经常会出现不同意见。还会带来激烈的争吵，如果不能迅速妥善处理，会影响成员之间彼此的感情。这些场合下，团队成员需要一个拥有丰富经验、足够成熟、并且见多识广的调解人，来帮助团队打破僵局，重新和谐。而敏捷架构师由于其成熟的水平和经验就成为了不二之选。

　　不做大型的预先建模

　　通常他不会使用重型的CASE 工具来做大型的建模设计和决策。一般来说，所有的建模都是“足够”的建模，并且是在白板上完成的。简单的模型会随着每个迭代慢慢成长、逐步改进。他会跟随敏捷建模的概念，对他来说“代码就是模型”。如果需要为了文档生成模型，那么这些模型也是通过一种合适的逆向工程工具从代码生成的。

　　模型、文档、沟通的方式会以尽可能简洁扼要的方式保存。关键是要将注意力放在内容上，而不是展现或其他为了看起来好看而作的事情，这些东西并不能添加多少业务价值。

　　寻找大规模重构的机会

　　他总是在注意观察可能成为严重技术障碍、损害项目架构的问题。随着系统的成长，他确保架构可以跟上发展的脚步。他总是在注意观察可以取得更大收效的变革。举例来说，果应用程序没有利用足够的CPU，导致性能低下，那么他可能会试图引入多线程，以使得空闲的资源可以被利用起来提供更好的性能表现。他会首先选择最简单的可用解决方案，下来会经常对其进行重构，以满足变化的质量和功能需求的要求。

　　敏捷架构师同样会帮助切分系统。他会推荐采用“先征服再切分（conquer and divide）”而不是“先切分再征服（divide and conquer）”的方式。最开始时，一个小系统是通过小团队实现的。最终，随着架构师经验的不断丰富，团队会将系统按照自然形成的界线进行切分，并且始终在心中包含有系统的整体概念，而且为系统每个不同的部分增加团队成员。

　　敏捷架构师是万能胶

　　他会在团队成员之间、不同的厂商之间以及利益相关者之间逐步沟通架构、设计决策、任何技术障碍之类的东西，来充当万能胶的角色。他是业务世界和技术世界之间的媒介。他能够在业务上下文中通过技术的角度和问题发现潜藏的业务问题。他能够以业务价值的角度解释当前的采纳技术，让利益相关者明白这些技术的价值所在。例如，他可以使用人员利用率、更快的周转率、节省的资金等业务价值用语，来说明为什么在两种技术中选择其中一种。针对某个项目时，他会同时思考如何回答“为什么”和“怎么做”这两个问题，以回答业务和技术上的疑问。大多数传统的架构师会关注如何实现一个解决方案，而不去思考为什么这个解决方案是最佳的。敏捷架构师会试图与业务人员一起，并找出为什么需要某种特别的解决方案，是否会有比业务人员提出的建议更简单的方式解决手上的问题？

　　最后但并不是最不重要的，敏捷架构师拥抱变化。

　　他拥抱架构和角色上的变化。真如正架构上的敏捷度，是指快速应变而并不损害架构的能力，同时对其他部分的影响尽可能小。要确保这一点，他要从好的设计开始，并让其随着项目的进展而演进。他常常会抽象出通用的元素，并将其封装在稳定的接口之后，因此将变化带来的影响最小化。

　　真正的角色敏捷度是可以扮演多个角色。在一天的工作中，他可能从事程序员、系统测试人员、指导者、协调者、团队成员、万能胶，甚至有可能是管理层等多种角色的工作。

　　结语

　　架构师象牙塔的根基已经被动摇了。新一类的“敏捷架构师”正在逐步涌现出来，并与团队一起工作，为团队做贡献。他们的确是在按照丰田原则【注】的第十二条在生活：“亲临现场查看，通过一手资料来彻底了解情况”。他们是开发团队的第一等公民，而且不只为团队工作，还在团队之中工作。因此，要想成为能够与开发团队共进退的敏捷架构师，成熟、经验以及上述的能力不可或缺。