这篇文章要给大肆宣传SOA和为SOA问题提供答案的人泼盆冷水了，本文谈到的很多问题都涉及为何、如何以及何时应该（或不应该）开始考虑实施SOA。
在开始讨论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％的受访者说他们正在计划，或者制定好了培训计划，以替代现有员工队伍，跟得上发展速度。
网友评论