BPM阵营通常声称，SOA对于实现BPM来说不是必需的。只需部署一个BPM套件，就可以更快地实现目标而不会带来多少复杂性。SOA阵营则注重于如何从一般意义上解决企业IT的复杂性。该阵营通常声称BPM是SOA的一个特性，但是它是SOA解决方案的一部分，而不是一个单独的东西。当SOA领域的人士谈到BPM时，该术语通常与服务编排或流程整合同义，而不强调对业务分析人员友好的建模或人员交互，而后者对BPM阵营来说非常重要。
为了澄清这些误解，我认为有必要阐明BPM与SOA的不同本质:SOA是一种架构方法;BPM则是一组协调活动。
因此，可以很容易地得到使用SOA或不使用SOA的BPM，反之亦然。我们来看看不同组合的优点。
如果部署一个不使用SOA的BPM套件，则可以获得快速创建、执行和监控/管理业务流程的能力。业务流程的模型可以由业务分析人员创建，但是其完整实现则需要与底层IT系统的集成(以及定义用户如何与该流程交互，但是现在我们暂不考虑)。BPM套件(如BEA的AquaLogic BPM Suite)支持使用各种不同的技术(面向服务的或不是面向服务的)对应用程序和数据库进行轻松访问。实现由代码和来自于并依赖于底层系统接口的元数据组成，因此，对底层数据库和应用程序的任何更改都将导致对业务流程的更改。
如果组织和IT环境规模比较小，并且由同样一组人来控制所有的系统(包括BPM套件)的话，这是完全可以的。如果底层系统完全不更改的话，这种方法同样运行良好。
但是，如果BPM套件由一个小组部署，并消费来自另一个小组的系统的服务，那么协调和管理每个小组中的更改的任务很快就会变得非常困难。这是SOA要解决的典型问题，因此，SOA可以应用于BPM套件的部署，就像应用于其它地方一样。
如果BPM作为SOA的一部分进行部署，这意味着当一个业务流程连接到底层系统时，它连接到由企业服务总线所提供的代理服务，这样就隐藏了底层应用程序和数据库的复杂性。这具有以下优点:
将业务流程连接到系统的过程会更简单，因为IT可以公开更有用的接口，比如聚合的数据服务或使用标准协议而不是专有协议的服务。这减少了实现流程所需的IT工作量，并允许流程人员将精力集中于流程，而不是粘合流程与底层系统所需的技术。
它使得实现更为健壮，因为对底层IT系统的更改不必影响流程所使用的接口。
它在BPM套件之外提供了一个独立的控制和管理层。这允许IT小组更好地管理他们所拥有和维护的服务的策略和资源。
SOA还支持从BPM套件中获得对它所连接到的系统的更好可见度。IT小组可以在服务注册库中注册服务，流程开发人员(甚至可能是业务分析师)可以在构建流程时浏览这样的注册库。这确保了服务可以被正确地使用和重用，而且通常简化了业务流程，因为使用正确的服务可以将流程本身的复杂性降至最低。
无疑，这些优点只有在IT基础架构足够复杂，并且/或者BPM项目达到一定的范围和规模时才能显现出来。因此，在很多情况下，应该首先开发出BPM，而将SOA组件留待以后考虑。
最好的方法是一开始就让业务运作团队和IT企业架构小组保持良好的对话，并针对未来进行规划，同时支持战术性执行。这就需要正确地组合产品。例如，BPM套件本身应该能够提供丰富的连通性，以便无需全面应用完善的SOA来使得BPM运行，这一点非常重要。类似地，BPM套件应该支持SOA，这样BPM与SOA才不至于存在于独立的竖井中，这也很重要。
文章来源于领测软件测试网 https://www.ltesting.net/
