让SOA更直观
模型驱动SOA采用了产业标准方法和语言对组合应用进行直观的描述和管理，从而构成能在整个应用与相关技术性服务的开发周期中引入规范化并逐渐发展自动化的SOA方案。建模使业务架构设计人员、方案设计人员和开发人员能在更高的层次上工作，并通过图形分析和自动检测在整个开发周期中引入质量保证技术。这种更高层次的抽象可以抛弃细节问题，让用户根据所需的用例和功能发表自己独特的观点、集中精力考虑应用所需提供的方案而无需担心如何构建应用。用户可以通过模拟分析并测试既定设计方案的正确性和效率，从而验证方案与用户需求的一致性。
这种SOA开发中的建模方法能使用户在开发的各个阶段（从架构到最终部署）不断检验错误和测试一致性，因此既能保证质量又能保证更低的成本。通过暴露组件及其接口，并对现有软件进行架构上的逆向开发以重用或重新部署服务、创建SOA接口升级遗留服务、改善现有组件之间的编排机制，它使分布式的网络型应用能够发挥最大的效率。还有一种优势，可能也是最重要的，就是这种基于模型的方法使开发人员能够在进行真正的升级之前模拟并测试对当前应用所做的改变，为用户节省昂贵的检修时间，并避免用户遇到因使用未经过检测的应用升级而带来的风险。
使方案规范化
企业架构与SOA应用开发环境结合得越紧密越好。在最理想的情况下，企业在这两者之间应该实现无缝连接，甚至还能支持相关的技术，比如要求管理和变更管理。而目标则应该是实现空前的企业范围的协作，使内部团队能够明白并整理业务战略并开发能够实现商业目标的IT方案。
换句话说，这就是从概念到部署、连续的、具有端对端可跟踪性和可靠性的工作流程，保证各个利益相关人随时都能正确地读取数据或使用相关技术。由于商业案例驱动着需求，而需求驱动着应用开发，因此需求管理实际上贯穿着整个过程。（下文是关于需求管理在整个项目周期中作用的论述）
业界有关研究表明，拙劣的需求实践是导致项目失败的最大原因。相反，优秀的需求实践又是项目成功的主要原因。需求过程并不是项目生命周期中的一个一次性的预先执行的步骤。需求贯穿着所有具有共同目标的开发规则、质量保证；并且，需求还能提供开发团队与客户之间的合约。
由于应用开发越来越复杂，要清晰地描述应用的要求也变得越来越困难，而要理解这些描述更是难上加难。许多架构师采用了全面的过程与方法论使需求管理与应用建模能够互相提供必需的信息。这种协作过程使架构师们既能描述问题与解决方案，同时还能跟上在这个过程中所做的决策。
要保证优秀的需求管理和项目成功，一个办法是采用正式的需求管理方案。这样可以提高业务方针、客户需求、技术细节和政策的可视性。由于强有力的采集、关联、分析、根据需求管理变更和追踪能力，这些方案保证了与需求的一致性，并保证符合相关政策与标准。最重要的是，它们能够自动将这些基于同一目标的开发规范和质量保证结合到一起。
比如，建模与支持企业架构、业务过程分析、SOA应用开发和需求管理的产品的无缝集成就可以实现这种工作流程。集成的方案以一种可以被所有利益相关人理解的方式，为每个利益相关人提供了交流与检查新的或更新的商业战略、实现理念与变更的渠道。影响分析可以在整个企业中进行，让所有利益相关人都可以在制定最终决策并实施之前评估可能发生的变化。
从高层的业务应用与服务编排，到技术服务用途的复合应用的设计与编排，几乎在所有的层次都可以描述、分析、测试并开发SOA的概念、设计与部署。在各个层次对设计进行模拟与测试很重要，而通过设计模型则可以把实际的Web服务当做模拟的一部分来调用并执行。
在设计可部署的组合应用的时候，开发团队就可以在SOA建模环境中测试应用的完整性，利用测试模型获得所缺少的服务的细节与设计的基本信息，并决定应应该从第三方购买这些缺少的服务或是根据设计模型提供的信息进行开发。
采用模型驱动SOA
面向服务架构（SOA）作为一种实现基于组合应用开发的企业方法论获得越来越多的赞同。为了发挥最大效率，这种SOA方案既需要一个明确的定义，也需要与业务和设计保持同步。
一个规范的基于模型的SOA方案，一经验证可以填补业务与IT之间的空隙，就可以使企业合理地部署并管理SOA环境。然后，SOA就能成为高效的业务语言，有效地管理并规划所部署的应用的复杂性。建模可以直观地表示出高层次的业务方针与各种服务的具体功能之间的关系，方便各种各样的用来实现业务目标与设计目标的应用的构建与维护。
这项技术的前景怎样呢？跟以往一样，预测某项具体的技术将来会有什么样的发展是一件很困难的事。然而，我们可以预计，随着企业逐渐体会到SOA的强大、接受SOA带来的敏捷性与灵活性，并且能够承担随后带来的责任，越多越多优秀的过程与非常好的实践也必然会随之涌现。模型驱动的SOA由于能直观地表示企业在业务与技术方面的情况，从而能够保证企业操作跟得上商业环境的变化。
