要是驾校的教练去出演像《速度与激情》这样的动作电影，我敢打赌他们给人的印象肯定有所不同。有人说：“他们应该更快绑好安全带。”这种分离类似于当今的业务流程管理。

　　业务端可能购买工具并模型化流程，但是却将其留给应用集成团队中的开发者，让他们来使其同企业软件服务一起运作。

　　业务端看到的是帅气的幻灯片和银行里的钱；开发团队看到的则是服务和流程之间错误匹配产生的危险阻力。业务端拥有愿景，而开发端来收拾烂摊子。这也是一定要跨越的桥梁。

　　实际上，人们一直期望分水岭的出现。的确，业务流程建模工具已经改善了很多，业务分析师在BPM/SOA环境中进行了更多的建模工作。但是这项工作和交付出的业务流程模型必须小心对待。开发者仍旧经常需要为前端业务模型用户创建一个有用的沙盒，以便业务建模者不会在SOA基础架构上实施的时候以构建糟糕的流程而终。

　　在考虑到最近出现的BPMN 2.0时,这种想法就冒出来了。BPMN 2.0表示法的出现是为了改善业务端建模者构建标准业务流程描述的能力，这种描述通过BPEL或者其他含义来执行。

　　但是BPMN 2.0建模真的很容易吗？业务用户是否准备好了呢？BPMN表示法非常类似流程图，因此就不会比原始计算领域的流程图更容易或者更难。当然业务端也有人可以根据流程图符号思考。但是他们可能不是大多数。如果要是让他们开始500多页的BPMN标准文档，这些人可能就更少了。

　　BPM建模工具可能已经改进了，但是公平地讲业务架构师和软件架构师仍将必须进行协作，从而实现可成功执行的业务愿景。

　　我们最近同Active Endpoints公司的CTO Michael Rowley探讨了BPM、BPMN、SOA和BPEL问题，他所在的公司就是BPMN 2.0的贡献者之一，同时也是BPEL4People OASIS标准的编者。他建议，有效和无效的方式进行跨团队流程/开发架构要同时存在。

　　“BPMN 2.0刚出版时，有人认为这将很好地适用于那些属于Visio的人。然后，他们发现有好多可以做的。有很多图标需要学习，都是非常具体的，”他说。

　　“我们惊讶于BPMN 2.0怎么会如此细节化。但是这是一件很自然的事情，给出目标，允许你来设计任何事情，任何的流程，还要让他可以执行，”Rowley说，“那确实需要很多技术细节。”

　　“在没有改变尝试实现的任何目标的时候，就不肯尼个让BPMN更简单，”他说。

　　BPMN当然也交付了很多好处。它的支持范围很广泛，你可以想象成一个不断成长的熟练实践者池。它可以精确描述流程。具有可执行性。它的标记可以为IT和业务人员共享。

　　恒定协作，在Rowley看来不是一件必须的好事。“每次业务端在绘图中改变了什么，他们不用必须反馈到开发端，”他说。业务端的人员也不应该负担学习像WSDL这样的编程问题，他说道。

　　“我们认为正确的途径就是业务和IT用户减少频繁的协作，”他说。这也可以成功实现。如果开发端预安装服务活动。这些就转变为安全的建模元素，业务端可以用来描述他们的工作流程。