不管是采用自上而下方法的BPM，还是采用自下而上方法的SOA，都无法彻底解决企业面临的诸多问题。因此，迫切需要寻找到能取两者之长的解决方案。
BPM和SOA的关系
自 20 世纪 80 年代末期以来，业务分析师始终在全力以赴地推广业务流程再造 （Business Process Reengineering）这一理念。之所以会出现这样一种趋势，主要是因为业务逻辑已经淹没在功能性的 IT 系统当中不见踪影，导致业务人员完全失去对它们的控制能力。
业务人员希望从业务驱动的角度来做事情，即采用自上而下的方式，在设计业务流程时先不与 IT 相关联，然后进一步深化到更细粒度的细节内容。直到最近，随着业务流程建模（Business Process Modeling，BPM）工具的出现，业务人员和业务分析师终于将他们的理论落到实处，他们将 BPM工具用做自己的“有力武器”，希望由此夺回对流程的控制权。
与此同时，在得到绝大多数 IT 人士支持的 SOA 阵营中，大家都坚信 SOA 才是真正能够使 IT 与业务变化保持一致的最佳途径。但SOA 并没有给予业务层面足够的重视，而是将工作重点过多地放在解决 IT 和集成挑战这类问题上。因此，绝大多数 SOA 工具和方法论仍旧只是停留在相对自下而上方法的水平。
由此可见，BPM和SOA分属不同的领域和不同层面，BPM在业务和管理层面，通过流程定义和建模，从而实现业务和管理的流程化。流程的实现过程不光需要IT，更需要人的参与，因此实现的成功与否和每个员工的配合程度有很大的关系。从这层意义上看，BPM和企业实施的ERP、OA、Portal等系统非常类似。
虽然BPM与OA有着本质的不同，但又有着千丝万缕的联系。
1. 经过BPM改造过的各业务系统仍然彼此相互独立地存在，SOA作为面向服务的IT架构方式可以不依赖这些业务系统，通过将各业务系统服务化（Service Enable）来消除“信息孤岛”，从而实现各业务系统之间的信息和业务逻辑的共享；
2. BPM通过组合单独业务和流程实现复杂的业务应用，而这些业务功能和流程同样可通过SOA使其服务化，把业务流程变成独立于应用程序及其运行平台的可复用组件；
3. 对于实现BPM来说，SOA虽然不是必需的，但由于BPM工具不能真正将变化的流程图与实际的IT系统有机地联系在一起，无法在足够深的层面确保底层的 IT 系统能够根据业务的变化随机应变；因此，目前能使BPM很好落地的技术还离不开SOA。
既然BPM和SOA有这么多联系，而且不管是自上而下方法的BPM，还是自下而上方法的SOA，都无法彻底解决企业面临的诸多问题。因此，我们很自然地寻找能取两者之长的解决方案。
设想一下，如同设计建筑物的体系结构一样，我们可以使用BPM工具来设计业务流程，然后将它分割成为相对较大的各部分（自上而下）。接下来，轮到 IT 通过使用砖块（自下而上）的方法来构建这些大块的组成部分。不过，问题在于单靠砖块可能无法修建出建筑物所需的形状，我们还需要用做粘合剂的“水泥”，由此将基础的砖块塑造成所需的形状。