逻辑谬误
经过8年以上的深入研究，软件行业及其客户陷入困境。 BPM初创公司在网络时代的愿景还没有实现：我们离使用业务分析师设计的业务流程模型来创建完整的可执行解决方案的能力还差得很远（即使开发人员的干预很少）。 对流程驱动的应用程序模型的需求是真实存在的：“业务流程改进”计划在G2000公司中无处不在，并且在不断地改进流程方面存在着巨大的需求，但BPM市场在2007年仍然处于边际状态（与之相比） 。 与此形成鲜明对比的是，某些供应商的语言在2000年被Swift地描绘成自己，成为下一个业务流程管理系统（BPMS）领域的Oracle。
所以发生了什么事？ 实际上，这很容易理解。 这是通常的“我会卖给您想要购买的东西”的故事。 在这些情况下，通常会产生一系列误解，导致解决方案欠佳。 如果您添加了大多数产品经理，架构师和开发人员从未与业务分析师交谈过的内容，更不用说尝试自行设计业务流程而已，那么，任何人都不会感到意外。
上周，布鲁斯·西尔弗（Bruce Silver）提出了“ 重新审视往返 ”的关键问题。 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中最常用的构造进行了调查（ 请参见幻灯片24 ），他的结论是常规使用了约25种构造。 就个人而言，我已经基于10个关键概念为业务分析师创建了一个教程，即使将BPMN配对，也很难说服与我一起采用BPMN的精益六西格玛黑带。
布鲁斯·西尔弗（Bruce Silver）的经验评论 （他教BPMN课程）：
BPMN具有很多仅用于生成BPEL的属性，这些属性通常被忽略。
谬论3：业务分析师应该能够从流程模型创建可执行解决方案
我并不是说BPMS供应商在试图向您出售BPMS时会冒昧地声称自己确实这样做了。 BPM的初衷是善意的：更好地实现业务/ IT协调的愿景，更快的开发周期...出现了这样的想法，即业务实际上可以产生可以转换为可执行代码的模型。 在那里做的没错，这与CASE工具，MDA，MDD，DSL处于同一生产线……这一愿景传达了我们最深切的梦想：快速，简便，廉价。 每当我听到供应商在这个话题上的言论时，我都会想起约翰·列侬的歌曲《 想像》 （ 即我想生活在这个世界上，但是这将不会在我的一生中发生 ）。 供应商认为，有一个坚实的想法基础的真实（巨大）市场，当您将其与来自风险投资商的几乎无限资金相结合时，您就会得到我们今天拥有的东西。 一些供应商在实现该愿景的一小部分方面比其他供应商更胜一筹，但我们必须承认，愿景不存在。 没有人可以声称他们提供了通用引擎，业务分析人员可以使用通用引擎（即使在IT干预最少的情况下）也可以根据流程模型创建解决方案。 大型项目失败，BPMS使用率被边缘化，给组织带来的收益很小。
我经常告诉人们，要他们的业务用户“设计”解决方案的笑话是：好消息是您刚刚向组织中添加了2000名开发人员，坏消息是您刚刚添加了2000名开发人员。 您希望用户能够个性化解决方案，而不是构建甚至不定制它们。 注意，在某些情况下，允许业务用户自定义一些业务逻辑（例如规则）是可以的。
谬论4 ：如果我们添加了一个神奇的BPMS，它可以直接从业务分析人员的输入中创建解决方案，那么我们将不需要开发与现有系统的集成，更改现有记录系统或进行任何质量检查。
如此说，我希望到现在为止，每个人都同意，我们至少在十年后才会在市场上看到如此神奇的BPMS。 是的，供应商已经完全放弃了将开发人员带出循环的脚步。 布鲁斯指出：
许多较小的公司开始完全忽略BPEL，从而向BPM买家和行业分析师展示了成功。 像Lombardi，Appian和Savvion这样的供应商更多地关注以人为中心的流程，而不是集成，他们以一种新型的BPMS引领了这一潮流，在该流程中，可执行设计以BPMN的实现属性的形式直接层叠在流程模型之上活动。
该工具本身鼓励在整个实施周期中进行业务与IT的协作，并且非常适合于敏捷的迭代方法，从而大大缩短了从模型到部署解决方案的周期时间。
回应布鲁斯的马龙·杜马斯（Marlon Dumas）同意我的观点：
您不会将开发人员从BPM生命周期中删除，只是因为没有业务分析师会愿意编写类似于XPath表达式或任何其他表达式语言的东西。
我会说，正如我之前所说，这些供应商取得的成功有限。 正如Bruce所指出的那样，他们专注于以人为中心的流程，我同意，这在很大程度上符合这些供应商开发的业务流程引擎的集中视图，尤其是在需要有限地定制和与现有系统集成的情况下。 。
谬论5 ：业务流程执行必须集中化
让我们花一些时间在这上面。 布鲁斯解释说，他面临一个新问题：
实际上，如果[他的BPMN用户]已经做出了BPM运行时决策，那么通常是BPEL。 这是一种标准的商品，可以使用开源。 这就是IBM和Oracle在其BPM运行时中使用的。 因此，有一些令人信服的因素对BPEL有利。 但是在BPMN和BPEL上都标准化了吗？ 不，当然这是不合逻辑的。
在来回死胡同的营地中待了大约一年，现在我发现自己不得不再次面对这个问题。 例如，在我的BPMN培训中，学生想知道他们应该在BPMN图表中使用哪些策略或模式，以使其与预期的BPEL实施相吻合。 刚开始我就不会想这件事。
BPMN / BPEL往返已成为该行业的圣杯。 这是BPMI.org最初提出的愿景，它是BPML和BPMN的创始组织。 那里发生了什么？ 当一些公司在BPMN中添加一些执行语义时，如何在无需中间编排语言的情况下为以人为中心的流程创造成功的市场？ 其他人则认为问题出在我们尚未找到正确的协调语言这一事实。 例如，Arzul Hasni 建议 ，GRAFCET可能比BPEL更适合实现此往返。 GRAFCET是专用于工业自动机的编程语言（Arzul在其帖子中提供了详细信息）。 从本质上讲，它与BPEL非常接近。
Ouyanang，Dumas，van der Aalst和ter Hofstede在创建BPMN / BPEL映射方面做得非常出色。 对于像我一样忘记了大部分大学数学的人，我为BPMN和BPEL发布了这些UML图，它们可以帮助您理解语义上的差异（即，您可以彼此表达的内容）在两个规格之间。 这组研究人员的结论很明确：
未来工作的可能途径是将建议的技术扩展到BPMN模型的更大子集，例如，涉及异常处理和其他高级构造（例如OR-joins）的模型。 不幸的是，BPMN的许多高级构造都没有得到充分说明，并且仍由相关的标准化机构进行完善。
集中式流程引擎的概念并不是什么新鲜事物。 这是自90年代初以来该领域99.99％的工作背后的基础。 富士通计算机系统公司研发副总裁Keith Swenson的精彩演讲可以很好地理解对集中式体系结构的关注（他对XPMN的BPMN交换格式投入了巨资）。
不幸的是，这种观点是完全错误的，我想花一些时间解释原因。 通过这种思考，我们只是忽略了业务流程的本质： 使组织能够通过转换资源来增加价值 。 从生产到制造，从报价到现金...的过程都沿着活动的工作流程移动“事物”，最终（并希望）为转化和消耗的资源增加价值。 信息系统只是在这里推进，捕获和报告这些资源和活动的状态。 是的，您可以采用描述物理概念的任何业务对象：采购订单，发票，库存项目，员工，客户...它们都有生命周期（可以用状态机描述-见图2）。
我想以工作申请业务流程（这是从候选人到雇员的流程）为例，该流程接收候选人申请并将其处理到可以聘用候选人或拒绝他的申请的程度。
这是典型的职位申请信息模型。
图1.职位申请数据模型
该作业应用程序具有生命周期（请注意，作业应用程序数据模型-content-与它的生命周期无关， 反之亦然 ）：
图2. Job Application生命周期
职位申请生命周期本身独立于任何从候选人到员工的业务流程。 这是一条业务逻辑，即使与之交互的流程可能经常更改，也很少更改。 公司也可以在相同的生命周期中使用多个流程：例如，一个用于副总裁职位，一个用于经理职位，一个用于所有其他员工。 另一种情况是由于法规的原因，某些过程可能涉及其他活动（背景调查...）。 这些过程变量非常普遍。 但是，在大多数情况下，作业应用程序是作业应用程序，即使也可能存在某些作业应用程序生命周期变体，它们在大多数情况下都与流程变体脱钩。
现在的问题是，您将如何实施这个Job Application Lifecycle组件？ 我这样做的方式是创建一个服务，该服务实现将导致状态转换的所有操作：
图3.职位申请服务
所有这些服务操作实际上将执行一些业务逻辑，这些业务逻辑将导致状态转换。 实施此服务的最佳语言是什么？ Java / C＃？ BPEL？ 涂鸦？
我更喜欢像BPEL这样的面向消息的编排语言，因为这些资源生命周期是长期运行的（几天，几周，几个月，几年）。 为了说明这一点，让我们以客户资源为例：作为客户，我本周取消了与信用卡公司的12年合作关系（这导致我的客户实例的生命周期过渡到最终状态），因为由于我认为计费过程很中断，因此我不得不支付一些额外的费用...是的，过程确实很重要，他们可以在不更改Bill生命周期的情况下就在其过程中添加一项活动，这会让我感到满意，但是没有，他们选择了最大化费用。 BPEL是适用于如此长的生命周期（不是流程）的理想实现语言，因为它可以理解消息（接收，发送，调用），消息相关性，并且可以处理并行流（是的，资源可以具有复合状态）。 此外，BPEL引擎已被设计为自动处理流程实例的脱水/水合作用，这是一件少（痛苦）的事情。
BPEL实现如下所示（使用与供应商无关的BPEL表示法）：
图4.职位申请服务的实现
我知道很多人会告诉我这是一个过程，但事实并非如此。 它是一种实现作业应用程序生命周期的服务，该服务独立于可能会提高作业应用程序状态的流程和活动。 流程是一组推进其状态的活动。 资源生命周期和流程是分离的，我认为没有人可以争论这一点，但是每个人都在没有清楚地了解资源生命周期的情况下尝试建模和实现流程，它们或多或少是“内置”的流程模型。
因此，大多数人为标准化BPEL引擎所做的选择是正确的选择……到目前为止 。 请注意，由于使用SCA ，可以轻松扩展您喜欢的编程语言以合并BPEL语义。 在过去，我本来会首选BPEL-J而不是BPEL，但是今天，如果您需要使用传统语言来表达一些业务逻辑，SCA使使用您喜欢的语言（Java，C ++，COBOL，PHP，ABAP）的业务流程功能变得非常简单。 ...）。
资源生命周期和业务流程语言之间有着如此密切的关系，以至于领先的业务流程引擎提供了状态机范式作为创建业务流程定义的一种方式。 IBM Process Server和Microsoft Workflow Foundation就是这种情况。 （如果我忘记了一些内容，我深表歉意，如果您认识其他人，请告诉我们）。
请注意，到目前为止，我建议使用业务流程引擎来实现管理资源生命周期的服务，但我尚未谈论业务流程或业务流程引擎。
在开始研究生命周期和流程之间的关系之前，让我们强调一下，生命周期是一个非常直观的概念。 大多数业务分析师可以轻松地描述这些生命周期（例如使用UML表示法）。 我会争辩说，组织中的几乎任何人都可以理解这些生命周期，无论其角色是什么。 但是，我还要指出，在频谱的另一端，几乎没有人能够设计（符合使用BPMN的图形设计）符合所有相关资源生命周期的业务流程。 假设您创建了这样的模型，那么假设您现在创建一个流程变体。 如何保证资源生命周期不受影响？ 您需要执行多少QA来验证这一点？
流程和资源生命周期只能在流程实施期间进行协调，并且可能会“弯曲”流程以确保其符合生命周期。 只能由开发人员仔细地映射BPMN中表达的业务分析师的需求并重用管理其组织核心资源生命周期的企业级服务，才能执行此活动。
现在，让我们看一下业务分析师如何使用BPMN创建作业应用程序业务流程定义：
图5.职位申请流程（蓝色组代表人工任务边界）
首先，BPMN没有“资源”的概念，也没有一个 “生命周期”的概念，充其量只有一个人可以在流程的给定点用预期状态来注释其BPMN定义（如上所示）。 很好，这就是BPMN应该的样子。 其次，业务分析师完全不知道将在作业应用程序服务上调用以提高其状态的操作。 它们属于系统视图。 期望业务分析师在他或她描述为用户活动的活动之间添加“调用”活动是完全错误的。 不幸的是，人们在BPMN和BPEL之间建立的关系是错误的关系，他们最终在流程符号中添加了Send，Receive和Invoke的核心BPEL操作语义。 这完全是人为的，切勿使用，除非接收或发送的消息是商业消息，而不是作为被调用的操作（例如，到达招聘人员办公桌上的工作申请）。
业务流程如何实现？ 业务流程执行环境是彼此交互的服务的集合（图6）（不是集中编排的服务集合）。 业务流程的交互实现了资源的生命周期以及人工任务，事件和简单服务调用的执行，从而推动了流程的发展。
图6.作业申请流程的实现
令人欣慰的是， 我们已经拥有实现这一愿景所需的所有技术，包括组装技术： 服务组件体系结构 。 您可以通过组合使用SCA 1.0，BPEL 2.0，Web服务（由于BPEL 2.0而使用XSD和WSDL 1.1），BPEL4People 1.0和Human Tasks 1.0来实现在此图中看到的所有内容。
在此BPMS体系结构蓝图中，Bruce 先前所做的声明是 ：
使用BPEL，您无权忽略不支持的元素。 BPEL是BPEL，您必须支持规范中的所有内容。 其余的称为专有扩展。 它们生活在自己的名称空间中，对BPEL 1.1的有效批评是实际流程需要太多的流程。 在BPEL 2.0中要好一些，但是人工任务，子流程和其他基础仍然需要在2.0中进行扩展，例如几乎是神话般的BPEL4People。
不再适用。 WS-HumanTask和BPEL4People属于任务容器，并且确实与BPEL本身分离。 现在您可以争论BPEL是否需要“子流程”，但是我想说，作为资源生命周期服务的一种实现语言并不重要：状态机中很少有可重用的元素，它们紧密地属于其资源。
此时，并且很不幸，Microsoft尚未加入SCA或BPEL4People，因此即使可以完美地完成工作，您也无法使用Workflow Foundation替代BPEL引擎。 但是，您可以将WCF用作实现可以从SCA和您最喜欢的BPEL引擎调用的服务的服务容器。 Microsoft本身没有组装机制，因此您甚至无法在.Net中实现此体系结构蓝图。 在开源方面，您拥有大多数组件（ SCA ， BPEL和Service容器 ），但是缺少BPEL4People容器。 这并不是很关键，基本的人工任务容器实际上并不太难构建（但不必达到BPEL4People和WS-HumanTask的水平）。
为了了解开发人员在这种新体系结构中的作用，让我们集中讨论流程模型的“ Schedule Interview”活动（图5）。 如您所见，该活动是流程模型中的特色（这是有道理的，因为如果工作申请系统停机，这是用户必须要做的事情），但是作为一种优化，它是由企业决定的。例如，调度任务将在交换服务器之上自动执行。 求职申请生命周期提供了挂钩（即要求），在保留候选人的申请后安排面试。 请注意，作业申请服务不知道该如何实施。 这也可能是人类的任务。 根据我的理解，完全不可能自动解决这种设计决策。 这就是为什么流程模型必须与任何执行语义完全分开的原因。 不会影响流程定义的另一个设计决策是，候选应用程序可能会在其他人工任务容器中发生。 我们很可能会通过在流行的职业网站上进行候选人申请来“组合”此过程。 申请被批准接受面试后，一项活动将向候选人发送电子邮件，以将他或她指向处理任务（审阅报价，输入就业信息）。 我敢打赌，您无法使用当前的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业务流程的原始B2B流程定义模型，而是在资源级别而不是业务伙伴级别应用，这就是执行模型的原因在组织内部和外围与业务合作伙伴交互时，它们是连续的。
谬论6：可以轻松地从现有的编程概念中得出业务流程执行语义
我在“执行”标准工作组中遇到的几乎每个人（例如BPML，BPEL，WS-CDL）都不是实践者（包括我在内）。 他们是开发商和建筑师。 他们经常专注于复杂的数学理论（例如Pi-Calculus ），而没有验证这些理论的语义是否真的足以支持业务流程执行。 通常，这些技术委员会将专注于3至5个用例来编写其要求。 这些用例通常很琐碎，很少反映业务流程的“实际”复杂性。
业务流程执行语义很难概念化。 实际上，如此困难，以至于大多数可执行过程仍然很难在我们的解决方案中硬编码，一次只能一行。 如果有更好的方法，我相信每个人都会接受它。 鼓励我阅读“为什么Java开发人员讨厌BPM？”中的评论。 讨论 。 没有人抱怨抽象的有效性。 甚至包括代码Kahunas，例如JBoss的首席架构师Bill Burke（在他加入JBoss之前我们一起构建一个人工任务容器时，我都曾与他短暂合作过）也评论道：
我认为BPM也是如此。 那无非就是XML脚本和开发人员的愚蠢。 在我真正开始研究BPM框架之前……我没有看到这些框架必须提供的附加值。 当我开始考虑[关于它们]一个可靠且容错的状态机时，我真的开始看到了BPM框架的潜力。 然后，当您开始将事务管理和薪酬的使用与业务流程结合在一起时，在开发应用程序时便有了一些不错的抽象概念。
根据我在上一节中解释的内容， 他和其他人的陈述朝着正确的方向发展。 开发人员现在看到了必须一遍又一遍地编码状态机的困难，以及通用引擎如何减轻他们的工作（在大多数情况下）。
谬论7：布鲁斯· 西尔夫（ Bruce Silver）在其文章的结尾总结道：“协作实现范例是将可执行设计置于BPMN模型之上的方法。”
Bruce认为，业务流程模型的实现应从BPMN中表达的业务流程模型驱动，并相继添加注释（与开发人员协作）以实现可执行流程。
不幸的是，这种远景没有考虑到业务流程的实际情况（作为提高资源状态的活动的工作流程），我希望我相信您，即使从概念上说，这是一项有效的努力，但这种陈述不能说得更多。错误的，因为我们无法同时对活动和资源生命周期的工作流程进行建模（至少在我所知的当前状态下）。 我可以预见，在相当长的一段时间内，开发人员会将业务分析人员产生的流程定义转换为人工任务，资源生命周期服务和服务（包括决策和MDM服务）的组合。
现在，这个新的体系结构蓝图并不意味着您在自己喜欢的BPMS上进行的投资就丢失了。 但是，您将需要添加一个复合服务容器（例如BPEL容器）和一个组装容器（SCA），并将您的BPMS大部分用作人工任务容器（无论如何，它们实际上实际上是大多数）。 人工任务容器是体系结构中的重要组成部分。 当前的BPMS任务容器非常复杂，很难自行构建，因此花了很多钱。 我根本不想破坏这个容器的作用。 我实际上期望，在不到两年的时间内，所有BPMS供应商都将采用本文提出的愿景，并根据此蓝图将其套件转换为可在SCA组件和BPEL容器中使用。
我还认为，在实施结束时，可以自动重新构建操作过程的“现状”视图。 我还没有证明，这可能成为研究课题。
结论
在寻找BPM Magic Bullet这么多年之后，软件行业面临一堵墙。 通过范式转换和基于资源生命周期的业务逻辑的新分解，可以轻松克服这一难题。 如果我们今天走错了方向，但仍然相信在这7个谬论中，我们将冒着由于缺乏ROI而不得不丢弃所有这些产品和标准并返回手工编码的风险。 但是，如果我们采用与当今相同的技术并以不同的方式使用它，那么我们可以提供对企业和IT都非常有吸引力的愿景。 我不会将其称为BPM 本身 ，它比BPM大，我宁愿将其称为“复合应用程序”或更确切地说是“复合解决方案”。
复合解决方案愿景直接说明了IT部门的业务需求：
- 使用尽可能小的项目快速构建解决方案（依赖多次迭代）
- 快速更改解决方案并支持迭代的精益六西格玛方法
- 能够可视化当前正在运行的业务设计，而无需复杂的“当前状态”项目
- 无需复杂的评估项目即可从当前业务设计中获得运营情报
我认为，“能够通过创建/更改业务设计直接构建/更改解决方案”的能力（无论看起来多么理想）都与这四个要求相反。 原因是因为它导致了简单而僵化的以任务为中心的应用程序模型（正如我们今天在BPMS中所看到的）。 这些应用程序模型不能满足业务需求，通常会导致项目成本增加，因为当需要开发实际的解决方案时，它们需要围绕BPMS应用程序模型进行大量定制开发。 使问题更加复杂的是，“为什么Java开发人员讨厌BPM？”指出了这些套件。 讨论 ，尚未为该自定义代码提供健壮的开发环境，并且不适用于大型项目。
我认为前进的愿景是复合软件（基于两个组成模型：组装（SCA）和编排（BPEL））-当然，编排正在走下坡路-当然，但是我将在另一篇文章中对此进行解释。开发此蓝图的技术已经可以使用，此外，今天定义的BPEL和BPMN可以正常工作，如果需要在BPMN中进行某些更改，则应删除所有执行语义，并设计其目的是让业务分析师如果您想了解有关如何使用这些标准和体系结构蓝图构建复合软件的更多详细信息，这本迷你书将在上周于InfoQ上发行。
如本文所述，复合解决方案平台的体系结构还提供了SOA和BPM之间更简洁的接口 。 它为SOA提供了构建真正可重用服务的机会：可以在流程域和流程变体之间重用的资源生命周期服务。 由于这些资源生命周期服务可在各个流程之间重用，因此这也意味着任何给定流程的实施都变得更加便宜，快捷和容易。 资源生命周期服务的实现是流程中的“代码”。 认为业务分析师（或其他任何人）将具有在流程定义中以图形方式对这些生命周期进行编码和重新编码的知识，这仅仅是在将BPM推向错误的方向。
该蓝图作为一个复合解决方案平台，已经拥有一个可以支持它的企业方法： Praxeme 。 普莱克斯学院（Praxeme Institute）正在用英语翻译其文物，并朝着这一目标取得了巨大进展。
现在，我确实与Bruce和Marlon共享了一些让开发人员参与当前技术（SCA，BPEL ...）的担忧，这就是为什么我启动了一项名为wsper的计划的原因 。 该计划提供了一个抽象的编程环境，可以简化生命周期实施和流程组装过程中开发人员和架构师的工作。 它还帮助从异构组件构建复合解决方案平台，因为它将业务逻辑实现与这些组件（及其未来的发展）隔离开来。 它还将业务逻辑与标准的发展隔离开来。
我要感谢Sandy Kemsley提供了许多有用的链接和评论。
[1]本文是对Dominique Vauquier的文章（“业务流程改进的6个谬误”）的补充。 在这里，我们专注于业务流程建模，因为它可以转化为执行。 Dominique的文章探讨了业务流程建模与业务流程改进项目之间的关系。 我翻译了多米尼克的法文文章（该文章 已于2008年1月 在 BPTrends.com 上接受发表 ）。 对于那些阅读法语的人来说，可以在Praxeme企业方法的“ 务实方面指南”的第39页上找到该文章。
逻辑谬误
扫一扫
2025
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
