Application portability is always an issue in the cloud because competitive market changes can either create a new "best choice" or put a provider out of business. Most users accept that Infrastructure as a Service applications are fairly portable, and most realize thatPlatform as a Service application portability will depend on application features used.Software as a Service services are not typically considered in the portability discussion, because SaaS applications are owned by the provider and are not portable. In a strict sense, that is true, but portability planning can help users deal with pricing and business stability issues for SaaS providers, and can even help users migrate from a SaaS service back to a self-hosted version of the same application.
Ollie>> Completely agree and part of our original concept.
Third-party application and SaaS benefits
A Software as a Service (SaaS) app that is based on a provider's own custom software cannot be ported unless the provider creates the option, which will virtually never be the case. Thus, where portability is a concern, a SaaS prospect should first focus on providers who host third-party software rather than those who develop their own. The software developers likely make hosting arrangements with multiple providers, so portability of this form of SaaS is relatively easy. It's also possible to buy a copy of the software for local installation, so "self-hosting" is an option in cases of provider failure or the loss of software support.
Ollie>> Also completely agree, and why we chose Open Source solutions for ERP, CRM, Web Content Management, Portal, ESB and more. These solutions, being open source are COMPLETELY portable mitigating the risk for our subscribers.
The best sources for "portable SaaS" are the major providers (Microsoft, SAP, Oracle, etc.) of applications. Nearly all will offer SaaS, sign agreements with third parties for SaaS hosting or both. The key point is that wherever a SaaS service is built by hosting conventional application software, it's a good bet there will be multiple providers available offering the most popular options. Specialty vendors who offer vertical-market packages are less likely to attract multiple SaaS hosting providers, so a different approach will be needed for those.
Ollie>> Yes, and we also offer a full PaaS with Integration as a Service and Bring Your Own License such that any of these you may also want to integrated onto the O4BO platform can be done without worry.
Pros, cons of IaaS instead of SaaS
The second option for SaaS portability is "self SaaS," the licensing of a software package and hosting of the package on a cloud Infrastructure as a Service (IaaS) offering to create what appears to be SaaS. The value of this approach is that the resulting service is as portable as a machine image, which can increase competitive choices for hosting. The negative side is that unlike SaaS, self SaaS still exposes the user to the cost of the software and the support of the entire software stack from operating system to application. This means self SaaS is an option for creating a cloud version of a given application, but not for reaping the full benefits of SaaS.
Ollie>>Also completely agree, which is why we chose to host on the IBM SmartCloud Enterprise, where we retain the option for our subscribers to have their own images as needed and still retain portability and out Integration as a Service and Platform as a Service features.
DIY SaaS portability
Even these two options won't fully address SaaS portability issues. A growing number of users are integrating SaaS apps with other on-premises or cloud software to create orchestrated multi-component applications. One company combined Salesforce CRMservices with SaaS-hosted unified communications and collaboration to create a sales support application, for example. Here we have two SaaS components, and if either has to be changed, the whole sales support application is compromised.
Ollie>>Right on Tom! When you consider that O4BO is designed to service the SMB with little or no IT staff, we do all the heavy lifting for you and offer a Rapid Application Development PaaS, along with Infrastructure as a Service and Integration as a Service that includes a Context Aware Rules Engine and an Enterprise Service Bus for just about any customization needed and often without low level coding.
Portability planning … can even help users migrate from a SaaS service back to a self-hosted version of the same application.
One solution to this problem is proper selection of the application integration tool(s) used to build the higher-level application from its SaaS components. Many application front-end tools (Citrix, for example) allow users to customize the interfaces to the lower-level applications that provide data and processing. Changing a SaaS provider for one component means changing the integration definitions, but not the entire application. For this approach it's important to look for SaaS services that offer flexible application programming interfaces (APIs) that can be integrated easily. RESTful APIsare typically more easily integrated than service-oriented architecture/Simple Object Access Protocol APIs, for example.
Ollie>>Again right on Tom! When we integrate an application, we take the Event API for that application, wrap it in a Service Layer and integrate that API with our Context Aware Rules Engine that has Event Handlers for the ESB as well as Drools, jBPM and industry standards based Event Handlers including SOAP/REST and more.
When all else fails, SaaS integration and portability problems can be solved by customizing an application based on the SaaS APIs. A SaaS API appears to a developer like a distributed application component, and so it can be built into a program as such. To prevent this process from simply creating another portability risk, the best practice is to encapsulate access to all SaaS service APIs in a local class/object, and refer to that new object to access the service. That way, if it's necessary to change SaaS providers at some point, the local object can be modified to suit the API of the new provider.
Ollie>> Not only do we use a SOA component approach for our existing integrations but for any new integrations including external SaaS solutions like SF.com, NetSuite, Azure Apps, Google Apps, etc.
SaaS vendors fostering portability?
All integration and encapsulation strategies for SaaS portability depend on there being functional correspondence among the competing SaaS providers of a given application. Obviously, if one provider of a unified communications/collaboration service offers video sessions and the other does not, no amount of interface integration will make up for the lack of functionality. Not all functional differences are that obvious, though, so before undertaking a SaaS integration or encapsulation project, inventory the available service providers and ensure that you build applications based on features that have general support.
Ollie>>OR....choose a vendor that will do all this for you and perhaps already has done this.
Because SaaS services displace the largest amount of platform and infrastructure components, they offer the largest benefit case and are the most easily adopted by non-technical users.
Accommodating portability issues with SaaS is possible, but users must be aware that these accommodations will nearly always add to the cost of the project, reduce the field of SaaS providers available for consideration, and risk undermining some of the sources of SaaS savings. These disadvantages have to be weighed against the benefits of portability before any steps are taken, or the cure may be worse than the disease.
Ollie>>We are cost competitive with all the known SaaS vendors including SalesForce.com NetSuite.com and even the vendors of the Open Source solutions that offer hosted SaaS versions.
About the author:Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Follow us on Twitter at @CloudAppsTT.
Ollie>> See http://www.o4bo.com and follow us on twitter @O4BO