关于业务流程管理(BPM)和面向服务架构(SOA)之间关系的讨论热闹非凡。二者也是多年来的热门话题，但是关于它们的讨论通常都出现在互不相关的论坛上，讨论它们的人通常也属于不同的圈子。不过现在这种情况正在改变，因为这两个概念以及相关技术的使用者和提供者正日渐将二者结合起来看待。
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才不至于存在于独立的竖井中，这也很重要。
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才不至于存在于独立的竖井中，这也很重要。
