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 demand for more economical and efficient enterprise applications for an ever-expanding global market. Combining 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 - A Guide to Transforming Your Software Product into a Service 1

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 provides customers with 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 small and mid-sized enterprises SaaS solutions. Other benefits include the financial advantages of predictable recurring revenue streams and strengthened customer relationships. 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.


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 and the development considerations related to moving to a SaaS model. Time is of the essence. As with any new business model, early market entrants often receive rewards. 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 ensure an on-time, on-budget, on-scope implementation.

The Challenge of Transforming Your Software

While there are many 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, 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 various 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 allow integration with other applications and data flows.

Single Instance Applications

Traditional client/server applications are single instances. They require Software to be installed on the user’s computer to perform computations and provide functionality. Clients often implement highly interactive features, enabling the user to manipulate large amounts of data. This can be difficult to implement in a traditional HTML request/reply web application interface requiring frequent page refreshes. Migrating from client/server to an Internet-based SaaS model depends on your specific application.

Today, new Rich Internet Application (RIA) technology is available from Macromedia, Laszlo System, 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 is 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 deliver 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 many customers. It also cannot be used for small and medium-sized customers who 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 various customers. Most business applications use a database, and each additional copy of the Software installed requires a new database instance. Installing multiple copies of your Software on one set of servers may not be as easy. Installation procedures must be modified so that each model 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?”

You can keep installing instances of your Software until resources are exhausted. However, you must also consider the system’s performance under load by users. Typically, your Software must support a maximum number of simultaneous users, and minimum version or response time requirements 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?” 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 examples of your application, carefully monitoring system resources, and running user load tests using variable traffic modeling to determine the point at which returns diminish. 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, and 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, suppose your application reads and writes a file with a hard-coded filename and location on the disk. The file must be created in different areas for each instance to avoid conflicts between each model. These problems will be discovered, and changes must be made during the next one to three weeks.

Next Steps – Improving Functionality and Reducing Costs

Once your Software runs effectively as a multi-instance SaaS application, you may want to pursue a multi-tenant architecture. Multiple customers share a single example of your Software in a single instance, multi-tenant architecture. 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 middleware. Significant savings can be realized by migrating to lower-cost or open-source alternatives. An investment here might provide substantial savings in operating costs that would be transparent to your end users and 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 a customer’s Intranet 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 various 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 creating 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 user accounts.

Modern database technology can enable quick duplication of the data model so each customer has a 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 the 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 uptime during natural or artificial disasters.

Maintaining the Performance of Your Multi-Tenant Web Application

Multi-tenant applications must deal with several issues 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 use so additional hardware and bandwidth are provided to maintain service levels.

Roberto Brock
the authorRoberto Brock
Snowboarder, traveler, DJ, Swiss design-head and HTML & CSS lover. Doing at the nexus of art and purpose to develop visual solutions that inform and persuade. I'm a designer and this is my work. Introvert. Coffee evangelist. Web buff. Extreme twitter advocate. Avid reader. Troublemaker.