| 经过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年我还写了两篇文章（1、2），它们都被OMG BPMN
1.0 规范所引用。我将重申我在这些文章中的一些观点，可能更清楚一些，使用不同的例子。这里，我的目的是探讨作为当前BPMS架构基础的一些误解，同时给出一个新的架构蓝图，在此基础之上可以构建一个新型的业务过程管理系统。
谬误#1：业务分析师从系统的视角建模他们的过程。
如果你跟从业者谈过的话，他们会告诉你他们从用户的视角建模过程，而不是从执行的视角或系统的视角。这意味着他们的过程指导用户做什么，他们从不建模系统对用户输入的响应。这么做有充分的理由：业务连贯性。如果系统失败了，用户需要知道该做什么才能使业务继续下去。这也是业务分析师思考，以及他们如何定义和获取过程指标的方法。这个用户视角对于业务非常重要，因为它直接关联创造价值的工作流活动。业务分析师从不根据系统边界、执行、消息或业务对象进行思考（开发人员是）。业务分析师所理解的系统至多就是一个等价于纸制格式电子版本的屏幕（阅读或输入信息）。
谬误#2：业务用户可以很容易的学会BPMN并使用全部特性。
BPMN是一份超过300页的规范。即使你的若干业务分析师决心去掌握所有这些概念，它也是难以思考的。Michael
zur Muehlen对BPMN中最常用的结构进行了一次调查（参见 slide 24)，他的结论是日常使用的大约是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指出他们关注以人为中心的过程，在很大程度上，我同意它非常适合由这些厂商开发的业务过程引擎的集中化视图，尤其是需要对现有系统集成和进行有限的定制时。
谬误#5：业务过程执行必须是集中化的。
让我们在这个谬误上花点时间。Bruce解释了他面临的一个新问题：
事实上，如果[他的BPMN使用者]已经做出了他们BPM运行时的决策，那么它通常就是BPEL。它是一个标准、一个日用品，而且可以找到开源实现。它被IBM和
Oracle用在他们的BPM运行时中。因此，在选择BPEL时有强制性因素。但是BPMN和BPEL不是都在进行标准化吗？不，这当然不合逻辑。
在“双向工程已死”营地（roundtripping-is-dead camp）待了大约一年之后，我现在发现自己不得不再次面临这个问题。在我的BPMN培训中，例如，学生想要知道在他们的BPMN图中使用什么策略或模式才能非常匹配他们期望的BPEL实现。这并不是我一开始期望去考虑的问题。
BPMN / BPEL双向工程已经成为这个行业的圣杯。这最初本是由BPMI.org提出的愿景，该组织缔造了BPML和BPMN。这儿发生了什么？在一些公司给BPMN增加执行语义的时候连一个中介编制语言都没有，他们怎么可能为以人为中心的过程创建一个成功的市场？其他人认为这个问题来自于我们没有找到合适的协调语言这一事实。例如，Arzul
Hasni认为在双向工程上GRAFCET会是比BPEL更好的候选。GRAFCET是工业自动机的专用编程语言（Arzul在他的帖子中给出了细节）。基本上，它非常接近BPEL。
Ouyiang、Dumas、van der Aalst和ter Hofstede在创建BPMN/BPEL映射上做了卓越的工作。对于那些像我一样早就忘记了大学数学的人，我发布了BPMN和BPEL的UML图，它们可能对于你理解两个规范的语义（即，它们可以表达的事物）分歧有所帮助。来自这个研究组的结论非常的清楚：
未来工作的一个可能方法是扩展提议的技术，覆盖BPMN模型更大的子集，如对相关的异常处理和其它高级结构（如OR-joins）建模。不幸的是，BPMN的许多高级结构并没有细化，依旧处于由相关标准化团体改进的过程中。
集中化过程引擎的概念并不新鲜。这是自90年代早期以来该领域已取得成果的99.99%的幕后基础。通过这个优秀的介绍可以很好的理解对集中化架构的关注，它由Fujitsu
Computer Systems（该公司也在XPDL上投资，为BPMN创建一个可交换的格式）的研发副总裁Keith
Swenson撰写。
不幸的是，这种观点是有缺陷的，我非常愿意花些时间解释这一点。使用这种思考方式，我们完全忽略了业务过程本来的天性：通过转换资源给组织增加价值。像Source-to-make、Quote-to-cash……这样的过程都沿着工作流活动移动“东西”，这些活动最终（且有望）给转换中或消费中的资源增加价值。信息系统在此只是推进、捕获和报告这些资源和活动的状态。是的，你可以携带任何一个描述物理概念的业务对象：购买订单、发票、库存项、员工、客户……它们都有生命周期（可用状态图描述--参见图2）。
我愿意举一个工作申请业务过程（即Candidate-to-Employee过程）的例子，它抽取一个候选者的申请，并将它处理到候选者要么被雇用要么申请被拒绝的位置。
以下就是典型的工作申请信息模型。
图1. 工作申请数据模型
这个工作申请有一个生命周期（请记住工作申请的数据模型——内容——独立于它的生命周期，反之亦然）：
图2. 工作申请生命周期
工作申请生命周期本身独立于任何Candidate-to-Employee业务过程。这是一块很少变化的业务逻辑，即使与之交互的过程可能经常变化。一家公司可能有几个这样的过程为这个相同的生命周期服务：例如，一个用于副总裁职位，一个用于经理，一个用于其它所有的员工。另一种情况可能是因为规章制度，一些过程可能涉及额外的活动（检查背景……）。这些过程变体是非常平常的。但是，在很大程度上一个工作申请就是一个工作申请，即使也存在一些工作生命周期变体，它们在很大程度上与它们的过程变体没有瓜葛。
现在的问题是，你将如何动手实现这个工作申请生命周期组件？我要使用的方法是创建一个实现所有动作的服务，这些动作将导致状态转换：
图3. 工作申请服务
所有这些服务操作将有效执行一些会导致状态转换的业务逻辑。什么是实现这个服务的最好的语言？Java/C#？BPEL？GRAFCET？
我的偏好是如BPEL这样的一门面向消息的编制语言，因为这些资源生命周期是长期运行的（日、周、月、年）。为了说明这点，让我们举一个客户资源的例子：作为一个客户，我这周刚刚取消了一个与信用卡公司12年的关系，（这使得我的客户生命周期实例迁移到了它的最终态）因为必须支付额外的费用，我觉得违反了计费过程……是的，过程确实麻烦，他们可以完全无需改变我所喜欢的账单生命周期就能给他们的过程增加一个活动，但是他们没有，相反他们选择了最大化费用。对于这种长期运行的生命周期（不是过程），BPEL是一个理想的实现语言，因为它理解消息（接收、发送、调用）、关联消息，它可以处理并行流程（是的，一个资源可以有组合状态）。此外，BPEL引擎被设计来自动处理过程实例状态数据的持久化（dehydration/hydration），这个工作的麻烦相对少些。
BPEL实现看起来就像这样（使用厂商中立的BPEL符号）：
图4. 工作申请服务的实现
我知道很多人会告诉我它是一个过程，但是它不是。它是一个实现了工作申请生命周期的服务，它独立于那些推进工作申请状态的过程和活动。一个过程是推进它的状态的活动的集合。资源生命周期和过程是解耦的，我认为这是无庸置疑的，然而每个人还是试图在没有清晰的理解资源生命周期的前提下建模和实现过程，它们或多或少“内建在”过程模型中。
因此，大多数人将BPEL引擎作为标准选择是正确的……目前为止是这样。注意，由于SCA，你钟爱的编程语言可以很容易地被扩展结合BPEL语义。过去，我喜欢BPEL-J
over BPEL，但是现在如果你需要在传统语言中表达一些业务逻辑，SCA使得在你钟爱的语言中使用编制能力这一工作真的变得非常简单（Java、C++、COBOL、PHP、ABAP……）。
资源生命周期和编制语言之间存在如此强的关系，以致于一些领先的编制引擎提供了一个状态机范式作为创建你的编制定义的一种方法。IBM
Process Server和微软Workflow Foundation就是例子（如果我还忘了哪些产品，我要在此说声抱歉。如果你知道的话，请告知我）。
请注意，到目前为止我一直在建议使用一个编制引擎去实现那些管理资源生命周期的服务，我还没有说到业务过程或业务过程引擎。
在了解生命周期和过程之间的关系之前，我们需要注意的是生命周期是一个非常直观的概念。大多数业务分析师随时可以轻易地描述这些生命周期（比方说使用UML符号）。可以这么说，不论他们是什么角色，组织中的任何人都可以理解这些生命周期。但是，我也要强调一下它的另一极端，几乎没有人有能力设计（使用BPMN进行图形化设计）满足涉及的所有资源生命周期的业务过程。假如你创建了这样一个模型，我们就说你现在创建了一个过程的变种。你如何能保证资源生命周期不受影响？你需要进行多少QA工作来验证它？
过程和资源生命周期只能在过程实现时是一致的，而且可能要向过程“妥协”以确保它符合生命周期。这种活动只能由开发人员仔细地将业务分析师画出的BPMN进行映射，并重用那些管理他或她组织的核心资源生命周期的企业类服务来做到。
现在，让我们看看业务分析师是怎样使用BPMN创建一个工作申请业务过程定义的：
图5.工作申请过程（蓝组代表人工任务边界）
首先，BPMN连表示“资源”的符号都没有，更别提“生命周期”了。人们最多可以在过程的某一点（如上图）使用期望的状态对它的BPMN定义进行注解。这非常好，BPMN就应该是这样。其次，业务分析师完全不关心工作申请会调用哪些操作来推进它的状态。它们属于系统视角。期望业务分析师在他或她描述的用户活动间加入“调用”活动简直是痴人说梦。不幸的是，人们着手去建立的BPMN和BPEL之间的关系就是一个错误的例子。他们最终在过程符号中加入了核心BPEL操作语义，发送、接收和调用。这完全是画蛇添足，不应该被使用，除非被接收或发送的消息是一个业务消息而不是一个被调用的操作（如一份工作申请到了一个招募者的桌上）。
怎样实现业务过程？一个业务过程执行环境是一个彼此（非集中编制的服务集合）交互的服务的装配（图6）。它描述了实现资源生命周期的编制，以及人工任务执行、事件和推进过程的简单服务调用的交互。
图6. 工作申请过程实现
好消息是我们完全拥有了实现这一愿景的必需技术，包括装配技术：服务组件架构。你在图中看到的一切可以结合SCA
1.0、BPEL 2.0、Web Services（XSD和WSDL 1.1——因为BPEL 2.0）、BPEL4People
1.0 and Human Tasks 1.0来完成。
Bruce先前宣称：
使用BPEL你没有忽略你不支持的元素的自由。BPEL就是BPEL，你必须支持规范中的一切。剩余的被称为私有扩展。它们只存在于它们自己的名字空间，BPEL
1.1的一个有根据的批评就是一个真正的过程需要太多的元素。BPEL 2.0要好一些，但是人工任务、子过程和其他的基本的东西仍需要2.0中的扩展，如，近乎神话的BPEL4People。
在这个BPMS架构蓝图中，他的言论不再有效。WS-HumanTask和BPEL4People属于任务容器并且确实与BPEL本身隔离开。现在，你可以争论BPEL是否需要“子过程”，但是我会说作为一门资源生命周期服务的实现语言，它并不迫切：状态机元素极少可被重用，它们完全属于它们的资源。
在这一点上——不幸的是——微软并没有参与SCA或BPEL4People，因此你不能将Workflow
Foundation作为BPEL引擎的替代品，即使它能很好的完成工作。但是，你可以将WCF当作服务容器实现服务，你可以从SCA和你喜爱的BPEL引擎中调用这些服务。微软本身并没有装配机制，因此你甚至不能在.Net中实现这个架构蓝图。在开源方面，你可以找到大多数组件（SCA、BPEL和服务容器），但是BPEL4People容器除外。这并不要紧，基本的人工任务容器并不是太难构建（但是还没到BPEL4People和WS-HumanTask级别）。
为了理解开发人员在这个新架构中的角色，让我们仔细看看过程模型的“面试安排（Schedule Interview）”活动（图5）。如你所见，这个活动在过程模型中被进行特别对待（这是有意义的，这是因为，如果工作申请系统宕机了，用户就不得不这么做），但是作为优化，它由业务来决定，例如，任务安排在Exchange
Server上自动进行。工作申请应用生命周期提供了在候选人的申请被保留后安排面试的钩子（即，必需品）。记住工作申请服务并不知道这是如何实现的。它是人工任务也没有关系。在这一点上我认为，自动解决这种设计决策完全是不可能的。这就是过程模型必须完全和任何执行语义分离的原因。另一个不会影响过程定义的设计决策是这样一个事实：候选人申请能发生在一个不同的人工任务容器。我们能很好地将这个过程和发生在一个流行的求职站点的候选人申请“装配”在一起。一旦申请被批准面试，一个活动将给候选人发送一封邮件，告诉他或她下一步过程任务（复查录用通知，输入员工信息）。我打赌你现有的BPMS系统做不了（容易地）这件事。
作为一个附注，你现在可以看到任务引擎并不是一个业务过程引擎真正的子组件。当然，当今的BPMS系统就是这么设计的，但是事实上它确实不是，它是架构的独立组件，管理人工任务（图6）。这些人工任务本质上总是关联一个或更多的业务过程，但是它们有它们自己的生命周期，而且直接和资源生命周期服务交互。正如Dominique
Vauquier[1]在他文中所说的：“人工任务嫁接了资源生命周期”。此外，我们在前一段落看到，为了使“业务过程”能和几个任务容器进行交互，它至关重要。
在此，我并不想描述规则或主数据管理的角色（对不住了，James），但是它们的确扮演了关键角色并且需要特殊的服务容器，这就是众所周知的BRMS（图6）。Michael
zur Muehlen或Mark Proctor问的问题就变得完全不相关了，因为SCA使这变得不相关（从运行时的角度）。SCA会让你选择决策服务的最佳调用机制（技术上可行的话，它可以和你的BPEL引擎一起运行在过程中）。SCA很大程度解耦了这个架构的元素，这使得它们可以在不同的过程中被重用，同时为每个过程选择可能的最佳运行时配置。
我也不会谈到B2B的角色，在我最初的两篇文章（1、2）中，关于它们我说了很多。通过支持定义装配内的任意边界，这个架构蓝图支持B2B。例如，我能“装配购买订单生命周期的两个视角（买者和卖者）”。这是一个巨大的进步。传统的“集中化”执行模型在B2B边界强加了一个人工的断层，被迫使用两个不同的执行模型：在每一端的一个集中化编制，以及中间的一个装配。在某些方面，我的提议完全是基于OASIS
ebXML Business Process最初的B2B过程定义，但是应用在了资源级别，而不仅仅是业务伙伴级别。这就是执行模型在组织内外都连续的原因，因为它和它的业务伙伴交互。
谬误#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的文章从法文翻译了过来（它将被BPTrends.com于2008年1月发表）。如果你能阅读法文，这篇文章可以在Praxeme企业方法的Guide
of the Pragmatic Aspect的39页找到。 |
