工作流管理《你服务，你全家才服务》

我的工作流新书出版了：http://book.douban.com/subject/25883177/

在拥挤的公交车上读完《工作流管理(模型、方法和系统)》，自从搬完家，上班的路途突然变得遥远。

这本书确实是按照它的副标题组织的，分别介绍工作流的建模模型、应用工作流开发的方法以及部分商业的工作流产品。

对petri网的介绍是这本书的重点，如果想对petri网有个大概的了解而又不愿意接触深奥的数学，那么可以一读。本书随后分析了如何对流程模型进行分析，包括对建模正确性与否的定量分析以及对资源运行效率的定性分析。至于介绍的工作流产品，因为年代久远，可读性不高。应用工作流开发的方法就更是理论了，不过作为一本2000年的书，里面提到的一些原则还是很有敏捷的意思，例如和客户在一起、迭代开发、交流的重要性等等。

读完这本书，加上先前的范玉顺的书，突然就明白为什么BPEL会如此之流行，原因在于它们都非常强调BPR的概念，即业务流程重组。从一开始，工作流系统就是瞄准BPR这个目标来的，想利用工作流系统将整个企业的业务流程都管理起来。目标如此远大，整合自然是不能避免，整合包括了对人员工作的整合，也包括了对IT系统的集成。如此以来，恍然大悟：BPEL这种强调服务集成的执行语言自然会大红大紫。至于说国内最普遍的工作流应用：将工作流引擎嵌入应用系统中，分离流程逻辑与业务逻辑，则自然登不了大雅之堂了。一句话说，就是国内应用工作流的层次太低。或者反过来也可以理解：现在的所谓BPM软件都眼高手低，不太适合国内的应用。

可是问题依旧存在，即BPEL根本上说是一种执行语言，要业务人员理解简直是强人所难，所以BPMN应运而生。好吧，BPMN有了，自然BPMN到BPEL的映射就出现了，可惜这终究是一厢情愿，一种是业务建模语言，一种是计算机执行语言，中间的代沟比70、80还宽。就像科比，篮筐在他眼里比大海还广阔。

此外，BPEL的应用还存在一个天然的障碍，即应用集成从来都不是一件轻松的事情。将接口用web service包装一下就SOA了？就面向服务了？这鬼话你也信，那可真是你服务，你全家才服务呢。应用集成不轻松，所谓的企业敏捷性：能够根据外部环境的变化迅速调整服务编排流程那自然是镜中月，水中花了。君不见，无数程序员们在开口大骂：靠，流程又要调整，早吃屎了？！

所以结论有三:

1、国内的嵌入式工作流应用还是什么适用就用什么吧，和XPDLBPEL都无关；

2、一心要SOA、要BPEL。那别指望它能减少工作量，也别指望流程能够迅速修改；

3、要对企业流程进行敏捷管理，那就考虑文档化，别考虑执行。