论道WP（三）：应用程序栏
作者通过具体翔实的例子介绍了Winodws Phone 7中应用程序栏的使用方式。
文章
该内容已经被标记书签！
标记书签错误，请重试！
国内主要工作流厂商分析
作者 荣浩 发布于 2011年2月28日
尽管在企业应用中工作流应用的越来越多，但对国内的工作流厂商们来说，这并没有给他们带来期望中的快速增长，这并不奇怪，因为国内工作流产品基本上全部面向开发者和系统集成商，解决的是编程问题，旨在简化对流程进行支撑的软件创建，这个定位决定了当越来越多的系统集成商开始自己研发工作流和越来越多的开发者采用开源工作流时，原有的工作流厂商发现生存日益艰难。
在这篇文章里，我们将一起回顾一下国内主要工作流厂商的产品以及发展策略，接着讨论他们当前所面临的困难以及未来的机会。这里分析的工作流厂商包括了东方易维、西安协同、普元、炎黄动力、有生博大、华创动力、携创、天翎、博汇数码、中创、浪潮以及台湾的华芩。
一、 现状
大部分的工作流产品都实现了WFMC工作流参考模型（参见附录）的接口1、接口2、接口3和接口5：
- 接口1，流程设计器：包括了两种类型的设计器，一种是基于Web的设计器，实现技术包括了Swing和Flex，一种是基于Eclipse插件的本地应用实现。除去普元之外，大部分工作流产品都选择实现了一种类型的设计器。Web设计器的好处在于对最终用户友好，基于Eclipse的设计器的好处在于对开发人员友好，能够比较容易的进行单元测试和流程测试，缺点则是基本上隔绝了最终用户对工作流的使用，将工作流死死限制在开发者的层次上。普元同时实现了两种类型的设计器，是做得最好的厂商，东方易维和西安协同实现了基于Web的设计器，通过流程仿真来弥补测试的不足。
- 接口2，工作项客户端接口：通过API暴露调用和交互接口，完成工作项的列表展现、拾取、退回和提交。
- 接口3，外部应用调用接口：基本上都没有对主流ERP、企业管理软件和财务软件进行集成的专有支持，这和国内工作流产品应用的场景有关系，工作流多作为支持单个应用的嵌入式使用，在这一点上天翎提供有与SAP的集成接口。大部分通过支持Web服务调用进行支持。
- 接口5，管理控制台：包括两部分，一部分是对运行中的案例进行监控和干预，包括了案例的中止、挂起与恢复，任务的中止、跳过、挂起与恢复，参与者的重新指定和催办，工作流变量的修改查看等；一部分是对案例的统计与分析，包括了针对案例、任务的时间统计，针对参与者的任务效率统计等。
除去对工作流参考模型的支持，基本上所有的工作流产品都实现了电子表单，在处理以数据填报及数据收集为主的应用中（数据不需要过多的逻辑处理和没有复杂的关系关联），电子表单能够显著的增加生产力，但是更现实的情况是企业应用大都具有复杂的业务逻辑，在这一方面，电子表单不是银弹。
通观所有的工作流产品，尽管有些产品不乏闪光点，但是整体用乏善可陈来形容是合适的，有些产品甚至可以用非常初级来描述，这不能责怪厂商，因为他们所要解决的问题域决定了他们产品所能解决的问题域。
乏善可陈表现在6个方面：
- 除去华芩（支持XPDL，WFMC成员），大部分的工作流产品都不支持流程定义规范（东方易维对XPDL进行了很多扩展），主流的规范包括了XPDL、BPMN和BPEL。
- 对工作流模式的支持不够。工作流模式反映出产品对业务流程的建模能力，选择一个工作流产品最重要的考量就是其对工作流模式的支持程度。在这一点上老牌的厂商如东方易维、西安协同、携创和普元做得好一点，而一些以平台为销售重心的厂商做的就差一些，甚至有产品非常初级，建模只提供开始、结束和任务三种节点类型。
- 流程可视化差。流程定义作为企业重要的资产，并没有看到有产品对其可视化管理的直接支持。这里的管理包括了在组织结构内进行不同层次之间的流程可视化导航、流程权限和职责在组织中的分配、流程的全文检索和查找、与流程相关的文档管理等。流程定义更多的是作为了开发者和IT部门的私有财产。
- 流程建模与测试没有很好的统一。如何对建好模型的流程进行测试？两种方式，一种方式是进行流程仿真，将流程模拟的跑起来，这种方式效率低，另一种方式是将流程定义导入IDE进行单元测试/调试。除去普元，大多数产品都没有提供对IDE的支持。
- 整合能力弱。这个在上面已经提到了，基本上都是通过支持Web服务调用进行支持。
- 版本更新迟缓，没有持续投入。很多工作流产品早已停止更新。
- 尽管存在上述种种不足，但是也不乏亮点：
- 业务流程治理（BPG）的提出。东方易维首先明确提出了BPG的概念，并将企业流程应用清晰分为了三个层次，分别是BPG、BPMS和工作流。BPG解决的是企业流程是什么的问题，这涉及到企业流程的设计、梳理和协调；BPMS和工作流解决的是企业流程如何执行的问题，区别在于BPMS的要点在于打破各个应用系统（CRM、ECM、ERP、SCM）之间的界线，将分散在这些系统中的流程集中管理；而工作流则旨在简化对流程进行支撑的软件创建。在此之前，大部分厂商将工作流产品与BPMS产品混为一谈。
图1不同层次流程所对应的问题
- 云平台的提出。炎黄盈动提出了搭建流程私有云平台和将流程平台部署到公有云中。观念在国内厂商中比较超前，但是仔细思考，私有云其实是工作流产品向BPMS产品提升的一次尝试：工作流不再嵌入满足单个应用的使用而是暴露出流程服务让所有应用可以调用，但这项工作绝不是暴露出几个API可以完成的，涉及的方面非常多。至于公有云，国外产品如Cordys早已有成熟的流程服务，这能够显著降低企业的流程应用成本，特别是对中小企业，炎黄盈动提出了这个想法，但是并不是直接提供类似的流程服务。
- 高可靠性。西安协同和普元的产品都有很高的可靠性，这和他们的客户有关系，电信、金融。
1、 工作流与平台
几乎所有的工作流厂商都提供平台，携创是个例外，但是这让他的市场非常狭窄。为什么会提供平台？我们先来看看工作流要解决的问题域，工作流旨在简化对流程进行支撑的软件创建，既然是简化编程，那么更进一步提供平台就显得水到渠成了。
平台分为两种，一种是快速开发平台，一种是业务平台（或者提供相关的业务套件）。
- 快速开发平台主要包括了电子表单、一套开发框架还有为宣传所需要的ESB和SOA设施（这些所谓的支持都是浮云）。
- 业务平台则包括了文件管理、在线编辑、即时通讯、电子印章、门户、内容管理、人力资源、客户服务、行政管理等套件/模块。
与单纯的快速开发平台相比，业务平台显然站在了一个更高的层次上。在软件开发中，最大的浪费往往并不在于技术本身，而是在于对业务的不熟悉，在于核心领域模型的频繁变动。对用户而言，根据需要选择合适业务平台和相关服务无疑能够产生最大的价值。
为什么有的厂商提供快速开发平台，而有的厂商提供业务平台呢？这取决于两个方面，一是厂商切入工作流市场的年限，年限越长，越积累有丰富的项目经验，这些经验很容易转化成业务套件；二是厂商的客户定位，不难发现提供快速开发平台厂商的客户都是系统集成商，自己并不承接相关项目。而反观这些快速开发平台，很难发现有特别突出的技术优势，大部分都是对Struts、Spring、Hibernate、Ibatis简单封装后的CRUD框架，加上代码自动生成和Eclipse插件支持，没有任何闪光点（普元是个例外，但是我们同样对其平台发展持不乐观态度，这可以再开一个话题）。
我们的观点是：快速开发平台没有太大价值，提供行业应用的业务套件/模块才是正道。
2、 客户
观察台湾地区的工作流应用和国内的工作流应用，我们能够明显的发现：台湾地区的应用大部分集中在制造业（私企），而国内的应用则集中于政府、电力和金融行业（国企）。为什么会出现这种情况，作为制造业的大国，为什么工作流的应用却只集中在国企和政府，答案不得而知。
抛开工作流应用，工作流厂商的客户包括了以下2种：
- 系统集成商。这包括了两部分需求，一部分是系统集成商采购工作流产品或平台自己进行开发，一部分是系统集成商直接将项目外包给工作流厂商。这条路限制很多，越走越窄，但对于小的工作流厂商来说没有选择（没有资质和足够的资金）。
- 政府和企业。也就是自己直接接项目，这基本上是目前最好的一条道路。有些原有的工作流厂商早就转向（或部分转向）项目型公司，工作流产品不再更新和销售。
3、 厂商的层次分类
根据上面的讨论，我们不难将工作流厂商分为3类：
- 只提供工作流产品。这类厂商产品单一，尽管产品质量能够得到保证，但是发展最为困难。
- 提供工作流产品和快速开发平台。这类厂商在工作流的基础上提供开发框架进一步简化编程，相比第一类厂商会更有竞争力，但是其发展受到系统集成商的限制。同时需要注意的是，部分厂商着力点在于开发平台，工作流产品水平非常一般甚至初级。
- 提供工作流产品和业务套件/平台，同时自己接项目。这是目前生存状态比较好的厂商，多是老牌厂商或是有充足的资金。业务套件/平台能够给用户提供最大的价值。在任何时候，直接面对最终用户都是王道。
二、 挑战与机遇
尽管在企业应用中工作流应用的越来越多，但对国内的工作流厂商们来说，这并没有给他们带来期望中的快速增长，单纯的工作流产品甚至面临销售越来越困难的窘境。
1、困境
工作流厂商面临的压力来自于3方面：
系统集成商由购买转向自主开发。这是工作流厂商发展受阻最重要的原因，工作流应用越来越多，没有集成商愿意将这个重要的中间件依赖于他人。大多数集成商选择的方式是直接购入现有工作流厂商的源代码，也有基于开源工作流进行开发的，但是不多。
开源工作流的竞争。对于中小软件公司来说，如果遇到有流程的需求，他们的第一反应是采用开源工作流，而事实是开源工作流做的并不差，除去对国情的支持较弱外，开源甚至比一些商业产品还要好，尤其在对标准和模式的支持上。
不能面向最终用户。这是最根本的问题。工作流解决问题域的限制让最终用户根本感觉不到工作流产品价值的存在，而又没有一家工作流厂商能够做到像英特尔公司那样：组装电脑时指明要一颗奔腾的心。于是发展严重受限于系统集成商。
2、机会
那么，工作流厂商的机会在哪里？最重要的就是：将产品面向最终用户。
- 提供行业应用业务套件。能够做到对某类应用的快速实施，例如对于电子政务和协同办公，东方易维和西安协同都积累了丰富的经验，很多功能能够做到开箱即用。这样的好处是显而易见的，一是对集成商和中小软件公司来说，能够最大程度的节约成本，二是能够直接面对企业进行快速的项目实施。是时候抛弃单纯的快速开发平台了。
- 转向BPMS。在工作流的基础上开发BPMS，这需要两方面的努力：一是业务方面需要与业务流程咨询公司进行合作，二是产品需要增加BPMS特性，这些特性包括了对BPMN的支持、实现流程及相关文档可视化的内容存储仓库、提供在组织结构内进行不同层次之间的流程可视化导航、更好的业务活动实时监控预警与控制以及对流程执行的统计分析与反馈。转向BPMS的目的也很简单：产品面向最终用户，不再隐藏在某个应用内部。但是如何在市场上推广产品，这又是个问题，几乎所有的工作流厂商都宣称自己的工作流产品是BPMS。
- 提供云中的流程服务，降低中小企业的流程应用成本。这个是未来的趋势，但是从目前工作流应用集中在政府和国企的情况来看，并不乐观。
- 自己做项目。大公司靠财务，小公司靠销售。有很多原有的工作流厂商转变成了项目性公司，在有工作流实施经验的情况下，开发成本相比其他一些公司会更有竞争力。
三、 总结
国内工作流产品全部面向开发者，解决的是编程问题，旨在简化对流程进行支撑的软件创建。
国内工作流厂商分为3类，分别是工作流、工作流+开发平台、工作流+业务平台/套件。
工作流厂商面临困境的主要原因在于产品不能面向最终用户，这样当越来越多的系统集成商开始自己开发工作流和越来越多的开发者采用开源工作流时，生存日益艰难。
工作流厂商的机会与困境相对，就是将产品面向最终用户，这包括了自己实施项目、转向BPMS以及提供云中的流程服务。
附录
WfMC之工作流参考模型
图2 WFMC工作流参考模型
图2是工作流管理联盟（WFMC）提出的工作流管理系统参考模型，工作流执行服务器周围的接口是WAPI（Workflow APIs），通过这些接口可以访问工作流管理系统的服务，这些接口还控制工作流控制软件与其他系统组件间的交互。在这5个接口中的许多功能，都是被2个或更多个接口同时拥有的，因此WAPI可以看作是统一的服务接口，可以交叉使用这5个接口来支持工作流管理功能，而不是单独的使用其中某个接口，其中各个接口的具体含义如下：
- 接口1：工作流定义接口，为用户提供一种可视化的，可以对实际业务进行建模的工具，并生成业务过程的可被计算机处理的形式化描述即流程定义。
- 接口2：工作流客户应用接口，它给用户提供一种手段，以处理过程案例运行过程中需要人工干预的任务。每一任务的最小工作单元就被称为一个工作项(workitem)。工作流管理系统为每一个用户维护一个工作项列表，它表示当前需要该用户处理的所有任务。
- 接口3：工作流调用应用接口，指工作流执行服务在案例的运行过程中，调用的、用以对应用数据进行处理的程序。在过程定义中包含这种应用程序的详细信息，如类型、地址等。
- 接口4：工作流引擎协作接口，在大型的分布式的工作流管理系统中，工作流需要多个工作流引擎共同完成，甚至需要其他异质的工作流执行服务来辅助完成，此接口为不同的工作流管理系统之间的协作提供了一种标准。
- 接口5：管理接口，其功能是对工作流管理系统中案例的状态进行监控与管理，如组织机构管理、实例监控管理、统计分析管理、资源控制等。
工作流引擎：它是工作流管理系统的核心，工作流引擎对使用工作流模型描述的过程进行初始化、调度和监控过程中每个任务的执行，在需要人工介入的场合完成计算机应用软件与操作人员的交互。另外它的另外一个重要的功能是完成与应用软件及操作人员的交互。
关于作者
荣浩，ThoughtWorks咨询师，关注敏捷和企业流程改进过程，目前正与辛鹏合著《Head First Process-深入浅出IT流程》一书。博客地址http://ronghao.javaeye.com 。
感谢马国耀对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
分析的很全面
发表人
曹 云飞
发表于
这里讨论的多是Java的，没有包含.NET的
发表人
张 善友
发表于
从面向最终用户的问题说起
发表人
Xiaoguang Yang
发表于
非常客观深入的分析
发表人
wang shi
发表于
Re: 非常客观深入的分析
发表人
king ianywhere
发表于
-
开始拜读大作《Head First Process-深入浅出IT流程》
-
这里讨论的多是Java的，没有包含.NET的，国内也有不少基于.NET的工作流。
-
工作流面向最终客户，我觉得产品公司来说会造成方向上的问题，因为面向最终用户必然会面临业务结合的问题和满足个性化需求的问题，要么做好一个行业，这就造成了产品使用范围问题。要么形成很多分支，这样除非你有足够的资源，否则就会产品业务都做不精。
-
很有启发性，感谢楼主。
我个人以为在国内，对于很多做信息系统的中小心厂商来说，一套开源的符合中国国情的快速开发框架还是有发展前途的。目前有一些水平很不错的快速开发的框架，但感觉在易用性和文档等各方面还存在较多问题，和业务的扩展、集成能力也不足。大部分开发这类框架的技术人才对实际业务项目的参与可能并不多，并不能很好的理解业务项目程序员的实际需求。
想听听楼主对快速开发框架的见解，特别是认为目前存在一些框架的不足的认识和需求建议。 -
研发要有雄厚的资金支持。这也许是“浮云”产生的原因之一吧
5 条回复
关注此讨论 回复