寻找大规模重构的机会

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

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

    敏捷架构师是功能较多胶

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

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

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

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

    结语

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