发表于:2014年9月12日
作者:Tom Nolle
SaaS(软件即服务)应用服务需要追踪用户的需求,但有时候它们在这方面做的并不好。随着潜在需求的不断增加,对于不同的企业,移动SaaS应用服务还要根据不同的应用服务规则、不同的移动设备、不同的用户活动方式以及不同的移动操作系统,在各方面做出相应的改变。由于有如此多的变数,完美体现移动SaaS应用服务灵活性的方案几乎是不存在的。但是,选择适合的SaaS应用服务供应商、为移动用户制定个性化的SaaS应用服务,甚至创建自己的SaaS应用服务,会对实现服务的灵活性起到帮助。
评估SaaS的灵活性
无论什么力量让移动应用用户和他们的SaaS应用服务供应商从不同方向发展,SaaS应用服务供应商根据不同规则做出应变的能力是体现他们能否跟上市场发展的关键要素。每一位SaaS评估人员都需要关心一个问题,就是应用服务根据不同规则做出应变的速度。通过几个月做出应变,肯定会产生问题,并且这也说明服务供应商没有能力做出及时的应变。此外,当这样的服务供应商面对其他方面的需求变化时,必然也会表现出同样的惰性。因此,更换掉这样的服务供应商会是一个明智的选择。
每一位SaaS评估人员都需要关心一个问题,就是SaaS应用服务根据不同规则做出应变的速度。
在对一个服务供应商作评估时,还需要认真评估其SaaS软件应用服务所选择的应用程序接口。有些用户喜欢直接在他们的手机上运行SaaS服务商提供的应用服务,然而由于不同的BYOD解决方案(自带设备),不同的移动操作系统,不同的实际工作内容,这么做经常会引发一些问题。因此,应用程序接口的选择显得至关重要。引发问题的这些应用服务往往仅适用于特定的操作平台,因此当应用于其他平台时,总是会显现出一些问题,而用户对此却无能为力。最直接的解决方法,就是不去使用SaaS服务商提供的那些移动应用,而是去自行开发相应的移动应用或者直接通过使用浏览器架构的解决方案来代替那些移动应用。
SaaS服务商所使用的应用程序接口对确保移动SaaS应用的灵活性至关重要。大多数IT专家都知道,RESTful(REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful)架构使用最简单,对于那些相对Java或C++编程,更熟悉网站开发的技术团队来说尤其如此。从理想化角度来说,作为SaaS应用服务供应商,应该提供RESTful架构、SOA/SOAP架构以及各种移动应用供客户选择,但如果从灵活性考虑,RESTful架构是最好的选择,其他架构并不适合在所有移动设备上运行。
自制SaaS应用以确保灵活性
在使用了基于RESTful架构的SaaS应用服务后,开发内部的一些应用将变的非常容易。事实上,大多数目前支持移动设备的多平台开发工具都支持这种应用程序接口。因此多数情况下,你总能找到一个适合的平台为你编写自己的移动应用提供最好的支持,以增加应用的灵活性。但为了确保应用能迅速在新平台上顺利运作,还是应该去了解这些工具供应商以前是如何解决平台转变这个问题的。当你选择自行开发移动应用这条路时,在必要的情况下,你可以调整BYOD规则,减少支持平台的种类以降低风险;如果这么做不可行,你也可以选择走浏览器架构解决方案这条路。以上这些做法也会带来另一种风险,那就是企业自己研发的应用今后可能成为服务灵活性的绊脚石,而SaaS服务商反而回避了责任,这显然不是一种进步。
好的JavaScript或者HTML5应用实践在图形用户接口方面有很好的灵活性表现,也能满足SaaS应用服务接口面临的不同需求,即使有时候需要增加新的特性或者领域。以上表现的关键是选择合适的浏览器。不是所有的浏览器都能对各种脚本以及新的HTML特性等提供良好的支持,因此出于灵活性的考虑,选择最能够支持你企业BYOD规则所涉及平台的浏览器非常重要。通过查看浏览器的更新日志,能大致了解该浏览器新特性增加的频率,也就能大致推测今后该浏览器服务商面对新特性做出应变的速度。
某些情况下,可以将SaaS服务商的接口同企业自身云端上应用的一些要素相结合。事实上,这么做其实就是在SaaS服务商那里安置一个前端程序,将服务商及企业各自的一些应用特性互相结合。这个新的SaaS服务层级可以在SaaS服务商那运行,或者有时候(至少能够确保)在另一个云端运行。但有一点需要注意,移动用户并不一定就使用SaaS应用服务,所以有时候在这个额外的服务层上去搜索某些信息就会出现问题。
IaaS或PaaS在灵活性方面的表现优于SaaS吗?
如果其他方法尝试下来都失败了,为了追求灵活性,用户可能选择使用IaaS(基础设施即服务)或PaaS(平台即服务)来代替SaaS。对用户来说,独立托管软件包和SaaS应用服务看上去差不多,事实上,可能所有通过云端提供的应用服务用户看来都像SaaS应用服务。因此,IT部门人员可以在云端为移动办公员工提供各种需要的软件包,通过这么做,创造出一种虚拟的、“自建”的SaaS应用服务。第三方应用也可能存在灵活性方面的问题,但是由于选择范围很广,并且很多第三方软件服务商愿意为移动用户个性化定制图形接口来解决这方面的问题。如果是开源软件包的话,企业还可以根据自己需要自行的去定制该软件。
那么哪种灵活性解决方案是最好的呢?自制应用?采用浏览器架构?或是“自建”SaaS?根据用户调查显示,一个使用RESTful用户接口的SaaS应用服务,在经过浏览器架构的定制化服务后,不但对各种情境能够做出良好应对,而且公司在应对的效率和速度方面也表现的最好。通过浏览器架构来接入移动应用,能最大化的实现定制服务,并减少针对应用调整升级作出应变的时间。因此,先尝试上面所说的方案,如果发现浏览器架构解决方案不能应对你企业所面临的问题时,再选择其他定制方案吧。