作为近些年来越来越得到关注的一项技术，业务流程管理（Business Process Management，BPM）如今显得酷似发展势头越来越猛的另一项技术：面向服务的架构（Service-oriented Architecture，SOA）。而这种相似之处使得一些CIO一齐运用这两项技术：使用SOA方法作为交付平台、使用BPM方法作为“业务智能”平台。

　　BPM和SOA都要求你安排好业务流程，并且弄清楚它们应当如何与对方，或者其他应用及数据源进行交互。有分析师说：“你不可能实施没有业务流程的SOA.”不过许多公司还是把两者人为地分开来，认为服务只是IT功能，认为业务流程只是业务工作流功能。

　　但BPM应当成为SOA的中心编制机制，这是因为BPM本身就是面向流程的。SOA通常使用的编程机制――通过企业服务总线（Enterprise Service Bus，ESB）进行消息传递――却不是面向流程的。

　　BPM将会成为SOA最重要的一个部分，原因就在于它让你在需求变化时可以组合服务。

　　西诺乌斯金融公司就是这种情况，这家金融服务联合大企业为美国东南部的客户提供服务。三年前，公司的首席技术官John Woolbright开始探究SOA概念，让他动心的是SOA的这种功能：可以减少要开发及管理的软件资产数量，另外由于能够组合核心服务，而不是针对不同的变化情况重新创建服务，因而增强了提供新服务方面的灵活性。但厂商们提供的SOA方案都以基础架构为重心，漏掉了对Woolbright来说却很关键的部分：服务执行的业务流程。

　　他说：“我们从业务流程开始着手，然后试图改变IT工具和技术，以便支持业务流程。”

　　于是Woolbright引入了Active Endpoints公司的BPM工具，对业务流程进行定义及建模，然后让BPM工具充当编制工具，以便管理执行流程的SOA服务。实际上，BPM工具成了西诺乌斯金融公司服务架构中的编程层。“我们使用SOA技术来获得通用的数据和呈现模型，以便能够构建执行业务流程的应用。”

　　Woolbright还决定不投资于企业服务总线（ESB），这是大多数SOA厂商大力拥护的技术平台。他问道：“我们已经针对大多数ESB层实施了相应技术，譬如安全和数据转换；还引入BPM作为业务编程层，那么为什么要更换这一切呢？”

　　Woolbright当时还担心这一点：ESB的编制方法只是致力于服务之间的消息传递管理，而不是致力于业务流程本身。他说，而任何应用项目最终的重点却需要放在这些业务流程上。 他指出，充当编制层的 BPM工具在服务执行如何影响业务流程方面提供了更大的控制度和洞察力。这是因为，业务环境关注的是业务流程本身及它们执行的任务，譬如开设客户帐户或者执行信用检查。

　　西诺乌斯金融公司同时发现了SOA和BPM的优点，所以它能够在两方面都关注的情况下开发架构——但这种情况并不常见。许多企业实施的BPM项目和SOA项目是各自独立的，所以需要同时开展BPM和SOA这两个项目，而不是一下子即可改造公司。正如SOA是通过好多步骤才能实现的长远目标，部署极广泛的BPM也是如此。

　　企业首先要为独立的流程部署BPM，正如许多企业首先把SOA部署在特定的项目里面那样。而在这两种情况下，它们会与ERP和CRM等应用系统进行交互，对它们之间的流程进行协调，并且与其他应用系统进行交互。因而，BPM交付的流程和SOA服务最初会以事先确定的方式来联系组件，被称之为“A-to-B-to-C”方式。但如果企业已经定义好了同时面向流程和服务的一种架构，它就能够根据需要改变联系，以支持新的需求或者出现变化的需求。到某个阶段，作为配置上的变化，也许有人会采用A-to-C-to-B的联系方式。

　　摩托罗拉是预期进行这种SOA与BPM融合的一家企业。摩托罗拉负责企业平台的高级主管Charles Soto说：“我们把BPM工具与系统系列架构结合起来，这定义了我们公司的蓝图。毕竟，它们都是同一概念——业务模块化（business modularity）的延伸。”

　　企业架构同时面向业务流程和软件服务，而不是单单关注其中的一个方面。而采用企业应用集成（Enterprise Application Integration，EAI）方法的企业尤其需要这样的宏观视野，EAI这种方法完全致力于软件的交互关系，而不管它们为之服务的业务流程如何。

　　作为围绕跨不同技术平台交付流程的一种架构方法，SOA自然符合IT集成方法。而宏观的SOA方法也自然符合业务流程协调，从而填补这种空缺。有了真正的SOA，再也不会出现BPM/EAI对立的情形。