过程开发的过程
在知道了这些之后，我想勾勒出一个对于业务过程自动化更实际的分析和开发过程例子。首先，一个分析员创建了一个包括图的业务过程描述。然后需要将它翻译成可执行过程语言。这种翻译的影响将取决于这个分析员的技术技能和可执行过程语言的能力。任何情况下的目的都是使转换对图影响最小，这样业务分析师才能认识和理解可执行过程图。注意，图只是冰山的一角，因为对分析师毫无兴趣的可执行过程将包括大部分的技术细节。翻译之后，可执行过程就成为了一个软件，非技术出身的业务分析师只允许以只读方式查看它。
BPM带来的巨大优势是分析员和开发者拥有一门公共语言。图方便了业务分析师和开发者的沟通。这的确实现了由BPM带来的‘敏捷’。但是幻想出现业务分析师在编辑图表之后点一下‘发布成产品’按钮就万事大吉的情景显然过于乐观且不现实。
建模细节
这节将论证这一观点：当需要在分析图和可执行过程间建立直接关系时，图中不要包括太多的细节。参与BPMN的人员背景是不同的。当人们仅仅只站在BPM的分析模型或可执行过程侧面看问题的时候，他们必然会象Frank McCabe在一次OMG会议中所发表的报告那样感到惊讶：
关于BPMN和BPDM的关系有些争论：BPMN‘仅仅’是一个符号，或者它确实有某种语义？所有的这些对BPMN团队来说都是新闻，因为他们（包括我）都愉悦地认为我们正在努力定义一种语言。对于我们来说，最大的问题好像是关于BPMN图的执行语义；对其他人来讲，它只是一个图形符号，完全不需要我们操心执行的事儿。你可能会猜到事情接下来会怎样。
这表明建模专家需要一种非常准确的符号以便在图上能放置大量的信息。作为一种帮助记录业务过程的分析语言，我认为BPMN是一个很好的选择。David Chappell提倡建模层次的移植性和实现（可执行过程）层次的移植性至少同样重要。
想一想我们一直以来想要达到的目标，过程逻辑的移植性——把实现从一个平台移到另一个平台的能力——无疑是其中之一。但是人的移植性——允许我们把技能从一种过程设计工具转移到另一种工具的能力——也很重要。BPEL潜在地可以帮助完成第一个目标，但却不适合第二个；大部分创建过程的人从来不会直接使用这种复杂的基于XML的语言工作……正在崛起的图形化定义过程的标准就是业务过程建模符号（BPMN）。如果BPMN得到广泛的支持——这好像是可能的——它将使人的过程设计技能可以移植。
这让我得出这样的结论：假如要将过程建模绑定到可执行过程上，过程的图形化表示不应该包括太多的信息。当在你的组织中使用BPMN来进行过程建模的时候，最好引入一个更基本的子集，并且只使用它们。因为，试图在图形化的图表中表达太多的细节需要所有人都能理解它们。图形符号中的细节越细，它们与可执行语言匹配的机会就越小。BPMN符号细粒度细节的复杂性不应该被低估，且应该只用在与可执行过程没有直接联系的大型业务分析师团队中。
因此，我认为过程语言（可执行的和非可执行的）的区别太明显，以致于不能把它们统一到一种基于BPMN的图形过程设计器中。我确实认为为每一个过程语言都可定义一个与之很好匹配的BPMN子集。设计工具应该直接支持特定于这种语言的结构和适当粒度的细节。我可以预见到这样的一种工具，其中设计者可以在不同过程语言间切换身份。但是在每一种情形中，使用者都很清楚用哪种语言建模和开发过程。同样，作为一个非执行的分析语言使用的普通BPMN，是那些单独的语言之一。工具可以帮助处理转换，但每次都是一个有损，单向的转换。
映射和失配
BPMN的映射方式会使双向工程出错。双向工程的思想是在BPMN分析模型和可执行过程之间可以不断地切换。业务分析师使用象BPMN这样的建模语言，使用图形符号和BPMN属性；开发者使用象BPEL这样的可执行语言。很明显，这种方式的问题在于在实际应用中很难维护两套属性。即使在两个视图中可以共享一些属性，但是业务分析师和开发者仍然会因为一个属性在BPMN和BPEL中含义不同而难以相互沟通。另外一个问题是工具厂商很难创建一个支持无损双向工程的工具。
既然BPMN和BPEL正在成为最受关注的BPM技术，让我们进一步看看两者的映射。第一个也是最显眼的问题是两种语言的结构不匹配。BPMN是基于图形的，而BPEL是一个没有变迁的树形组合结构。第二，两者的并发模型差异巨大。Bruce Silver对此有很好的总结：
如何使过程模型（如BPMN）和对应的BPMN实现（如BPEL)保持同步，就是我们所说的双向工程问题……如果你一直在跟踪BPMN Watch上的这个话题，你就会记得BPMN让你画出的东西并不能很方便地映射到BPEL——至少映射到一种你愿意编辑和维护的BPEL，但BPMN的有些子集是可以自动映射的。假如是你控制BPMN工具，你可以通过禁止用户画那些不能映射的东西来解决这个问题。
