业务过程建模符号（BPMN）是被当今所有过程设计工具都采用的流行符号。BPMN是OMG维护的公共标准，已广泛地被不断携新产品进入市场的商业和开源BPMS工具厂商共同接受。

尽管其已被广泛采用，但是BPMN工具仍有许多令人难以忍受的缺陷：

• BPMN是一个图形符号，不支持标准化的元模型。这导致BPMN工具之间几乎没有互操作性可言。尽管可以使用XPDL来存储和交换过程图，但是并非所有的BPMN工具都支持这样做。
• BPMN是一门设计语言，一般被翻译成业务过程执行语言（BPEL）。正如Bruce Silver指出的，“面向图形的（graph-oriented）BPMN模型——其中，你可以将流程导向任何地方——与面向块的（block-oriented）BPEL之间的不匹配”造成了这两种语言间相当数量的不兼容，这使得在很多情况下这种翻译具有挑战性。“BPMN规范试图为很多图模式（diagram pattern）描述简单的BPEL映射，但是长期以来人们认识到有些模式肯定无法按BPMN规范中描述的方式映射。那些对以简单映射为基础的BPEL翻译有效的BPMN工具，在BPMN没有严格按面向块（block-oriented）风格绘制时，会给用户报大量的有效性（Validation）错误。”结果是，大部分的工具只提供BPMN到BPEL翻译（不是双向工程），甚至连这种受限方式也极少提供真正可执行的代码。

Antoine Lonjon的白皮书给出了BPMN 2.0标准主要目标的纲要，其与Bruce Silve的BPMN愿望清单类似。其中最重要的就是创建一种BPMN交换格式（除了现有的XPDL之外）。根据Sebastian Stein的说法：

就像回到了UML 1.x时代，图形模型没有交换格式。然而，BPMN甚至更糟。它连模型的内容交换格式（因此没有UML 1.x中类似的XMI）都没有。BPMN 2必须解决这个问题，引入一个涵盖模型内容和图形布局的交换格式。

问题的可能解决办法之一是使用业务过程定义元模型（BPDM）作为BPMN符号的相容元模型。这不仅解决了交换格式的问题，而且还明确定义了BPMN执行语义。尽管这是非常强大的解决方案，但是它引入了许多新概念。新规范要解决的其他问题包括：能指定多种启动过程的方法，支持非中断中继事件（non aborting intermediate event），半结构行为（semi structured behavior）等，这些都会潜在地使BPMN更复杂。

尽管要到8/9月间OMG才会给出推出BPMN 2.0的时间表，但是关于它可能方向的初始公告在网络上反响强烈。根据Sebastian Stein的说法：

引入更多新鲜可能有悖于BPMN目前的优点——简单。这会增加BPMN建模的学习曲线，可能不利于进一步的采用。

Vishal Saxena重复了Sebastian的观点，他写道：

首先，让我来说说在BPMN 1.0（1.1）中是什么了不起的东西使其成为过去几年内采用率最高的规范之一，姑且不论其他建模标准为了这一目标奋斗了更长的时间。第一和最重要的原因就是BPMN的简单性——或者说得确切点：它使简单的事情保持简单。举例来说，如果我想对取现金过程建模，我能在极短时间内通过少量和不那么陡峭的学习曲线做到。许多人发现这就像他们在画板上用别的什么画流程图一样简单，比方说Visio。

在考虑所有这些新特性时，关于BPMN的角色的问题也需要被提出。一方面，有些厂商（如Intalio）已经引入了可执行BPMN（完全使用BPMN设计过程，然后在幕后产生BPEL作为可执行部件）；另一方面Jean-Jacques Dubray认为，假定“业务分析人员能从过程模型中创建可执行解决方案”是业务过程管理的谬误之一。除了一些最简单的过程，如订单批准，实际的BPM实现一般都需要涉及IT，因此无需（绝大多数情形是不能）直接运行BPMN。这种情况下，更重要的问题是，过程实现时所作的变动如何与初始BPMN模型同步。

那么，BPMN未来的角色究竟是什么？许多实践者仍在讨论这个问题。但是，看起来它必须在BPMN标准新版本发布前得到回答。

本文转自infoQ中文站  作者 Boris Lublinsky  译者 胡键