BPMN有大量的只是用于产生BPEL的属性，这些一般都可以被忽略。
通过完全忽略BPEL，一些更小的公司开始示范了BPM购买者和行业分析师的成功做法。像Lombardi、Appian和Savvion这样的厂商，把精力放在以人为中心的过程而不是集成。这样导致了一种新风格的BPMS，其中可执行的设计直接建立在过程模型之上，以BPMN活动的实现的属性的形式。
这种工具本身鼓励整个实现周期中业务-IT的协作。并且非常适合敏捷迭代方法论，这种方法显著地缩短了从模型到已部署的解决方案的周期时间。
你不能仅仅因为从来没有业务分析师愿意书写一些类似XPath表达式或其它表达式语言，就将开发人员排除在BPM生命周期之外。
事实上，如果[他的BPMN使用者]已经做出了他们BPM运行时的决策，那么它通常就是BPEL。它是一个标准、一个日用品，而且可以找到开源实现。它被IBM和 Oracle用在他们的BPM运行时中。因此，在选择BPEL时有强制性因素。但是BPMN和BPEL不是都在进行标准化吗？不，这当然不合逻辑。
在“双向工程已死”营地（roundtripping-is-dead camp）待了大约一年之后，我现在发现自己不得不再次面临这个问题。在我的BPMN培训中，例如，学生想要知道在他们的BPMN图中使用什么策略或模式才能非常匹配他们期望的BPEL实现。这并不是我一开始期望去考虑的问题。
未来工作的一个可能方法是扩展提议的技术，覆盖BPMN模型更大的子集，如对相关的异常处理和其它高级结构（如OR-joins）建模。不幸的是，BPMN的许多高级结构并没有细化，依旧处于由相关标准化团体改进的过程中。使用BPEL你没有忽略你不支持的元素的自由。BPEL就是BPEL，你必须支持规范中的一切。剩余的被称为私有扩展。它们只存在于它们自己的名字空间，BPEL 1.1的一个有根据的批评就是一个真正的过程需要太多的元素。BPEL 2.0要好一些，但是人工任务、子过程和其他的基本的东西仍需要2.0中的扩展，如，近乎神话的BPEL4People。我认为BPM也一样。只不过是编写XML脚本，开发人员并不把它放在眼内。直到我确实开始深入BPM框架……我并不认为必须提供这些增值框架。当我开始把它们当作一个可靠的和容错的状态机思考的时候，我开始真正意识到BPM框架的潜力。然后，当你结合你的过程和事务管理与补偿使用时，你就得到了一个真的好的抽象，这在你开发你的应用时可以派上用场。