Readiness for SAAS: Criteria and Considerations

Moving software to the cloud and having it available as a service involves consideration of a number of factors. Unless the software was initially conceived and designed to be offered through SAAS right from inception it is highly unlikely that it will be ready to be rolled out on the cloud without any changes. The most significant of these factors are as follows.

Architectural scalability. A software product may be made available on the cloud either as a logically single instance servicing a large number of users (who are either individual customers or members of an institutional customer), or as a number of separate instances in a virtualized environment. Either way, the technical architecture of the software has to enable scalability. It has to be clearly layered, and be able to handle large volumes of transactions and data (possibly Big Data) in a stateless manner. In addition the scalability has to extend into the infrastructure which has to cater to high reliability and availability, load balancing and global content distribution, depending on the nature of the product and how widely and unevenly dispersed its target user base is.

Multi-tenancy. One of the key differences between enterprise software that is installed locally for a single enterprise versus hosted on a cloud platform and made available to users of multiple enterprises is that the latter has to appear and operate as a dedicated instance for each enterprise even though it is not. Each enterprise customer will have its own identity, user interface, custom configurations, transactions and data, although all of this is actually enabled on shared instance(s) of the product.

Billing. Each customer may purchase their subscriptions at different times, select a different package of services, different subscription tenures, and some may even have specially negotiated custom deals. All of this requires dedicated automation for purchasing, usage monitoring and metering, invoicing, provisioning, cancellation, reporting, and so on, features which are usually not built into onsite-installed enterprise software.

Data storage and management. Database design and data storage and distribution are additional factor that need considering. SAAS application databases will typically need to store much larger volumes of data than locally-hosted software databases and so their design and selection has to take into account the need for partitioning, striping, sharding, and other considerations.

Product features and User Experience. SAAS software is usually meant to reach a much larger, possibly global user base. While the core business features of the software may be designed for common use, there may be a number of features that are desirable to certain user groups but not all. If the software is not already web-based, increased internationalization and localization may also be a necessity. Further, there may be user groups within user groups, such as departmental users within individual enterprises. There may also be customization of user experience, corporate colours and logos, and white labelling (depending on the business distribution model). Whatever it is, SAAS software release management is done centrally, and not for individual users, and so the planning of scope, inclusion and deprecation of features has to be take on a perspective that is practical to implement both from a technical or engineering viewpoint as well as a business management viewpoint.

Security. Whether the software is for enterprise use or personal use, security in the form of confidentiality, privacy, business continuity, and protection from external threats and theft is always a key concern of the buyer. When hosted on a SAAS platform with the bulk of the software, stored data and infrastructure is beyond the reach and control of the user, the burden of implementing security and controls across all layers of the SAAS software and infrastructure hardware in a manner that instils confidence rests with the vendor of the SAAS software. In addition, to these aspects of security, enterprises in certain industry sectors will also need support for compliance to various regulatory needs pertaining to data storage, security, portability, archiving and availability.

Infrastructure and Licensing. While some SAAS vendors may try use as much of their own infrastructure software and hardware, apart from their applications themselves, many will use third party hardware, software and services in order to complete their SAAS offerings. Apart from being able to scale easily, when third party infrastructure software components (in particular) are a part of a SAAS solution, their licensing models have to be facilitate and support the concept of being further offered to multiple users (enterprise or individual) across multiple servers across multiple geographies. While the standard licensing models of many open source platforms and technologies may permit this it is very likely that those of proprietary commercial software infrastructure components (such as databases) may not.

Support Operations. SAAS software requires the availability of a 24x7, central support organization for a wider range of issues than a locally-hosted software might need. At the same time, the SAAS software user experience and interfaces must also be designed for either a low need for support through extensive automation, or for the enablement of user self-service to the best extent possible, as the number and geographic spread of the user base may be too large to economically service through human intervention.