面向服务架构的一大目标就是在面临不断的变化和不一致性时，实现业务灵活性。这里我们所说的不只是让技术更好的合作，而是要保证SOA能够满足业务需要。业务首先通过机构的业务流程反映出来。有些人可能认为SOA是以流程为核心的，但是ZapThink 与终端用户，咨询公司，以及技术供应商并不关注这些业务流程，而是关注底层的技术平台，基于标准的接口，以及系统之间的通信。事实上，有时业务流程往往过于热衷讨论SOA与业务关系。SOA本身和业务无关。但是，如果SOA所产生的一切长期影响和收益，一定和业务有关，并且是由业务所驱动的。

　　许多IT人员无法为SOA投资信号验证一个业务实例。因此在业务试图解决的这些问题之间一定有许多不连贯性，SOA有望解决这些问题。但是并不是所有的IT措施都有实例，事实上，业务流程管理领域（有些人会在BPM上再加上建模和监测），他们在机构中所起到的作用并不大，除非它们能够画出特定的业务流程。但是，那些拥有BPM技术的人不在SOA讨论的重要范围之内，因此，他们的知识以及和业务之间的联系并没有转化为机构的有生力量。那么从事SOA研究人员究竟可以在他们的BPM同事那里学到什么呢，为什么我们必须将BPM研究工作和SOA研究工作分开呢？

　　BPM专家所了解的业务流程知识

　　IT人员过去常常将集成和业务流程分别对待，在信息技术发展过去的三十到四十年里，IT环境变得更为复杂了，似乎要想在相互之间进行通信和交互作用对于IT行业来说也是十分具有挑战性，但是，像企业应用集成 (EAI)抽取转换加载(ETL)以及企业信息集成(EII)之类的技术措施重点关注解决集成问题，不需要通过业务环境证明他们的价值。如果你需要数据在系统A和系统B之间完成这个目标，为什么还要求助集成专家实现这个目标呢？但是，通过关注集成的技术问题，业务就不必重点要求集成技术人员和专家必须要理解业务环境或者业务流程了。

　　当集成还未完成时，业务需要找到能够解决IT领域不断变化的业务需求的方法。BPM的演化彻底将业务请求所用的时间提炼为现实可行的部分。业务流程以模型的方式被展现出来，帮助机构识别如何实现当前流程，并针对流程的变化做出改进。生产力的不断增强是BPM最为主要的价值主张之一。该价值主张可以通过减少小组管理和技术集成方法中设计到部署的时间框架得以实现。成功的BPM要求迅速开发并测试流程模型，建立并部署这些流程的用户接口，然后将这些接口连接到现有的系统当中。

　　BPM小组认为“对于操作业务来说业务流管理是一个自然并且完整的管理方法，操作业务高效灵活，富有创新精神，可以被那些采用原有传统管理方法的组织所接受。”我们会想到两件事，首先，BPM的定义和SOA极为相似，也许将BPM同SOA企业架构相结合就更能得到一个和业务相关的SOA视角和一个基于架构基础之上的BPM视角。事实上，要表现一个业务流程并在模型上快速迭代，会创建一个要求的逻辑，这很像一个自上而下，由模型驱动的方法，这种方法得到了SOA团体的支持。但是企业仍然坚持用自下而上的方式建立服务，他们最先着手建立的服务不是自下而上的业务流程而是底层系统。

　　其次，许多SOA团体的成员从来没有听说过BPM小组，或者见过BPM参与SOA工作，另外，许多BPM会议的主题和SOA会议的主题相同，但是两个会议的听众完全不同。点我们在SOA Box ZapFlash以外的思考中就曾经介绍过。SOA技术和BPM技术之间距离超乎了人们的意料，此外许多精通SOA技术的人并不懂业务流程这门语言，他们缺乏设计业务流程的模型的技巧，并且没有参与过BPM工作，因此不了解众多BPM方法的益处以及容易犯的错误。问题在于传统集成专家和业务流程专家二者之间的分工不同。