SOA夜未眠 5

 

SOA项目的负责人

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

 

SOA和一般项目不同的地方在于，它会面对企业中各种各样的系统。SOA的目标就是把紧耦合的系统打散了，做成松耦合的服务。这样会带来很多好处（省略SOA的好处若干字）。为了达到这个目标，需要对企业中的各种各样的系统都进行改造，使之服务化。

 

在系统改造的过程中，会遇到各种角色，比如各个系统的开发商，企业的业务部门，下级部门的人员，项目开发商，项目监理方等等。在绝大多数情况下，某些角色都会多多少少对系统改造工作起到不良的阻碍作用。

 

比如系统开发商，系统开发商一般会有自己的产品，比如一套营销系统，他可以卖给江苏省的客户，也可以卖给北京上海的客户，这样的成本是很低的。而SOA需要他对他的产品进行改造，进行定制，对于他来说，成本会提高。一般短视的开发商都会尽可能的减少对他系统的改动，能不改就不改，我遇到过很多这样的开发商。

 

其实SOA是一个全新的领域，对于系统开发商来说，能早一天进入到这个领域中，就早一天获得经验，在这个领域立足，在激烈的竞争中挣得丰厚的利润。

 

另外，业务部门对SOA的不重视，也会导致SOA项目不能顺利开展。SOA中的S，服务，实际上就是为了业务部门服务的，SOA需要业务部门的业务专家全过程参与和确认，才能保证做出来的SOA是业务部门需要的。不过也有例外的情况，我遇到一个客户，他们的业务部门的人基本上都只对属于自己的那一小块业务比较熟悉，对别的业务不熟。反而是他们的开发商，对所有的业务都很熟。唉，客户有钱真是好啊。

 

鉴于以上的情况，并不是所有的客户能可以顺利的开展SOA的。一般对于一个企业，SOA项目都有一个牵头部门，或者说，责任部门，这个部门需要去协调其它部门，开发商，各种资源来完成SOA项目的推进。SOA项目的负责人一般由这个部门的领导担任

 

这位领导必须很强势，他可以不懂SOA，但是他必须强势。SOA项目如何开展，可以由顾问或者其他人告诉这位领导，当项目小组需要其他部门的配合或者需要其他的资源，这位领导一定要能够及时的帮助项目小组获得。

这位领导的后面必须要有更强势的后台，比如企业的CIO，VP等等，他必须得到后台领导的信任和授权，要求其余部门（比如业务部门）全力配合。他必须能让开发商听话，让改什么就改什么，让怎么该就怎么该。他还能够镇得住下级部门。

 

如果该领导说话没人听，下达指令总是被人托三阻四，哪怕他十分了解SOA，估计这个项目还是要失败的。

 

我遇到过两个客户，可以说是鲜明的对比，第一个客户，项目负责人对他的系统开发商掌控力极强，果真是让他们改什么就改什么。

 

而第二个客户，SOA的项目开发商有好几家，除了一家是本地的公司，其余都是外地的公司，负责人无法完全驱动这些开发商。甚至出现，开发商的开发人员公然叫板，“我就是不改！”其实所要改的功能两个小时就能做完。为了解决这个事情，负责人找开发商的经理，开发商的经理再找开发人员了解情况，然后开发商经理开始诉苦，负责人再让点步，三天后才改好。当然，这种情况也是很多原因造成的，比较常见的原因有：客户没付钱或者付了很少的钱；负责人虽然和开发商强调了项目的重要性，开发商也确认了项目的重要，但是开发商内部沟通不够，在客户现场的开发人员并没有足够认识；IT部门人员对业务的理解和开发人员对业务的理解不一致；人员的积极性不高等等。

 

所以，SOA项目的负责人最好是这样的：

他要得到企业高层领导的授权，这样他才能协调其他部门，尤其是和他平级的部门或者更高级的部门。

他对开发商有强的掌控能力。

他要很强的协调能力，帮助SOA项目小组解决遇到难题。