行业分析师 Neil Ward-Dutton，著文表示业务流程管理(BPM) 与面向服务的架构(SOA) 的组合被看作是技术互补的。 关于这两个概念如何交互有着不同的观点。然而，作者坚持这两者有着足够的协同作用来增加业务价值。
Neil 探讨了为什么将 BPM 和 SOA 结合起来这一想法会让业界倾向于认为这两者是互补的技术的原因。
1. BPEL 在主流软件产品中的采纳。在 2004 到 2005 年，向追求 SOA 项目的客户出售新的中间件产品的供应商开始提供 […] 跨越多个外部服务引擎的多步逻辑流 [以及] 实现一个被称为业务流程执行语言 (BPEL) 的标准；对于“业务流程”这一术语的重载使用引起了很多评论者将 SOA 与 BPM 的主题混合起来。
2. 产品对于技术买家具有吸引力的软件供应商正在找寻一种对于业务领袖的销售办法。将他们的新技术能力加上“BPM”的标记被视为一种绝佳的方式 [来销售给业务用户，除传统的技术买家以外。]
3. BPM 技术产品利用了 Web 服务。与此同时，一组初创软件供应商正在推销一种新的为 BPM 项目专门构建的软件平台类型，被称为业务流程管理系统 (BPMS)[…] 对于 SOA 的兴趣正在快速的传播开 [因此] 这些供应商在新的 Web 服务协议基础之上来“开放”其产品，以便于消费者能将新的自动流程与现有的后端应用，系统及数据源进行集成，就有其一定的意义了。
他相信这两者实际上是对于 SOA 不同视角的结果，自底向上的方式，这主要是 IT 驱动的，以及 BPM，自顶向下，这主要是业务驱动的。他将从这两种方案的协作实现价值的失败归因于其发起者的驱动力利益是相背的。
- 在 BPM 的实现中没能有效地利用“集成服务”。
- 没有能够考虑到流程重用的机会。
- 没有能够将信息架构的价值资本化。在 SOA 实现当中，“公共信息模型”的定义，对于把当服务在不同的环境被组合和重组合的时候所必须执行的信息流之间的翻译的数量降到最小是至关重要的。
Neil 提倡在设计业务流程及它们的支持服务时，为业务架构和技术架构两者都创建一个“服务上下文”。纯粹业务驱动的服务设计在重用，以及有效的使用资源和信息方面可能并非是最佳的。对于完全 IT 驱动的服务而言也是一样的道理，对于参与编配的服务流程而言也许没有特别地良好设计。
在一个业务架构驱动的 SOA 中，一个服务组合并非是仅仅根据关注现有的软件应用和资源是如何能更有效的被暴露而达到重用来创建的。一个同等重要的起点是对于一个组织对于外界实体作出的高层次的业务服务承诺的理解 […]。运作于不同的粒度和抽象层次之上的服务模型分解了这些顶层的业务服务承诺，并将服务承诺的需求通告给一个组织及其系统的不同层次。
就像他之前所概括的那样，“其本质是 * 结果 * 第一，而服务和流程对于达到正确的结果而言，不过是同一枚硬币的两面罢了。”，他鼓励这些项目的驱动者，开拓他们的视角，全盘的设计他们的系统以同时满足 IT 和业务两者的需要。
当你看待如何结合 BPM 与 SOA 项目时，不要仅仅关注在明显的集成实现方面。如果你能开拓你的视野而看到 BPM 与 SOA 如何适应于一个更宽阔的业务架构视角，更深刻的关系与机会会变得更加明显。
评论