SOA在最近的几年中得到了比较大的发展，但是进步更多的还是在技术方面，在实际的应用上还相对滞后。公共服务部门对SOA只有很少的应用，并且主要集中在比较小型的内部系统整合上，涉及到比较大规模的业务层面的整合项目还寥寥无几。

    “一口式”取代“一站式”

    从2005年开始，某市某区政府（以下简称A区政府）开始与高校合作对有关政府公共服务的整合进行研究。通过一年多的前期研究，基本确定了以下的模式：通过将部分业务整合到统一的平台上进行处理，为市民与区内企业提供领先的公共服务。

    当前，国内的政府机构在业务上存在这样的一些方式：

    其一，基本上按照传统的模式，用户要办事就需要到各个不同的部门，找不同的人。

    其二，作为上一种方式的改进，某些地区政府将一些服务部门集中起来，在一个固定的场所对外提供服务，这称之为“一站式”服务。省去了用户在不同部门之间来回的成本，是一个比较大的进步。如上海市某区的市民中心就是承担了这一职能的机构，不过这一模式仍然存在不同部门之间的业务无法统一，并且存在大量重复过程的弊病，同样不能很好的提高效率。另一方面，这需要一个或者多个场地来容纳那些提供服务的部门，如果某一级政府的辖区较大，则集中在某一处提供服务同样会存在某种程度的不方便。

    其三，将部门之间的公文流转、信息服务等同质化业务整合到一起。

    A区政府规划的业务模式与以上三种模式都不同，通过信息系统对提供公共服务的业务进行整合，依托现有的社区事务受理服务中心的场地与人员（对于企业用户则有专门的企业服务中心），为用户提供单一窗口的全面服务。这被称为“一口式”服务，与前面所述的“一站式”服务有所区别。用户就近到任意一个社区事务受理服务中心（或企业服务中心）的任何一个窗口，都可以获得系统所整合的所有服务。用户只需要根据有关说明提交符合要求的文件与信息，不需要了解后台业务，大大的降低了公共服务的社会成本。除了基本的业务运行系统外，A区政府同时还计划开发提供支持服务的呼叫中心系统以及监控、评估业务运行质量的行政绩效监督系统等附属系统。以上各系统以及一些业务支撑的基础架构总体形成了A区行政服务中心项目。

    行政服务中心项目经过近两年的前期研究、论证以及准备，于2007年春节后开始正式启动。通过招标程序，最终选择S公司作为项目的总承包商，于2007年5月正式开始了项目的设计工作。

    尝试SOA

    显然，作为这样一个业务整合项目，采用SOA技术是非常合适的。S公司确立了在服务层面上基于SOA，底层则基于COA（面向构件）的基本思路。继而进行了系统原型设计，项目分为市民服务系统，企业服务系统、呼叫中心系统及行政绩效监督系统四个业务系统以及相应的硬件软件基础支撑平台集成等工作，6月通过A区组织的专家评审会议评审，进入开发以及实施阶段。

    市民服务系统预备整合20多个政府部门约200项为市民服务的业务，对于不同部门的业务，其中存在比较大的差异，但是究其基本的行为模型，基本可以归纳为“信息-判断-传递”的模式。业务流程无论长短，基本都可以抽象为这一模式的迭代。通过有关信息的加载则可以组成具体的业务流程，而基本的行为模型则可以构成基本服务，通过基本服务以及一些辅助的服务来搭建业务平台。

    企业服务系统预备整合约30个部门的将近300项服务业务，其业务与市民服务系统有比较大的相似性，主要的区别在于企业服务系统有较多的跨部门协作的流程，但是在业务平台基本的构建方式上基本与市民服务系统类似。

    呼叫中心系统一方面承担了政府对内对外联系的职能，同时还有提供信息服务、接受用户投诉或求助等业务的功能，而在后台还要为业务分发与处理的中心提供服务。因此呼叫中心系统整合非常复杂，包括在项目内纵向整合呼叫中心底层的软硬件系统以及横向的整合市民服务系统和企业服务系统以及行政绩效监督系统、知识库系统等，以及项目外与区政府外部与内部网站的整合，与区信息基础架构体系中的市民基础信息库、企业基础信息库以及短信平台等支撑系统的整合。

    行政绩效监督系统的情况比较特殊，本质上说这是一个BI和业务性能管理的平台，更多的是关注数据的抽取转换和装载以及数学模型和呈现方式方面的问题。

    当然，在具体的实施过程中情况要复杂得多，以市民服务系统为例，涉及到民政、劳动、统战、旅游、市政管理等多个部门。有一些业务还没有通过信息系统来管理，这部分业务直接通过市民服务系统开发，是最简单的整合。有一部分业务已经由区级部门实施了信息化，可以通过WEBSERVICE或者系统接口的方式进行直接整合。还有部分业务是使用的市级业务部门的系统，大部分只能通过数据接口或者数据文件导入导出的形式进行整合，还有一些涉及如劳动、公安等使用较封闭专网系统的业务，使用类似CITRIX的技术进行整合，或者数据二次录入的方式进行整合。

    根据项目进度计划，通过S公司紧张的开发以及与A区政府有关部门的反复沟通与确认，市民服务系统于2008年春节前后开始在各街道的社区事务受理服务中心开始进行分步推广。呼叫中心也于4月开始进行用户培训以及逐步的试用，行政绩效监督系统也逐步开展用户培训工作，企业服务系统则被安排在相对靠后的时间。

    问题的根源在管理

    虽然项目并不能算是结束，但是此时进行一些回顾，也可以总结很多的经验和教训。

    首先，划定项目范围应谨慎，该项目所包含的数百项业务，是由A区政府划定的，涉及的部门相当于A区政府的一半。业务所占比例更低一些，基本采用由区政府下发调查表，各部门自行决定是否将业务纳入项目，但是从项目执行情况来看，数量还是过多。虽然业务平台在逻辑上将业务模型抽象成“信息-判断-传递”的迭代，但是大量的业务在开发过程中还是有不小的工作量。同时考虑到不少业务要采取开发以外的方式进行整合，这对于项目进度有非常大的风险。而在系统建设之外，向一线工作人员开始进行业务的推广时，大量的业务也会造成推广上的困难。但是，从政府的角度来看，如果项目范围较小，则项目的效益会较差。尤其是对于用户的益处就显得太小，这对于整个项目也是不利的，会造成在整个行政服务业务整合的进度上投入过长的时间。

    其次，项目质量与项目进度之间的矛盾要处理好，考虑到政府的特殊性，往往不倾向于时间较长、尤其是跨年度的项目。时间过长就会对项目进度施加非常大的压力，可能会因此影响到项目质量，如何解决需要认真考虑；

    第三，管理上的难点如何避免。类似的项目通常是由政府指派信息委进行监管，但是对于业务上的问题，信息委的权限与力量都是不足的，这也会对项目造成消极影响。同时，政府内部不同的部门也存在差异，某些部门的业务受到较强的垂直监管，横向管理力量自然就较弱，这对于项目也是不利的因素。类似的一些难点造成项目阻碍的情况还不少，如何避免同样需要十分谨慎。

    第四，业务标准化问题，不同部门之间，在业务上存在不小的差异，这对于整合业务是非常不利的。实际上有不少业务的差异都是因为部门运作方式的差异造成的，有一些业务流程节点是非必要的，在项目前期如果不进行相应的标准化，把业务统一到一个相对比较标准的模式中来，那不仅对于一线的工作人员来说要承受大量的不同业务的冲击，对于项目的承包商而言也很难在项目中获得可复制的能力。当然，要做业务标准化，也面临着更大的困难。

    应该看到，SOA是帮助公共服务部门整合业务的一个非常合适的手段，但是必须认识到，先有了业务和管理上的需求，才有利用技术手段解决问题的可能。很多的问题根源并不在技术上，而在于管理上。前面所提到的那些问题，还需要在今后的实践中去一一的解决。
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。