This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
2. - Mobile applications alter IT's course of action: Read more in this section
- The pros of HTML5 hybrid native applications
- Building the server side of mobility applications
- Will JD Edwards and Oracle mobile apps change the future of business?
- Achieving mobile SaaS apps agility
- Mobile applications offered by SaaS provider
- Why are more enterprises developing mobile apps for SaaS?
Explore other sections in this guide:
Software as a Service (SaaS) applications have to track the needs of the workers they support, but they don't always do that successfully. According to enterprises, mobile SaaS applications change for one of the following reasons, in increasing order of likelihood: changes to regulations governing the application, changes in mobile device policy, changes in worker activities and changes in mobile OS features. There is no perfect strategy for making mobile SaaS apps Agile with so many drivers of change, but picking the right SaaS provider, customizing the SaaS service for mobile use or even creating your own SaaS can help.
Evaluating SaaS agility
Whatever forces drive mobile application users and their SaaS providers in different directions, the ability of a SaaS provider to respond to regulatory changes that impact an application is a key indicator of their determination to track the market. One of the questions every SaaS evaluator needs to ask is how rapidly the application has accommodated changes driven by regulations. A response measured in months will almost certainly create issues with regulators, and it also suggests that the provider isn't able to change the application quickly. That same inertia will likely impact the SaaS provider's response to other demands for change, so it may be wise to pick a different provider.
Every SaaS evaluator needs to ask how rapidly the SaaS application has accommodated changes driven by regulations.
A careful review of provider application programming interface (API) options for SaaS should also be included in a provider assessment. APIs are critical because users who have SaaS problems with handset bring you own device (BYOD) policy changes, handset OS changes or work practice changes are most often users who directly employ mobile apps from SaaS providers. These apps are almost always platform-specific and so will always present challenges when the platforms change, and they typically can't be changed by the users themselves. The obvious solution is to avoid consuming SaaS via provider-supplied mobile apps, and that can be done either by developing mobile apps for SaaS services in-house or replacing app-based SaaS services with browser-based services.
The most critical technical issue in supporting Agile mobile SaaS applications via either of these mechanisms is the APIs exposed by the SaaS provider. Most IT pros know that RESTful APIs are the easiest to work with, particularly where development will be done by teams more familiar with Web development than with programming languages such as Java or C++. Ideally, a SaaS provider should offer the option of RESTful APIs, SOA/SOAP APIs and apps, but for optimum agility, it's the RESTful APIs that are critical; other options may not work with all mobile devices.
DIY SaaS apps assure agility
It's fairly easy to develop internal apps for RESTful SaaS APIs, and in fact, most of the multi-platform development tools now available for mobile devices support this type of interface. In most cases, one of these platforms will offer the best option for writing your own mobile apps to increase application agility, but to ensure that new platforms or platform changes will be quickly supported, get the release data on how past platforms and changes have been accommodated by the tool provider. To reduce risk, it may be necessary to tune BYOD policies to limit the number of different platforms that will be supported if you take the build-your-own-app route, and if that's not possible, it may be necessary to take the browser path. The risk here is that your own organization's app development becomes the impediment to change, not the SaaS provider, and that's not progress.
In some cases, it may be possible to augment a SaaS provider's normal interfaces with your own cloud-hosted application elements. In effect, what you are doing is writing a front end to the SaaS provider's services, incorporating their features and some of your own. This new SaaS layer may be hosted on the SaaS provider's own service or (sometimes, at least) on a different cloud. Be wary here of issues with problem isolation and determination; the mobile users won't actually be using the SaaS service, and so it may be hard to track issues through the extra layer.
Is IaaS or PaaS agility better than SaaS?
When all else fails, users who demand application agility may have to achieve it through the replacement of SaaS services by hosted applications on Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) services. A hosted independent software package looks to its users like SaaS, largely because all cloud applications look to users like SaaS. Thus, an IT staff can create virtual, or "Self-SaaS," for mobile workers by deploying any suitable software package in the cloud. Third-party applications may still have agility issues, but there are more providers to choose from, and many will offer some flexibility in customizing the GUI for mobile workers. If an open source package is available, there's an option to customize the package yourself to accommodate changes.
Which agility strategy is best: self-developed apps, browser-based or Self-SaaS? Users report that while browser-based customization of SaaS services via RESTful APIs can support the types of changes needed, they expose companies to the least effort and accommodate changes fastest. A surprising level of customization can be built around browser-based access to mobile apps, and this approach eliminates the delays in accommodating changes that app developers may introduce. Try this approach first, then, and save other forms of customization for situations where a browser mechanism won't serve business needs.