Software as a Service - A Guide to Transforming Your Software Product into a Service

Software as a Service – A Guide to Transforming Your Software Product into a ServiceThere is growing market demand for more economical and efficient enterprise applications to an ever-expanding global market. The combination of the ubiquitous Internet and the availability and legitimacy of open source software creates substantial opportunities and economies for software vendors to deliver Software as a Service (SaaS). Software as a Service is a model in which the software vendor provides an Internet-hosted version of their application (in-house or at a managed 3rd party site) accessed by customers from the website and paid for on a per-use, per-project, or subscription basis.

The SaaS model offers significant benefits to software vendors and their customers. The SaaS model offers customers cost-effective subscription-based or per-use pricing, eliminating the need for substantial capital outlays to purchase perpetual software licenses. It also eliminates the initial outlay and ongoing costs and risks of installing, supporting, and maintaining in-house hardware and the associated IT staff. In addition, user access and application performance can be dramatically improved with Internet-based, on-demand, 24×7 systems. Finally, the SaaS model opens new markets to software vendors.

Established software companies can broaden their market reach by offering SaaS solutions to small and midsized enterprises. Other benefits include the financial advantages of predictable recurring revenue streams and strengthened relationships with customers. In addition, software vendors migrating to or developing products from the outset as SaaS offerings will have a significant competitive advantage when competing with traditional license-model vendors.

Summary show

Realizing the benefits of the SaaS model may require fundamental changes to a software vendor’s business model, software architecture and operational structure. This white paper provides an overview of the issues associated with the software application itself and the development considerations associated with moving to a SaaS model. Time is of the essence. As with any new business model, the rewards often go to early market entrants. Accelerating the time-to-market of your software deployment is critical to your business success. Outsourcing product modifications to implement your SaaS offering, with the assistance of an expert services team, and engaging an optimal on-demand service delivery firm will accelerate your time-to-market and insure an on-time, on-budget, on-scope implementation.

The Challenge of Transforming Your Software

While there are a multitude of benefits in providing Software as a Service, traditional software companies may face challenges in moving to this model. First, your software must be web-enabled with all functions carried out by the user using a web browser. Second, if you have a client-server application, you must replace the functionality implemented in the client with HTML and possibly other technologies (XML, Java, etc.) that a web browser can display over the Internet.

Next, in order to gain operational efficiency, your software needs to be multi-instance. You move from single-instance to multi-instance by loading multiple copies of your software on a single set of servers. Multi-instance enables you to share the cost of a server across multiple customers. Additional productivity enhancements and economies may be gained by moving to multi-tenant SaaS or replacing proprietary commercial software with open source software. Finally, Webb services provide an opportunity for integration with other applications and data flows.

Single Instance Applications

Traditional client/server applications are single instance. They require software to be installed on the user’s computer to carry out computations and provide functionality. Clients often implement highly interactive features and enable the user to manipulate large amounts of data. This can be very difficult to implement in a traditional HTML, request/reply web application interface that requires frequent page refreshes. Migrating from client/server to an Internet-based SaaS model is highly dependent on your specific application.

Today, new Rich Internet Application (RIA) technology is available from Macromedia, Laszlo System,s and others, giving web applications the look-and-feel and functionality of a desktop application or client. In addition, RIA requires little or no software to be installed on the user’s client computer. The most that are needed is a small browser plug-in or Java applet. This fundamental change to the user interface converts your client /server application to a single-tenant web application.

Web applications may be single instance or multi-instance. A single-instance web application is typically installed on dedicated servers in the customer’s data center and used only internally, behind the firewall. Yourr software is configured to consume whatever system resources are needed and available on the computer at installation times. When a web application is offered as a service over the Internet, it should be hosted in a professional data center. This will minimize costs and delivery high quality service to your customers. If you have a single instance application and more than one customer, one approach is to install a new instance of your software on a dedicated server for each customer. This may work for a few customers or some big accounts, but it does not scale effectively for large numbers of customers. It also cannot be used for small and medium sized customers that cannot afford the set-up costs.

Moving from Single to Multiple Instances

An alternative to individual customer dedicated servers is to install multiple copies of your software on a single set of servers. This is called multi-instance. Multi-instance enables you to share the cost of a server across multiple customers. Most business applications use a database and each additional copy of the software installed requires a new database instance as well. Installing multiple copies of your software on one set of servers may not be as easy as it sounds. Installation procedures need to be modified so that each instance is installed without disrupting resource allocation or the security of the other previously installed copies of the software. In addition, there is a limit to the number of instances that can be installed, and eventually, system resources will be consumed. System resources include shared memory, process semaphores, and other internal operating system parameters. So the question becomes, “How many copies of your software can you install on a server?”

Obviously, you can keep installing instances of your software until resources are exhausted. However, you must also consider the performance of the system under load by users. Typically there are a maximum number of simultaneous users your software must support and minimum performance or response time requirements that must be met to satisfy customer commitments. Therefore, an accurate answer to the “How many copies of your software can you install on a server?” question is derived by testing the software as you add additional instances.

This is best done with automated testing software tools that can simulate the desired number of users placing a load on the system. The testing process is to determine the optimal number of instances and the resulting performance. This is accomplished by installing additional instances of your application, and carefully monitoring system resources and running user load tests using variable traffic modeling to determine the point at which returns diminish. This process of maximizing the number of instances on the servers can take one to three weeks depending on the size and complexity of your system, the quality of your installation process, whether you have already created automated user load testing scripts and procedures.

Minor code changes may be needed to move to multi-instance. For example, if your application reads and writes a file with a hard-coded filename and location on the disk, then the file must be created in different locations for each instance to avoid conflicts between each instance. These problems will be discovered and changes will need to be made during the one to three weeks.

Next Steps – Improving Functionality and Reducing Costs

Once your software is running effectively as a multi-instance SaaS application, you may want to pursue a multi-tenant architecture. In a single instance, multi-tenant architecture, multiple customers share a single instance of your software. Migration from multi-instance to multi-tenant can be a significant project and may even require a rewrite of your application from the ground up. The efficiencies gained in moving to multi-tenancy need to be closely examined. You might find your resources better spent in other ways.

Another possible step would be to focus on driving costs out of your model. Many applications have dependencies on expensive proprietary databases and/or middleware. Significant savings can be realized by migrating to lower-cost or open-source alternatives. An investment here might provide significant savings in operating costs that would be transparent to your end users and very beneficial to your bottom line.

You might also consider adding web services for inter-process communications. This will be particularly appealing if your application is part of a workflow with information passing-to or gathering-from another application. Again, designing with web services in mind will minimize long-term integration requirements.

A Single Instance, Multi-Tenant Web Application

Software companies have created web applications for over ten years now. These are often installed on the Intranet of a customer and only used internally, behind the firewall. Just one customer uses this single instance of the software. This is both single-instance and single-tenant. You saw above how you can install and test your software to make it multi-instance — having multiple copies running on one server. However, each copy is a single-tenant web application. Single-tenant web applications can be modified to support multiple customer tenants on the same instance. Multi-tenant web applications minimize the amount of hardware needed to support multiple customers. Also, customers can self-provision their use of your software by signing up for an account and entering payment information. This minimizes, and often eliminates, the amount of support needed to set up a new customer.

One of the modifications to support multi-tenant is the creation of a user interface for user provisioning of accounts in the system. Another modification, depending on the requirements for integration with other enterprise systems, is an LDAP interface for convenient provisioning and administering of user accounts. Modern database technology can enable quick duplication of the data model so each customer has its own copy of each table in the database. This is an elegant way to keep customer data separate when stored in the single database instance used for the service.

Templates for configuration of the software should be provided to accelerate customization and adoption of the service by new customers. Templates support various scenarios of system usage by customers. A system management dashboard showing system use by all tenants may be required. A mechanism must be available to measure the system used for billing purposes and monitoring system load. Administrative accounts for customer support purposes may also need to be implemented. Finally, it may be necessary to enhance the reliability of the back-end, using database technology to implement parallel servers at physically distant locations, to ensure constant up time during periods of natural or man-made disasters.

Maintaining Performance of Your Multi-Tenant Web Application

Multi-tenant applications must deal with several issues that are not as pronounced in single-tenant and client/server systems. First, because multi-tenant systems are available over the public Internet, usage may be unpredictable. Therefore, demand planning must be done more carefully. Second, the systems should be instrumented to detect increasing usage so additional hardware and bandwidth are provided to maintain service levels.

Driving Down Costs by Moving to Open Source

Many software developers are agnostic about the application server and database software used by their applications. The customer often dictates these choices. If your customers want to use Oracle as the database, then you must support this popular choice. Your software must have modules to support each database technically. Business-wise, you pass along the database license costs to the end custome if they do not already own a license. But what database should you choose for your software when it is offered as a service? There may not be a need for the technical features of an expensive commercial database.

Moreover, the economics of offering your software as a service may preclude the expense of a commercial database license fee. Therefore, many companies converting their software to a service will choose one of the low or no-cost open-source databases available today. These database choices are now widely used and robust. Advanced features such as redundant clustering and automated backup capabilities rival those of commercial databases. If your application does not yet support one of these databases, a few technical issues need to be overcome. The format and syntax of most SQL used to access and manipulate data in a database is standard. However, almost every database vendor extends SQL and many applications use these extensions, such as special functions to modify and compare data. There can be many variations in how each database vendor treats cursors, triggers, data types and package variables. If you use SQL extensions in your application, you will need to recode these SQL statements to work with the target open-source database.

Migration to on-demand delivery models works cohesively with bootstrapped technology deployment and investment. Even if the open source database software does not have all the features you want to have or if they run a little slower, you may have no choice economically when you first start offering your software as a service. It may not make financial sense for you to invest tens of thousands of dollars in a commercial database license while you can only charge a few hundred dollars per subscriber. Over time, as your subscriber base grows, you may choose to switch to the commercial database. Until you can afford it or activity levels grow to high levels, open source database solutions may be your only practical solution.

Another relatively expensive part of your software is the license required for a commercial Java application server. This is another category of software where several open-source options exist. Generally, conversion over to an open-source application server is relatively straightforward. All must comply with the Java 2 Enterprise Edition (J2EE) specification, and your code should not need any modifications. However, there are differences in how you install your code on the application server. The installation and set up process is well documented for all open-source application servers. You must modify your installation process to accommodate the requirements of the application server you use.