谬误 6：业务过程执行语义可以简单地从现有编程概念中派生出来。
我在“执行”标准工作组（如BPML、BPEL、WS-CDL）中碰到的每个人（包括我在内）几乎都不是从业者。他们是开发人员和架构师。他们经常关注复杂的数学理论（如Pi-Calculus），从来不去验证这些理论的语义是否真的足够支撑一个业务过程执行。一般来说，这些技术提交者会关注3~5个用例来书写他们的需求。这些用例通常比较简单，很少反映“现实世界”业务过程的复杂性。
业务过程执行语义很难概念化。这个过程是实际上是如此的困难，以致在我们的解决方案中绝大多数的可执行过程依旧是痛苦的硬编码，一次一行。如果有更好的方法，我确定它能很快被每个人接受。我被推荐去阅读“Java开发者为什么憎恨BPM”的讨论。没有一个评论抱怨抽象的有效性。即使是代码大仙（code Kahuna），如JBoss的首席架构师，Bill Burke（在他加入JBoss之前，我和他有过短暂的共事，当时我们一起在做一个人工任务容器）如此评论：
我认为BPM也一样。只不过是编写XML脚本，开发人员并不把它放在眼内。直到我确实开始深入BPM框架……我并不认为必须提供这些增值框架。当我开始把它们当作一个可靠的和容错的状态机思考的时候，我开始真正意识到BPM框架的潜力。然后，当你结合你的过程和事务管理与补偿使用时，你就得到了一个真的好的抽象，这在你开发你的应用时可以派上用场。
根据我在前一节的解释，他和其他人言论的方向是正确的。开发人员现在看到了一遍又一遍不得不编写状态机的困难，以及一个通用的引擎可以减轻他们的工作（大多数情况下如此）。
谬误 7：Bruce Silver这样总结他的帖子：“一个协作实现范式，其中可执行设计位于BPMN模型之上的层级，这是正确的道路。”
Bruce认为业务过程模型实现应该从以BPMN表示的业务过程模型中派生，然后增加注解（和开发人员协作）得到一个可执行的过程。
不幸的是，这个愿景没有考虑业务过程（作为推进资源状态的活动的工作流）的实际情况，我希望我能使你相信，这个言论即使在概念上经过有效地努力，也是大错特错，因为我们不能将工作流活动和资源生命周期建模在一起（至少以我现阶段的知识）。我可以预言，在很多时候，开发人员会将业务分析师完成的过程定义翻译为结合了人工活动、资源生命周期服务和其他服务（包括决策和MDM服务）的东西。
现在，这个新的架构蓝图并不意味着你在你喜爱的BPM上所做的投资就没用了。但是，你需要增加组合服务容器（如一个BPEL容器）和一个装配容器（SCA），以及将你的BPMS主要作为人工任务容器使用（不管怎样，在很大程度上，它们实际上就是如此）。一个人工任务容器是架构高贵重要的组件。当今的BPMS的任务容器非常复杂，而且很难自己构建，因此花点钱是值得的。我根本没有削弱这个容器的角色。事实上，我期望2年内所有的BPMS厂商会采纳本文中展示的愿景，并将它们的套件改在基于这个蓝图的SCA装配和BPEL容器内工作。
我还要声明一点，在这个实现结束的时候，有可能自动重新构造一个操作过程的“现状”视图。我没有证明这一点，这可以成为一个研究课题。
结论
经过这么多年搜寻BPM魔力弹，软件行业正在碰壁。通过范式转换和基于资源生命周期新的业务逻辑的分解方式，这堵墙很容易被拆除。如果我们还执著于今天错误的方向，依旧相信本文列出的7个谬误，我们就会遇到因缺少ROI而抛弃所有这些产品和标准，并回到手工编写任何东西的风险。但是，如果我们选择今天完全相同的技术，以另一种方式使用它，我们就能交付对业务和IT都引人注目的愿景。就其本身而论，我不会将之称为BPM，它比BPM要大。我更愿意称之为“组合应用”或更贴切的“组合解决方案”。
组合解决方案愿景直接说出了业务想要从IT得到东西：
- 通过尽可能小的项目快速构建解决方案（依赖更多的迭代）
- 快速改变解决方案，支持一个迭代、精益六西格玛方法
- 在当前时间能可视化操作中的业务设计，没有复杂的“现状”项目
- 无需复杂的度量项目，就能从当前业务决策中获得运营智能。
我要声明，“能够构建/通过创建直接改变解决方案/改变业务决策”（不论它以怎样令人称心如意方式的出现）背离了这四个需求。原因是它导致以过于简单、僵硬的任务为中心的应用模型（从今天的BPMS中就可看到）。这种应用模型不能满足业务的需要，一般会导致项目成本的增加。因为当真正的解决方案需要被开发时，围绕BPMS应用模型，它们需要大量的客户化开发。为了使问题复杂化，这些套件，正如“Java开发者为什么憎恨BPM”讨论中指出的，还没有为客户化代码和适合大项目交付一个健壮的开发环境。
我声明这个愿景的进一步就是组合软件（基于两个组合模型：装配（SCA）和编制（BPEL）——是的，编排正在走下坡路——当然——但是我会在另一篇文章中解释这个）。开发这个蓝图的技术是现成的。此外，BPEL和BPMN，如今天所定义的，有效。如果还有什么要对BPMN进行修改的，那就是应该去除所有的执行语义，BPMN应该被设计为让业务分析师能自由的表达。如果你想要了解关于使用这些标准和这个架构蓝图如何构造组合应用一些更多的细节，请参考这本发表在InfoQ上的迷你书。
本文中描述的这个组合解决方案平台架构，同样提供了一个SOA和BPM间清晰的接口。它使SOA有机会构建真正可重用的服务：资源生命周期服务可以跨过程域和过程变量被重用。因为这些资源生命周期服务可以跨过程重用，这也意味着实现任何给定过程变得便宜、快速和容易。资源生命周期服务的实现是过程内的“代码”。认为一个业务分析师（或其他什么人）在过程定义中拥有编写和重新编写这些图形表示的生命周期的知识完全是将BPM推向错误的方向。
这个蓝图，作为一个组合解决方案平台，已经有一个可以支持它的企业方法：Praxeme。Praxeme协会正将他们的文章翻译为英文，并在这个目标上取得了很大的进展。
现在，我要分享一些来自Bruce和Marlon关于在当前技术（SCA、BPEL）中和开发人员有关的想法，这也是我开始一个名字叫wsper项目的原因。这个项目提供了一个抽象编程环境，它能简化开发人员和架构师在生命周期实现和过程装配中的工作。它同样有助于构造来自异构组件的组合解决方案平台，因为它隔离了来自这些组件（和它们将来演变的）的业务逻辑。它隔离了来自标准演变的业务逻辑。
我非常感谢Sandy Kemsley提供了如此多有用的链接和评论。
[1]这篇文章是对Dominique Vauquier的文章（“业务过程改进的6个谬误”）进行了补充。此处，我们关注于业务过程建模。Dominique的文章探索了如何关联业务过程建模和业务过程改进。我将Dominique的文章从法文翻译了过来（它将于2008年1月在BPTrends.com发表）。如果你能阅读法文，这篇文章可以在Praxeme企业方法的Guide of the Pragmatic Aspect的39页找到。
