尽管sOA是一个it技术解决方案，但是其实质却是一项管理变革，而能否解决好组织和管理中的问题也是sOA实施成败的关键所在

尽管在产品、理念、标准、路线等诸多方面存在不少的差异，三家sOA主要厂商ibm、sap,sap,sap,sapsap以及bea今年却有了一个相同的方面，那就是把sOA推广的重点从it人员转移到了业务人员。

ibm在它的sOA峰会上表明，业务人员对于实施sOA的影响力已经超过了技术人员，其今年提出了sOA的5个切入点，其中技术方面只有两个，而业务方面却有3个；bea则干脆在丽江举办了面向企业架构师的论坛，共同探讨如何优化企业现有的it与业务架构的问题:sap也在收获erp市场的同时紧盯sOA市场，其从应用入手的策略更是直接从业务突破。

和两年前这些企业集中“进攻”cio相比，这种转变不得不让我们再次思考一个问题，在经过了两年多的灌输与扫盲阶段之后，sOA为何将业务和管理放在了技术的前面？

表面是技术实质是管理

从sOA的定义上来看，它就和之前的erp、crm等有着很大的不同，sOA既不是一个产品，也不是一个纯正的技术项目，它更多地指的是一种以服务为核心的设计架构，是一种理念，也是一种方法论。简单来讲，sOA是一种帮助企业解析流程，使企业能够充分重复利用资源、达到最佳优化、提升效率的一种理念。

从这个角度上来说，sOA能帮助企业实现业务与it同步，有效降低成本，提高灵活性，从而提升竞争优势。这一系列的好处似乎让人无法拒绝，但为什么sOA被无数专家看好，而目前采纳并真正实现其价值的企业尚不多见呢？

实际上最大的问题是对于sOA在理解上出现了偏差，过分强调了技术而忽略了管理变革上的难度。根据国际数据集团（idg）最近进行的sOA调查，有半数以上的企业认为，组织和管理问题是他们实施sOA所面临的主要障碍。

在实施sOA的时候，一个现实的问题是必然要改变原有的流程与组织架构，这样sOA虽然能实现it和业务的真正的协调，但实现真正的协调同时势必会带来大量管理问题。因为人们已经习惯于使用专用资源构建运行在专用设备上的系统和应用，这样有利于了解依赖关系。

同样，sOA从技术方面实现了从it应用中分离出业务流程，人们因此可以充分利用在企业不同部门中构建的服务，但随着应用开发变得更加水平化，对于it而言，追踪所有集成点之间的依赖关系，了解变化或问题隔离的影响，也因此变得更加困难。不仅如此，即使从部门之间的关系来看，在实施sOA时，需要先将现有的it系统打包，这就意味着我们要对现有的it系统进行一些改造，需要打通业务部门之间的屏障，实现各业务部门的数据共享，这可能需要改变业务流程。在改变业务流程的过程中，很自然会涉及组织部门之间的利益和关系，甚至还可能会改变组织结构。

很多sOA的失败案例并不是因为技术问题，而是组织架构上没有办法实现sOA理念。沪士电子(昆山)有限公司it经理王翔分析，sOA并不是单纯的it概念，而是与组织、管理、商业模式紧密联系在一起：“这是一个系统工程，需要企业各方面力量的协调。”

在这样的情况下，作为实施的it部门与各个业务部门之间很难达成共同的认识与理解，所有的整体性问题都有一个共同点，就是它们的报偿机制对于每一个部门都很难定义，而且都是需要先贡献，过一段时间才能获得回报。这对于一个组织来说，本身就是一个很大障碍。可见，建立sOA需要重新搭建企业组织架构，需要每个部门公开自己的信息作为前提，这就很容易牵扯到每一个部门的利益。

对企业来说，能否成功实施sOA并不仅仅是一个技术问题，它还涉及到战略、商业模式、组织、业务流程甚至企业文化等诸多管理问题。在帮助客户实施sOA的过程中，首先遇到的就是管理难题，其次是沟通协作，最后才是技术。

所以说，尽管从外表看起来sOA是一个技术投资，但是从内在实质来看，sOA更多还是一个管理问题。

[1]