也谈流程模型的层次设计
07年的时候,去了家国外的工作流厂商做研发,就此和工作流打上了交道。中间断断续续一直在搞和流程相关的东西。去年秋天换了份工作,花了一年和team一起搞了套全新的流程平台,中间磕磕碰碰不少,但也算小有所获。赶上正月里闲暇时间较多,把一些心得分享出来,一来算是对过往的思想有个小结,二是多听听大家的意见和建议,开拓思路,共同进步。
由于07年之前从事的工作并没有涉及太多工作流,因此当进入这家公司后,其产品的设计思想对我的影响很大,随后接触了微软的WF,以及基于它搭建的BizTalk:Ochestration,MOSS Workflow以及其他一些工作流产品,对于后续的设计风格都有这不同程度的影响和补充。
关于流程层次,园子里的WF元老级人物 @WXWinter 有过好几篇文章着力介绍:
流程的层次:http://www.cnblogs.com/foundation/archive/2009/02/06/1385122.html
同一流程多种状态:http://www.cnblogs.com/foundation/archive/2009/02/24/1397111.html
WXWinter兄对其论述的已经相当充分,很多文章都让我受益匪浅,因此本文只算是对其思想的一种补充。流程层次决定了流程模型的设计,也就直接决定了这套流程系统适宜处理的流程模式(Workflow Patterns),开年第一篇的标题,就叫做“也谈流程模型的层次设计”吧。
通常的流程模型,我们一般分为2层:流程-节点(或者叫:活动):
流程在业务上被用来表述一个具体业务场景、业务流程(比如:采购流程、报销流程等)。
而节点则是对一个特定业务动作的封装(比如:发邮件、审批、付款等)。
业务动作是可以复用的。一组业务动作的有序组合构成了一个业务场景;一个或多个业务场景的组合构成了一支业务流程。
通常我们在设计流程的时候,很少会清晰的对业务场景进行细分(主要也是流程不复杂),因此最常见的流程设计模式就是:一组代表不同业务动作的节点,通过转换逻辑(通常是连接线),构成了一支业务流程。
但这样带来的问题,就是WXWinter兄提到的:结构不清晰,职责没有明显的边界和划分,这是从业务的视角看会带来的弊端。
而从流程模型的技术视角方面,过度细节的暴露也不利于流程的清晰。我们设想一个简单的请假审批流程(只列正向流程):
其业务的表述一般是:【提交请假单】 -> 【领导审批】 --(同意)--> 【通知通过】。
OA集成度较高的,还会从传统的审批流(Human-Human WF)转为人机流(System-System WF):
【提交请假单】 -> 【领导审批】 --(同意)--> 【修改HR系统剩余天数】 -> 【通知通过,并告知剩余天数】
当我们用二层模型去设计的时候,真实的流程图可能是:
【开始】 -> 【创建代办任务】 -> 【发送审批通知】 --(同意)--> 【写数据库/调用API】 -> 【读数据库/调API并赋值于变量】 -> 【构造邮件内容,发送邮件】
继续之前先说明一下:这里大家可能会觉得 【创建代办任务】和【发送审批通知】应该被放在一起实现,并合为一个节点,叫审批。不过如果从可复用性的角度和扩展性角度看,建议拆开,而通过易用性改进将其整合起来。不然以后如果用户今天是发邮件,明天发短信,后天发微博,会很麻烦(除非你在审批中实现了MessageProvider)。
回到正题,从上面的实际流程上,我们可以看到几个问题:
1)【创建代办任务】和【发送审批通知】实际上属于同一个业务场景。
2)【写数据库/调用API】和【读数据库/调API并赋值于变量】过于技术化。
3)节点膨胀(业务设计:4,技术实现:6)
为了解决这个问题,有多种方式,最简单有效的莫过于放弃或降低业务动作的复用性,实现【审批】这个特定节点,实现【修改HR系统字段】这个特定业务动作(业务具体化)。如果是项目实施的话很方便,但对于业务平台或者产品来说就降低了灵活度。
第二种方式是引入组(Group)或者模版(Template、Snippet)的概念:
由于这两个概念在各类产品比比皆是(比如PPT),不多详述。只是组只能做归纳,模版只能做简单复用,随着系统的复杂度和流程数量和节点数量的增加,在另一方面降低了系统整体的可用性。
第三种方式是引入容器(Container)这一概念:
容器可以封装多个业务动作,其相对于组最大的区别,在于它自身更像一个接口,其对内和对外都有一定的可交互特性在里面,仿佛微观层面的Facade模式一样。这里举出两个产品的容器概念:
1)微软的WF:其本身是二级模型,但是活动(Activity)可以包裹其他的活动,因此一个Sequential或者If、FlowChart都是一个容器。其本身即可将实现细节封装起来,同时通过Argument和Variable来有效的和内外进行数据交互。
2)K2:K2产品本身即三层模型结构:流程(Process)- 活动(Activity )- 事件(EventWizard)。其事件即用来实现特定的业务动作,而活动则更像是一个功能容器,一个活动可以包裹多个事件,以此实现一个特定的业务场景。
我个人也很推崇容器的概念,因为这种模型带来的直接好处便是:业务人员只关心其业务流程的设计(只绘制流程和容器),而IT人员则对其进行业务动作的配置和补全。 以此来实现业务和IT更流畅的沟通。
还有一些其他的方式:
比如节点上可以配置多个扩展服务调用,但是这样不够直观,我们要隐藏细节,但是也要能够方便的展现细节。
还有便是子流程调用,但这已经超出本文的讨论范畴,属于广义上的业务流程交互,不多讨论。
本文主要想讨论一些二层模型和三层(容器)乃至多层模型对业务表述、沟通和支撑的影响。 第二次发技术文,一口气写完,很多想法可能还推敲不够,希望能够多和大家交流。我除了博客园,最常用的就是新浪微博:@杨二毛SZ
希望能够结交跟多朋友,祝大家新年快乐!