摘要：在谈及客户端（桌面、浏览器和设备）和基于服务器使用一种或多种Internet（cloud）服务的应用程序时，本期杂志中的许多文章都使用术语“软件+服务”（Software + Services，S+S）。虽然这种模型具备“软件即服务”（Software as a Service，SaaS）的某些特征，但对于企业IT来说它们之间还是存在明显的差别。

本文比较了采用S+S与采用SaaS面临的各种挑战；很显然，对于企业来说，使用定义明确的外部服务比使用全套服务（finished service）所面临的挑战更少。

当今，通过Internet交付的应用程序（即SaaS）大多数都针对消费者和小型企业市场。使用业务货币化模型（无论是捐赠还是广告投资）在很大程度上都表现出长尾经济的特征；通过可伸缩的分发渠道将很少的东西出售给许多客户，Chris Anderson对此已有描述（请参阅参考资料）。

但是，企业的需求与消费者和小企业部门的需求完全不同，因此，可以假设支持长尾经济和服务交付（和消费）不适用于企业环境。例如，消费者不必担心遵从性和企业应用程序集成(EAI)，这些也基本上不牵扯到小型企业。

因此，从企业角度看，软件服务会带来很多问题。谁拥有数据？什么是服务等级协议（Service Level Agreement，SLA）？内部身份标识可以扩展到防火墙外部以访问cloud服务吗？存在法规限制吗？

背景

IT预算中约有70%用于维持现有系统，其余约30%才投入于新的解决方案。虽然硬件和软件成本逐渐低于管理成本，但支持成本正在不断增长。相比以前，企业现在期望从IT获得更多回报，这部分由于网络公司（dot.com）倒闭后企业信心的恢复，以及对防火墙内部Web 2.0形式的功能不断增长的需求。

与此同时，企业IT却正在遭受认知危机，人们对Nicholas Carr 2003年的文章《IT Doesn't Matter》的反应便是明证。（请参阅参考资料）。内部IT项目耗时数月且投资巨大，而获得的好处却能够从Internet轻松获取，企业领导者常常因此感到气馁。用户在Internet上体验到的搜索、协作和发布功能，远胜于许多企业的内部功能。越来越多的应用程序正作为服务项目可以从Internet上获取，给企业提供了一个可供选择的IT源模型。

在本文中，我将讨论在现有企业IT基础结构和各项操作上使用外部软件服务的影响，并比较在使用整个公司广泛采用的任何业务线应用程序时，SaaS模型与S+S模型所面临的各种挑战。我使用术语“软件服务”（software services）表示SaaS和S+S模型中的服务，因为我们可以将软件交付视为一个统一体，无论它是创建的还是购买的，或者从另一方面极端地说，是通过Internet交付的全套服务（即SaaS）。内部软件加cloud服务的混合形式（即S+S），位于这个统一体的中间。图1说明了这个软件交付统一体。在本文中，

• 传统软件（Traditional software）是指安装在基础结构中专门供内部用户使用的应用程序。
• 构建块服务(Building Block Services)提供开发人员在构建复合应用程序时可以使用的低级功能。这些服务存在于cloud中。
• 附加服务（Attached services）与构建块服务相比，提供了更高级的功能。应用程序利用附加服务来添加功能。
• 全套服务（Finished services）类似于完全成熟的应用程序，是使用SaaS模型通过Internet交付的。
• S+S是指使用附加服务的应用程序或通过构建块服务构建的应用程序。

图1：软件交付统一体和软件服务分类

在考虑IT基础结构或应用程序源模型时，了解业务对象非常重要。例如，对成本效益的需求驱动了外包业务，通过合同支付形式将现有成熟应用程序的交付成本和风险转嫁给另一方。相反，软件服务的采用满足了业务需求，如更有效的客户管理（就CRM来说）。从业务经理的角度来说，SaaS似乎是一种两全其美的模型：以合理的成本（甚至免费）获取业务收益，在IT资源方面不需要额外投资或预先投资。虽然企业是确定服务是否能很好地解决业务问题的最佳场所，但除非将IT纳入讨论范围，否则企业IT的许多更广泛问题（软件服务应用涉及的隐性成本）都将被忽视。

软件服务：新的集成挑战

在采用软件服务时，服务交付和服务支持这一组挑战成为服务供应商的职责。但是，在采用新模型时，IT将面临额外的一组新挑战（图2）。

图2：软件服务消费增加新的挑战

这些新挑战是不可避免的，不能对其熟视无睹。我们将会看到，这可能成为直接或间接成本、资源问题以及遵从性问题。换句话说，软件服务的采用是内部IT的一种混合采购/集成项目。集成 图2：需要从以下三个广泛领域考虑软件服务消费带来的新挑战：

• 身份和访问管理
• 数据
• 操作

规范和法律责任也应该予以考虑。

身份和访问管理

身份和访问管理是影响IT各个方面的长期问题，包括帮助台成本、用户生产力、数据安全等。这也是企业IT应该比Internet提供更佳用户体验的领域，目前大多数企业仍有很多用户目录。分析机构经常提到，平均有30%的帮助台呼叫都是询问重置账户密码的问题。

全套服务与相应外部目录的增加需要扩展供应和取回过程，即使这是一个人工过程。例如，当某个员工辞去工作时，许多组织尽力及时取回或禁用内部账号；外部应用程序或服务的暴露风险事关重大，因为企业防火墙无法阻止用户访问应用程序及其数据。

Active Directory (AD)和元目录产品（如Microsoft Identity Lifecycle Manager）都不能解决这个问题。AD是专有的，其信任模型没有足够细粒度，元目录部署应用不广泛并且不能实时操作。基于标准的一些东西，如联合服务器提供的一组功能，特别适合与外部应用程序或服务集成。这是松散连接的，可以实时操作而不是按照进度表进行，从而简化了供应和取回过程。联合信任关系是细粒度化的，允许消费组织只公开其子集目录（基于规则），以及属性到“要求”的实时映射，减少了对内部目录更改的需求。（参见图3；有关联合服务器和ADFS的详细信息，请参阅参考资料。）

与SaaS相比，S+S应用程序可以使后端服务在防火墙内部运行，这样单个企业或代理的身份就能够传递到cloud中的服务。身份集成是许多企业应用程序的一种共同功能，因此后端服务可以与Active Directory或开箱即用的普通LDAP目录集成。

图3：联合服务器提供身份标识集成

访问控制

授权和访问管理是需要考虑的另一个方面。许多应用程序针对不同用户提供不同的功能。例如，开支应用程序允许管理员授权的金额达4,000美元，4,000美元以上的金额则需经主管批准。当今，企业防火墙内部的许多应用程序都针对每个用户设置了许可权，实际上，应用程序包含用户及其授权之间的映射关系。然而，许多组织已开始从基于用户的授权转向基于角色的授权。这样做的优势很明显：更低的管理成本，一致的基于角色授权，透明的遵从性。

如果一个全套服务具有多级授权，则有两种选项：手动将用户映射到授权级别以向组织中的人员分派任务；将内部基于角色的模型扩展到外部应用程序。前者常求助于帮助台，这是采用全套服务的隐性成本。后者将内部角色映射到外部应用程序，可以通过联合服务器完成；例如，Active Directory组的成员可以映射到外部应用程序使用的cookie中的名称/值对。

构建块或附加服务（混合软件+服务）中的授权可以采用联合服务器模型，并且这么做确实能带来好处：完整性由服务供应商负责严格管理，这有助于实现遵从性。更灵活的S+S模型意味着在对外部服务发出请求之前可以由本地服务器进行授权。进行本地控制和策略强制意味着组织可以更快地应对业务变化。它还简化了集成；企业可以对供应商应用程序on-premise部分的配置进行更改，以适应其环境。

对身份和访问管理的影响总结

• 如果外部服务依赖于用户身份（对于SaaS非常可能，对于S+S是可能的），则需要扩展供应和取回过程。集成可以通过技术或手动过程完成，这两者都会影响成本。
• 服务供应商用户账户策略需要根据您的内部策略进行评估（例如，密码复杂度、锁定等）。

数据

业务线应用程序不一定以岛屿形式存在，即使其来源于外部。Payroll软件能很好地证明这一点。Payroll服务供应商需要Raw数据（如员工名称、工资总额等）来处理月工资单。在此示例中，从内部HR系统简单提取相关信息就可以提供数据。显然，通过电子邮件将XLS或CSV文件邮寄到payroll供应商不可能提供所需的安全/机密等级，因此需要另一种形式的数据交换，人们期盼IT能够满足这一要求。换句话说，IT面对企业应用程序集成(EAI)项目。

从EAI角度来说，构建块和附加服务应该易于集成；毕竟，作为本地应用程序的扩展，它们是专门为开发人员使用而设计的。附加服务的一个示例是Exchange托管筛选服务（Exchange Hosted Services for Filtering）（有关Exchange托管服务的更多消息，请参阅参考资料）。这种情况下的集成分为两部分：

1. DNS：MX记录更改为指向服务供应商（本例中是Microsoft）

2. 防火墙规则更改为仅允许来自服务供应商的入站SMTP（这可提高安全性）。

本文中的关注点是基础结构，我不会就EAI进行深入探讨。但是，我们将从其他一些角度来讨论数据的基础结构问题：

• 防火墙规则和筛选器
• 加密和签名
• 用户视图

防火墙

要了解使用全套服务的防火墙问题，我们需要调查哪些内部应用程序将与软件服务集成以及集成的形式。需要集成的内部应用程序是一个还是几个？需要创建什么样的防火墙规则以允许发布和信息流?如果应用程序正在交换XML，那么这需要在防火墙处验证吗，放火墙可以提供这种功能吗？数据需要与某种形式的工作流集成吗，如果需要，该工作流如何跨越内部/外部基础结构？如果通过HTTP（例如，SOAP）进行集成，除创建规则之外，防火墙可能不会有什么问题。

构建块和附加服务可能成为某种本地后端基础结构，这自然成为数据集成和安全的关注点。某些SaaS供应商已认识到，在其数据存储在企业防火墙内时企业更愿意订阅，因此，他们正在客户数据中心内部安装设备，将其全套服务发展为S+S模型。

加密和签名

通过Internet交换加密数据最有效的方法是采用公共证书机构的证书。如果证书安装在客户端上，则需要实施公共密钥基础结构（PKI）计划，解决其所有问题，如证书生命周期管理和发布证书撤销列表。这不是一个无足轻重的事情，一旦完成，它将在基础结构中启用其他功能，例如电子邮件签名和智能卡身份验证。

当然，在S+S实现、加密和签名中使用本地后端基础结构可能更为简单（更少的端点）。

用户视图

数据的另一个角度是用户视图。不管这样做是否恰当，但许多企业用户都希望继续使用他们熟悉的工具—Microsoft Office应用程序。新应用程序常常无法发挥其全部潜在功能，因为企业用户坚持提取数据和使用Excel进行日常管理。此数据很少会回到应用程序。许多独立软件供应商都宣布要将其应用程序客户端构建为Office商业应用程序(Office Business Application)，实质上是使用Office作为应用程序平台。这通常会导致采用速度更快、培训开销更低，但却给IT带来了部署和维护问题。要考虑的要点：软件服务提供企业所需的所有功能吗，还是需要使用本地工具/系统抽取数据来执行操作/分析？软件服务的采用会导致更多部门应用程序在Excel和Access中构建吗？

对数据的影响总结

• 为了确定数据集成和ETL需求，需要进行分析。
• 为了允许集成，可能需要防火墙规则。
• 为了提供应用程序数据筛选功能（例如，XML Schema验证），防火墙可能需要更新。
• 为了支持身份验证、加密和签名要求，可能需要购买证书或实现PKI。

操作

从外部获取应用程序或服务时，操作集成问题有点不协调：毕竟，作为消费者的主要好处在于，操作是供应商的职责，但内部操作和过程在几个方面会受到外部应用程序或服务影响，最重要方面是帮助台和用户培训。

帮助台

许多消费者被效率低下和混乱的呼叫中心弄得沮丧不已。为了避免类似问题，内部帮助台团队应该了解集成到IT操作的新应用程序和服务。企业用户依赖许多内部IT系统访问外部应用程序：网络、DNS、代理服务器。支持这些服务是企业帮助台而不是服务供应商的职责。许多组织现在认识到简化业务支持过程的重要性，例如，只需一个电话号码和内部网站点，就可以将他们连接到适当的一线团队。

培训

用户培训是引入任何新应用程序的重要方面，无论其安装在哪里。全套服务的一个优势是供应商通常提供按需培训。但是，企业对此类培训的控制力较弱，质量低劣的培训会提高支持成本并降低企业生产力。作为服务的一部分引入升级（订阅全套服务的好处之一）是另一个潜在问题：如果企业在所有员工都得到培训之前没有能力延迟升级的实现，则内部帮助台可能必须面对激增的电话求助。相关问题是全套服务的单个功能是否可以有选择地禁用：如果内部已经提供了该功能，IT需要确保用户都在使用该内部功能。

“应用程序对企业的重要性越大，您需要考虑的相关事项就越多。作为全套服务交付的业务线应用程序是一项重要的集成活动。”

部署

如果全套服务使用浏览器作为其客户端，则正常的兼容性涉及：浏览器版本和安全性设置，以及安装的插件及其版本。对于传统应用程序，企业可以决定何时更新到新版本，如果新版本要求最新的浏览器，那么这一点至关重要。如果该应用程序是外部的，则企业可能无法提供这种选择。

如果服务的客户端不是基于浏览器的，内部IT将负责部署工作及相关事项(兼容性测试、部署规划、新品展示等）。

如果服务是附加或构建块服务，将需要在企业数据中心中部署后端基础结构和/或客户端。对于后端服务，一般的非功能性挑战有：需要什么样的服务器、网络和存储容量才能满足负载？可以使用共享服务（如现有的SQL服务器或web服务器场）吗？如何提供弹性和灾难恢复能力？可以在多个数据中心运行吗？答案取决于应用程序的本地组件而非cloud中的附加服务：换句话说，在很大程度上它可以像正常的后端部署一样进行处理。

供应商运营/业务连续性

在选择、监控和评估服务供应商时，我们应将注意力完全集中在SLA的内容上。重点考虑如何实现SLA：SLA规定在灾难发生后的24小时内恢复服务，表面上看起来很不错；但是，灾难定义和恢复形态是至关重要的。对于服务消费者来说，灾难可能是应用程序记录的意外删除，但服务供应商可能对此有不同看法。再举例来说，对于许多业务应用程序，恢复应用程序数据是一个复杂的过程。例如，在这些应用程序得到完善之前，恢复Exchange邮箱或消息、SharePoint站点或文档是一项重大挑战。现在，这种挑战出现在多租户（multitenant）的SaaS应用程序中，即使可以进行细粒度恢复，但考虑到操作成本，供应商业不会愿这么做。

一些架构师告诉我，他们关注的另一件事情是服务供应商完成业务后的风险，即如何保护数据以防止泄漏到竞争者手中。将应用程序代码根据协议交由第三者保存起来是一个正确的处理方式，但这还不够。就算企业消费者可以获得数据，但不安装说明文件或求助开发人员也很难在其数据中心重新构建应用程序。这方面的风险还没有一个完美的解决方案，这是一个信任问题，如果出现最坏情况，供应商会正确加以应对，相信他们具有良好的业务和管理技能。

报告

与任何SLA一样，企业和IT团队应该评审报告执行情况，并调查在哪些方面SLA还没有被满足。

对操作的影响总结

• 需要对帮助台程序进行更新，以排除新应用程序的一线故障，升级过程由服务供应商定义。
• 当依赖服务供应商获取升级支持时，复查内部帮助台SLA以确保其依然可以得到满足。

规范和法律责任

验证对规范和法律责任的遵从性将对基础结构产生影响，确保整个内部系统和外部服务业务过程的遵从性尤其具有挑战性。有关遵从性的潜在解决方案：如果应用程序或服务是向业界看齐的，那么主要市场很可能遵从相关规范；一般性服务可能不会如此。即使遵从性成为服务的一个卖点，企业的内部安全策略或区域性法律（如欧洲议会数据保护法）也可能与服务供应商策略相抵触。

数据所有权

企业无疑希望在任何时候都保留对其数据的所有权；合同中应该明确声明这一点。此外，可以谨慎地检验数据能够按需提取。

隐私

企业应该谨慎地评估供应商的隐私策略和使用术语，以确保其数据的专用性，不得用于市场营销或销售给其他方，在全套服务接受广告支持的场所尤其重要。隐私认证计划在确认供应商的可信赖性方面能够提供很好帮助；具有TRUSTe许可证的供应商具有公开的策略并经受独立审核，可确保遵从隐私保护准则。

对法律方面的影响总结

• 遵从性可能扩展到服务供应商，您如何来证明遵从性呢？
• 出具遵从性报告可能有一定成本。

表1：建议摘要

结束语

针对消费者和小型企业的产品占据着当前的SaaS市场，因为该细分市场不需要集成的交付模型。使用来自这些供应商的业务线应用程序对于任何企业都存在风险，因为本文中讨论的集成点有许多无法解决。

应用程序对企业的重要性越大，您需要考虑的相关事项就越多。战术性应用程序的首要关注点是合同问题，如数据所有权，与此相比，作为全套服务交付的业务线应用程序需要大量的集成活动。图4的热图（heat map）中表示了这种关系。

图4：考虑事项热图

今，企业IT部门对于消费构建块或附加服务的体验和自信远远胜过完整的应用程序。将它视为富应用程序（如Reuters 3000）或基础结构服务（如垃圾邮件过滤）的数据供给，就能很好地理解该模型。

由于SaaS交付模型已经成熟并且得到了更广泛采用，因此能迎合更多的企业要求（如集成）是很自然的事情，企业为“源即服务”准备的功能范围将扩大。最终将是软件+服务应用程序；on-premise软件和cloud服务的自然平衡。

正如Gianpaolo Carraro和Fred Chong在其文章《SaaS:An Enterprise Perspective》中所述，SaaS和S+S是聪明的CIO可以用来为企业提供更多价值的传统工具。IT经理应该了解SaaS和S+S的用途，而不是感到惶恐：这是带来业务收益的替代性源模型，构建解决方案的另一种架构方法。

经过正确运用，软件服务将帮助改变企业对IT的认知。

参考资料

• European Parliament Data Protection Laws
  http://ec.europa.eu/justice_home/fsj/privacy/index_en.htm
• Exchange Hosted Services
  http://www.microsoft.com/exchange/services/default.mspx
• “IT Doesn’t Matter,” Nicholas G. Carr, Harvard Business Review，2003年5月 http://harvardbusinessonline.hbsp.harvard.edu/b01/en/common/item_detail.jhtml?id=R0305B
• The Long Tail:Why the Future of Business Is Selling Less of More, Chris Anderson (Hyperion, 2006)
• 软件产品和开发Microsoft专用指南
  http://www.microsoft.com/downloads/details.aspx?FamilyID=c48cf80f-6e87-48f5-83ec-a18d1ad2fc1f&displaylang=en
• Microsoft法规遵从性规划指南（虽然本指南关注的是内部IT，但评估外部供应商时也很有用） http://www.microsoft.com/technet/security/guidance/complianceandpolicies/compliance/rcguide/default.mspx?mfr=true
• WS-Federation是已被一些供应商采纳的一项草案OASIS标准，这些供应商包括Microsoft、IBM、RSA、BEA和VeriSign。Microsoft的WS-Federation支持采用了Active Directory Federation Services (ADFS)形式，这是Windows Server 2003 R2的一个组件。
• OASIS
  http://www.oasis-open.org/committees/documents.php?wg_abbrev=wsfed
• Active Directory Federation Services (ADFS)
  http://www.microsoft.com/WindowsServer2003/R2/Identity_Management/ADFSwhitepaper.mspx