简介
“软件即服务”(SaaS) 有可能改变信息技术 (IT) 部门与企业其他部门之间的关系，甚至可以认为 IT 部门的角色是企业其他部门的计算服务提供商。 SaaS 作为一种有效的软件交付机制，其出现为 IT 部门创造了机会，使他们可以将工作重心从部署和支持应用程序转移到管理这些应用程序所提供的服务上来。 反过来，一个成功的以服务为中心的 IT 部门通过提供从内部和外部资源中获得的服务，并将其与企业目标保持一致，就可以直接为企业创造出更大的价值。
（本文章还包含指向英文网页的链接）
这是关于 SaaS 系列文章中的第三篇文章。 前两篇文章侧重于详细介绍如何开发 SaaS 应用程序以及如何将其提供给客户，请单击此处查看。 这次，我们将这个问题换个形式，从企业使用者的角度介绍 SaaS： IT 部门如何从 SaaS 应用程序加入服务资产组合中受益？ 外部托管应用程序加入企业计算环境的意义何在？ 针对 SaaS 需要进行哪些准备工作？ 本文将解答上述所有问题，并一起分析几个特殊案例，可能对您所在的部门成为 SaaS 提供商和使用者有所帮助。
了解 SaaS
简而言之，SaaS 可以定义为“将软件部署为托管服务并通过 Internet 进行访问”。
SaaS 概念通常与二十世纪九十年代的应用程序服务提供商 (ASP) 有关，ASP 通过 Internet 为企业用户提供“压缩-包装”应用程序。 在授权和体系结构等方面，这些早期所尝试的通过 Internet 交付的软件与传统的内部部署的应用程序有许多共同之处，而与现代的 SaaS 应用程序的共同之处相对较少。 因为这些应用程序最初是作为单租户应用程序构建的，与其他应用程序共享数据和进程的能力比较有限，所以与本地安装的应用程序相比，它们的经济效益较低。
现今，预计 SaaS 应用程序可以通过单实例、多租户体系结构，利用集中化优势并提供功能丰富的体验，能够与类似的内部部署的应用程序相媲美。 典型的 SaaS 应用程序既可以直接由供应商提供，也可以由称为聚合器的中间方提供。中间方将来自不同供应商的 SaaS 产品绑定在一起，作为统一应用程序平台的一部分提供。
与常用于内部部署软件的一次性许可模型相比，通常使用订阅模型出售 SaaS 应用程序访问权限，客户需要持续付费以使用该应用程序。 费率结构随应用程序变化；一些提供商收取固定费率，允许无限制地访问应用程序的一些功能或全部功能；另一些提供商收取可变费率，视使用情况而定。
在技术方面，SaaS 提供商集中托管应用程序和数据，将修补程序和升级程序透明地部署到应用程序，然后使用浏览器或智能客户端应用程序通过 Internet 将访问权限交付给最终用户。 许多供应商还提供应用程序编程接口 (API)，它可以将应用程序数据和功能提供给开发人员，供他们在创建复合应用程序时使用。 您可以使用各种各样的安全机制，确保传输和存储过程中敏感数据的安全。 应用程序提供商还可以提供一些工具，客户能够使用这些工具修改数据架构、工作流以及应用程序运行的其他方面，以满足其使用要求。
使用 SaaS 的好处
当然，正因为 SaaS 可以加入 IT 基础结构本身不是 SaaS 加入的原因，所以必然还有其他可行的经营原因。 SaaS 为各种规模的组织提供了实实在在的转嫁软件购置风险的机会，并使 IT 部门从一个被动反应的成本中心转变为主动参与且能够为企业创造价值的部门。
管理软件购置风险
一直以来，部署如 ERP 和 CRM 应用程序套件等大型的关键业务软件系统是一项非常重要的任务。 在整个大型企业部署这些系统时，提前支付的授权成本就高达数十万美元，而且通常需要大批 IT 人员和顾问自定义这些系统，并将其与组织的其他系统和数据集成。 这种级别的部署在时间、人力和预算方面的要求，对任何规模的组织来说都意味着巨大的风险，因而较小的组织往往无法使用这类软件，否则可从中获得大量的效益。
按需交付模型在一定程度上改变了这种状况。 SaaS 应用程序不要求在客户端位置部署大型基础结构，因此可消除或彻底缩减提前支付的资源承诺。 因为分期付款的首付款数目不大，对于那些部署了 SaaS 应用程序的企业而言，如发现结果不尽如人意，则可以轻松地转而寻求其他方法，从而避免在内部部署基础结构上进行了大量的投资，最后弃之不用而造成的浪费。
另外，如果不需要自定义集成，还可以最大限度地减少规划和执行 SaaS 应用程序所需的工作和推广活动，从而可能成为主要 IT 投资中见效时间最短的项目之一。 许多 SaaS 供应商可以提供一定的无风险（通常只是字面上的无风险）软件“试用”期，例如 30 天。 在潜在客户购买软件之前，为他们提供一个试用软件的机会，将有助于避免许多围绕购买软件所产生的风险。
有关 SaaS 的商业效益的详细信息，请参阅 MDSN 库中的抓住长尾市场的架构战略。
管理IT部门的工作重心
有了 SaaS，部署应用程序和维持应用程序正常运行的日常工作，其中包括测试和安装修补程序、管理升级程序、监控性能和确保高可用性等等，都可以由提供商来完成。 通过将这些“开销”活动的职责转让给第三方，IT 部门可以将精力更多的集中在符合和支持企业经营目标的高价值活动上。 从最初的被动反应和侧重于操作的日常工作解脱出来，首席信息官 (CIO) 和 IT 职员可以更有效率地工作，他们可以担任公司其他部门职员的技术策略专家，和业务单元员工一起工作，了解他们的需求，就如何最好的利用技术实现其目标给出建议。 IT 部门非但不会因为 SaaS 的使用而衰落，反而有机会比以前更直接地为企业的成功做出自己的贡献。
SaaS 连续区间
在“纯”SaaS 中，提供商集中托管应用程序，并通过 Internet 向多个客户提供访问权限以换取使用费。 但在实际应用中，内部部署的应用程序和 SaaS 应用程序之间的定义特征不是二元的，而是沿着三个不同的维度累进的： 软件的许可方式、软件的场所以及软件的管理方式。 上面的每个特点都可以看作是一个连续区间，一端是传统的内部部署软件，另一端是纯 SaaS。 中间是结合这两方面的其他方案。
.gif)
图 1. SaaS 应用程序以三个不同的连续区间上的概念性位置为特征
| • |
许可：内部部署的应用程序通常是永久获得许可，可以为每位用户或每个站点预付一笔费用，也可以完全拥有应用程序（在自定义构建应用程序的情况下）。 SaaS 应用程序一般通过基于使用情况的事务模型获得许可，只根据服务事务的使用次数向客户收取费用。 中间是我们所熟悉的基于时间的订阅模型，即客户为某一特定的时间段（例如一个月或一个季度）支付固定费用，就可以在该时间段内无限制的使用服务。 |
| • |
场所：SaaS 应用程序安装在 SaaS 托管方的场所中，而内部部署的应用程序则理所当然的安装在您自己的 IT 环境中。 中间是设备模型，即由供应商提供一个称为“黑盒子”的硬件/软件组件，这个组件安装在您的场所，而不是供应商的场所。例如包含物流应用程序和进行缓存并定期更新的数据库的设备。 运输公司可以为一些大客户提供这样的设备，如果他们需要查询运输信息，可以直接查询该设备，而无需每天对运输公司的服务器进行数千次单独的查询操作。 |
| • |
管理：一直以来，IT 部门负责为用户提供 IT 服务，这意味着他们需要熟悉网络、服务器和应用程序平台；负责提供支持和故障排除；负责解决 IT 安全性、可靠性、性能和可用性问题。 这是一项工作量很大的工作，因而一些 IT 部门将其中某些管理职责转包给专业从事 IT 管理的第三方服务提供商。 在这个区间的另一端，SaaS 应用程序完全由供应商或 SaaS 托管方管理；实际上，这些管理任务和职责的实现对用户而言并不透明。 服务级别协议 (SLA) 管理着质量和可用性，并支持提供商对订阅者所做出的承诺。 |
采用 SaaS 时的注意事项
对于任何指定的应用程序或功能，您都可以通过在各个连续区间上标示贵组织的要求和期望来确定 SaaS 的准备情况，请使用图 2 作为指南。
.gif)
图 2. 每个连续区间都可以再分成三段，分别代表传统方法、SaaS 方法和混合方法
如果您在最右侧一列中的所有三个框内都做了标记，那么说明您已准备就绪，可以考虑迁移到 SaaS。 这意味着，对于此应用程序，您或许应该坚持使用传统的内部部署的解决方案。 任何其他组合则意味着混合方法比较适合；您应该调查一下市场情况，看看能否确定几个适合的解决方案。
在每个连续区间上找到合适的位置需要考虑众多的因素，但每个因素最终都归结为控制和成本之间的平衡。 其中一些考虑事项包括：
| • |
政治方面的考虑 有时，来自组织内部的阻力会使决策短命。如果重要人物坚持认为某个功能应该留在内部，并应该由 IT 部门控制，那么其他因素就都不重要了。 有时候，试用部署（请参阅前面题为“管理软件购置风险”的小节）可能会有助于说服不愿冒险的管理者批准试验性项目。 |
| • |
技术方面的考虑 SaaS 应用程序通常可以为客户配置提供某些灵活性，但此方法也具有局限性。 如果某一重要的应用程序需要专业技术知识才能操作和提供支持，或者需要 SaaS 供应商无法提供的自定义功能，那么该应用程序就不可能采用 SaaS 解决方案。 另一个需要考虑的因素是与该应用程序之间日常传输的数据类型和数据量。 与企业 LAN 中常用的千兆位以太网链接相比，Internet 带宽就显得逊色多了。如果在服务器机房中的服务器之间传输数据，可能只需要几分钟；但如果与位于其他国家或地区的 SaaS 应用程序之间传输数据，可能就需要几个小时。 因此，考虑解决方案时应该将网络滞后因素考虑在内。 例如，基于设备的解决方案就可以进行高速缓存或批处理。 |
| • |
财务方面的考虑 考虑 SaaS 应用程序的总体拥有成本 (TCO)，与相当的内部部署的应用程序的 TCO 相比较。 虽然通过 SaaS 购置若干软件功能的初始成本通常比内部部署的应用程序低，但长期成本结构的确定性却不如后者。 影响 SaaS 应用程序 TCO 的因素包括：获得许可的用户数量；将 SaaS 应用程序与您的基础结构集成时必须执行的自定义配置量；您现有的数据中心是否已经具有一定规模的经济效应，因此降低了 SaaS 的成本节约可能性。 此外，如果您现有的应用程序比较昂贵或者是最近实现的，您也可能决定延迟实现 SaaS 替换，等到原有应用程序产生满意的投资回报 (ROI) 后再实行。 |
| • |
法律方面的考虑 一些行业在世界的不同地方会受到不同的法律法规约束，因此必须满足各种各样的报告和记录维护要求，而这些是您的 SaaS 候选解决方案所无法满足的。 这就需要考虑贵组织从事经营活动的所有不同的管辖区内的法律法规环境，以及它们如何影响您的应用程序要求。 有时，技术方面和财务方面的考虑也会涉及法律方面的问题，例如候选 SaaS 提供商是否能够满足为避免合法披露而建立的一些数据安全性和隐私权方面的内部标准。 还需要考虑为客户或其他方承担的任何法律义务，然后看看 SaaS 是否能够允许您继续符合这些要求。 |
以服务为中心的 IT
我们已经使用相当专业的业务和技术术语讨论了 SaaS 的好处。 但 SaaS 的最大影响可以归结为这样一个事实：SaaS 可以促使 IT 部门采用以服务为中心的模型。
如果我们研究过去数十年来 IT 部门在企业中所扮演的角色的发展变化，我们会发现，信息技术的职责已经从过去的执行日常的记录维护和计算任务，逐步发展到了现今的简化工作流和通信的行业差异化功能。
-->- 该日志由 ageing 于11年前发表在综合分类下，最后更新于 2013年09月22日.
- 转载请注明: 软件即服务 (SaaS)： 企业角度 | 学步园 +复制链接