敏捷开发过程迫使组织改变实现企业架构的方式。旧的搭建精细模型以及技术抉择已经不再适合于今天灵活、快速的开发环境。尽管为了能够与开发者一起工作，架构师仍必须学习一组新的最佳实践，需经历成长的阵痛，但变化最终也许并非坏事。

“企业架构团队以协作、轻量的方式工作似乎与成功有一定的联系。不按这种方式工作的团队未来的失败率要高得多，”总部位于多伦多的Scott Ambler +协会的资深咨询合伙人Scott Ambler如是说。

那么以轻量化的方式工作又是什么意思呢？“他们不会弄出一堆的文档或模型，因为细节的人工品会为开发者所忽略，如果说他们还打算看的话。他们在帮助团队理解架构型的愿景如何，并积极地帮助构建此愿景，”Ambler说。

企业架构最佳实践及好处

IBM Rational的资深管理顾问Scott McBride对此表示同意，他指出了记住要有一个战略游戏计划的重要性。“要想把EA（企业架构）搞砸，最可靠的方式就是架构师埋头苦干数月做出一个庞大的计划，然后折腾出一堆没人懂也没人用的模型。”

还有一些其他的通用技术和企业架构最佳实践也应该部署。Matt Brasier，总部位于英国Worcestershire的咨询公司C2B2 Consulting Limited的咨询负责人的观点是团队工作是这一切的基础之一。

“架构师的关键最佳实践是聚焦于架构性原则并确保团队的所有人—包括业务端、开发者、实施团队都理解需要记住有一套原则，并知道为什么自己在这里，这样大家才能买账，”Brasier说。

一旦大家看到了吸收企业架构最佳实践的价值，McBride说他们就更愿意去遵从。“我们现在处于EA 2.0，我们也从错误中学到了东西。原则还是一样，但是我们已经从软件开发中学到了东西—比方说，快速开发，然后不断地开发、测试，周而复始，”他说：“在EA中，快速地构建EA块，然后就其进行沟通、测试并获得反馈。”

Maja Tibbling是总部位于波特兰的Con-Way有限公司的首席企业架构师，他同意说遵守特定规则具有显著的好处。“每一项敏捷行动所需输入的一部分包括架构性原则、指南及规范，以及用于发现哪些现有东西可重用的发现工具，”她说。当然，这需要强有力的、包含有利用社交网络及获得反馈在内的沟通计划。

仅仅就企业架构最佳实践进行沟通并预期开发者严格遵守是不够的。既然敏捷方法论支持变更需求，架构性需求也必须演进。“需要让开发团队自己做出一些决定，然后标识出哪些与架构性决定是不相符的，”Brasier说。

敏捷开发建议

让架构师与开发团队紧密配合对于促进架构原则的引入及控制变更也是有帮助的。财产及意外索赔管理技术提供商Mitchell International的资深企业架构总监Fred Albert说，他的10人架构师团队直接参与到每一支Scrum团队中，并提供技术咨询及设计和审核的能力。“那不是象牙塔式的架构，那种情况下往往采用的是更加瀑布式的办法，”他说：“架构师嵌入到团队中，聚集于在即时设计中予以支持。”

这就回到了Ambler的建议上，即与开发团队并肩工作。“通过卷起袖子帮助团队工作，团队利用企业架构师努力推出的东西的机会就会大得多，”他说。

尽管为了适应敏捷开发团队，大多数企业架构最佳实践把改变工作风格的责任放在了架构师身上，但担子也不能让他们全背了。开发者可以通过直面需求来分担。

比方说，Brasier建议，在没有东西交付给最终用户期间每四次迭代专门为架构债务腾出一段时间。“用一段迭代致力于减少技术债务并满足国内需求，”他说。

这给了开发团队处理那些可能没有处于最佳工作方式或未遵循架构性原则的组件的机会。“这相当有效，因为这对架构性需求及非功能性需求，以及哪些那么会错失的东西赋予了强烈的关注，” Brasier说。

Tibbling说她的组织采取了类似的办法。“在Con-way……我们用迭代0来处理任何重大或变更过的架构性需求。在此迭代期间，需要更多时间的技术验证（technical spike）会被识别出来并在迭代计划中加以适应，”她说：“一次技术验证可能包括了新技术的引入，数据移植等等。”