关于 BPMN 的未来之争还在持续中。OMG（负责 BPMN 以及其它的 BPM 标准）的 BMI 任务组联合主席 Fred Cummins，就目前 BPMN 关于解决 BPMN 与 BPDM 之间差异的一个提交版本以及对 BPDM 复杂性的关注，发表了他的看法：
BPDM 是 OMG 所领导发展的业务建模语言套件中的一员。例如，SBVR（Semantics of Business Vocabulary and Rules）支持对业务概念的语义以及对包含这些语义的业务规则的表达进行建模。BMM（Business Motivation Model）为捕获战略计划模型提供了框架支持。OMG 的业务建模与集成任务组的一个战略目标就是发展一个完备的业务建模标准集以更加有效地支持企业计 划、分析、设计与提升。其结果就是，BPDM 有着健壮的抽象元模型来支持 BPMN 建模概念。这一抽象元模型定义了基本的概念，其中很多概念在其它业务模型中也有，只是上下文环境不同而已。
在 BPDM 当中，这些概念构成了一个一致的基础来支持对业务流程建模而不用考虑特定的建模工具。粗略看来，Fred 作出如下陈述：
BPDM 元模型看似复杂。然而，应该理解的是，正是这一复杂性为具体元素提供了精确的定义。这些抽象概念不会表现为附加的 BPMN 图形，也不会作为附加的 XML 概念来表达… 总的说来，BPDM 元模型的复杂性使得这一规范更加精准和健壮，并为未来开发一致的、互补的业务建模功能提供了支持。该复杂性并不会使得业务流程建模对于用户来说更加繁杂，也不会为工具的开发商带来不必要的限制。
Bruce Silver对 Fred 的此番言论回应到：
我必须要说在我对 BPDM 的一长串抱怨当中，元模型的复杂性并不是首要的。更为严重的是注解次之于元模型的这种看法，以及只要底层的元模型描述支持、用户就可以自定义语义这个事实。
Nick Malik 讨论到高级的 BPM 语言 / 注解是否最终会实现业务流程创建和实现的完全自动化：
在那些“忠实信徒”看来，我们可以给终端用户那些漂亮语言中的一种（BPMN 或 BPEL），他们就会写出自己的软件来，IT 开发者都可以裁掉了
Nick 指出尽管这些语言常常能简化实现，但对于业务流程的实现来讲，它们却并不能完全取代 IT 开发者（以及一个恰当的开发过程）：
…BPM 语言是对人类行为的建模。而“成为代码”的是对机器行为的陈述。我们对于机器必须要比对人类更明确一千倍，所以我们开发的代码就需要比为人类开发多出一千倍。
遗憾的是（尽管是出于好意），Nick 将 BPMN 与 BPEL——二个目标完全不同的语言——混为一谈了。因此马上引来了 Bruce Silver 的回复，指出了这一错误，但在总体的结论上却达成了一致：
让我们假设 Nick 对于 BPM 是什么还是有一定了解的，尽管 BPMN 本身并不能产出实现（它只是对活动流的建模）——BPEL 却是实实在在的开发语言，并 不是针对“终端用户”的。（也许 Nick 认为只有 Java 程序员才算“真正”的开发者？）基于 BPMN 的 BPM 套件确实提供了一种敏捷的实现风格，业务人 员和开发者在流程的自动化上紧密地协作。
基于这些争论看来，显然，BPMN 不管是在所扮演的角色上还是其自身的方向上仍然是不确定的，或者说至少是没有完全达成一致的。这一不确定性会显著的阻碍 BPM 在设计与开发上取得进步。
查看英文原文： The BPMN 2.0 Debate Continues
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论