软件即服务 (SaaS)：企业角度
转载至MSDN
简介
“软件即服务”(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。中间是结合这两方面的其他方案。
图 1. SaaS 应用程序以三个不同的连续区间上的概念性位置为特征
l 许可：内部部署的应用程序通常是永久获得许可，可以为每位用户或每个站点预付一笔费用，也可以完全拥有应用程序（在自定义构建应用程序的情况下）。 SaaS 应用程序一般通过基于使用情况的事务模型获得许可，只根据服务事务的使用次数向客户收取费用。 中间是我们所熟悉的基于时间的订阅模型，即客户为某一特定的时间段（例如一个月或一个季度）支付固定费用，就可以在该时间段内无限制的使用服务
l 场所：SaaS 应用程序安装在 SaaS 托管方的场所中，而内部部署的应用程序则理所当然的安装在您自己的 IT 环境中。 中间是设备模型，即由供应商提供一个称为“黑盒子”的硬件/软件组件，这个组件安装在您的场所，而不是供应商的场所。例如包含物流应用程序和进行缓存并定期更新的数据库的设备。 运输公司可以为一些大客户提供这样的设备，如果他们需要查询运输信息，可以直接查询该设备，而无需每天对运输公司的服务器进行数千次单独的查询操作。
l 管理：一直以来，IT 部门负责为用户提供 IT 服务，这意味着他们需要熟悉网络、服务器和应用程序平台；负责提供支持和故障排除；负责解决 IT 安全性、可靠性、性能和可用性问题。 这是一项工作量很大的工作，因而一些 IT 部门将其中某些管理职责转包给专业从事 IT 管理的第三方服务提供商。 在这个区间的另一端，SaaS 应用程序完全由供应商或 SaaS 托管方管理；实际上，这些管理任务和职责的实现对用户而言并不透明。 服务级别协议 (SLA) 管理着质量和可用性，并支持提供商对订阅者所做出的承诺。
采用 SaaS 时的注意事项
对于任何指定的应用程序或功能，您都可以通过在各个连续区间上标示贵组织的要求和期望来确定 SaaS 的准备情况，请使用图 2 作为指南。
图 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 部门在企业中所扮演的角色的发展变化，我们会发现，信息技术的职责已经从过去的执行日常的记录维护和计算任务，逐步发展到了现今的简化工作流和通信的行业差异化功能。
图 3. 以服务为中心的 IT 成熟度模型
图 3 显示了一个成熟度模型，该模型描述企业获得技术功能并从中受益的特殊习惯。
在早期阶段，当企业最初考虑合并技术时，通常会将适用于某些需求的解决方案与可提供有限功能的特定应用程序相关联。例如，如果用户需要与合作伙伴交互，讨论硬件组件的设计，则可能会使用简单的电子邮件应用程序作为主要的协作和通信工具。
当企业认识到特定业务需求最好通过一类相关的应用程序（而不是仅仅一个应用程序）来满足时，就向以服务为中心的观点前进了一步，发展到采用应用程序资产组合。回到前面那个合作伙伴交互的例子，企业可能会认识到通过 Web 门户可以增强协作能力，其中 Web 门户合并了文档共享、版本支持、在线讨论、实时白板和幻灯片演示支持等功能。结果就是企业可能决定购买和部署门户解决方案，以增强目前仅有电子邮件功能的协作 IT 服务功能。
随着通过 SaaS 交付模型交付越来越多的平台和业务线应用程序，企业不仅有着越来越多的供应商可供选择，对于应用程序的交付地点和方法也有着越来越多的选择。如前所述，SaaS 通过提供各种各样的许可、经营和管理模型影响了企业的资源分配。聪明的企业能够通过牺牲直接控制（针对服务实现细节）来换取更大的灵活性，从而优化核心业务的策略和执行。但是，企业可以使用 SaaS 的程度与其转嫁和降低风险的能力直接相关，对服务级别协议的合理运用是风险管理的关键所在。因此，如果扩展 IT 的服务资产组合，使其超出防火墙范围，则意味着达到了另一个业务和技术混合级别，超过了以服务为中心的 IT。
在采用 SaaS 并将其集成到以服务为中心的 IT 后，企业除了降低风险外，还必须学习通过使用内部部署服务和外包服务的资产组合所提供的功能和数据，获得最大化的营业利润。确保通过完全不同的系统处理过的业务数据是简洁、一致且安全的，这通常是构建业务增强型 IT 的基础步骤。集成技术通过数据转换和过程编排帮助提供了这个基础。这类似于已开业餐馆中经常使用的“调配”惯例：将大蒜、药草等菜谱配料适当切碎、剁碎和绞碎，为最后由主厨掌勺的“烹饪盛宴”做准备。类似地，一个有效的集成体系结构可以通过复合应用程序，帮助整合和组织上游用户所使用的企业中的信息资产。复合应用程序可以提供一种计算结构，能够为最终用户有效地组合或分解业务功能和信息。在与复合应用程序进行交互时，最终用户不知道（也无需知道）真实的信息源，而是将精力集中在综合和分析业务信息上面，将使用技术相关的上下文切换降到最低程度。
大体上：
| • | 在第一级（左上角），通过单独存储的应用程序集合来初步满足企业用户的需要。 |
| • | 在第二级（右上角），通过服务资产组合来更好地满足企业用户的需要。其中每个服务资产组合均包含若干相关的应用程序，共同提供一组更为完善的功能。 |
| • | 第三级（左下角）是关于服务资产组合优化方面的。 SaaS 提供商提供了更多的选择，使企业的服务资产组合得到了增强，所以企业能够进一步优化其 IT 策略和成本分配决策。 |
| • | 在第四级（右下角），外包服务和内部部署服务无缝集成，为符合业务目标的复合应用程序提供了平台。 |
本文的最后两部分详细介绍了集成体系结构和复合体系结构如何在将 SaaS 融入企业计算策略方面扮演决定性的角色。但在下一部分中，我们首先介绍一下 SaaS 在以服务为中心的企业中对 IT 管理和角色的影响。
SaaS 如何影响 IT
决定部署 SaaS 后，下一步就是准备过渡。首先评估部署对现有 IT 资产的影响，然后采取相应措施确保平稳过渡。
IT 管理的意义
对于任何成功的 IT 基础结构部署项目而言，在日常工作中务必要做到尽职尽责，您应该对此已经相当熟悉。但有一些问题还是值得特别注意。在尽职尽责检查清单中，以下问题亟待解决：
| • | 数据安全性标准。将关键的业务数据转移到“墙外”，可能会产生数据丢失或无意中泄露敏感信息的风险。评估您的数据安全性需求，确保提供商拥有相应的措施来满足您所设定的标准。 |
| • | SLA 保证。您与 SaaS 提供商之间的管理合同采用服务级别协议 (SLA) 形式，可以保证 SaaS 供应商所提供的性能、可用性和安全性的级别，并管理着当提供商未能满足这些保证条款时应采取的措施或者提供的补偿。确保这些 SLA 已安排妥当，也就是说，他们所承诺的保证足以满足您的需求，甚至在最坏的情况下，他们所提供的补偿也足以缓解您的问题。 |
| • | 迁移策略。有时，您可能要将数据从 SaaS 应用程序迁移到其他解决方案，因此从应用程序取出现有数据并移动到其他解决方案的能力就显得特别重要。请咨询潜在的 SaaS 提供商，以了解其是否拥有数据迁移策略以及相应的程序，其中包括数据和代码托管方面的规定。（有关迁移数据准备方面的更多建议，请参阅后文中的“集成体系结构”。） |
| • | 内部集成要求。确保 SaaS 迁移满足组织内任何现有的功能性和数据集成要求。我们会在后文中更为详细地讨论各种集成方案。 |
| • | 报告服务。因为 SaaS 涉及到放弃对于某些数据的直接控制，所以报告的准确性和实用性显得特别重要。确定提供商能够提供的报告服务，以及这些服务与您的业务智能要求是否吻合。 |
对 IT 角色和职责的影响
如前所述，SaaS 加入企业 IT 资产组合后，会造成 IT 部门作为信息服务提供商角色的根本转换。有时会用漫画手法讽刺业务单元害怕变革，但 IT 部门也不是对组织政策无动于衷，他们可以像其他部门一样容易地从制度上抵制 SaaS。过去，软件部署工作的性质将首席信息官 (CIO) 及其下属放在了看门人的角色，他们只需声明数据中心不会托管某个软件就可以对任何软件部署提议行使否决权。由于可以选择 SaaS，控制数据中心未必等于控制整个企业计算环境，因此造成这些看门人害怕失去控制权：一个“无赖”副总裁只需为部门订阅 SaaS 应用程序，就可以完全绕过 IT。
当然，如果 CIO 依靠控制数据中心来控制更大的计算环境，则总会存在一些管理方面的问题。成功的 CIO 会与业务单元交流，告诉他们采购对其未来灵活性所产生的影响，并与他们合作，以确定能够最好的满足其需求的方案是内部部署软件还是 SaaS。通过扮演这种顾问角色（如上所述），IT 部门可以帮助业务单元与技术达到最佳配合，从而直接为企业增加价值。
对法规合规性的影响
第 70 号审计准则公告 (SAS 70) 是一项国际审计准则，为其他组织提供服务的企业可以使用该准则就其内部控制措施和方法提供一份独立可靠的报告。 SAS 70 审计由独立审计人员实施，审计结束后将出具一份 SAS 70 报告，服务提供商可以将此审计报告提供给使用者和客户，供他们自己进行审计时使用。 SAS 70 不是一项法律，但世界各管辖区公布的审计和披露准则（例如美国的 Sarbanes-Oxley）都规定：为其他企业提供服务的企业必须提供最新的 SAS 70 报告。这一规定实际上使最新的 SAS 70 报告成为必要条件，因此任何 SaaS 提供商都应考虑提供一份 SAS 70 报告，随时随地可供审核。
SAS 70 也不是审批标志，因为它未规定组织最低限度必须遵循的一组准则。 SAS 70 报告只记录了组织的内部控制方法，并未提供关于组织是否符合准则的任何判断。因此职责提出了这样的要求：您不仅需要让潜在的 SaaS 提供商提供 SAS 70 报告，而且您自己必须彻底地仔细审查此报告，确定提供商是否能够符合公司所制定的关于隐私权和数据安全性等方面的内部标准。例如，假设您当地的隐私权法律规定必须以加密形式存储客户的个人财务数据，那么提供商的 SAS 70 报告就可以显示出它所拥有的数据存储方法能否帮助您遵守这项法律。
集成体系结构
订阅 SaaS 应用程序意味着，业务数据不是保存在可控的本地网络中，而是保存在 Internet“cloud”中。集成体系结构指定了将这些外部数据集成到逻辑基础结构中的方式，从而使基础结构各组件之间能够进行交互操作，而不管它们是内部托管组件还是外部托管组件；每个组件都能够访问所需的数据，而不管这些数据源自何处。
在大多数情况下，SaaS 应用程序的实现过程包括将数据从一个或多个现有应用程序或数据存储库传输到新系统中。几种常见的情形如下：
| • | 使用内部部署源中预先存在的数据“引导”SaaS 应用程序。 |
| • | 配置 SaaS 应用程序，依靠由内部部署源产生的数据实现部分功能（例如，CRM 应用程序引用由内部部署库存应用程序管理的库存数据）。 |
| • | 配置内部部署应用程序，依靠由 SaaS 应用程序产生的数据实现部分功能（例如，内部部署薪资应用程序引用由 SaaS 人力资源应用程序管理的人力资源数据）。 |
但在许多情况下，将 SaaS 应用程序集成到您的环境中，就意味着数据之间产生了依存关系，为了方便数据处理，必须在 SaaS 应用程序和一个或多个内部应用程序之间同步和移动数据。使用集成代理程序来管理数据移动和系统集成。
集成代理程序
许多企业已经开始使用某种集成代理程序来提供应用程序功能、编排业务流程以及集成内部后端系统。在许多情况下，可以自定义和配置同一个集成代理程序，为各种内部和外部数据源执行集成和路由功能，其中包括 SaaS 应用程序。
图 4. 集成代理程序可以将内部和外部数据源合并为一个统一的整体
数据可以来自不同的数据源，使用不同的协议以及各种相互之间不兼容的格式。集成代理程序的任务就是从各种数据源提取数据，并确定所需的数据处理方式和路由位置，然后以目标系统可以使用的形式发送数据。代理程序采取的是管道体系结构的形式，您可以从中添加和删除执行特定集成操作的模块。可使用多个逻辑管道处理移动方面不同的数据。例如，在一个典型的案例中，使用一个管道将来自 Internet 源的数据与本地数据源集成，并使用另一个管道提取本地数据，将其与 Internet 上的 SaaS 数据集成。
数据通过数据通道进出管道，数据通道可以定义与数据源通信所使用的协议。例如，建立一个通道，使用 SOAP 将来自特定 Web 服务的数据传输到代理程序；建立另一个通道，使用 FTP 将来自代理程序的数据传输到 SaaS 应用程序。（有关数据传输的详细信息，请参阅后文中的“数据传输模式”。）
管道中所插入的模块用于确定数据处理、路由以及与目标数据集成的方式。元数据服务提供了每个模块工作时所使用的可配置规则。常见的集成操作如下：
| • | 安全性 - 通常由安全性模块处理传入的数据，该模块执行的操作包括验证数据源或数字签名、解密数据和检查数据是否存在安全性风险（如病毒）等。安全性操作可以配合现有的安全性策略来控制访问。 |
| • | 验证- 验证模块将数据与相关架构进行比较，可以拒绝不兼容的数据，也可以将不兼容的数据转发到转换组件，以转换为正确的格式。（有关数据转换的详细信息，请参阅后文中的“数据转换模式”。） |
| • | 同步工作流- 同步组件使用工作流和规则确定以何种方式和顺序将数据更改传播到目标。如果某个工作流序列不能成功完成，同步组件可以使用事务性逻辑或补偿逻辑轻松断开数据传输，以保证不同系统之间的数据一致性。 |
| • | 路由 - 最后，路由规则定义了每段数据的目标。路由可能只包括将所有数据从一个特定的源传输到指定的目标，也可能包括比较复杂的逻辑，例如根据内容信息（如客户 ID 号）确定目标。 |
数据可用性服务提供了几种方法，集成代理程序可以使用这些方法来检测新数据是否可用。有关数据可用性确定方法的详细信息，请参阅下一部分“数据可用性模式”。
数据可用性模式
同步数据包括将新数据和更改过的数据从源传输到目标（数据接收器），可以定期执行同步，也可以由事件引发同步。可使用以下三种基本模式在本地源和 SaaS 应用程序之间触发数据同步：
| • | 轮询 - 使用轮询时，一个源通常定期查询其他源是否存在数据更改。 |
| • | 推动 - 推动与轮询相反。在推动关系中，包含已更改数据的源会通知数据接收器发生了数据更改。数据源可以在数据源中的数据每次发生更改时发起推动，也可以定期发起推动。 |
| • | 发布和订阅 - 基于事件的发布和订阅是一种混合方法，它综合了轮询和推动这两个方面。对数据源进行更改时，该数据源会发布一个更改通知事件，数据接收器可以订阅该事件。 |
不同的方法适用于不同的数据，一个应用程序可以使用多种方法的组合。用于检测数据更改的正确方法取决于许多不同的因素，其中包括必须实时反映数据更改还是可以稍后反映数据更改，以及数据更新必须集成到多少个数据接收器。在某些情况下，您必须寻找一个可平衡不同利益的折衷方案。例如，对于必须始终保持最新的数据而言，推动方法通常是最好的，但将数据传送到大量相关源中，会使计算和网络传输都很紧张，还有可能使应用程序性能下降。无论您选择哪一种方法，都必须制定相关的规则来管理实现细节，例如轮询频率、聚合格式等等。
数据传输模式
可以使用同步或异步通信技术在两个端点之间传输数据。同步传输类似于接口：一方需要信息时，它连接到另一方并发出请求，期望立即收到结果。此连接发生的形式多种多样。同步传输可以是简单的文件传输，也可以通过 FTP、HTTP 或其他方法进行。
在异步传输中，可由发送者传送信息而由接收者在另外不同的时间处理信息。异步传输通常是基于消息：一方向另一方发送一条请求信息的消息，但不期望得到立即响应。第二方处理完请求之后，会在另一条消息中将响应发送回第一方。消息可以通过电子邮件协议（例如 SMTP）传送，也可以通过消息队列技术传送。
数据转换模式
数据转换意为从某数据源提取数据，然后改变其格式和/或内容以便由数据接收器使用。同 SaaS 应用程序交换数据会涉及某种程度的数据转换。例如，某个现有的内部部署系统可能使用 EDIFACT 标准来交换数据，而所要集成的 SaaS 应用程序则使用基于 XML 的不兼容格式来发送和接收数据。源自内部部署系统的数据在发送到 SaaS 应用程序之前必须经过转换，反之亦然。
转换数据是一个多步骤流程。首先，应验证传入数据的格式和架构是否合适，以保证其转换之后确实可用。另外，与来自其他源的数据相结合可增强该数据。最后，数据本身会转换为目标格式。
身份集成
从用户角度来看，正如我们先前所提到的，应用程序无论是在企业防火墙内部还是外部进行物理托管均不应是个问题：应当可以采用方便一致的方式对处于多个位置的应用程序进行访问。这种一致用户体验的一个很重要构成因素是单一登录：用户每天第一次登录 Microsoft Windows 操作系统时输入他们的用户名和密码，之后即可访问应用程序和网络资源，而不必在每次访问时重复出示其凭据。除带来方便之外，单一登录意味着用户可跟踪更少的凭据集，还减少了丢失或错放密码造成的安全风险。
从 IT 管理与控制角度而言，单一登录表明支持员工不必再管理独立的凭据集。这在其他方面也方便了身份集成，比如启用现有应用程序访问策略的重用来控制对 SaaS 应用程序的访问。例如，某项策略可能会指明特定的管理人员有权力批准特定价格以内所有采购行为，同时还希望 SaaS 应用程序能够识别该权限。将您的目录服务与 SaaS 应用程序相集成，意味着在设置帐户时将不必手动复制策略信息。
通过使用与客户自身企业用户目录服务相接的客户网络内部联合身份验证服务器，SaaS 可提供单一登录验证。此联合身份验证服务器与位于 SaaS 提供商网络内部的相应联合身份验证服务器具有信任关系。
当最终用户尝试访问应用程序时，企业联合身份验证服务器会在本地验证用户身份，然后与 SaaS 联合身份验证服务器协商，为用户提供已签名的安全令牌，SaaS 提供商的验证系统会接受并使用此令牌来授予用户访问权限。
图 5. 联合身份验证服务器为企业客户提供对 SaaS 应用程序的单一登录验证
以公认的标准如 WS 联合身份验证或安全声明标记语言 (SAML)，实现远程验证的联合身份验证服务器，可以借助广大的 SaaS 提供商资源来简化单一登录实施过程。
复合体系结构
利用复合应用程序，可以为最终用户有效地集成业务功能和信息。设计良好的复合应用程序的商业效益有很多，包括减少重复的数据输入、更好的人力协作、对待处理任务及其状态的清醒认识和经过改进的相互关联业务信息的可见性。在更加理论化的级别上总结复合应用程序的原则时，我们发现，将信息作为统一的整体而不是孤立的数据流会给用户带来更多好处。据此，用户可以更好地了解来自不同数据源的数据之间的关系，并应用他们自己的“域智能”，亦即有关其业务以及流程工作方式的已有知识，制定出更为明智的决策。这还可以创建更加完善的“流程智能”，可令用户更清楚地看到其本身的任务和职责。
假设医院中的一位医生。在其一天的工作中，该名医生可能要处理大量与患者有关的信息： X 射线、患者病史、处方与药物信息、保险责任范围限制、来自政府卫生部门或疾病控制中心的公告等等。通常情况下，是由单独的应用程序来分别跟踪上述的每种信息，这就导致了医生的工作效率低下。如果上述所有功能全部集成到单一的应用程序，而该应用程序将业务智能（如上面所列各种信息）、流程智能（如手术室调度和医生的求诊患者队列状态）及协作工具（便于同事之间会诊）进行无缝集成，则医院、医院职员以及患者就会得到更好的服务。
在以服务为中心的 IT 部门中，应用程序和其他资源就以这样的方式成为可以结合到一起的因素，从而在一个软件包中创建面向任务的复合应用程序，将“业务智能”同“流程智能”组合到一起。创建复合应用程序并不简单：它涉及到组合不同的应用程序、协议以及技术（设计之初，可能并没有考虑到要相互通信），并将它们无缝集成为一个整体。设计复合体系结构的目的就在于让这一切变成现实。
图 6. 复合体系结构旨在从大量不同数据源（位于不同位置，而且类型也各不相同）中提取数据
复合体系结构的最底层体系结构级别是这样的数据源：它们提供存储的数据或经处理的数据作为“原始材料”。数据源可以包含内部应用程序、内部数据库、SaaS 应用程序、Web 服务、平面文件和大量的其他数据源。许多 SaaS 应用程序为您提供 API，您可以直接使用这些 API 提供的各种属性和方法。
在复合层中，聚合原始数据并将其以新的统一形式提供给用户。其功能是将数据转换为业务信息和流程智能，反之亦然。
复合层本身即由大量组件构成，这些组件负责管理访问、数据、工作流和规则。应用程序、数据库、Web 服务和其他资源通过服务代理作为“插件”集成到本层，此代理记录与每项服务协商连接和交换消息相关的详细信息。身份管理组件确保用户经过适当的验证和授权，并且还可以管理与 Web 服务进行通信的凭据，这些服务通常要求所管理的凭据不同于用户提供的可访问本地网络的凭据。
复合层的数据聚合组件从数据源中提取信息，并以应用程序实体模型所定义的方式来转换信息。例如，目录实体可能需要不同系统中的不同产品和库存信息。然后该信息作为统一、相关的数据集呈现给最终用户。工作流组件采用条件和流程组织信息，指导人员的交互和协作；然后在指定的条件满足时，事件机制开始发送和接收通知，以便最终用户做出相应反应。
在面向任务的集成中心用户界面（该界面即提供决策信息也提供采取行动的功能）中，用户中心层为用户提供了复合数据。这可能是以服务为中心的 IT 的应用潜力的完全展示：将任意数量的应用程序和数据的最佳方面整合到一个单独的应用程序中，这个应用程序关注用户的需要，而不是任何一个系统的功能和限制。
成为 SaaS 提供商
我们已经讨论了企业如何因成为 SaaS 使用者而受益。在某些情况下，如果企业成为指定的 SaaS 提供商，也能获利不菲。
如果企业具有从属实体（比如代销商或转销商），且利用这些实体建立了强大的业务关系，但是在 IT 流程自动化和信息传输方面却表现不佳，则成为 SaaS 提供商会给企业带来巨大转机。例如，假设有一家快餐连锁店，该店采用特许经营模式运作。它的部分或全部餐馆归独立的代销商所有，这些代销商要与总经销商签订合约，在品牌、配方或库存和设备租用方面达成协议。代销商在其经营的店中既没有部署和维护附属 IT 基础结构的人员，也没有相应的预算，因此他们与总经销商之间的大部分或全部通信往往按传统的方式进行：通过邮政系统、电话、在地方办公室定期召开会议或使用一些其他没有技术含量的方法。通过信息传输的改进和某些流程自动化的实现，中心企业和其代销商之间可建立更好的 IT 关系，进而提高服务质量。
这就是 SaaS 流行的原因。若成为 SaaS 提供商，中心企业可为其代销商托管指定的应用程序，这些应用程序涉及到诸多业务功能，如库存控制、帐目管理、人员晋升、忠诚度计划等等；仅需一台普通的个人计算机和宽带连接，世界各地的代销商就可访问这些应用程序。这种安排实现了关系中多方的共赢。在所提供的示例中，代销商通过这些应用程序取得了丰硕的成果，而这是采用其他方式所无法做到的。同样，通过代销商使用这些应用程序，总经销商收到的反馈和数据得到了增强，这些反馈和数据让业务智能更准确、更具价值。
如果企业开发了颇有价值的 IT 资产，可以通过将其提供给其他企业而变现，则也可以考虑成为 SaaS 提供商。例如，如果某银行开发了一种供内部使用的复杂的欺诈检测系统，则它可以开发一个商业版本，并将其作为一款 SaaS 应用程序来提供订阅。企业可以从 Internet 云中消费服务，同样也可以向 Internet 云提供服务，二者道理是相同的。
结束语
企业在将 SaaS 添加到其 IT 服务资产组合时，如果考虑一下内在的灵活性和风险管理，将大有裨益。在您的体系结构策略中，要成功地将 SaaS 融入以服务为中心的 IT 基础结构，让其成为全面参与的成员，则集成和复合是非常重要的组成部分。
最后，我们相信企业计算的未来不会是纯粹的提前部署，也不会是纯粹的设想。相反，就像阴和阳一样，它们会相辅相成、和谐共生。
6657
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
