SOA有多好，似乎已经无数的人说过了，但是怎么做，却是大家各执一词。
技术厂商自然是推广自己的产品，根据自己的产品提出不同的路线图，EAI也好，ESB也好，莫衷一是。
实际上，就技术层面而言，我认为具体采用什么技术都不是关键因素，从目前看，基本上各厂商也都有相应的成功部署的经验与案例。
不过厂商所言，大部分还是技术层面的内容，也许单纯的从技术层面看，SOA可以让用户在开发和部署新的应用时有更快捷的手段，但是对于用户的整个组织而言，要依靠SOA带来的益处获得竞争优势，仅有技术是远远不够的。
SOA的精髓在于业务驱动技术，目前的解决方案，基本都集中在服务封包、模块化及其复用方面，但是针对用户组织进行的实际业务流程方面的工作则提及得非常的少，个人认为这个恰恰是SOA能否发挥最大效力的关键因素。
过去的一年见我参加了某级政府的一个规模相当大的项目，该项目通过建立一个统一的平台，整合了几十个政府部门的大约300项为民服务的事项，这几乎是一个天生的SOA项目，要整合不同部门不同平台上的业务，还要与大量的现存系统进行数据及业务的交换，并且要开发一些辅助的应用，在未来还有可能部署更多的应用。部署SOA，无疑可以把整合与开发的速度大大的提高，并且提供更好的灵活性，为将来的扩展提供良好的基础。
应该说，对于这个项目用户是非常重视的，由一位主要领导挂帅，前期，政府方面会同实施方，与一所国内知名的大学合作，进行了长达一年多的调研与规划，在技术上也采用了国内某领先厂商的较为成熟的构件平台，软硬件的配备都投入了相当成本。
在实际的项目实施中，SOA的技术架构也确实体现出了开发快捷、灵活的优势，但是在部署与实际应用中则出现了较多的问题。
主要的问题在几个方面，其一，用户不同，对于业务流程的要求也存在差异，用户有若干个面对市民的前台服务机构如社区事务受理中心，各个前台服务机构对于同样的业务都有不尽相同的流程，甚至同一个前台机构不同的工作人员也有不同的操作方式，而具体办理业务的后台部门与前台服务机构对于办事流程的执行又存在差异，这就造成了系统部署后又要进行反复的修改，还无法满足所有用户的需求；其二，新的业务模式需要前台服务机构的工作人员要能处理数百项的业务，而以往处理的业务仅仅是几分之一，而且还是根据不同的业务部门进行专人处理，这就造成了前台服务机构的工作人员需要熟悉数倍于以往的业务，直接影响了系统部署的速度。
探究这些问题出现的原因，显然并不完全是技术层面的因素，实际上，在进行系统设计与开发时，已经针对这些问题进行了大量的工作，包括尽可能的按照用户的习惯进行设计、提供尽可能多的在线操作帮助等等，然而这些技术层面的措施能够起的作用是非常有限的。问题的根本原因，在于业务流程之间的差异过大，没有进行必要的统一与标准化——或者说，在业务上没有SOA化。对于大量的业务流程的研究表明，有关的业务流程各环节实际上行为模式相当类似，因此在技术层面上，整个业务流程中有大量的迭代过程，但是，在业务层面上，完全可以对于业务流程的各环节进行相应的标准化，形成标准服务模块，具体的业务流程通过有关模块组合搭建而成，这样可以统一不同部门的业务流程，避免因为众口难调而对系统造成影响，也可以大大的降低一线人员的操作难度，提高培训的速度，保障系统部署的速度。
如果仅仅在技术层面上部署SOA，或多或少将面临类似的困境，在业务层面上进行相应的流程标准化工作，则不仅可以对于后续业务的部署起到良好的支撑，同样对于技术层面的设计与开发也能起到大大的简化作用。这实际上与前些年ERP实施时很多人都谈的BPR（业务流程再造）非常接近，可以说是BPR的另一种形式或者说是其延伸。
对于公共部门而言，进行流程的标准化面临着不小的困难，这主要来自于现行的行政管理体系。由于不同部门、各级政府对于某些工作存在不同的管理形式，同时很多工作还必须受相关法律的监管，包括一些局部利益与整体利益冲突等等因素综合作用，因此相关的工作在推进上存在相当的阻力，国外的有关研究表明，在公共部门进行业务流程的改进工作需要更加缓和的推进。
而作为企业，相关的管理结构和执行能力的特点决定了能够实施相对激进的改革措施，因此进行有关的业务流程上的标准化工作能够对企业SOA部署有着更大的益处。