SOA_analyse.doc

哪些行业会是面向服务架构（SOA）的先行者一项突破性技术产生后，总要有第一批勇于“吃螃蟹”的先行者来示范。这个道理应该同样对SOA适用，所以一直在思考和留心这个问题，“哪些行业会是SOA的先行者？”随着SOA实际部署项目的逐渐增加，答案也慢慢浮出水面。最近，Forrester出了一份关于亚洲SOA在各个行业应用情况的研究报告（Asia Pacific SOA Industry Adoption Trends），副标题就是“公共部门和金融行业将主导SOA投入（Public Sector And Finance Will Drive SOA Spend）”。另外还看到过来自易观国际的一篇分析报告，“中国中间件市场及部署SOA趋势展望”，同样提到排名前三的行业需求来自电信、金融和政府。答案不算出人意料，这里倒是可以检讨一下其中可能的原因。提供增值服务是这些行业的特点之一。而且无论公共部门还是金融服务，行业内提供的服务基本是同质的。在提供同质服务的行业里，取得优势的通常方式是如何提供差异化和创新。在差异化和创新中，信息系统的支持应当是不可或缺的，特别是一个高效灵活的业务信息系统。SOA的理念正切合了这个需求。先说差异化，例如：金融行业里各个银行对个人提供的基本业务基本没有本质的差别。如果说差别，大多数是用户体验的差别。用户体验的差别源于业务流程的差别。而说到对业务流程的优化与重组的支持，SOA无疑是有优势的。再说创新，现在的公共部门总是在不断推出各种各样的便利新服务，这些服务大多数也都要以信息技术支持。说到信息技术为支持业务创新应该要具备的柔性（Flexibility），SOA同样是有吸引力的。这些行业能够率先“尝鲜”SOA，也得益于其良好的信息系统基础。无论是公共部门还是金融，都应该算是信息化比较成熟的行业。就那国内来讲，这些年的信息系统建设投入，早让公共部门还有金融行业，实现了全面的信息化。不管是硬件设备、软件环境，还是管理意识、人员素质，都能说是万事具备。转向SOA，是一个自然而然的举措。因为SOA理念的运用，无疑会帮助加速整合其信息技术方面的优势，对业务发展提供更好的支持。除了信息技术的原因，管理的标准化也便利了SOA的推广。公共部门或金融行业，管理上相对其他行业，例如制造业，可以说更加有规矩可循，在这些行业中大多数业务流程都已经在管理上被清晰定义，SOA的概念非常容易同业务模式互相映射。拿SOA中最困难的问题之一，关于业务流程中服务划分的颗粒度问题来讲，在这些行业能够比较好的参照原来的业务定义来做映射。而且，关于服务的对内对外接口也相对稳定。SOA理念和管理模式的契合，对获得各方面的认同和支持也是必要的。最后还有一点比较重要的因素，就是在公共部门或金融行业中个体占有的市场地位对采用SOA的影响。毋庸置疑，这些行业里的个体都占有相对垄断的地位。一方面垄断地位说明其独享一个庞大的市场，服务具有相当数量受众。SOA概念的实施，能够受惠一大片，取得相当大的效益（经济的或者是社会的）；另一方面，垄断地位让其有能力来领导和掌控SOA项目，特别在项目早期，项目效益的示范作用还不明显的时候，一个强有力的领导者能避免项目的夭折。SOA项目的集成（Integration）效益是随同参与者的增加而增加的，也就是说越多人参与进来，不仅倍增参与者的增益，而且降低参与成本。总之，行业的垄断地位，能保证足够多的参与者，也能在避免不必要的犹豫不决和踌躇不前。检讨公共部门和金融行业能先行主导SOA的原因，是希望对其他行业的SOA推动有所借鉴。实施SOA并不是单纯的技术革新，而更多的是方法论和业务模式的进化。SAP在这方面一直是强调“进化论”。从上面的分析，也能看到SOA的成功需要从管理到技术，从内部到外部，从设备到人员，等等，多方面协同推动。电子政务需要SOA，从面向构件开始SOA已经有很多人在讲了，并且讲的时间也不算短了。以此为题做论文，难度可不小。不过，既然是面向服务的体系架构，我始终以为，SOA是不能脱离业务的，它应该首先是一种业务设计方式，指导着隶属领域范畴的业务服务的构思、创建、使用、变化和终结。其次，这种业务设计方式应该在面对不同领域范畴的不同业务服务的各个生命周期中能够始终如一地贯穿技术标准化的策略原则。所以，要谈SOA，我还是把它放在一个特定的领域，比如电子政务领域谈起吧。如此接下来的话题就自然而然地变成了以下几个：电子政务需要SOA吗？是过去需要、现在需要，还是将来需要？电子政务的SOA如何开始？电子政务需要SOA吗？我国的电子政务建设格局像一个纵横交错的大棋盘，在刚刚过去的“九五”和“十五”期间，我国各级政府部门纷纷规划和建设起各自的电子政务系统工程，从中央到地方竞相投入人力物力财力，在很多方面都取得了显著的阶段性成果。以国信办17号文件中所规划的12“金”工程为代表，国家各大部委正在积极借鉴“金税”、“金关”、“金盾”等工程的成功经验，努力而快速地推进自上而下的、涵盖“部、省、市、县、乡”等五个层次的纵向综合业务系统。纵向电子政务建设的成功经验是围绕政府的某项具体职能，利用信息化的手段，达到业务标准和业务资源的统一，实现数据自底向上的快速准确汇集和业务自上而下的高度协同。“金税”、“金关”等工程的实施也确实证明了它们在强化政府的税收管理和外汇管理等方面所起到的巨大作用。从某种程度上讲，能够自上而下的推进涵盖“部、省、市、县、乡”等五个层次的纵向综合业务系统，本身就是SOA的一种体现，只不过此时SOA的设计仅仅是面向内部的、面向具体业务功能的，因此也是局部的SOA。局部SOA的后果就是，局部的统一不能带来全局的统一，如果跳出局部看整体，在更宽广的范围内来看，比如站在国家电子政务全局来看，或站在公众的角度去看，满眼尽是一个个划地而治的信息孤岛，需要为整体去做集成。而这恰恰成为了横向电子政务所需面临和解决的信息共享和资源整合的挑战。横向电子政务正在逐步实现由“政绩导向”向“服务导向”的转变。以服务为中心，使老百姓能得到更广泛、更便捷的政府信息和服务，使政府真正转变为服务型政府，党和政府为此都做出了重要决定。党的十六届四中全会做出了加强执政能力建设的重要决定，提出转变政府职能，创新政府管理模式，是提高政府执政水平的重要措施。温家宝总理在主持召开国家信息化领导小组第三次会议上提出要从全面和战略的高度加快推进信息化建设，抓紧推进电子政务，提高政府的经济调节、市场监管、社会管理和公共服务能力，促进政务公开。因此，以公众服务为中心，服务公众就成为电子政务建设的出发点和落脚点。过去的经验是功能性的、局部的，现在要求以公众服务的角度去看电子政务全局，面向服务去重新梳理业务流程，即面向服务去详细描述政府和公民互动的过程、政府履行的各种业务与功能以及关键的业务流程。电子政务建设必须面对以下几个挑战：1、如何做好电子政务的顶层设计？尤其是在跨部门电子政务项目中，如何加强牵头单位、协作单位、信息主管、决策领导之间的联系？2、如何克服以部门为中心的思维方式，设计出既满足局部功能，又符合发展要求（如快速适应变化），同时又能参与全局协同的服务？3、如何有效评价服务的质量和更好的理解各部门的互相关系？4、如何把以单个部门为核心的不兼容的信息系统升级为以服务为中心的、可集成的统一的服务或服务组合？这些挑战有技术范畴的，也有业务范畴的。可以给出的解决方案是首先要给出一组服务业务模型和服务评价模型，业务模型描述服务业务的可持续发展，不仅包括它的创建态，还可以包括其变化态和协作态，评价模型描述服务的评估态。这个模型就是SOA提倡的方法论。在这个统一的方法论指导下，将模型细分为服务域、服务流程和服务构件，并始终贯彻统一的技术标准加以实现，就能基本解决上述的几个挑战。现在再来重新审视一下我们是如何做到了以服务为中心这一点的。“政务公开、公众服务、决策优化”正成为电子政务发展的新形势，以服务为中心，使老百姓能得到更广泛、更便捷的政府信息和服务，以服务为中心，梳理和重组业务流程，使各个业务系统能够互联互通和资源共享，有效降低实施和运行成本，提高监管能力和公共服务水平。因此，电子政务的发展需要以服务为中心的设计和方法指导，这就充分说明了电子政务需要SOA的论断是必要而且可行的。是过去需要、现在需要，还是将来需要？电子政务需要SOA已毋庸置疑，但是什么时候最需要？过去、现在还是将来？人们在考虑这个问题的时候，往往会想到我过去已经建了哪些系统，现在还需要建设哪些系统，哪些系统需要整合，至于将来，有个五年规划就可以了。实际上这是走入了一个误区，即将建设与整合孤立看待。这一误区的主要表征就是以孤立的、静态的、割裂的，而不是发展的眼光看待电子政务的应用建设和应用整合，将业务需求和业务发展割裂开来，以致建设出来的电子政务系统需要整合，整合的电子政务应用仍是按静态需求建设起来，如果需要则再次整合。而走出此误区的方法就是将建设和整合有机统一起来。要树立没有从头建起的系统的观念，要从设计上就能够充分意识到系统总是在整合一切可以利用的资源（内部的、外部的）的基础上发展起来的，是为了满足新的业务变化需求。新系统就是旧系统的利用整合，同时它又是将来能够被新业务整合的资源。 实际上，有些人可能会感到惊奇，但面向服务的架构确实已经存在20多年了！因为SOA是基于一种设计理念及一系列设计原则的，而这些都是与技术无关的。在过去20多年里，可用于实现SOA的技术是多种多样的，它们包括CORBA、J2EE、COM/DCOM、MQ、ebXML、EAI、ESB等。在这些技术中，有的适于构建SOA，有的则不然。从某种意义上讲，SOA可以被看作是EAI的一种延续，但不是简单的延续。EAI与SOA同样解决企业集成的问题，但SOA解决的问题远比EAI解决的IT问题多得多、复杂得多，因此产生的影响要深远得多。有一部分应用集成问题是可以通过EAI来解决的。但是，EAI解决集成的问题往往是在事后，碰到了集成问题，才去想办法通过 EAI来解决。与之相反的是，SOA架构解决集成的问题是事先的，也就是说，在一开始搭建SOA这一IT架构的时候，就已经考虑了集成的问题。这是SOA区别于EAI的一个重大不同，也是SOA能够帮助我们走出“割裂建设和整合”误区的佐证。 另外，EAI解决集成问题时，可能会带来更多其他集成问题，最终会带来一个更加复杂的IT架构。SOA解决这些集成问题时，是将现有的系统以统一的标准接口进行一次重新的梳理，不会再带来新的集成问题。因此，电子政务是时时刻刻都需要SOA的，过去需要，现在需要，将来也需要。尤其以服务为中心和导向的电子政务建设需要SOA，在它的指导下，我们才能够避免走进误区。电子政务的SOA如何开始？我们已经论证了电子政务需要SOA，但现在的问题是在电子政务的建设过程中，如何才能发挥SOA的最大功效？SOA该如何做起？面对我们所涉及到的众多重要概念，如面向服务、顶层设计、业务模型、流程重组、服务构件等，我们该如何入手呢？首先，要把SOA看成方法论，要根据电子政务的业务需要，通盘考虑所需要的业务模型和数据模型。每一条业务线和数据线都要从服务的特征、管理的特征和适应变化的特征去审视，并且每次审视都要围绕上下左右中等多重视角，还要加上一个时间维度。可能需要建立新的成本/利益模型，要打破单个业务使用独立IT系统的模式，特别是那些可以重复使用的，必须要求服从一个统一的SOA架构，开发出有层次的、可重用的体系。其次，要把SOA看成架构平台，或者说要根据业务模型建立支撑重用软件的运行和管理平台。在可重用的层次模型支持下，平台要做到技术无关性，就要以统一的标准去运行和管理重用软件。再次，要把SOA看作是软件工厂里的产品装配线。它是一笔对将来业务运营的投入，所以在这笔投入发挥效益之前，需要做相关的计划、设计和开发工作。正如生产线上制造的第一辆车的花费要比第一千辆高出很多一样，用SOA部署的第一个服务所需的花费要比部署第一百个多出很多。SOA的主要优势是逐渐体现出来的，不能一蹴而就。最后，必须投入足够的精力和人员进行技术和业务流程的培训，才能确保所开发的服务是可重用的。任何服务的开发，不能只顾及眼前利益，也要（或许是更重要的）考虑长期利益。换句话说，各个服务的单独存在并无太大价值，除非这些服务能与其他服务一起被使用，并能根据业务的变化，快速组合成各种新的应用。 上面，我们是在尽量使用业务的语言去说明电子政务的SOA应该如何开始，现在让我们用技术化的语言重新诠释一下。SOA的方法论就是电子政务领域的一个个构件库，它们在业务模型的支持下呈现出层次结构，构件粒度可大可小，大构件是小构件的组合，上层构件是对下层构件的抽象，在一定的层次上，构件表现出一定功能的服务特征。SOA的架构平台就是一个标准的构件容器，它负责解释、运行、监控实例化的构件。这个构件容器是能够跨技术平台的，允许不同服务之间交互数据、参与协同流程，无论它们各自背后使用的是何种操系统或采用了何种编程语言。SOA的装配线就是构件的图形化集成环境(IDE)。可以在这里创建构件、复用构件、嵌套构件、组装构件，可以在这里通过构件的组装生成一个个服务。而服务因为具有了内部的构件化特征，使得服务成为一个柔性的结构，而一个柔性结构在适应变化方面要远远优于一个钢性结构的服务，从而延长了这个服务的生命周期。所以说，SOA可从面向构件开始。SOA从面向构件开始从面向构件开始，电子政务的SOA就建立在了可被管理的业务单元基础之上，而不是建立在不可被管理的代码之上，构件成为业务的技术无关性基本单元；从面向构件开始，电子政务的SOA可以从一个局部做起，以渐进的方式向SOA架构演进，因为构件的标准统一使得这个局部不会给全局带来新的集成问题，这样可以最大程度地规避项目风险，降低初期投入；从面向构件开始，电子政务建设将最终达成我们梦寐以求的标准统一，架构统一，建设统一，管理统一；从面向构件开始，电子政务将实现一个同构的世界。评论：通盘考虑所需要的业务模型和数据模型。每一条业务线和数据线都要从服务的特征、管理的特征和适应变化的特征去审视，并且每次审视都要围绕上下左右中等多重视角，还要加上一个时间维度让架构师真正成为SOA实施领航者TechTarget在近期采访了webMethods公司SOA市场营销部副总裁Miko Matsumura，本文即采访的第二部分。在此他讨论了谁会在2007年领航SOA教育以及为什么这个问题是决定组织实施SOA成败的关键，主要谈到一个艰巨、困难的任务，就是使SOA具有无限的业务主动性，以及成功地实现SOA的业务主动性又会对企业、组织带来些什么优势。查看本次采访的一部分问：在采访的第一部分中，你谈到关于SOA教育的问题，以及除了IT因素外，SOA教育在推动服务导向架构中至关重要，可是谁会成为领航SOA教育的关键人物?Miko Matsumura: 我认为SOA教育的领航人应该是一个广泛的合作伙伴。我已经看到一些提供商在进行SOA教育。我认为分析师和第三方提供者也同样有机会做SOA教育课程。当然也有综合人员的教育角色，他们可以加入，提供一些培训。所以可以提供SOA教育的人群非常广泛，他们都随时有可能成为SOA教育的领航者。问：是什么导致这样的现象产生?Matsumura:出现这样的现象是因为一旦当你开始认真实施SOA，系统的可测量部分会需要可测量的理解，而系统中我们看不到的架构会给组织带来困扰和阻碍，应该根据组织实际需要配置。问：调查中发现业务人员对SOA没有切实了解，这个问题是由它造成的吗?Matsumura:是的，所以在进行SOA教育时这些虚幻、看不到得架构需要多方合作，由任何可以提供帮助得人组成一个合作团队。所以，很多情况下会出现提供商合作。架构师也希望通过提供商可以帮助他们传播SOA的讯息。很明显，提供商是出于商业原因才会参与到团队合作中。当然，也会有综合人员参与合作教育，同时，这也为第三方提供了许对机会。问：那么在进行SOA教育时，架构师需要进行帮助?Matsumura: 进行SOA教育的模式这样的，由有SOA知识的架构师提出大纲，由许多相关人事组成团队按照大纲进行教育培训。ZapThink咨询公司预测2007年熟悉SOA的架构师将供不应求。由于面向服务架构成为市场需要的功能，所以熟悉掌握SOA的架构师也会炙手可热，供应不足。值得注意的是，有许多人对SOA的了解还十分肤浅，所以SOA教育要做的就是让那些受过培训的人可以在组织中帮助宣传SOA知识。缺少有资格的架构师将成为2007年的又一迫切问题。问：那我们需要培养教育更多的、有资格的架构师吗?Matsumura: 那是当然。关于这个趋势有趣的是如果你看机器技术方面，你会发现大部分的人员培训是成线型规律发展。培训的内容都是可以设计、考核的。而在业务领域对接受面向服务架构来说，规律是由两条平行线来表示。一条线需要关注知识，而另一条线要关注动机。这两者都是重要的战略信息。所以，也要教育人们关心SOA。目前，就是这种性质的SOA在不断进步。问：那些方面在不断进步，这有意味着什么?Matsumura: 从IT服务层到业务服务层都在不断提升、进步，这是一种方式、方法的改变，从按照服务管治或IT管治的形式转变为以公司管治的方式经营企业。这就意味着整个公司可以分解为多个业务服务。这些业务服务通过业务单元和竖井相互依赖，在外部，又通过合作者和调整者、消费者和提供商相互依赖。这就是服务生态系统平台模式。这是按照人类有动力地参与学习的方式进行。例如，如果在一个孩子的房间中放一个收音机，并用中文一直播放广播，通过观察研究人员发现孩子并不能学会中文，如果不是在房间中交谈，那么广播只是一种噪音。所以，仅仅处于语言环境中是不够的。必须要有学习的动机。因为孩子没有跟着收音机学习语言的动机，所以它只是噪音2007年SOA发展趋势的分析和建议截止2006年年底，越来越多使用Java 和.NET技术平台的数据中心与SOA的有效应用产生冲突。通过与运营经理，应用软件研发人员，IT 执行主管探讨，预计在2007年，SOA内及其相关行业将出现如下趋势，并向您提供这样的一些建议。 IT企业继续从架构和标准层面上对SOA进行评估。但是，截止2006年年底，越来越多使用Java 和.NET技术平台的数据中心与SOA的有效应用产生冲突。从总体趋势上来讲， 这些情况在很长一段时间内依然会持续发生，应用软件服务器的使用从商业边沿转移到了中心地位，数据中心将之看作是他们运营的核心。 而许多这样的数据中心可能并不被认为是SOA, 他们比SOA有过之而无不及。它们是充分的分布并在功能性和复杂性都有成长潜力的应用软件， 而且正变成商业交易的重要组成部分， 在一些案例中也扮演着关键的角色。但是，也有一些技术人员争论到底他们是不是真正的SOA应用。从SOA初步目标来说，他们更快实现了整合，再利用和重新包装和重新定义商业系统目的的目标，而且从成本上来说也更为低廉。通过与运营经理，应用软件研发人员，IT 执行主管探讨，预计在2007年，SOA内及其相关行业将出现如下趋势，并向您提供这样的一些建议：1、应用大过技术人们已经将SOA视为一项技术而非解决方案太久了。在2007年，其重点将径直向着应用的方向发展，具体来说，是向如何管理，监控和扩大已有的Java与.NET应用发展。直到前不久，关于SOA的讨论还着重于寻找服务，选择基础架构，管理开发，仅此而已。以Web服务为基础的应用软件方面的发展使得开发人员着重于一些技术以便得出商业解决方案，驱使数据中心寻找能帮助直接监控和管理已有成果的SOA应用。假如你想要在SOA技术中找寻ROI(Return on Investment，投资回报)成分，那就请转移注意吧。将您的侧重点重新放在如何将现有的Web服务变得更有效率，在数据中心中更易管理上来。从这方面，SOA和Web服务已经证明了自己：以SOA为基础的解决方案正成长得更为有机，因为它们能完成工作。不管是否是由于端口、电子商务、应用软件整合项目或者商业情报的需求，Java 和以.NET为基础的实施方案已经在IT界发展出合理的甚至是成功的解决方案。我们的建议是：在初始阶段，不要选择SOA管理工具包或者管理解决方案，为你的Portal，程序整合或者系统合并项目选择所需的技术。记住，这是应用。如果对程序引擎有具体的业务驱动要求，考虑使用ESB(Enterprise Service Bus, 企业服务总线).如果该项目是为端口，考虑使用具体的Portal技术。要持续关注该应用软件和并以其对商务程序的影响为基础测量结果。2、装配而非购买第二种趋势的核心是：越来越多的人意识到真正的价值在何处。这样的改变是由于该领域的中心从企业应用软件转向数据中心的核心复合软件。这种观点是由Oracle 和SAP加强并巩固的，他们都在为将其SOA产品Fusion 和 NetWeaver引入市场做努力。这种观点的核心在于装配应用软件包的客制化部分、遗留系统、复合软件的客制化逻辑，而非应用软件包本身。从另一个方面来说，客制化已经从应用软件包、数据库走了出来，进入Java、商业流程引擎和Portal逻辑，它能很容易的在企业软件升级时创造、管理并灵活的根据商业需求重新配置。我们的建议是：持续思考其应用和所解决的商业问题。在SOA平台上建立你的商业价值观并通过你的商业目标来确定使用的SOA架构种类。在这条道路上，你并不是孤独的，因为BEA、IBM、 微软、甲骨文和SAP都将在2007 继续倡导在复合SOA应用软件中建立自己的价值观。3、重点在于生产许多数据中心正意识到这些SOA应用的生产管理需要和操作中一些令人烦恼的问题。2007年里，SOA的管理将着重于对应用的管理。在过去的一两年中，SOA的管理意味着SOA架构的管理。这的确是重要的，但与数据中心面临的眼前挑战并不存在直接联系，那就是对新生复合面向服务应用软件的生产管理。数据中心将越过SOA管理解决方案而寻找着重复合应用程序运行时间的解决方案。曾经尝试监控解决方案的数据中心发现对网络、CUP、存储器和数据库性能控制台工具是远远不够的。我们相信到2007年末，争论将转向找寻能判断应用软件是否运行正常的解决方案。在这方面最好的方案将为自动化管理应用软件初期提供坚实的基础，以他们带来的应用软件中具体观点作为驱动力。我们的建议：在生产中运行，指向应用软件核心而非外围的解决方案才是您的首选。在测试环境中，SOA应用问题可能会异常难于复制。简单测量终端用户经验或者硬件指标的工具只能治标，你所需要的是能从根本上解决问题的方案。4、大胆思考关于SOA技术的争论已经沸沸扬扬，而SOA正悄然演变着， 在2007我们将看到由SOA带来的更大趋势有： 更小的IT商家会为他们的运营配置更复杂的客制化商业逻辑，同时在外围配以功能性软件包。 在大的企业中，客户内勤制度将为以在复合SOA应用中客制化为支持的标准ERP包取代。 数据中心SOA解决方案将与包括ETL在内的传统IT技术集合相结合，实现巩固操作数据，B2B通信的FTP，为后台流程管理进行工作日程安排，以APM(软件性能管理)管理SOA合成软件中的软件包部分。 标准软件包将越来越积极的将通过SaaS模式将外购作为目标。这些控制服务的不同之处在于，根本上并不来源于Web UI，而是作为SOA复合应用的一部分出现。 随着IT将资源整合入应用软件操作并从整体上管理硬件资产，SOA的应用将激起虚拟化的发展。我们的建议：在将你的商业逻辑转向SOA和Web服务的同时，确保考虑到所有即能降低成本又能扩大功能的机会。我们见证了此领域运用该技术实现的创新与成功， 并诚挚的邀请您成为2007大潮中的一员拨开云雾：中国SOA应用大调查分析报告如今，服务导向架构(SOA)不仅仅是首席信息官(CIO)耳熟能详的时髦话语，而且也真实体现了企业IT架构的应用趋势。虽然SOA在国内尚处于 早期部署阶段，但中国企业对SOA的投入却在快速增加。信息周刊和埃森哲的调查显示，一些国内企业出于业务需要，期望通过部署SOA，获得更大的商业 价值。同时调查也表明，中国企业部署SOA还存在着一定的风险和挑战，因此，清晰的部署规划及路线图显得尤为必要。 积极部署与欧美企业相比，SOA对于大多数中国企业还是一个新名词，其商业价值也还有待证明。但是此次调查结果表明，大多数中国企业已经意识到部署SOA的必要性，并且对SOA的发展前景抱有很大信心。参与调查者中，四分之一的企业已经针对SOA采取行动，包括进行内部SOA相关培训、规划SOA系统架构蓝图、测试SOA应用以及把SOA作为 主要流程架构在企业内部署。另有67.8%的企业虽尚未采取行动，但他们表示正在了解和研究SOA。上述中国企业中，有80.9%的公司表示将采取积极态 度部署SOA，73.7%的公司表示在未来两年内有SOA项目的部署计划。可以预计未来一两年内，SOA在中国将进入快速发展期。调查还显示，SOA应用与企业的IT部署程度紧密相关。调查结果显示，中国企业部署SOA的比例与其IT应用现状基本吻合。在参与调查企业中， 拥有SOA应用的占8.8%，大中型企业部署SOA的比例略高，350家大中型企业中，有10%的企业已开始部署SOA应用。在已经或计划部署SOA的企 业中，四分之一已经有限部署了电子数据交换(EDI)、XML、Ws*、SOAP、UDDI、BPEL、BPMN等SOA基础技术，但主要集中在大中型企 业。已经或计划部署SOA的受访企业，既包括大中型企业，也包括了一些规模较小的企业，这种情况反映出企业是否部署SOA与公司规模并不存在必然联系;同时也表明，通过部署SOA，小企业可以缩小和大型企业之间的差距。值得注意的是，中国企业部署SOA的基础仍然十分薄弱，明显体现在应用管理制度的缺位。此次调查数据表明，91.2%的小型企业与76.9%的 大中型企业，缺乏有效的应用系统管理制度，不能对企业所有的应用系统进行监控评测，并根据业务需要对系统进行升级、调整。所有参与调查的企业中，仅有 15.5%的企业拥有比较完善的应用管理制度。业务驱动不过，此次调查也发现，SOA早期部署者已拥有较为良好的IT基础应用，且大多处于应用整合和数据挖掘阶段。调查显示，商业智能(BI)、客户 关系管理(CRM)、供应链管理(SCM)等系统是中国企业基于SOA开发新应用的优先选择。这表明，部署SOA的中国企业在渠道管理、客户管理方面有较 为突出的业务需求。事实上，部署SOA是一项由业务驱动的组织变革，而不是技术带来的成本削减。SOA所具备的灵活性和可重组等特征能够帮助中国企业适应急剧变化 的市场及客户需求，这正是中国企业目前的迫切需要。调查数据也显示，中国企业90%的应用无法满足企业未来的业务发展，而SOA由于能够有效加强现有应用 的能力，因此被视为企业IT投入的优先选择。中远集装箱运输有限公司(下称中远集运)是国内最大的海运物流企业之一，其EDI系统承载着中远集运的核心业务，是维系企业贸易活动的命脉，同时它 也是最容易被业务变化所牵制的部分。尤其是“911”事件后，美国出台了“提前24小时报关”的新规定，使得中远集运的原有业务流程受到重大影响。 而且，该公司的业务涉及全球很多国家和地区，不同地区的海关流程各有不同，在原有固化的系统中，只要某个国家的海关提出特殊需求，往往需要公司 另起炉灶，专门进行定制开发，费时费力，反应缓慢。因此，自2004年起，中远集运基于SOA实施了新的EDI平台，在一个平台上，就能够方便地把几个程 序组装起来，这样可以快速响应需求，为中远集运未来的业务扩展提供广阔的空间。许多中国企业在成长过程中都面临着与中远集运类似的情况。在选择部署SOA的首要驱动因素时，参与调查的企业十分强调整合现有应用系统以及整合 业务流程。不过，相对而言，小企业对商业创新明显较为关注。15.8%的小企业认为，部署SOA是建立新的业务能力的基础。同时，38%的大中型企业也表 示，建立新的业务能力是企业在未来部署SOA最重要的驱动因素。业务驱动使企业部署SOA时更为看重商业价值。参与调查企业中，88.8%的企业优先认可SOA的商业价值。其中，分别有43.1%和 44.6%的大中型企业期望通过部署SOA促进企业的业务发展及流程优化，只有12.3%的大中型企业认为SOA的价值主要是技术创新。部署风险较早开始SOA部署的企业已经意识到，部署SOA并不是简单的购买软件产品，而是需要通过一定的投入进行组织的深刻变革以获得最大的利益。在已经或计划部署SOA的被调查企业中，三分之一的被调查企业的SOA预算在100万元人民币以上。中国企业还认识到，部署SOA存在一定的风险，它并非一剂包治百病的万能良药，也并非适合所有企业。对于部署SOA无法达到预期的原因，调查显示，企业对此有不同的看法。56.3%的已部署企业认为，技术或产品不成熟是导致SOA应用达不到预期的主要因素。而同时大多数企业并不认为技术问题是部署SOA的最大障碍，业务流程没有完全准备好才是关键。这种认识上的差异可能与问卷填写者在企业中扮演的角色不同有关。由于绝大多数中国企业缺少部署SOA的经验，在部署SOA过程中面临着很多未知困难。已经部署SOA的企业提醒说，流程再造的准备不充分、无法明确SOA的商业价值以及与管理层沟通的困难等因素很可能会成为后来者部署SOA的障碍。部署SOA的困难和风险，也使得国内企业在部署SOA之前应当考虑一下自己是否具备足够的资源。调查中，有四分之三的受访企业表示，希望在部署 SOA过程中借助外部资源。福建省工业设备安装有限公司2005年年初启动SOA项目，经过需求调研、架构设计、流程优化、应用开发，目前其SOA项目正 处于部署测试阶段。该公司信息部经理郭珅认为：“准确的认识及理解SOA、深刻把握业务整合的需求，强有力的领导支持、选择成熟的产品及咨询服务商是SOA项目成功的关键。”辉瑞制药有限公司中国区信息业务与技术总监潘俊杰建议，中国企业应当慎重部署SOA。他认为，并不是所有的项目都适合SOA的架构，比如数据库 和BI。当涉及到海量数据时，SOA并不是一个很好的选择。另外，SOA搭建框架阶段的时间会比较长，这段时间内可能看不出SOA的价值。只有当业务需求 发生变化，SOA才能证明这种框架能够在多大程度上适应这种变化。定制路线图 中国企业在部署SOA之前，需要清晰的部署规划以及度身定制的部署路线图，这将是避免投资浪费的最佳选择。对于从何处切入部署SOA，不同企业 有不同的选择。已经或计划部署SOA的参与调查企业中，28.7%的企业选择测试单个SOA应用、33.8%选择基于SOA的系统及信息集成、19.3% 选择基于SOA的部门内部自动化、13.4%选择跨部门的SOA应用、4.8%选择基于SOA的合作伙伴产业链。伯灵顿全球有限公司(BAX Global，下称伯灵顿)选择了合作伙伴产业链部署SOA。现已被德国铁路股份有限公司(Deutsche Bahn AG)购并的伯灵顿最早是一家空运公司，有核心的空运系统，随着业务延伸到仓储、运输等领域，其客户如戴尔公司(Dell)、联想集团(Lenovo)、 摩托罗拉公司(Motorola)等希望伯灵顿提供跨供应链的信息