软件即服务.docx
- 文档编号:30385454
- 上传时间:2023-08-14
- 格式:DOCX
- 页数:24
- 大小:219.36KB
软件即服务.docx
《软件即服务.docx》由会员分享,可在线阅读,更多相关《软件即服务.docx(24页珍藏版)》请在冰豆网上搜索。
软件即服务
软件即服务(SaaS):
企业角度
发布日期:
2007-05-25|更新日期:
2007-05-25
GianpaoloCarraro
FredChong
MicrosoftCorporation
适用于:
软件即服务(SaaS)
摘要:
这是关于“软件即服务”(SaaS)系列文章中的第三篇文章,从企业使用者角度说明SaaS。
本页内容
简介
了解SaaS
使用SaaS的好处
SaaS连续区间
采用SaaS时的注意事项
以服务为中心的IT
SaaS如何影响IT
集成体系结构
复合体系结构
成为SaaS提供商
结束语
致谢
进一步讨论和反馈
简介
“软件即服务”(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应用程序以三个不同的连续区间上的概念性位置为特征
•
许可:
内部部署的应用程序通常是永久获得许可,可以为每位用户或每个站点预付一笔费用,也可以完全拥有应用程序(在自定义构建应用程序的情况下)。
SaaS应用程序一般通过基于使用情况的事务模型获得许可,只根据服务事务的使用次数向客户收取费用。
中间是我们所熟悉的基于时间的订阅模型,即客户为某一特定的时间段(例如一个月或一个季度)支付固定费用,就可以在该时间段内无限制的使用服务。
•
场所:
SaaS应用程序安装在SaaS托管方的场所中,而内部部署的应用程序则理所当然的安装在您自己的IT环境中。
中间是设备模型,即由供应商提供一个称为“黑盒子”的硬件/软件组件,这个组件安装在您的场所,而不是供应商的场所。
例如包含物流应用程序和进行缓存并定期更新的数据库的设备。
运输公司可以为一些大客户提供这样的设备,如果他们需要查询运输信息,可以直接查询该设备,而无需每天对运输公司的服务器进行数千次单独的查询操作。
•
管理:
一直以来,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号审计准则公告(SAS70)是一项国际审计准则,为其他组织提供服务的企业可以使用该准则就其内部控制措施和方法提供一份独立可靠的报告。
SAS70审计由独立审计人员实施,审计结束后将出具一份SAS70报告,服务提供商可以将此审计报告提供给使用者和客户,供他们自己进行审计时使用。
SAS70不是一项法律,但世界各管辖区公布的审计和披露准则(例如美国的Sarbanes-Oxley)都规定:
为其他企业提供服务的企业必须提供最新的SAS70报告。
这一规定实际上使最新的SAS70报告成为必要条件,因此任何SaaS提供商都应考虑提供一份SAS70报告,随时随地可供审核。
SAS70也不是审批标志,因为它未规定组织最低限度必须遵循的一组准则。
SAS70报告只记录了组织的内部控制方法,并未提供关于组织是否符合准则的任何判断。
因此职责提出了这样的要求:
您不仅需要让潜在的SaaS提供商提供SAS70报告,而且您自己必须彻底地仔细审查此报告,确定提供商是否能够符合公司所制定的关于隐私权和数据安全性等方面的内部标准。
例如,假设您当地的隐私权法律规定必须以加密形式存储客户的个人财务数据,那么提供商的SAS70报告就可以显示出它所拥有的数据存储方法能否帮助您遵守这项法律。
有关SAS70的详细信息,请访问美国注册公开会计师协会网站。
返回页首
集成体系结构
订阅SaaS应用程序意味着,业务数据不是保存在可控的本地网络中,而是保存在Internet“cloud”中。
集成体系结构指定了将这些外部数据集成到逻辑基础结构中的方式,从而使基础结构各组件之间能够进行交互操作,而不管它们是内部托管组件还是外部托管组件;每个组件都能够访问所需的数据,而不管这些数据源自何处。
在大多数情况下,SaaS应用程序的实现过程包括将数据从一个或多个现有应用程序或数据存储库传输到新系统中。
几种常见的情形如下:
•
使用内部部署源中预先存在的数据“引导”SaaS应用程序。
•
配置SaaS应用程序,依靠由内部部署源产生的数据实现部分功能(例如,CRM应用程序引用由内部部署库存应用程序管理的库存数据)。
•
配置内部部署应用程序,依靠由SaaS应用程序产生的数据实现部分功能(例如,内部部署薪资应用程序引用由SaaS人力资源应用程序管理的人力资源数据)。
但在许多情况下,将SaaS应用程序集成到您的环境中,就意味着数据之间产生了依存关系,为了方便数据处理,必须在SaaS应用程序和一个或多个内部应用程序之间同步和移动数据。
使用集成代理程序来管理数据移动和系统集成。
集成代理程序
许多企业已经开始使用某种集成代理程序来提供应用程序功能、编排业务流程以及集成内部后端系统。
在许多情况下,可以自定义和配置同一个集成代理程序,为各种内部和外部数据源执行集成和路由功能,其中包括SaaS应用程序。
图4.集成代理程序可以将内部和外部数据源合并为一个统一的整体
数据可以来自不同的数据源,使用不同的协议以及各种相互之间不兼容的格式。
集成代理程序的任务就是从各种数据源提取数据,并确定所需的数据处理方式和路由位置,然后以目标系统可以使用的形式发送数据。
代理程序采取的是管道体系结构的形式,您可以从中添加和删除执行特定集成操作的模块。
可使用多个逻辑管道处理移动方面不同的数据。
例如,在一个典型的案例中,使用一个管道将来自Internet源的数据与本地数据源集成,并使用另一个管道提取本地数据,将其与Internet上的SaaS数据集成。
数据通过数据通道进出管道,数据通道可以定义与数据源通信所使用的协议。
例如,建立一个通道,使用SOAP将来自特定Web服务的数据传输到代理程序;建立另一个通道,使用FTP将来自代理程序的数据传输到SaaS应用程序。
(有关数据传输的详细信息,请参阅后文中的“数据传输模式”。
)
管道中所插入的模块用于确定数据处理、路由以及与目标数据集成的方式。
元数据服务提供了每个模块工作时所使用的可配置规则。
常见的集成操作如下:
•
安全性-通常由安全性模块处理传入的数据,该模块执行的操作包括验证数据源或数字签名、解密数据和检查数据是否存在安全性风险(如病毒)等。
安全性操作可以配合现有的安全性策略来控制访问。
•
验证-验证模块将数据与相关架构进行比较,可以拒绝不兼容的数据,也可以将不兼容的数据转发到转换组件,以转换为正确的格式。
(有关数据转换的详细信息,请参阅后文中的“数据转换模式”。
)
•
同步工作流-同步组件使用工作流和规则确定以何种方式和顺序将数据更改传播到目标。
如果某个工作流序列不能成功完成,同步组件可以使用事务
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 服务