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 报告就可以显示出它所拥有的数据存储方法能否帮助您遵守这项法律。
有关 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 模式和实施方案网站的 Data Integration 和 Integration Topologies。
身份集成
从用户角度来看，正如我们先前所提到的，应用程序无论是在企业防火墙内部还是外部进行物理托管均不应是个问题： 应当可以采用方便一致的方式对处于多个位置的应用程序进行访问。 这种一致用户体验的一个很重要构成因素是单一登录： 用户每天第一次登录 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 的应用潜力的完全展示： 将任意数量的应用程序和数据的最佳方面整合到一个单独的应用程序中，这个应用程序关注用户的需要，而不是任何一个系统的功能和限制。
关于复合应用程序，还有很多其他业务、体系结构和技术细节可以介绍。 即将发行的《Architecture Journal》（体系结构期刊）第 10 期将进一步探讨该主题。
成为 SaaS 提供商
我们已经讨论了企业如何因成为 SaaS 使用者而受益。 在某些情况下，如果企业成为指定的 SaaS 提供商，也能获利不菲。
如果企业具有从属实体（比如代销商或转销商），且利用这些实体建立了强大的业务关系，但是在 IT 流程自动化和信息传输方面却表现不佳，则成为 SaaS 提供商会给企业带来巨大转机。 例如，假设有一家快餐连锁店，该店采用特许经营模式运作。 它的部分或全部餐馆归独立的代销商所有，这些代销商要与总经销商签订合约，在品牌、配方或库存和设备租用方面达成协议。 代销商在其经营的店中既没有部署和维护附属 IT 基础结构的人员，也没有相应的预算，因此他们与总经销商之间的大部分或全部通信往往按传统的方式进行： 通过邮政系统、电话、在地方办公室定期召开会议或使用一些其他没有技术含量的方法。 通过信息传输的改进和某些流程自动化的实现，中心企业和其代销商之间可建立更好的 IT 关系，进而提高服务质量。
这就是 SaaS 流行的原因。若成为 SaaS 提供商，中心企业可为其代销商托管指定的应用程序，这些应用程序涉及到诸多业务功能，如库存控制、帐目管理、人员晋升、忠诚度计划等等；仅需一台普通的个人计算机和宽带连接，世界各地的代销商就可访问这些应用程序。 这种安排实现了关系中多方的共赢。 在所提供的示例中，代销商通过这些应用程序取得了丰硕的成果，而这是采用其他方式所无法做到的。 同样，通过代销商使用这些应用程序，总经销商收到的反馈和数据得到了增强，这些反馈和数据让业务智能更准确、更具价值。
如果企业开发了颇有价值的 IT 资产，可以通过将其提供给其他企业而变现，则也可以考虑成为 SaaS 提供商。 例如，如果某银行开发了一种供内部使用的复杂的欺诈检测系统，则它可以开发一个商业版本，并将其作为一款 SaaS 应用程序来提供订阅。 企业可以从 Internet 云中消费服务，同样也可以向 Internet 云提供服务，二者道理是相同的。
结束语
企业在将 SaaS 添加到其 IT 服务资产组合时，如果考虑一下内在的灵活性和风险管理，将大有裨益。 在您的体系结构策略中，要成功地将 SaaS 融入以服务为中心的 IT 基础结构，让其成为全面参与的成员，则集成和复合是非常重要的组成部分。
最后，我们相信企业计算的未来不会是纯粹的提前部署，也不会是纯粹的设想。 相反，就像阴和阳一样，它们会相辅相成、和谐共生。
致谢
非常感谢 Paul Henry 在技术撰写中给予的大力支持。