这是最近为某媒体写的一篇东西，类似于一个综述吧，他们应该已经出版了，根据约定我也可以发到BLOG里面了。
 
————————————分割线————————————————————————
SOA在最近的几年中得到了比较大的发展，但是进步更多的还是在技术方面，在实际的应用上还相对滞后，企业是相对在这方面走得比较靠前的，而公共服务部门则只有很少的应用，并且主要集中在比较小型的内部系统整合上，涉及到比较大规模的业务层面的整合项目还寥寥无几。
从2005年开始，某市某区政府（以下简称A区政府）开始与高校合作对有关政府公共服务的整合进行研究，通过一年多的前期研究，基本确定了以下的模式：通过将部分部门的部分业务整合到统一的平台上进行处理，为市民与区内企业提供领先的公共服务。
当前，国内的政府机构在业务上存在这样的一些方式：其一，比较原生态的方式，是按照传统的模式，用户要办事就需要到各个不同的部门，找不同的人，虽然近年各地都积极的加强政风建设，提高服务意识，但是在不同部门之间奔波本身就是非常耗费时间的一件事，这决定了公共服务的变革需要从业务模式上来着手；其二，作为上一种方式的改进，某些地区政府将一些服务部门集中起来，在一个固定的场所对外提供服务，这称之为“一门式”服务，至少省去了用户在不同部门之间来回的成本，是一个比较大的进步，如上海某区的市民中心就是承担了这一职能的机构，不过这一模式仍然存在不同部门之间的业务无法统一，并且存在大量不必要的重复过程的弊病，同样不能很好的提高效率，另一方面，这需要一个或者多个场地来容纳那些提供服务的部门，如果某一级政府的辖区较大，则集中在某一处提供服务同样会存在某种程度的不方便；其三，作为一些政府将内部的部门之间的公文流转、信息服务等同质化业务整合到一起，这在不少地方都已经实现了，这一种类型的局限性在于主要是进行内部业务的整合，并且类似公文和信息服务等业务在不同的部门中是基本一致的，整合起来难度较小。
A区政府规划中的业务模式与以上三种模式都不同，通过信息系统对提供公共服务的业务进行整合，依托现有的社区事务受理服务中心的场地与人员（对于企业用户则有专门的企业服务中心），为用户提供单一窗口的全面服务，这被称为“一口式”服务，以与前面所述的“一门式”服务相区别，这意味着，用户到就近的任意一个社区事务受理服务中心（或企业服务中心）的任何一个窗口，都可以获得系统所整合的所有服务，用户只需要根据有关说明提交符合要求的文件与信息，不需要了解后台业务，大大的降低了公共服务的社会成本。。除了基本的业务运行的系统外，A区政府同时还计划开发提供支持服务的呼叫中心系统以及监控、评估业务运行质量的行政绩效监督系统等附属系统。以上各系统以及一些业务支撑的基础架构总体形成A区行政服务中心项目。
行政服务中心项目经过近两年的前期研究、论证以及准备，于2007年春节后开始正式启动有关工作，通过招标程序，选择S公司作为项目的总承包商，于5月正式开始了项目的设计工作。
非常显然，作为这样的一个业务整合的项目，采用SOA技术是非常合适的，S公司确立了在服务层面上基于SOA，底层则基于COA（面向构件）的基本思路，并进行了系统原型设计，项目分为市民服务系统，企业服务系统、呼叫中心系统及行政绩效监督系统工四个业务系统以及相应的硬件软件基础支撑平台集成等工作，于6月通过A区组织的专家评审会议评审，进入开发以及实施阶段。
市民服务系统预备整合20余个政府部门的约200项为市民服务的业务，对于不同部门的业务，其中存在比较大的差异，但是究其基本的行为模型，基本可以归纳为“信息-判断-传递”的模式，业务流程无论长短，基本都可以抽象为这一模式的迭代，通过有关信息的加载则可以组成具体的业务流程，而基本的行为模型则可以构成基本的服务，通过基本服务以及一些辅助的服务来搭建业务平台。
企业服务系统预备整合约30个部门的将近300项服务业务，其业务与市民服务系统有比较大的相似性，主要的区别在于企业服务系统有较多的跨部门协作的流程。但是在业务平台基本的构建方式上基本与市民服务系统类似。
呼叫中心系统一方面承担了政府对内对外联系的职能，同时还有提供信息服务、接受用户投诉或求助等业务的功能，而在后台还要作为业务分发与处理的中心提供服务，因此呼叫中心系统整合了最多的其他系统，包括在项目内纵向整合呼叫中心底层的软硬件系统以及横向的整合市民服务系统和企业服务系统以及行政绩效监督系统、知识库系统等，以及项目外与区政府外部与内部网站的整合，与区信息基础架构体系中的市民基础信息库、企业基础信息库以及短信平台等支撑系统的整合。
行政绩效监督系统的情况比较特殊，本质上说这是一个BI和业务性能管理的平台，更多的是关注ETL以及数学模型和呈现方式方面的问题。
当然，在具体的实施过程中情况要复杂得多，以市民服务系统为例，涉及到民政、劳动、统战、旅游、市政管理等多个部门，有一些业务还没有通过信息系统来处理与管理，这部分业务直接通过市民服务系统开发，是最简单的整合方式，有一部分业务已经由区级部门实施了信息化，可以通过WEBSERVICE或者系统接口的方式进行直接整合，还有部分业务是使用的市级业务部门的系统，大部分只能通过数据接口或者数据文件导入导出的形式进行整合，还有一些涉及如劳动、公安等使用较封闭专网系统的业务，使用类似CITRIX的技术进行整合，或者数据二次录入的方式进行整合。
根据项目进度计划，通过S公司紧张的开发以及与A区政府有关部门的反复沟通与确认，市民服务系统于2008年春节前后开始在各街道的社区事务受理服务中心开始进行分步推广，呼叫中心也与4月开始进行用户培训以及逐步的试用，行政绩效监督系统也逐步开展用户培训工作，企业服务系统则被安排在相对靠后的时间。
虽然项目并不能算是结束，但是此时进行一些回顾，也可以总结很多的经验和教训。
首先，划定项目范围应谨慎，该项目所包含的数百项业务，是由A区政府划定的，涉及的部门相当于A区政府的约50%，业务所占比例就更低一些，基本采用由区政府下发调查表，各部门自行决定是否将业务纳入项目，但是从项目执行情况来看，数量还是过多，虽然业务平台在逻辑上将业务模型抽象成“信息-判断-传递”的迭代，但是大量的业务在开发过程中还是有不小的工作量，同时考虑到不少业务要采取开发以外的方式进行整合，这对于项目进度是非常大的风险，而在系统建设之外，向一线工作人员开始进行业务的推广时，大量的业务也会造成推广上的很大困难，但是，从政府的角度来看，如果项目范围较小，则项目的效益会较差，尤其是对于用户的益处就显得太小，这对于整个项目也是不利的，也会造成在整个行政服务业务整合的进度上投入太长的时间，同样是非常不利的；
其次，项目质量与项目进度之间的矛盾要处理好，考虑到政府的特殊性，往往不倾向于时间较长、尤其是跨年度的项目，这就会对项目进度施加相当大的压力，可能会因此影响到项目质量，如何解决需要认真考虑；
第三，政府管理上的难点如何避免，类似的项目通常是由政府指派信息委进行监管，但是对于业务上的问题，信息委的权限与力量都是不足的，这也会对项目造成消极影响，同时，政府内部不同的部门也存在差异，某些部门的业务受到国家较强的垂直监管，如公安、劳动等，作为一级政府的横向管理力量自然就较弱，这对于项目也是不利的因素，类似的因为政府管理上的一些难点造成项目阻碍的情况还不少，如何避免同样需要十分谨慎；
第四，业务标准化问题，不同部门之间，在业务上存在不小的差异，这对于整合业务是非常不利的，实际上有不少业务的差异都是因为长期部门运作方式的差异造成的，有一些业务流程节点都是非必要的，在项目前期如果不进行相应的标准化，把业务统一到一个相对比较标准的模式中来，那不仅对于一线的工作人员来说要承受大量的不同的业务的冲击，对于项目的承包商而言也很难在项目中获得可复制的能力，每个项目甚至每项业务都需要重起炉灶——因为不仅一级政府内部门间业务有差异，不同的政府间的同一部门的业务也是存在差异的，当然，要做业务标准化，也面临着更大的困难；
类似的问题还有很多，包括系统归属这类比较大的问题，也包括人员、编制这类小问题，还有在推广、运行中中的种种问题。限于篇幅，这里就不作更多的讨论了。
应该看到，SOA是帮助公共服务部门整合业务的一个非常合适的手段，但是必须认识到，先有了业务和管理上的需求，才有利用技术手段解决问题的可能，很多的问题根源并不在技术上，而在于管理上。前面所提到的那些问题，还需要在今后的实践中去一一的解决。