为未来巩固 BPM 产品的功能

据 Dennis Byron 最近的一项调查显示，所有 BPM 厂商都同意“业务流程管理（BPM）需要自动化地处理所有类型的业务流程。”工作流与直通式处理之间的区别，互联网与内联网的区别将会消失。这意味着…

[…] 许多传统的 ERP/ECM 供应商为了提供 BPM 功能，已经将他们的工作流和集成特性展示给了所有人，而不仅仅是那些“知情者”。 即使你不购买他们的应用，许多供应商也愿意向你出售这些功能。这种心态变化的最好例子是 SAP 公司。他们作为 ERP 的巨人，认为将 BPM 限制为软件栈的一部分“就意味着限制其对真实业务的影响潜力”

正如 Dennis 所说，这些拥有集成服务背景的供应商，如 Sun 公司，正在将其旧式的整块程序分解为组合式的应用程序，以增加其覆盖范围和适用性。许多人均指出在过去几十年，迈向分布式系统（无论是服务组合或是对象组合）增加了对于编配的需求。如今，这更突显了BPM 的关键性。这已不再是新闻，因为 Joe McKendrick 在 2006 年就提到:

需要提出的重要的一点是，SOA 的不仅仅是一个 IT 项目。若要取得成功，SOA 的所有权需要在企业内跨部门进行共享。迄今为止，还没能共享――它仍然主要是一个 IT 项目。作为一个 IT 项目，SOA 将一败涂地，草草收场。IT 在创建、维护、测试服务组件方面可以发挥作用，但 SOA 属于整个业务（而且必须由其来驱动）。SOA 和 BPM 项目两者均需要从业务引导的角度来看待和管理，否则他们将陷入对立的筒仓…

回到原来的文章，Dennis 相信：

IT 部门应该将 BPM 看做是一个基于面向服务架构（SOA）的方法的“新的发展模式”。根据这种观点，其目标是为商业用户提供能够控制和可视化的功能，同时支持重用。在这种模式下，IT 在提供数以千计的特定行业甚至企业生态系统的具体服务时不再成为系统瓶颈。

Tom Baeyens 领导着 jBPM，他在相关主题有如下观点：

我认为很多做 BPM 的人在谈到软件架构时缺乏对整体应用开发的洞察力。在我看来，应用软件是在筒仓内开发的。应用程序筒仓之间的连接可以由典型的 SOA、WSDL、WS 库得到加强。但是，BPM 具有更加广泛的适用性，只能构建于服务之上。

Cordys 在这个条目和相关文章中明显提到的是，推动下一代的 BPM，如其业务层提供了某种程度的抽象和…

[…] 从应用的控制中删除流程的方式与从中间件中删除数据类似。但是要把它做好，Cordys 说，BPM 必须支持业务流程的所有属性，其定义为 - 并行和串行地管理应用

• 管理人员密集型应用
• 从应用程序中分离流程
• 在防火墙内外均可工作
• 允许流程随着时间推移而改变
• 把流程交还给业务

正如我们之前所看到的，其他人可能在该列表中添加了不同的东西，或是删除了一些东西，例如对一系列的领域特定语言（DSL）的支持，更好的标准，和更好的分析工具。但是大多数似乎都同意的观点是，如何结合 BPM 与 SOA 是很重要的。 Gartner 的分析师 Mark Raskino 在 2007 年是这样说的：

为了提高灵活性，多数公司需要有 BPM 附加之上的 SOA 架构。

但是， Steve Jones 指出，这往往是说起来容易做起来难：

要百分之分的一清二楚。如果你正在做 BPM，然后只是说“步骤 = 服务”；然后你就开始做 VISUAL Cobol，用服务替换掉函数调用。事实上，您使用 WS-* 或 XML 并不能将这些元素变成服务

从市场可以看到越来越多的 SOA 或 BPM 的厂商基于各种原因开始互相拥抱。但这导出了最后一个问题：在 2004 年，当被问及对 BPM 未来的远景时， Lanner Group 的首席执行官 Scott Dixon Smith 说到：

在十年之内，他看到一个执行官在跟着 PDA 显示的重要步骤进行高尔夫练习。根据不同的结果，选择将是要么继续击球，去第 18 洞，或者致电另一位同事以寻求帮助。

我们到这种程度了没有？

查看英文原文： BPM Products Consolidate Functionality For The Future

刘涛，博士，毕业于西安交通大学，主要研究网络体系，现在主要从事多核环境下高性能算法的研究与开发工作。曾经进行过多个企业级软件的设计与开发工作。关心开源软件的发展动态，乐于使用开源软件。对前沿的系统软件与技术有浓厚兴趣。