SOA应用生命周期管理(ALM)时代已经到来，它必须反映这样的事实：现代应用程序逐渐由重用组件和重新编排工作流而组成。当一个组件发生变化，它可能会影响六个应用程序。改变组件行为的应用程序变化同样能够从应用程序边界扩展到意想不到的区域。

软件架构师必须考虑部署和调整，甚至测试和规范环节也完全不同于面向服务架构(SOA)。尽管有这种需求，大多数架构师还是认为组织还没有实现完全过渡。二维视图的应用程序和组件优化工具的选择使SOA ALM需要达到能够面向未来云计算的状态。

创造有意义的SOA ALM流程

任何有意义的SOA ALM流程起点都是一个连接组件与应用程序的机制。虽然SOA需要一些目录功能支持工作流组件之间的连接，但不强制这些连接返回到应用程序，然后到达它们支持的业务流程中。

像IBM、Microsoft和Oracle这样能够提供整套SOA开发/部署的供应商，针对这种追踪具备了组件库存记录功能和机制。创造自有ALM工具包的公司要考虑如何处理好业务-应用程序-组件间的映射关系，特别要考虑，它是否能支持追踪组件变化对应用程序和业务流程的影响。

这样做的目的是要确定组件变化的影响范围，考虑组件化应用程序的相互影响。现代SOA ALM流程中，其目标是通过所有这些影响的区域来追踪业务实践、应用程序或组件中的变化——“一维”变更管理。

测量变化范围

“第二维度”的关键是检查受主要变化影响的其他应用程序和区域。实际上，要建立一个业务实践、应用程序和组件之间的关系矩阵，画一个影响图明确变化所造成的影响可能传递的范围。这就成为ALM流程的范围。

多维影响矩阵中最容易被忽略的元素是业务流程元素。应用程序组件的变化可能会影响该组件如何被使用的，不仅在该应用程序中可能会发生变化，在其他应用程序中组件也会出现调整。软件架构师称，连接正式的企业架构(EA)业务流程图和软件组件之间存在一个问题。

所有主要的SOA套件供应商在结合EA方法(TOGAF、FEA、Zachman、Gartner等)和SOA开发时都会提供实践提示，但很少有具体的工具来支持这样的连接。这可能迫使建筑师(包括EA和应用程序)围绕软件和需求文档工具来组织实践。

开放团体提供了整合EA和SOA的实践管理措施，但这些更关注的是设计而不是整个生命周期。然而，将业务实践连接到SOA设计（在SOA中创建“服务”功能）中的适当EA框架会允许软件架构师将组件-应用程序矩阵轻松地扩展到业务流程维度上，实际上，这可能是创建可靠连接的唯一方法。

组织一个ALM流程

一旦应用程序架构师创建了一个矩阵，该矩阵可以识别由于SOA组件/应用程序中发生的特定改变而受影响的区域，下一步是相应地组织ALM流程。如何能以最佳的方式来完成任务主要取决于应用程序是如何相互依存的。

如果组件重用能够常见，业务流程影响得到流传，最好的方法是放弃单个应用程序ALM，而考虑整体的SOA-ALM组合。如果你所绘制出来的影响图总是显示所有事情都是被影响的，那么你会知道事实就是这样。

正常情况下，SOA应用程序和组件的变化通常会蔓延到仅仅几个相关的应用程序。在这样情况下，最好的方法就是针对受影响的应用程序直接启动ALM流程，测试阶段，聚合活动以确保没有重复或错过的元素出现。

管理ALM流程

管理一系列由于共享元素变化而启动的ALM流程，架构师报告说传统的项目管理工具是一个好的开始。多数情况下，ALM流程是被一组工具支持的实践文档而定义。

所需要做的是要将其聚合到适合的位置上（通常是试点测试,接触的往往是实际用户），并确保特定的测试数据和需求在那个阶段上聚合。ALM周期的其余部分会继续在合并后的需求集中运行，有效地将所有受影响的应用程序处理为一个独立的应用程序。

企业建议，针对这种聚合式ALM收益，它可以通过所有应用程序或者至少是相关应用程序组，来协调测试数据和实践而生成指标，这种做法是明智的。如果三个应用程序共享组件，拥有一个共同的测试框架将需要在给定应用程序不受影响的情况下忽略一些测试。如果正确组织和记录测试，通常就不会有什么困难出现。

企业报导称，甚至对组件重用进行谨慎的审计也能漏掉应用程序间的相互依赖关系。将全套的相关应用程序测试作为ALM确认的最后阶段，可以被视为规避问题的最后一个检查点。

SOA ALM和云计算

云计算的发展很有可能促进应用程序的组件化、允许组件复制、提高组件性能、促进工作者支持的定制和确保效益最大化。甚至在跨越公司界限的混合云关系下，它也可能促进组件的重用频率。让SOA ALM步入正轨是准备部署未来云计算中的一项艰巨任务。