BPM之大局势（2008版）

BPM之大局势（2008版）

在《工作流之大局势》2004版中，笔者向大家推荐了Shark系列工具，推动了Shark工作流引擎在国内的流行；在Shark大红大紫发展到最顶峰之时，《工作流之大局势》2006版向大家隆重介绍了jBPM开源产品，并预测了BPEL的发展。

到今天，jBPM已经成为开源工作流领域最受欢迎的开源产品（这个好像不需要给证据了）；而BPTrends报告告诉我们，当今的BPM市场中，BPMN、BPEL占有的市场份额分别为41%、26%，远远超过日渐式微的XPDL（6%的市场份额）。

《大局势》发表后的2006年，我以个人名义为深圳国税局信息中心等多家企事业单位提供BPM技术/产品咨询与培训，赚钱的同时一直在思考工作流、BPM相关技术、产品的最终目标。在技术开发、项目实施、BPM咨询、技术培训的过程中，我发现工作流技术还是存在这样那样的问题。在查找了很多的资料以后，我带着这些问题进入了现在的公司做SOA、BPM方面的架构设计工作。

         2008版的《BPM之大局势》就是这两年的架构设计工作经验的总结。

1 BPM总体局势

1.1      我的观点

我的观点，有这些来源：这两年的技术架构经验；这两年与外面的客户和朋友的技术交流；这段时间与同事的交流（很多同事的好的PPT总结）；这两年看的>20本的BPM与SOA方面的书。这些观点大都与公司的看法相同，但是本文并不能代表公司观点。

         观点一：在2009年到2010年底，BPEL将发展成为BPM（工作流）的流程执行语言标准。这个观点更多是从开源领域来做的判断，我预测开源BPEL引擎将在这两年出现井喷。大概估计项目实施中会有一半是基于BPEL的，基于开源的项目实施中会有70%是基于BPEL引擎的。（不了解BPEL与XPDL区别的请看我写的BPEL本质论）

         观点二：在2009年到2010年底，BPMN将发展成为业务流程建模的标准。但是只有它的图形化notation会被大量利用，BPMN语法和语义不会有太大的发展。

         观点三：软件工程领域，业务与技术的一致性将首先在BPM领域得到实现。BPM领域建模、设计、开发、部署的一体化将在2012年左右得到技术支撑与实现。（这个观点隐含的意思是：需要的软件技术人员的素质将越来越高，刚毕业的学生将没有办法实施项目，因为他的综合能力还不够、也没有任何的业务经验）。

         观点四：BPM将会和SOA有越来越多的联系。（我知道很多人对SOA有其他看法，现在也是SOA发展的平原期。但是我还是这个观点。SOA方面的内容我将另外写文章讨论，或者如果我没有时间写文章，大家找我讨论也可以，当然有限于有一定的理解的朋友）。

1.2      Gartner的观点

BPM（业务流程管理）的概念由Gartner在2000年提出，在后来的2005年，Gartner为BPMS（业务流程管理套件）下了明确的定义，并在2007年对这个定义按市场情况做了扩展。

2006年，BPM的市场规模是17亿美元，Gartner预计2011年将达到51亿美元，年增长率为24%，是软件领域的第二块增长市场。

Gartner对BPM领域的技术生命周期分析结果图如下：

<!----><v:shapetype o:spt="75" coordsize="21600,21600" filled="f" stroked="f" id="_x0000_t75" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t"><v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path o:extrusionok="f" o:connecttype="rect" gradientshapeok="t"></v:path><!----><o:lock v:ext="edit" aspectratio="t"></o:lock></v:shapetype><v:shape o:spid="_x0000_i1025" id="图片_x0020_1" type="#_x0000_t75" style="VISIBILITY: visible; WIDTH: 6in; HEIGHT: 324pt"><v:imagedata src="file:///C:\DOCUME~1\Owner\LOCALS~1\Temp\msohtmlclip1\01\clip_image001.png" o:title=""></v:imagedata></v:shape>

<o:p> </o:p>

图一： BPM技术生命周期  （来自Gartner）

技术生命周期可以从两个方面来分析：“技术可见性”和“技术采纳速度”。

技术可见性

Gartner认为每个技术的发展趋势，都符合同一个曲线图：首先是技术产生；被媒体宣传后，用户对技术产生过高的期望，认为可以解决自己的所有问题；当用户发现这个新技术的缺点后，技术发展进入萧条期；部分用户试用新技术，这个技术慢慢被更多的人接受；发展一段时间后，进入平原期。

在BPM领域，Gartner认为BPP（业务流程平台）处于产生期，BPMS（业务流程管理套件）处于顶峰期，Pure-Play（单一类型工作流）处于萧条期，BPA（业务流程分析）和BRE（业务规则引擎）处于平原期。

本篇将把BPM按业务流程的类型分解为系统密集型、人工密集型、文档密集型和规则密集型分别进行讨论，以此讨论BPMS的技术发展特点。

技术采纳速度

Gartner认为技术被主流采纳的速度，与技术的生命周期并无关系。有可能一个新技术的生命周期很长，但是一直没有被主流采纳；有可能一个新技术发展到了萧条期，但是主流采纳率还是很高。

技术采纳速度表示某个技术过多长时间会被主流认同。在BPM领域，Gartner认为，BPMS、BPA（业务流程分析）和BRE（业务规则引擎）会在两年内被主流采纳；SOA（面向服务架构）会在2-5年内被主流采纳；BPP（业务流程平台）会在5-10年内被主流采纳。

2 BPM产品发展局势

Gartner有个Magic Quadrant的图表，对全球最牛的BPM产品做过分析，一般是把它和上节的Hype Cycle联合起来使用的。不过我这里不用它的观点了（需要这个图的可以留下联系方式，我把PDF发给大家看看），我用bruce silver的观点。

Bruce silver是个独立的BPM评论家（和古时的言官一样，专门写批评文章的人），也做BPM的培训。他对BPMN还是蛮懂的，是我的BPMN启蒙老师；但是他对BPEL其实并不真正懂（当然了，我是从技术角度做的要求，好像有点过份了）。

按我以前的习惯，本文把BPM产品分为三大类：豪门、中产、寒门。

2.1 BPM豪门产品

豪门指的是这几家：IBM、Oracle、SAP（来还有BEA的，不过已经不存在的公司，就不说了。）

豪有一个共同的特点：就是他们不只是做BPM，一般来说他们同时也是SOA厂商。豪门的产品多，历史负担重；所以他们的产品使用过程都很复杂（请参考Oracle的产品包袱）。他们的市场主导能力一般都比较强，所以他们一般要把产品卖得很贵，而且不太考虑技术人员的方便性。

豪门BPM产品是这样的情况：支持BPMN建模，导出BPEL文件；另外支持BPEL编辑，但是不可以导回到BPMN中去；流程引擎基于BPEL。Bruce silver用Roundtripping Revisited 骂了这个做法。

2.2 BPM中产阶级产品

BPM领域的中产从Gartner的Magic Quadrant图表而来，并且只取其中的“领导者象限”的公司的产品。在Magic Quadrant图表中，这些产品比豪门的产品要更具有技术前瞻性。

这些中产包括：Appian、savvion、pegasystem。

Appian 基于 BPMN 建模，业务与 it 共用一种模型。 Appian 设计和管理工具都是基于 BS 结构。在设计过程中分析人员可以定制模型，具体代码可以在 Appian 的 studio 中实现。 Appian 的表单是基于 Web 方式的定制。 Appian anywhere 是第一款基于 BPM 技术的 SaaS 产品。

Savvion Business Manager是一款非常成熟的BPM产品， 人工流程功能较为强大，其策略是提供免费的建模分析工具，基于 BPMN 建模。并建立相关流程分析社区。

SmartBPM 包括 PegaRULES Process Commander, Process Analyzer, and Process Simulator, 和一些其他的模块。其中 PegaRULES Process Commander 提供了一种以规则图元的方式统计建模。可以向 BPEL ， COM 等各种技术暴露接口，也可以调用 BPEL ， MQ 等格式的接口。目前提供了 BPM as a service 平台。其中以人工活动最为著名。

说明一下，上面的内容来自于我们公司的特务机关：竞争情报分析小组。感谢这些特工们！

中产BPM的产品特性是：在BPMN上添加属性，用BPMN作为业务建模与设计建模的唯一标准，这种解决方案是不存在Roundtripping的问题的。Bruce silver比较同意这个做法。

2.3 BPM寒门产品

我主要还是做技术的，从2004年用Shark和jBPM开始，我就在学习使用BPEL；后来在项目实施中也使用了jBPM_BPEL。最近两年在工作之内和工作之外主要使用、改造了下面的BPEL引擎实现：jBPM_bpel；ODE；ActiveBPEL。所以本节是本文的重点，这三个开源的BPEL引擎实现也是我推荐的重点。

jBPM是基于jPDL实现的工作流引擎，相信很多读者已经有所了解。jBPM_BPEL与jBPM_jpdl共用了同一个内核，实现的方式和理念基本完全相同。jBoss正在把他们的共同点抽取出来，取名PVM（流程虚拟机）。PVM上面可以运行jPDL、BPEL、页面流等流程语言。jBPM_BPEL是API驱动的BPEL实现，没有实现Bpel4People，默认运行在jBoss上，提供jms方式的对外API。但是我以前用的时候，是改造为tomcat上运行的。这个改造有一定的工作量，如果想在tomcat等servlet容器上运行，而又不是非常了解BPEL的基础，且没有外界咨询人员的培训或者帮助，推荐用ODE或者ActiveBPEL。

ODE在apache下面，是Intalio捐的开源项目。ODE是基于axis2实现的BPEL消息接收器，比较合我们开源人的胃口。ODE只实现了BPEL规范，没有实现Bpel4People；Intalio另外有个开源项目叫 Tempo，实现了Bpel4People，但是这个项目没有被Apache接收。Tempo对B4P的实现不纯，有很多自己的特有的技术点，被Apache否决掉了。

ActiveBPEL相信大家都知道了，我在04年就写过关于他的文章，不过那时版本比较低，也只是简单的用用。最近在扩展它的最新的开源版本。ActiveBPEL支持B4P，是目前最完善的BPEL引擎。

欢迎同大家交流上面三个产品的架构、使用场景、扩展支持等内容。

3     BPM技术发展局势

这里的技术发展局势还是会结合前面的Gartner 的Hype Cycle图来进行分析。

3.1 系统密集型BPM

系统密集型BPM的特点，是在应用系统之间，通过实时消息的方式或者定期执行逻辑代码的方式，来实现松耦合的逻辑或者数据集成。它对应了图1中的BPM for C&SI（系统集成的BPM）和Integration Suites（集成套件）。

Integration Suites通过高效的实时消息，在异构系统之间转换和传递数据信息，它为各应用系统提供了统一的集成方式（这个方式是企业内部标准），也提供了可伸缩的技术平台，为消除信息孤岛起了很大作用。Integration Suites的缺点是人工操作支持不足、业务建模与流程建模脱节，所以它的发展处于平原期。

BPM for C&SI有Integration Suites所拥有的一些优点，并在功能特性上做了一些扩展。BPM for C&SI在流程运作中不支持人的参与，但是在业务异常时，可以有灵活的机制通知责任人进行处理；可以通过技术适配器或者定制适配器把应用系统的逻辑和数据封装成Web服务；可以利用应用系统本身的Web服务；还可以利用第三方ESB提供的Web服务。

从图中知道，BPM for C&SI发展处在高峰期，Integration Suites处在平原期，他们都要过2-5年才能被主流所采纳。

3.2人工密集型BPM

人工密集型BPM的特点，是流程的参与者以人为主，关键的流程流转由人的处理结果决定。它对应了图1中的BPM Pure-Play Tools。

人工密集型BPM是一个以工作流引擎为核心、由流程管理系统与个人消息桌面两部分