面向服务的经济学

摘要

面向服务的目标是通过重用和标准化来实现 IT 服务交付过程中的结构性成本降低。然而，把传统系统转变成基于服务的系统需要将整个应用拆分成标准的服务，而且经常使用 Web 前端来推动服务在内部和外部的重用。记住一点很重要，然而，如何这么做，许多服务会被外包出去，进而导致更低的运营成本同时牺牲了员工利益。同时，向 SOA 业务模型的转变并非仅限于大型企业，它同样也适合中小型企业。

虚拟化和网格计算通过促进物理资源的重用和共享，从而使那些特殊资源（不论是计算机还是网络）的使用更为高效，使成本得到了降低。在这一节中，我们将探讨由面向服务导致的结构性经济变更。当前的大多数 IT 组织都处于使其预算可控的极大压力之下。他们的成本在不断增长，而预算却象图 1 中显示的那样日益平坦。服务概念和在服务级别的重用所带来的结构调整承诺长效地减轻这种成本折磨。

图 1：不可抗拒的遗留成本

从某种程度上讲，面向服务其实没有带来什么新的东西。但它却具有产生深远变革的潜力，这要归因于其中涉及的经济学。面向服务极大地降低了引入特定能力的成本。我们通过这 4 张图阐述了这种成本变化的某些方面。从概念上讲，有一部分 IT 预算是被用来维护现有项目的。这部分预算之所以重要，其原因在于，它是“使业务保持运转（keeps the business running，KTBR）”的一个组成部分。在大多数企业中，这个 KTBR 部分在预算中是不可获缺的。KTBR 的缺点是它只看到过去，而不是将来，因而它是用于拓展业务的残留部分。它的另一个问题是：不受控的 KTBR 部分的增长速度往往超过了整个 IT 预算，这种情形显然是不可持续的。

为了控制 KTBR 的增长，一系列策略已经在 IT 组织中被采用。让我们以图 2 中显示的外包为例进行说明。在引入外包（而且可能是海外的）之时，成本实际会因发生组织调整和洽谈合同而上升。一旦外包计划得以实施，成本可能会下降，但仍然有可持续性问题。另一个问题是，成本在提供外包服务的国家可能会大幅上升，几年后这些国家中发生的成本将会和以前的方式持平。

图 2：外包的效应

图 3：引进新技术的效应

第三种选择如图 3 所示：引进新技术，如 Intel® vPro™处理器技术，降低了处理业务的成本，可以看作成本挤压。成本可以通过积极实行技术应用得到管理，但这并不会改变其整体的上升趋势，而且没有太多企业愿意或有能力支撑这种技术革新计划。

最后，图 4 说明了面向服务是如何最终导致了一种结构性且可持续的成本降低，这都要归因于重用的协同效应。和外包一样，一开始成本也是向上增加的，这是因为需要进行先期投资。注意，这种转变可能需要花好几年才能完成，而且要求艰难的企业文化和组织结构的调整。

图 4：通过采用面向服务获得结构性成本降低

面向服务带来了模块化这一早已在软件工程社区广为人知超过 30 年的戒律，尽管如此，其却极少应用公司内的项目中。前文已经说过，面向服务的目标是通过重用和标准化来实现 IT 服务交付过程中的结构性成本降低。和考虑互操作性和安全性一样，架构和规划同样需要更多的先期投入。但是，正如我们今天在软件工程中所看到的，随着越来越多具有同样作用的服务被开发出来得到重用，模块化和互操作性的好处将会显现。

总而言之，要想在合理可测的成本之下实现 IT 和业务的对齐是项具有挑战性的问题。最佳解决方案可以通过包含着业务流程改进（以面向服务的形式）、技术以及恰当业务规划的综合战略来实现。

面向服务架构的可扩展性

我们将在本节探讨可扩展性这一主题和 SOA 的采用模式。本节的讨论具有前瞻性，内容是关于尚未发生或发生中的事件和流程，因而其内容应该更多地应被视为一种思维激发练习，而不应该被视为对事实的陈述。

行业内 SOA 应用的普及有望极大降低 IT 项目规划、部署和运营的成本。那些从千年之交发生的网络公司集体崩溃死亡线上逃离，业务与 IT 对齐压力持续加大的 IT 组织对于这种趋势部分地起到了推波助澜的作用，他们唯恐自己成为下次预算消减下的牺牲品。这段时间内增加的法规合规特性为探索减轻法规压力的方法带来了更多激励。

把遗留应用转变成 SOA 可以通过一种创新的分解处理来实现，籍此，这些应用被分解成服务，他们具有基于 Web 服务的标准接口。然后，这些服务得到重用以支持其他应用。反过来说，也可以通过组装这些服务的标准接口来构建新应用。

由于 SOA 承诺通过重用来极大降低 IT 项目的规划、部署和运营成本，企业计算环境中 SOA 的采用呈增长趋势。然而，把传统企业应用转变成 SOA 应用的组织多数是大型企业。小型企业很少没有出现在这种 SOA 转变过程中。我们将看到，SOA 方法同样适合中小型企业（SMB）。

我们描述了一种新的 SOA 采用和服务交付模式，其内涵超越了在大型企业转变过程中所熟知的 SOA 的角色。

让面向业务的服务由公司防火墙外的独立服务提供商开发和交付，小型企业就可以挑选他们觉得有价值的服务。他们可以把这些服务“混搭（MashUp）”成最能满足他们业务需要的服务，其中遵循的 SOA 服务集成概念和大型企业采用的完全一样。因此，对小型企业而言，SOA 不再是一个抽象概念，也不再是一个大型企业才能玩得起的游戏。这就是由外向内（outside-in）的 SOA 采用模式，和传统的人们熟知的发生在大型企业中由内向外（inside-out）模式完全相反。

总的说来，在传统的由内向外方法下，服务是通过组合企业内部更简单的服务得到的，而由外向内的方法则假定小型组织能够从生态系统中可以找到服务和服务集成商提供的服务来构建服务。服务集成商可以依次选择其他厂商的服务组件来构建他们要提供的服务。由此下去，完全有可能发展成一个丰富多彩的生态系统。

中小型企业的影响不容忽视，因为其潜在数量相当的大：根据美国小企业管理局的统计，在美国，小企业代表了 99.7% 的公司雇主，其雇员占私营企业员工总数的半数以上（ http://www.sba.gov/advo/stats/sbfaq.txt ）。

面向业务的这种由外向内的视角可以成为普及 SOA 采用和转变小型企业使用计算机技术的路标。

我们同时也意识到，这种由外向内的 SOA 模型需要花些时间才能成熟。一些重大技术障碍需要业界厂商的实质努力才能克服。与改变小企业经营过程中的业务交易所涉及的业务流程和人们的行为相比，这些技术挑战算不上什么。

但是，正如我们在消费者市场中互联网和 Web 2.0 的采用情况中所看到的，只要我们能够交付具有吸引力的收益并降低进入门槛，这种采用情景就能而且一定会发生。

了解这种变化将帮助参与者、服务消费者和供应商们发现其中的增值机会。

最初的筒仓状态

根据前面已经描述的常见进化模式，公司应用已被部署成图 5 中显示出来的烟囱结构，一台服务器一个应用，或服务器层驻留了一个完整的解决方案堆栈。具有讽刺意味的是，这种趋势正是由 15 年前出现的基于 Intel 的低成本服务器所推动的，它鼓励以物理服务器为部署单元。

在得到这些系统物理服务器之前，大约要花 2 周到半年的时间不等。一旦这些服务器到达，它们就会被装上操作系统、数据库软件、中间件和应用。为了支持一个业务的运行，实际需要多种这样的管道。某些 IT 组织在升级到 SAP 的企业资源计划（ERP）应用时是以大约 15 个烟囱为阶段进行的。

迈向 SOA 转变的第一步就是把部分筒仓打碎，转化成更小的逻辑组件，并增加 Web 服务前端以使这些组件可为当前和未来的应用所用。在这一阶段，需要识别冗余组件，并使之退役。

因而，在 SOA 中，整体应用被分解成标准化的服务。安装 Web 服务前端代表了一种额外的开发成本，其回报并不能立即产生。在打着 SOA 旗号所进行的破旧立新活动之下，实施团队在一开始就可能会发现这种为了支持将来重用而需进行的额外工作。要想确保这项附加工作能够给组织带来更大好处，还需解决企业文化和行为方面的问题，即便它与项目的当前目标并不一致。这需要大量的传播和培训活动，而且即使如此，文化的转变也是缓慢且费劲的。

最后会达到一个平衡点，在该位置，某项目的这种额外实施成本通过重用过去项目的整体储备而得以结余。最终目标是得到一个正投资收益表。这还不是停止宣传的时候，因为储备可能还没有在各个组织中显现，而只是对那些可以观察多个项目的组织可见。

图 5：传统的应用烟囱

传统的由内向外的 SOA

图 6 显示了大型组织的 SOA 转变。堆栈层已经被服务组件替换掉了，由于有这么多的重用存在，使得这些堆栈几乎全部消失。

企业架构师可能发现某些功能是通用的，可以通过第三方厂商提供的产品替换掉。但是要注意，“通用性”的考虑取决于技术和生态系统的现状。对某些组织而言，它可能是指 HR 应用；而另一些可能是邮箱服务或者甚至是一整套 ERP 的实现。

即使从技术角度看转变的执行毫无破绽，然而它还是有可能带来破坏和痛苦：原来的内部服务组合变成越来越小的内核。如果内部服务被外包服务以低成本替换掉，整体成本就能降下来。这个小小的内核完全可能导致裁员和技能的重新调整。内部应用开发更少，并且需要具有业务和技术技能的人来管理与服务提供商的关系。

这种 SOA 转变过程可能由局部开始，其中那些非任务关键型服务是首要的替换对象，而 IT 内部开发团队则关注核心、复杂、任务关键型服务。

这些核心服务可能代表了企业核心的知识产权（IP）。某些公司可能在这一领域没有什么太多的限制，最后这个核心变得太小了，与外包服务相比显得无足轻重。达到这种状态就完成了由内向外的转变。

图 6：大型组织中的 SOA

由外向内的 SOA：中小型企业的 SOA

在前一节中，我们目睹了大公司中发生的从由内向外到由外向内的转变。在这一节中，我们可以看到相同的进化过程可以很自然的扩展至中小型企业（SMB）身上。其区别在于，该过程是发生在整个生态系统而非某个单独的大公司身上。

就其本身性质而言，SMB 通常不会有奢侈的大规模 IT 预算或大的 IT 部门。大部分这种公司只有一些懂 IT 的雇员兼职充当 IT 支持。他们也没钱购买那种“只面向内部”的 SOA 实施模型。因此，SMB 并没有迫切的要求去建立针对于由内向外过程的内部服务组合。

但是，如果我们假设大型企业成了 SOA 的第一批使用者，并且在这一过程中服务市场已经创建起来，那么 SMB 就可以完全跳过由内向外的过程。SMB 可以从外部购买服务。事实上，一旦生态系统成熟，由内向外的过程就会变得过时，因为今天它完全是从头开始构建内部应用。

在一个成熟的 SOA 环境，SOA 组合应用（Compound application）将主要使用外包服务构建。图 7 说明了这个概念。一个定义良好的业务流程（如采购订单的创建和处理或是一次银行的交易）代表了一组 SOA 服务，它们由不同的用户实例化并被集成到一个用户解决方案中以支持业务需要，而它们本身又是由业务驱动的。本质上，SMB 拥有者为自己企业挑选合适服务的过程非常类似当今 Web 2.0 世界的混搭。

图 7：对 SMB 环境而言，其企业核心已经小到不可再分的程度了。

这种采用 SOA 的方法可能会导致令人惊异的结果：根据大型组织中为创建 SOA 而制订战略的经验来看，在 SOA 市场的某个成熟阶段，采用 SOA 的前提条件将不再是大型组织。SOA 同样也能在小型组织环境中遍地开花。这一结论同样也与 Web 服务的开放性和标准化概念一致。这些过程具有架构合理性和技术可行性，即便有大量的技术和社会行为障碍要克服。

SOA 在中小型企业中的采用过程是一种完全不同的形式：重用并没有发生在大型企业的内部或组织之间——在考虑临界物质（critical mass）的必要条件时，我们将看到相同的临界物质——而是发生在整个经济学生态系统中。

换句话说，我们所建议的模型取决于多个生态系统厂商，他们提供的组合应用被用来构建更复杂的 SOA 风格的组合应用。在这样的环境下，我们可以预计某种程度的规范化，其中各服务由拥有合适专家的更小厂商提供。这种情况在图 8 中得到了反映。为了将这种方法和传统的“只面向内部”或“由内向外”的特定于大型企业的 SOA 方法区分开来，我们将其称为“由外向内”的 SOA。这种由外向内的方法并不仅限于中小型企业，它同样也可以发生在前一节所讲的大型企业中。

图 8：最终的状态是一个丰富多彩、技术和业务需求完美结合在一起的经济学生态系统

谁会有兴趣让这种由外向内的 SOA 转变成为现实？在经济学生态系统中的一条真理就是，某些参与者的成本方式被转换成另一参与者相同的收入报酬。当收获的价值远大于购买者所花成本，且卖家意识到由于这个价值还需要其他产品和服务时，整个生态系统的好处就会显现。

服务消费者一定会获利，因为通过利用组合服务的组合应用降低了整体购买应用功能的成本。软件工具提供商将通过提供针对于由外向内的 SOA 环境的产品获利，技术构建单元的提供商也可以利用相同方法盈利。这些构建单元必须具有支持自动供给和虚拟化设施概念的 SOI 能力。

服务提供者之间的关系将以相当复杂的方式发展。服务提供商将成为服务的提供者和消费者。甚至像 Amazon.com 这样的非传统服务提供者也开始开发剩余能力。这些公司将开始销售这些服务，创造新的收入来源。事实上，Amazon.com 并非一个好例子，因为它不是一家小公司。这个模型所适用的规模也可以是拥有 10–100 雇员的增值二手商（VAR）公司。

要使这套模式发挥作用，那些正规的服务组件，即那些从底层设计出来的服务，并不是必需的。可以通过给中间件进行填充使其行为与可组合服务一样来翻新图 5 中的传统烟囱应用，其方式类似于用那些屏幕抓取程序来延续遗留大型机应用的生命和用途一样。由外向内模型的障碍要比乍一看时要低，因为行业并不需要一直等待某个可重用服务的大型组合可用。

随着技术的成熟，以及更多参与者进入市场，我们可以预期会出现大量的服务作坊，绝大多数可以想象出来的应用都可以使用它们提供的服务来完成。这个市场随着地理区域的不同呈现高度的多样化，主要是受当地需求和法规的影响。在这种环境中，在构建特殊的功能时，通过在市场中把组成组件立约外包出去，其成本要比完全自己实现相同功能要便宜得多。

汽车或飞机行业的这种模式，具有巨大的供应网络，也将应用到软件应用。

这种由外向内的方法不同于传统的外包协议：洽谈把薪水计算功能外包出去可能得花上几个月，且还要面对面地坐在桌子旁边。相反，由外向内的交易将是高度自动化和动态的，使用开放标准以及自动化的注册中心和发现服务即可。象这样的一种交易可能花费不到一秒，至多花费几秒。

关于面向服务的经济学的更多信息，请参见 Enrique Castro-leon、Jackson He、Mark Chang 和 Parviz 所著的《虚拟面向服务网格的商业价值（The Business Value of Virtual Service-Oriented Grids）》。

作者简介

Enrique Castro-Leon

他曾担任过策划、解决方案架构师和项目经理，他还曾在涉及公司最终用户的验证概念的前沿项目中承担技术实施工作，同时他也负责在 Intel 内部阐述新兴技术的使用。他已经发表了 40 余篇文章、会议论文和白皮书，内容涉及技术战略和管理，也包括 SOA 和 Web 服务。他在普渡大学的电子工程和计算机系取得了博士和学士学位。

****Jackson He是 Intel Digital Enterprise Group 的首席架构师，负责可管理性使用和企业解决方案。他拥有夏威夷大学的博士和 MBA 学位。Jackson 接触 IT 已经超过 20 年，从事过多种学科，从教学到编程、工程管理、数据中心运营、架构设计和行业标准定义。Jackson 是在 OASIS、RosettaNet 和 Distributed Management Task Force 的 Intel 代表。他还曾于 2002–2004 年在 OASIS 技术顾问委员会服务。近些年来，Jackson 已经集中研究企业基础设施的可管理性和动态 IT 环境中的平台能量效率。他的研究涉及虚拟化、Web 服务和分布式计算的广泛主题。Jackson 已经在 Intel 技术期刊和 IEEE 会议上发表了 20 多篇论文。

****Mark Chang是 Intel Technology Sales group 的首席战略家，负责面向服务企业和高级客户端系统业务和全球技术战略。Mark 具有 20 多年的行业经验，包括软件产品开发、数据中心现代化和虚拟化、统一消息传递服务部署和无线服务管理。他参加了数个行业标准组织，定义了 CIM 虚拟化模型中的标准和相关 Web 服务协议。此外，Mark 和系统集成及 IT 外包社区有很强的关系。他在 Austin 的 Texas 大学获得学士学位。

Parviz Peiravi 是一名首席架构师，在 Intel 公司负责全球企业解决方案和设计；他到公司已经超过 11 年了。他主要负责面向服务的设计和开发驱动。

查看英文原文： The Economics of Service Orientation 。

感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

This article is based on material found in book The Business Value of Virtual Service-Oriented Grids by Enrique Castro-leon, Jackson He, Mark Chang and Parviz Peiravi. Visit the Intel Press web site to learn more about this book: www.intel.com/intelpress/sum_grid.htm.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for permission should be addressed to the Publisher, Intel Press, Intel Corporation, 2111 NE 25 Avenue, JF3-330, Hillsboro, OR 97124-5961. E-mail: intelpress@intel.com .