SOA夜未眠 6

 

业务流程

―――――――――――――――――――――――――――――――――――――――

SOA的价值之一就是能让客户自由方便的组合他的业务流程。

 

我做过的几个SOA项目都需要实现流程。

 

实际上，SOA的流程是很容易实现，因为基本上所有的业务逻辑都在服务中实现，而流程起到的是一个编排的作用。但是实际并非如此，拿我所做的两个项目来说，对于流程的开发，一个项目用了两个人一个月就完成了，另一个项目却用了两个人四个月。它们流程开发量都是差不多的，为何有这样的差异呢？

 

关键在于，第一个项目流程的业务需求基本没有发生变化，而第二个项目流程的业务需求几乎三天一小变七天一大变。

 

先说说SOA的流程的特点。

在企业中，一件事情可能会由好几个部门一起协同完成，比如对项目的管理，需要财务、物资、OA、工程等几个部门一起完成。通常，在各个部门自己的系统里面都会有一些关于项目的小流程，比如物资系统中会有项目物资管理流程，财务中有项目财务管理流程，工程中有项目施工管理流程，等等。这些小流程是整个项目管理这件事的片段，一般来说，在SOA项目开始前，这些小流程都在自己系统中，并没有串联起来。（如果这些流程已经串联起来，说明这个企业的IT规划建设都非常好，做SOA项目风险会很小）

没有串联起来的结果是什么呢？这意味着客户想要了解一个项目的状态，他必须到各个系统中查看，并没有关于项目的总体视图。

另外，流程没有串联，也会造成项目管理上的混乱。

打个比方，比如一个项目的开工申请必须在工程系统审批通过后，才能去购买物资。但是客户的物资系统中的流程并没有和工程系统的流程串联起来。物资系统可以独立启动项目物资采购流程。这样就会造成下列情况，比如项目的开工单还在审批过程中，项目经理拿着某位领导的批条，可以要求物资系统提前采购物资。因为物资系统可以独立启动采购流程，所以项目经理是能够得逞的。

综上所述，客户一般希望通过SOA项目，他能够得到企业中的跨部门流程，把各个部门的小流程片段串联成一个完整的大流程。一方面他可以清楚的知道，该流程当前流转到哪个部门了，被谁在处理，处理的时间有多长了。另外，他可以通过跨部门流程控制各个部门中的操作。比如上面物资系统的例子，通过流程改造，物资系统无法单独启动流程，必须等大流程通知它开工审批通过了，它才能启动采购流程。这样，即使项目经理拿了批条，物资系统也无法启动采购。

 

现在说回SOA流程的业务需求，对于跨部门流程，它涉及到多个部门的子流程，可想而知，如果要定SOA流程的业务需求，需要多个部门的人员配合。

 

我的第一个项目，客户是这么做的，项目启动后，他立刻从所有业务部门都抽调了人员，组成了一个流程小组，这个小组的人被封闭了两个月，专门梳理跨部门流程的业务需求，形成了文档，每个参与人员必须对这份文档进行确认。如果发现业务需求与实际不符，需要追究责任人。

 

我的第二个项目，客户是这么做的，项目启动后，他也成立了流程小组，但是流程小组的成员是开发商，经过了一个月，也形成了文档，没有业务部门的确认。然后服务设计小组开始根据这份流程文档设计服务接口。过了三个月，服务开发的差不多，客户开始要求做流程，结果发现那份文档很多地方还需要修改和计划。这时，客户要求流程小组成员召集业务人员咨询，流程小组的成员压力很大，开始分头找业务人员确认了，后来又出来一份文档。开发人员拿这份文档进行开发，发现还是有不对的地方，举个例子，比如流程设计说项目管理流程需要把开工申请发财务，然后再发给物资，结果开发人员发现物资系统的服务需要的某些字段是必须要从财务系统中取得的，但是目前的财务系统的服务并没有提供这些字段。结果，客户只能要求财务系统的开发商更改服务。这时财务系统的开发商就会有意见和抵触心理，“我明明是按照你的设计实现的服务，为什么要我额外修改？”这些例子还有很多，服务或流程会不停需要返工，导致进度大大延迟。

这是什么原因造成的呢？首先流程小组中必须有业务人员，每个部门都必须有业务人员参加。另外，不能分别找各个部门的业务人员确认需求，而必须把他们集中起来讨论，因为各部门的业务人员可能只清楚自己部门的需求，把他们的集中起来，才能知道流程从部门A到部门B需要什么数据，会遇到什么处理，出错时的异常数据是什么，流程在部门A中发生了一个错，它能不能忽略这个错误流转到部门B等等。

 

综上所述，

1.       SOA项目中，一般都需要开发跨部门流程。

2.       跨部门流程的业务调研和业务需求必须确定尽快开始，越快越好。

3.       跨部门流程的业务调研和业务需求确定必须有业务人员参与，必须经过业务人员确认，必须形成详细的文档，描述清楚系统之间的数据交换，流程的出错处理等等。