【IT168 分析评论】

    经过8年多的认真研究之后，软件行业和它的客户正头撞南墙。由DotCom时代BPM初创者提出的愿景依旧没有得到实现：我们远没有能力使用业务分析师设计出的业务过程模型来创建完全可行的解决方案（即使通过开发人员最低程度的干预）。过程驱动应用模型的需求确实存在：业务过程改进项目在G2000公司内随处可见，但是尽管持续改进过程的需求十分强烈，可BPM的市场在2007年仍然很贫瘠（相比它能够达到的程度），和那些迅速包装自己的厂商言语形成鲜明对比的是，在2000年，Oracle业务过程管理系统的空白……
    到底发生了什么？这其实非常容易理解。这就是通常的“你要什么，我就给你什么”的故事。在这些情况下，一系列的误解常常导致非非常受欢迎的解决方案。如果你加入到一个大多数产品经理、架构师和开发人员从不与业务分析师进行交流的团队，由他们自己独立设计超越一些方块和箭头的业务过程，任何人都不会对当前的这种情形感到惊讶。
    11月底，Bruce Silver在“再谈双向工程（Roundtripping Revisited）”中提出了一个关键问题。Bruce抱怨两个关键的标准：BPM:BPMN（业务过程建模符号）和BPEL（业务过程执行语言）之间存在严重的失配。他提到了一个研究者（Ouyiang、Dumas、van der Aalst和ter Hofstede）团队的杰出工作，他们提出创建一个BPMN到BPEL的编译器，因为它是经常提到的在当前的BPMS架构中缺失的一环。在解决这个问题上他们已取得很大的进展，但是他们的工作仍然尚未完工。他也宣称我们应该完全放弃BPEL，而将精力放在有可能成功的方向：在符号之下再创建一个可执行的BPMN标准层。
    我从1997年就一直在这个问题上工作，在2002年我还写了两篇文章，它们都被OMG BPMN 1.0 规范所引用。我将重申我在这些文章中的一些观点，可能更清楚一些，使用不同的例子。这里，我的目的是探讨作为当前BPMS架构基础的一些误解，同时给出一个新的架构蓝图，在此基础之上可以构建一个新型的业务过程管理系统。

谬误 1：业务分析师从系统的视角建模他们的过程。

    如果你跟从业者谈过的话，他们会告诉你他们从用户的视角建模过程，而不是从执行的视角或系统的视角。这意味着他们的过程指导用户做什么，他们从不建模系统对用户输入的响应。这么做有充分的理由：业务连贯性。如果系统失败了，用户需要知道该做什么才能使业务继续下去。这也是业务分析师思考，以及他们如何定义和获取过程指标的方法。这个用户视角对于业务非常重要，因为它直接关联创造价值的工作流活动。业务分析师从不根据系统边界、执行、消息或业务对象进行思考（开发人员是）。业务分析师所理解的系统至多就是一个等价于纸制格式电子版本的屏幕（阅读或输入信息）。

谬误 2：业务用户可以很容易的学会BPMN并使用全部特性。

    BPMN是一份超过300页的规范。即使你的若干业务分析师决心去掌握所有这些概念，它也是难以思考的。Michael zur Muehlen对BPMN中最常用的结构进行了一次调查，他的结论是日常使用的大约是25个结构。我个人就为业务分析师写过一份教程，它基于10个关键概念，同时附有相应的BPMN。说服与我一起工作的精益六西格玛（Lean Six Sigma）黑带接受BPMN不是件易事。
    Bruce Silver根据他的经验（因为他教过BPMN课程）进行了评论：

    BPMN有大量的只是用于产生BPEL的属性，这些一般都可以被忽略。

谬误 3：业务分析师应该能从过程模型创建可执行的解决方案。

    我并不是说BPMS厂商毫无诚意地试图向你推销一个说得比唱得好听的BPMS。BPM的出发点是好的：更好地靠齐业务/IT、更快的开发周期……其中蕴含的思想是：业务的确可以产生一个能转换成可执行代码的模型。这本无可厚非，它和一些CASE工具、MDA、MDD、DSL……处于同一战线上。这个愿景道出了我们最想实现的梦想：快、易、省。每次我听到厂商在这个话题上大喷口水之际，我就会想到John Lennon的那首Imagine（即I want to live in this world, but it is not going to happen in my lifetime）。厂商觉得基于一个坚实的想法有一个真实（并且巨大）的市场。当你将之与来自风险投资几乎无限的资金量结合起来的时候，那样，你就得到了我们目前的情形。在交付那个愿景的片断上，一些厂商要比其它的好一些，但是我们不得不承认这还不是愿景。没有人可以大声说他们已经提供了一个通用的引擎，业务分析师可以用来（甚至通过IT的最小干预）从过程模型创建一个解决方案。 大项目失败，BPMS使用的边缘化，给组织带来极少的益处。
    我经常告诉那些想让他们的业务用户“打造”解决方案的人们的一个笑话是：好消息是你刚刚给你的组织增加了2000名开发人员，而坏消息是你只是增加了2000名开发人员。你想让你的用户不用构建或者甚至客户化解决方案，就能个性化它们。注意，在一些好的约束条件下，让业务用户自定义一些业务逻辑（如规则）是可行的。

谬误 4：如果我们增加了一个可以从业务分析师的输入直接创建解决方案的魔力BPMS，我们就不需要开发任何与现有系统的集成，无需改变现有系统的记录，也不用进行任何QA工作。

    这样说吧，我期望到现在为止所有人都同意：至少在下个10年，我们不会在市场上看到这样一个魔力BPMS。而且厂商的确完全放弃了将开发人员排除在外的做法。但是，Bruce写道：

    通过完全忽略BPEL，一些更小的公司开始示范了BPM购买者和行业分析师的成功做法。像Lombardi、Appian和Savvion这样的厂商，把精力放在以人为中心的过程而不是集成。这样导致了一种新风格的BPMS，其中可执行的设计直接建立在过程模型之上，以BPMN活动的实现的属性的形式。
    这种工具本身鼓励整个实现周期中业务-IT的协作。并且非常适合敏捷迭代方法论，这种方法显著地缩短了从模型到已部署的解决方案的周期时间。

    Marlon Dumas对Bruce的反应和我的一致：

    你不能仅仅因为从来没有业务分析师愿意书写一些类似XPath表达式或其它表达式语言，就将开发人员排除在BPM生命周期之外。

    和我前面所说的一样，我会证明这些厂商的成功经验是有限的。正如Bruce指出他们关注以人为中心的过程，在很大程度上，我同意它非常适合由这些厂商开发的业务过程引擎的集中化视图，尤其是需要对现有系统集成和进行有限的定制时。