让敏捷方法和企业架构和谐共舞

作者 Amr Elssamadisy译者 孙向晖 发布于 2007年9月6日 上午12时48分

社区

Architecture,

Agile,

SOA

主题

企业级敏捷,

企业架构

标签

业务架构,

最佳实践,

业务/IT整合

一份来自Cutter Consortium的报告向我们提出了这样一个问题：“敏捷方法和企业架构兼容吗？”并且也给出了这样一个答案：“是的，但需要付出努力”。该报告的作者推荐运用特殊技巧以允许敏捷方法和企业架构互相受益。此外，他们的观察结果、分析和建议也直接是适用于敏捷方法和“面向服务的架构SOA”之间的结合。

企业架构(EA)和敏捷方法(AM)拥有共同的目标——交付能够跟业务需要对齐的软件，并响应对这些业务需要无可避免的变更。然而，EA和AM在达成这个目标时却采用了截然不同的方式。在报告中，对EA和AM定义如下：

EA处理如下的企业级问题：

• 通过提供一个整体的业务过程蓝图将业务策略连接到IT系统，蓝图可以映射到架构模式、核心服务和应用兼容性等方面。
• 通过维护一个当前的数据模式(schemas)、过程流和服务定义等内容的详细目录来改进贯穿于整个企业的一致性
• 通过减少系统间的冗余以及标识可以统一的组件和系统来改进操作效率
• 确保灵活的IT能力，能够响应技术厂商以及新的或者增强性的业务流程自动化的变化
• 通过维护IT 组合（portfolio）、当前和目标架构以及迁移路线图来支持项目成本化和优先级划分
• 为正在进行中的操作和系统开发提供一个稳定的、可信赖的基础设施平台和公用服务

敏捷方法关注于以下观念：

• 改进效率：关注于近期的问题，仅开发能够满足当前需要的的部分，允许以后形成设计
• 改进项目可见的可管理性：关注于允许任务的完成能被有效评估的短期的、迭代的开发周期
• 通过提供一个完整的过程，关注于广泛的自动化测试、尽可能早并且经常解决集成问题、允许多个（缺少丰富经验的）开发人员在共同的代码上开展工作以及从最终用户处得到持续反馈等方式来改进质量。
• 通过建立在持续重构过程上的集成来改进（内部质量的）可维护性
• 改进处理变更的能力：它是一个需求变更、一个澄清、一个新的需要优先处理的特性？通过综合客户反馈计划迭代内容。
• 通过隐式知识的使用、共享的团队空间以及关注问题的小的组成部分来改进交流效果。

我们会先从EA的视角来检验AM然后反过来检验以分析EA和AM之间的鸿沟。从EA的视角来看：

• 敏捷迭代提出的使用一到六个周的时间盒来构建一个可运行的部分系统的要求，很少得到采纳。当在一个迭代发生时尝试EA时，常常会割裂时间盒——在这个周期结束时并没有得到可工作的软件。
• 在一个典型的敏捷项目中，当系统的设计激增时，采用演进的设计、有机的增量的方式风险很大，可能会导致冗余和不同应用间的不兼容性。EA组希望引领设计和推荐的公用基础设施组件、数据库模式定义等……
• 敏捷非常依赖于可执行的的工件，例如：编写好的测试（不管是单元测试还是系统测试）。EA的工件不是可以测试的。它们限制了项目的影响范围，因为他们没有反馈环——当没有遵照设计时，不会给出警告。
• 敏捷提倡的客户作为团队成员是不能被承认的。EA组中不会存在任何一个客户，但是它有一个从IT到运营到开发团队到最终用户的间接的大型的广泛客户群。

从AM的视角看，EA也不是非常有意义的：

• EA关注于对齐IT系统和业务策略。一个映射了从现在到将来系统的计划被开发出来，然后落到一个独立的项目中。使用了AM的团队可能会使用此类文档中的信息，但当这些文档到达团队时它们已经失去了上下文环境，会变得难以理解。而且，文档是可测试的。不能接触现实状况，这也是EA团队被视作“象牙塔”架构的一个主要原因。
• 为了减少冗余并增进一致性，EA组会针对如何构建应用而产出参考架构、推荐框架、发布指南。AM团队将这些决定看做是单个项目的领域，不会由未在”前线“上的人来口述。
• EA也关注于企业内不同应用的集成。同样，EA组推荐使用参考架构和框架的特定方案。许多的AM团队任务这些决定的是不成熟的甚至是毫无根据的。
• 最后，EA方法通过考虑了将来的设计（例如建立抽象来轻松应变）的方式来应对变更。AM团队将此方式视为是不成熟的，认为是典型的庞大的预先设计（BDUF）。实践AM的团队宁愿迟些使用抽象，通过重构并依赖于自动化测试来允许变更。

报告的标题确实说：“是的，但需要付出努力”，所以仍然还有希望。但需要EA组和AM项目认识到对方有价值的贡献，并在他们的工作中做出适应性调整。EA组和AM团队可以相互得到以下收益:

• 一个AM团队应该认识到虽然参考架构和框架可能是一个项目级别的BDUF，但在企业中需要重复做，而且耗费好多。如果已经建立好了就没有理由再发明轮子了。
• EA团队应该保证信息在正确的范围内以正确的方式可提供。例如，创建的工件应该努力与每个项目创建的工件相关。
• EA组应该考虑将客户和他们的指南视为是一类需求。
• 每个AM项目的架构应该与架构组进行联络
• 努力将AM项目范围内的重构变成是企业级的。
• 应该建立可测试的EA工具
  
  • 标准的基础设施和平台配置
  • 数据模式
  • 服务 
  • 参考架构
  • 业务流程模型
• EA应该确保企业级的“上下文”应该是随时间流逝而分段的，以解决AM团队关于BDUF的质疑。
• EA应该与项目的生命周期有关。
• 信息流应该是双向通道，当AM团队在参考架构或者框架的瑕疵或者不足时，他们需要一种执行变更的方式，这个变更也应该有方式返回到EA组。例如，EA的过程应该支持企业服务的增强。
• AM团队可以尽可能去影响企业架构
• 企业内的测试环境应该增进一致性、重用并启用集成。AM团队是编写测试的专家，他们应该进行均衡。EA工件应该尽可能变得可执行。

InfoQ同报告的两位作者（Michael Rosen和Jim Watson）就该专题的内容以及导致他们给出的推荐方案的客户经验等方面进行了交谈。Jim Watson描述了最场景的场景：

一个曾经使用过其中一种但因为缺乏对另一个的使用而失败了的项目会最大程度拥有使用两者的经验。例如，一个重要的文档处理系统可以使用最好的AM实践开发出来，但不能协调好系统的EA需要如跨越需求、接口、和操作性问题等。作为选择，一个采用瀑布方式的项目会准备妥当它的所有的企业架构，但是却不能向及早的向客户展现它的价值，或者不能够通过有意义的迭代来解决风险问题。所以，这些paper都是来自于经验的，例如：项目是如何因为忽略了其他可行的规程才陷入这种境地的，有效的处理方式是什么等。

一个意义更加深远的案例可能是在项目启动时均衡EA和AM。 然而，这其实非常难，很少发生，主要是因为组织性问题，以及谁在过程的哪个部分被涉及的角度。你会看到很多的失败，例如架构师跟客户（更惨的是在根本没有客户）但没有开发团队参与的情况下整理需求，然后开发团队脱离开架构师进行接管。

Jim Watson和Michael Rosen告诉我们，关于这个专题的范围，SOA可以被看作是EA的一个实例。因此这里所有相关的问题和解决方案适用于采用了SOA并存在AM团队的组织(无需惊讶，这与InfoQ上的文章SOA和敏捷：是朋友？还是敌人？相吻合)

EA和AM的交互并不依赖于SOA，但值得注意的是SOA提供了相互的兴趣和问题以允许进程一起使用EA和AM。例如，想在一个SOA主导的项目定义真正有用的业务级别的服务可能具有难度，一个缺乏AM开发实践的由EA主导的SOA会产生许多的SOA shelfware，因为它很难实现或者仅仅定义出不是真正需要的接口。

一个推荐的方案是， 对一个AM团队而言它被当作架构的一个包含部分，作为每个团队的成员与EA组进行联络。当被要求阐明推荐Architect Reloadus 或是 Architect Oryzus（其定义见Martin Fowler的Who Needs an Architect? ）中的哪种架构类型时，Michael Rosen建议哪种也不采用。在大的组织中会拥有重要的EA组，一个典型的IT组可能拥有2000个员工，500个架构性的重大项目，在EA组中只有70个架构师。没有足够的架构时可供应因此Architect Oryzus很难应用。Architect Reloadus同样不能得到应用，因为它们没有可实施的环境。有效的架构师的使用方式是作为一个单独的AM团队的咨询顾问，这样，一个来自EA组的架构师就可以发挥效用而不是嵌入到团队中。

所以，拥有EA组和AM团队的组织不必要互相容忍，虽然他们拥有共同的目标，他们的缺省操作模式是不与其它成对的并且（成对使用通常会）产生问题。因此这些实践等对达成企业的战略目标和交付战术性的软件项目非常有用。

最后，完整的报告可以从http://www.cutter.com/events/multimedia/agilemethods.html 处下载，在页面的底部还包括推广报告所用的代码。

查看英文原文：Making Agile Methods and Enterprise Architecture Play Nice

---

译者简介：孙向晖，儿子小名“豆豆”，常被人称为“豆豆他爹”。1998年开始步入IT行业，现任浪潮软件质保中心副主任。专注于研究和实践MDA/UP/UML/SCM等相关技术在团队中的大规模应用，对产品化的软件项目管理、需求管理和配置管理略有心得。他的博客为http://blog.csdn.net/xiaosun/。参与InfoQ中文站内容建设，请邮件至china-editorial[at]infoq.com。

• 更早的 >