这篇文章要给大肆宣传SOA和为SOA问题提供答案的人泼盆冷水了，本文谈到的很多问题都涉及为何、如何以及何时应该（或不应该）开始考虑实施SOA。
CIO 们正在追赶地平线上遥远的一个红点，这就是IT的灵活性，这是一种能快速改变IT以适应业务需求的能力。但是这个点如同落日一样正在渐渐消退，远离他们。
最近由企业绩效管理协会（Business Performance Management Institute）资助的一项调研发现，只有11％的受访信息执行官说企业的IT架构能够满足业务需求，实现由技术启动的业务流程改变——根据调研，这些业务流程现在有40％需要IT部门的帮助和关怀。更糟糕的是，36％的信息执行官报告说，在满足业务需求方面公司的IT部门现在面临“重大困难”，或者说“完全跟不上业务需求”（后者占到了9％）。
“Service-oriented architecture”，面向服务的架构，简称SOA，是一大长串最新被大肆宣扬的战略之一，这个战略设计用来把消失在地平线上的那一红点（灵活性）带回到人们的视线中来。SOA在技术上反映了大量重要的业务流程，它有望给公司提供一套服务的组合，这些服务能被快速混合并且迅速匹配，创建自动化流程，从而以高达50％的比率降低应用程序的开发时间和成本。
SOA 的起点卑微，最初是一种以项目为导向的设计，和一套基于要素的软件开发方法，而现在它已经步入一个倍受期待的专属领域。SOA的故事在继续，它不仅仅设计用来重塑IT，它还将成为一颗能促成业务转型的魔力子弹，转型前的业务也由IT为之提供服务，转型后更是如此。
CIO通常是一个具有怀疑倾向的人群，现在他们正在帮忙推动人们对SOA的这种期望。根据一份Forrester Research最近的一份调研，有46％的大型公司SOA用户（中小企业大约有27％的SOA用户）说他们正在使用SOA “来实现战略性业务改造”。来自其他研究机构的调研报告也显示了业界存在同样的热情，一份高层战略调研显示SOA具有“竞争优势”，这种竞争优势具备最受欢迎的期望值，而且在阿伯丁集团（Aberdeen Group）进行的调查问卷中，SOA是占据首尾的、能够“拓展新能力和开发新产品”的占被选项。在《CIO》和《Computerworld》最近完成的一份调查中，77％的问卷填答者都说SOA会带来更强的业务灵活性。
并且，SOA有可能做到的事情会更多，只是还没有被完全发掘出来。
其实比你想得还要艰难
SOA还远非一个经过检验的概念（在Aberdeen的调查中，只有16％的公司有超过24个月的SOA技术体验），而且应用SOA最成功的公司到目前为之都是那些在技术方面总是取得成功的公司：这些公司都有充足的IT预算，他们的业务总是基于技术展开（比如说通信和金融服务业务）。这些公司也往往对SOA抱支持的态度，并且有技术方面非常老练的业务领导人当家。
对于那些没有这种优势的公司来说，SOA可能就不是能够包治百病的万能药了。
这是因为SOA需要更大的投资和更长久的战略性考虑，这项工作可能超出了CIO的预想。SOA的战术部分——以服务为导向的开发，是一个能加以客服的挑战。但是战略部分——创建基于多个服务组合的架构，却要求CIO创立一个引人注目的企业架构案例、一套集中的开发方法和一个由项目经理、架构师和开发人员组成的集中工作团队。它也要求有一位积极配合的CEO和执行官团队为IT深潜入公司的核心业务流程铺平道路。理解这些流程以及实现企业大规模资源共享，这是基于SOA的业务改造工程得以实现的真正必要条件。
有些公司没有技术产品、缺少足够预算，或者没有那种每次进入会议室都不想辱没CIO的名号的激情CIO领导人，对这些公司来说，SOA并非一个实现业务改造的保险路径，在某些情况下，甚至是不受欢迎的事儿。对于小公司和那些押大宝于集成应用套件的公司，以及已经有固定的应用集成战略到位的公司来说，SOA不是一个“何时开展”的问题，而是一个“是否开展”的问题。CIO需要仔细考量SOA战略，因为SOA服务开发和SOA架构设计是截然不同而又相互依赖的两个部分——它们需要并行考虑和执行。孤立打造的服务，没有考虑公司的整体架构和业务目标，可能不会有重复利用的潜力（而重复使用是SOA最重要的一个好处），或者有可能彻底失败。重大的架构计划实施可能会无限期拖延下去，不会产生任何实际的业务上的收益。
而灵活性本身却难以量化。“我们不能说，打造SOA是因为它将为你提供一套更具有灵活性的系统”，Daniel Sholler说，他是Gartner的研究副总裁。“没有标准说，如果我更灵活我就能节省多少百分点。SOA的头号难题就是难以把它的ROI（投资回报率）落实到财务电子表格上”。的确如此，集成软件商WebMethods 公司进行的一项调研发现，最抑制SOA的两个头号因素分别是，缺少对SOA的整体认识和量化SOA投入产出比的困难。
David Johns在建筑材料公司Owens Corning 身兼数职，他是公司的副总裁、CIO，以及负责供应链项目的首席执行官，他警告说任何技术战略实际上都没有固有的ROI。因此他说：“开发一个以服务为导向的架构不是我们的目标。推动生产力提高和把浪费驱逐出供应链则是真正的目的，而且在判断和选择技术解决方案的时候，我们会从SOA产业所吹嘘的最新、最高级的技术以外开始我们的筛选工作”。
有些人甚至更加怀疑。“公司正在围绕SOA建立一套复杂的官僚机构，其中大约有90％的时间被过度浪费掉了”，Thomas Gagné说，他是软件和金融服务供应商InStream Financial公司的CTO。“为什么我们要更换技术，为什么我们要人为地让员工技能过时的速度超过我们看到收益的速度呢？这些技术之前得到我们的肯定，而现在却主观推测它们达不到我们地要求”。
在开始讨论SOA业务改造成活率之前，这是一个CIO需要自问的难题。
我们在下面列示了一些有关SOA的提问和专家做答，供读者参考。
一些有关SOA的问答
问题一：SOA 是一个技术架构，那么如何为一个新的技术架构给能够受益的业务部门设计一个恰当的案例？
做不到这一点。“不要和业务部门谈论SOA，因为业务部门根本不关心它”，Forrester Research 的分析师Randy Heffner说。SOA能够把应用成本降低到什么程度，以及帮助业务流程运行更快到什么程度，业务部门对SOA的兴趣就会扩展到什么程度。但是用服务的形式简单地重新编程，却不会带来前述成本和效率方面地收益。打造SOA，IT部门需要从建立多冗余IT应用开始，这些应用程序要能够被整合到一项单独的服务中去，或者有可能在多个业务领域使用专一的服务。为了和业务部门有效进行沟通，量化冗余会有帮助。“我知道这样的事实，在我们多目标的环境中，同样的数据在至少26个应用程序里被引用”，Jeff Gleason说，他是泛美人寿保险公司养老金产品及服务事业分部负责IT战略的领导人。“我们正在不停提取这些多路使用的数据，然后花费精力和成本在不同的地方储存。如果能完成流程架构改造，那么仅仅取消这种支持性成本就是一笔划算的大买卖”。
如果SOA被集中在关键业务流程上的话，那么它就具有一个灵活性系数，能够增加价值。举个例子，在鲜花在线交易网站ProFlowers.com，没有冗余应用程序或多业务流程单元围绕服务拥挤在一块儿。但是根据CIO Kevin Hall的观点，可以把鲜花定购流程拆分成不连贯的业务，这意味着，流程每一部分都能被隔离开，并且根据需要做出变动，以处理节日时间的高峰需求。当用一个独立的、庞大的整体化应用程序处理业务时候，如果流程某个地方发生变动或者交易量在某一时间突然增长（比如说情人节），这种情况就意味着要把整个系统拆分加以改造。
新系统在鲜花订货程序的每个阶段，把数据存储能力转移到最需要它的特定服务那里，一个集中处理的数据中心由此就可以对定购的高峰处理要求做出快速反应。ProFlowers的这个系统具有更强的预测能力，由于由服务驱动的流程在2002年就已经上线，所以从那以来就不再有断货情况出现，Hall说。“因为新架构下，我们能够在水平和垂直两个方向上调整系统（横向做法是增加更多服务器，纵向做法是拆分更多服务流程），这样我就不必为了在峰值负荷期间购买所需要的全部硬件设备来满足每一个服务需求。你不必一口吃掉一个胖子”，他说。
问题二：SOA何时外包？
复杂性是SOA的主要先决条件。小公司被固定在某个架构上（比如说微软产品），而且没有复杂的应用集成需求，他们就不是实施SOA的上佳候选对象。较大的公司其应用架构大部分来自某一个单独的供应商（根据我们访谈的专家观点，占到60％或更高的比例），它们会仔细考虑建立自己的SOA是否是必要或是否明智。
然后就是速度，就是对速度的需求。如果流程不需要迅速做出改动，那么单纯为了能够更块地改造IT而改造IT的做法是没有意义的。
在Owens Corning公司，75％的应用软件都来自SAP公司。Owens Corning的产品在全球以类似的方法制造和出售，这意味着，CIO Johns 一直以来都在推动通过SAP的应用程序来实现业务流程整合的战略。“SAP是这个整合战略”，Johns说。他的目标是把公司的全球分支机构都整合到同一个SAP系统版本上来，这个系统运行同一数据库。他也在监控SAP战略，这个战略以服务驱动公司的各项应用，从而为客户建立一个现成的SOA。
全球性的制造商Whirlpool 也押大宝于SAP及其全球流程整合，对于公司的副总裁兼CIO Esat Sezer来说，全球流程整合比建立应用程序集成更有意义。“我不再处理那种事情了，我已经把它们外包给了SAP。我希望SAP能处理好我过去必须自己完成的应用程序基本需求”。
问题三：创建一个服务比传统的应用开发和集成要求更多的规划和设计。服务驱动的战略会额外产生多大的成本呢？
Forrester的Heffner 估计，在设计阶段，面向服务的开发造成的额外工作会在30％到100％的范围内变动，在应用项目的总体成本中大概会占到10％上下的比例。额外的工作对于建立一个能够应用于多个业务领域的服务是必要的，这些业务领域每个都有自己特定的需求。泛美人寿的Gleason举了个例子，处理客户保险金支付的服务通常需要满足借助多种传输渠道的需求——也就是说，要借助网站、银行数据传输模块或者呼叫中心等形式——这些渠道依赖每个业务部门的业务流程。理解每个业务单元想通过什么方式来使用该服务，这是设计工作的一部分。而且，让所有业务单元就使用同一个服务达成一致意见，分析和确定服务的使用方法也是完成开发的一个关键步骤。
商业人士会常常意识到服务需要有额外工作付出，但却有可能不想为此付出什么。Gleason说，“我听到业务部门的人说这种话不下一百次了，‘如果你打算让我为首次创建这样的服务支付费用，那你就把我项目的成本收益弄没了，这个服务不会得到我们支持。并且我想让你继续努力，努力给应用集成编程，因为我需要这样的功能’。如此一来，我的工作就是帮助他们明白，所创建的服务实际上不是一个项目制品，而是一个业务架构制品。我们正在创建自己的一个业务架构，这个架构能够被重复使用和改造。一旦你让人明白了做这些事情的条件，那么他们就会停止对这些问题的担心——因为写码工作艰难，所以他们担心初次创建这个服务是否会花掉他们更多的钱”。
问题四：我能期望新创建的服务能有多高的重复使用率？以及这些服务的再利用率怎么用美元来表示？
Heffner，说服务的再使用，在形式上可以变化多端，而且取决于设计的精密度。反过来也取决于开发人员和项目经理的能力与经验。服务再使用也取决于围绕特定服务而开展的架构计划的设计水平的高低。举个例子，如果某个服务被当作一个广义SOA战略的某一组成部分进行开发，这个广义SOA战略包括了统一的开发方法、集中的架构设计团队和业务分析专家（业务分析专家能够在公司全局范围内考察流程，并且把业务部门独特的需求整合到服务的设计中去），那么这个开发出来的服务就更有可能被重复使用。“组织的其他部门有可能希望用某种方式使用一项服务，如果在不了解这种情况的时候就把它开发出来，那么最后让那些部门采用它是不可能的”，Gleason说。更糟糕的是，如果设计出的服务是一次性的，那么这种努力就不会复制到下一个服务设计中去。“你可能需要创建另一个新的服务来补充，因为你没有时间去修改第一版；或者因为现在它不能满足你的要求，所以你不得不另起炉灶”，Gleason说。“长期来看，如果我们不从一个架构的角度来看待服务创建，业务流程集成或业务流程管理就不会有前途。”
但是，根据Henffer的观点，一个服务即便只能被重复使用一次，那么它也能够给成本节省带来指数效应。即便服务需要更多的前端设计工作，重复使用却意味着不再有设计、编程的成本，或者不再有下次重复测试的成本。加在一起，所有这些环节总共占到一个软件项目成本40％左右的比例。
有经验的人士警告说，人们很难预知某项服务重复使用的情况。按规模大小给服务进行适当的排序，从而让花费在这些服务上的努力不会过多或过少，这是一门艺术。“我们面临着用什么指标衡量服务重复使用率的挑战”，负责IBM内部IT部门的集成架构的副总裁Howie Miller说。“我愿意采取的表述方式是：我们用30％的资产推动了90％回报的取得，这种方式对我更合适”，Miller说。Heffner同意他的观点：“在我谈话的一家汽车制造公司那里，他们告诉我有些服务被使用了20次，而另外一些却只被使用过一次，所以不能简单用再使用次数来衡量”。
问题五：我需要向业务部门展示我所做一切事情的价值。一方面是架构规划工作本身，另一方面是需要迅速向业务部门证明该架构的价值，我如何平衡这两者之间的关系呢？
架构规划是耗费时间的事情。利用已知的编程法则和广泛存在的技术标准（比如SOAP、HTTP等），面向服务的开发可以更快地进行。但是规划和开发需要并行展开，专家说。“我们根据需求实施开发，另外我们还进行跨度数年的长期项目，这些长期项目规划了我们的流程并且创建了企业级服务”，Kurt Wissner说，他是美国电力公司（American Electric Power， AEP）负责企业架构和开发的常务董事。“别人需要非常快的看到SOA的好处。这是我喜欢拿着项目设计图说话的原因，因为有了它你就有了切实的方案向别人兜售，这个方案具备充分的实施理由”。
尽管在建立服务（提高重复使用的可能性）之前能帮助业务流程图到位，但架构规划还是不会有取得短期回报的可能，这种状况对你所做的事情具有毁灭性的打击。“我曾经努力在另外一家公司按这个思路另起炉灶，但是我失败了。我们复制已有的系统，做了一个数百万美元的架构规划。它并没有产生超出传统的“点对点”集成更多的价值，我们没有任何东西可以表明所付出的努力。如果你在一个大型整体企业里开始架构性规划，那么你就会冒太多失败的风险”，Wissner回忆说。
在AEP，通过把企业整体规划分解成较小的模块，Wissner能够更轻松的从挫折中恢复过来。“因为实际需要解决的问题并不是那么庞大。我们曾经因为大上快干而消化不良，但是我们能随之采取校正的行动。如果你把事情分解成更简单的片断，那么它就容易消化了”，他说。
“业务流程要始终发生改变”，交通运输公司Con-Way 负责企业架构和基础设施的董事Praveen Sharabu 说。“没有人会在你用文档表述一切的时候等你两年，到你完成事情的时候，它将会是一堆过时和被废弃的东西”。
问题六：我负担不起创建那些相互差别很大、价值上百万美元的服务。我怎么才能知道哪些服务能给我的投资带来最大化的价值？
当拿不准的时候，就从涉及顾客的流程下手吧，直接去影响产生收入的环节，以及解决特定的业务关键问题。2006年由“企业绩效管理协会”发起的一项调查中发现，客户需求和偏好一直在保持进化，这成为变革业务流程或引进新应用的头号驱动力，紧随其后的因素是竞争威胁和新的收入机会（成本节省因素则远远排在第四位）。“外部所面临的应用需求是那些能提供最大化商业价值的应用，而且这些应用都会产生一整套不断更新的变革要求”，Gartner的Sholler说。“如果你能以10％的比例提高这类应用的水平，效果就会比提高低水平的应用的50％要好得多”当然，他补充说，SOA可能并不会比某些方案能提供更多的价值，比方说一套组合性应用。“但是如果你必须由自己通过某种方式完成某些工作，那么你就需要从面向服务的角度来实施”，他说。
问题七：SOA将任何影响IT部门？
如果你的公司是分散型的，那么就要准备为此做出努力。“必须有合适的人领导整个工程，而且必须让某个个人或小团队管理这个架构”，Eric Falls说，他是工业和建筑材料供应商Fastenal公司的高级系统工程师。“如果每个团队都被置于自主作战的境地，由此一来他们就会拿出创建服务的不同方法。你需要一个团队，进行协调和整体研发，你需要设置专人确保开发部门坚持使用统一的服务开发方法”。
随着服务组合数量的增长，面向服务的开发过程看上去有可能会像一条流水线。“它变成了一个工厂”，AEP的Wissner说。“你拥有不同的能理顺工作的项目团队，而且团队的规模能够随着需要增长或收缩”，AEP的Wissner说。
一旦这个SOA工厂模式获得向外的扩展，由于开发人员的生产力得到提升，所以可以期望增加更多的项目经理、业务分析师和架构师，ProFlowers的Hall说。“现在两名开发人员能做6个人的工作。这意味着架构和项目经理正在追赶上工程师的产出。我们现在有可能能够比3年前多做50％的工作”，他说。
那些程序员需要理解以目标为导向的编程和分布式应用程序——而这意味着要增加培训的投资。根据《CIO》和《Computerworld》联合进行的调查，只有25％回答者说拥有实施SOA所需要的人才——49％的受访者说他们正在计划，或者制定好了培训计划，以替代现有员工队伍，跟得上发展速度。
如果你不能击败现有的对手，那么就去和它实现集成吧
在新的SOA领域，企业供应商突然热衷于确保自己的应用程序套件能和其他产品保持“和平共处”。
在90年代，集成系统是简单的：从单独一家供应商那里购买尽可能多的预先集成好的应用软件。那种模式曾经很奏效，并且对供应商也非常有好处——因为集成应用套件是架构昂贵，并且要求有一份长期维护和支持合同做保障，这份合同确保了可以从客户那里取得稳定的、可预测的现金收入。
而且不管什么时候，对于新的服务架构，公司都可以在现有系统基础上增加一个新应用，CIO对这种痛苦的集成工作抱有恐惧心理，这给供应商提供了一个天然的销售优势。与其冒险采用一个具有“最佳血统”的产业新人的产品，CIO还不如从某家既有的优势供应商那里挑选一个预先集成的应用产品，这种选择会更轻松。即便新人的应用程序有着更好的功能，但是如果出现灾难性后果，价格昂贵的集成最后会变成被大肆宣扬的产业毒药。CIO们用自己的理性推理出，让用户失望比成为《华尔街日报》的反面头条要好的多。
但是面向服务架构应用的崛起带来了集成战略的转移。SOA给出了激进的断言：企业应用软件架构是落后的。采用的技术要根据业务部门的特定服务而构建，而不是由企业级应用软件供应商软件包里装着的那些流程所决定。在这一背景下，组合打包提供的软件是只是SOA下服务的一个片断，只是一个较大业务流程上的另一个组成部分——拿保险索赔流程举例，这个流程把一大堆的功能和ERP、CRM以及旧的大型机遗留系统中的数据连接在一起。应用程序供应商不再关心其他事情；应用程序之间的关联是最重要的事情。
结果就是，供应商的集成战略变得比他们的软件特征更重要。（两家主流企业级软件供应商，Oracle和SAP，都已经开始提供集成中间件产品，和他们的软件套件一起提供给用户，尽管他们都坚持自己的大型、集成软件套件的观点和策略）。
在SOA的勇敢新世界里，大的软件供应商们已经决定要从微软主导的SOA剧本里书写自己一页篇幅，并且复制了Windows的策略。由于95％的PC上运行Windows操作系统，所以软件开发人士现在热衷于开发能和Windows协同工作的软件，这意味着他们能深入接触到最多的用户，并且挣到最多的钱。结果就是，今天围绕Windows的可用应用软件有上千种，这些软件保证了微软在明天的操作系统市场上的统治地位。类似地，通过打造围绕自己核心应用软件的生态系统，大的软件供应商正在努力保证自己赢得SOA领域的未来。
举个例子，最令人吃惊的战略变化来自SAP公司，长时间以来它一直是ERP领域的统治巨头。SAP在几年时间里都拒绝和其他软件供应商结盟，并且坚持打造自己的应用程序架构。但是在后SOA时代，SAP 正在忙于用服务来为自己的应用产品赋能，并且使用了新的中间件软件——NetWeaver，来引诱其他公司开发软件产品在NetWeaver的平台上运行（这个平台集成了一系列Web服务标准）。在线CRM软件供应商Salesforce.com开发了AppExchange，开发人员能够在这个平台上下载免费软件，把他们自己的软件附加件和Salesforce的核心软件集成在一起。同时，Oracle也一直在忙于通过并购打造自己的平台，它新近收购的对象包括了对其SOA产品非常关键的中间件软件厂商。
由于CIO们不愿意升级到企业级软件的新版本，于是大的软件供应商就在说了：“你们看，我们不能再用旧的价值主张向客户兜售了”，Gartner的Sholler说。“于是在他们未曾触及到的市场上，他们努力让自己的软件成为这些市场中其他解决方案的基础”。
但是这一战略把企业应用软件公司放到了一个和传统中间件供应商相冲突的位置上，这些中间件供应商包括了BEA、IBM和WebMethods等公司，他们自下而上，通过集成架构层，来到了SOA阵营。“人人都铆足了劲在同一个空间里纠缠争斗”，Scholler说。
尽管集成架构公司有更多SOA基本要素方面的经验，但是所有的供应商还是都在寻求和客户建立长期的关系。结果是，尽管他们的产品都嵌入了丰富的Web服务标准，这些统一的标准能缓解集成难题，但是每个厂商依然在某些方面保留了自己的特别之处。比如说Oracle的Fusion 应用软件套件只能和Oracle的数据库一起工作。而根据Gartner和Forrester两个研究机构的说法，SAP的新套件则需要NetWeaver 中间件。甚至，集成架构公司都各自都有很多特殊要素，使得推广自己的集成软件成为困难的事情。
CIO的底线是什么？当供应商信誓旦旦地向你保证为你打造你的SOA的时候，你要要当心了。除非像Whirlpool公司的Sezer那样，他不担心产生对供应商的依赖性，他就选择了SAP。“只要在用供应商的解决方案给公司提供价值，那么依赖他又有什么错？”他问。
但是根据2005年埃森哲的进行的CIO调查来看， CIO整体上还是担心这种依赖性的，特别是在现在的合并浪潮下。65％的CIO说供应商整合会向着提供一个更加集成的软件架构的方向发展；61％相信合并会降低供应商的管理负担；87％说会导致垄断和封闭；61％认为会降低价格竞争；57％认为会减轻供应商创新的压力。只有35％的人把供应商整合当作一件好事情来看待。
泛美人寿保险养老金产品和服务事业分部的Gleason是SOA的信奉者，对于这类CIO来说，由CIO控制的一个独立的SOA是对抗垄断和封闭的最好保护措施之一。“没有哪家供应商能提供满足所有客户需求的产品”，他说。“对于业务流程的某个部分来说，总会有合适的供应商比其他人做得更好。而且最先采用其产品的公司将取得竞争优势”。
《CIO》CHRISTOPHER KOCH Roland & Adela 编译
网友评论