The Future of Software Delivery

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

The Future of Software Delivery: a delivery model that can help transform the legacy software to SaaS


SaaS is a concept that is here to stay and will have a significant upshot on how people use and build the software. This paper will help reader to establish problems and issues with the legacy software and discusses the benefits SaaS possesses over them. Moreover, the paper discusses gearshift required for the current software vendors to develop the SaaS based software. It includes a technique of transformation to SaaS based software, modeled on the SOA architecture. This paper illustrates the steps to transform to SOA as part of the technique. Whilst taking KOHA open source library management system' as sample, the paper has proposed an architecture that well suits the software architectural requirements of this system and is well suited for any software containing any of such functionality. In a nutshell, this article focuses on 'The technique to make SaaS an alternate to the legacy software'.

Keywords: Software as a Service (SaaS), Service Oriented Architecture (SOA), WSDL, Maturity Level, Transformation, Multi-Tenancy.3GL/4GL (GL - generation language)


The recent years has made companies think over cutting costs at large; mostly due to recession. IT department at any firm requires the good chunk of budget every year for licensing and updating software. Traditional software usually has a high tag to acquire & then its maintenance and license renewal is like an additional cost and some times greater than the actual product's cost. There is a time when software is no longer efficient without upgrades and then either upgrading or buying a new solution becomes compulsory and that again has a cost to acquire. [1] IT assets developed years ago to perform business operations and were termed as 'software' is what we call legacy software in the modern IT world. Carrying out useful operations, these IT assets are the one we run our critical business operations on. [2]

Decade of 90's, the 'Internet' conception took pace and connectivity throughout the planet in terms of speed and availability increased at large. Organizations started to espouse computerized procedures and connectivity over the internet. [3] With so many areas to address, computer industry started getting gigantic. Regular augment in the licensing costs of software made people think of a better alternate. This notorious increase of organization's IT budget fueled the notion of SaaS.

As a new paradigm for the software industry, SaaS will ease up the IT budget as organizations no longer need to buy an on-premise application rather host it on web, as a service. [3] Organizations would prefer to run a service over the web rather purchasing a license and installing the same on premise indulging more cost and time. We can't deem SaaS as another IT fad rather it has the potential to pave way for the all-new software industry. [4]

  • We believe that SaaS is a concept that is here to stay and will have a significant impact on the current software industry. Moreover, it will have a significant upshot on how people use and build the software. Highlighting some of the foremost flaws in the contemporary software delivery model, in this paper, we have proposed a technique to transform an on-premise legacy system to SaaS based system. Our proposed technique has essence of 'Software as a Service (SOA)' as a base architecture.

    We have researched the feasibility of SaaS being able to compete with the conventional software and the gearshift required for the current software vendors to develop the SaaS based software. Moreover, techniques and transformation process to shift to SaaS whilst briefly discussing the maturity levels of SaaS are also the part of the paper. To accomplish our research, first we explored all four levels of SaaS and choose the best suitable level for our sample legacy system.

    For the very reason, legacy software 'Library Management System' (KOHA - open source LMS, being used in Parliamentarian Library of Kenya) was studied as a sample. The technique is proposed for the below stated features:

    • Cataloguing, Reports, Searching, Transactions

    Hence any system comprising of such functionalities will have somewhat same procedure of transformation to SaaS based system.


    This section of the paper will form the basis of the reader to digest the technique. Discussing the tools used for carrying out the research, the paper highlights some basic features of those tools as an add-on.

    2.1. Selecting a Proper Legacy Software (LMS)

    For our research, there was a need to pick a mock-up system that could be meticulously studied and could be used as a model for the transformation process. A solution that was open source (available for free), and possessed the functionality that is most common in the legacy systems, we had an obvious choice to choose KOHA library management system.

    Developed in New Zealand, KOHA is first of its kind open source library management system. Blend of number of basic features in collaboration with some advanced ones, KOHA has evolved in a due course since its launch in 1999. The system was developed on 'PERL' hence most suitable to run on Linux although it can work on Microsoft Windows as well. Implemented in parliamentarian library of Kenya, this LMS has the following features:     

    • Web 2.0 based User Interface with customizable search
    • Transaction management
    • Issue/Reserve/Return
    • Cataloging
    • Member management
    • Open source / No licensing fee [5]

    2.2. Exploring SaaS Maturity Levels

    Before moving on with the SaaS transformation process, it is of utmost importance to build basic understanding of different SaaS maturity levels. The different levels of maturity are the basic building block of complexity or simplicity within the system. Figure 1 is the graphical illustration of basic differences between the levels. The core difference between these levels is the "number of instances" required for one application/user.

    2.2.1. SaaS Level 1

    It's the basic level of maturity. Every customer in this level has its own instance of the application running on the host server and the instance is specific to the customer. Customization thorough configuration is not supported in this model. [6]

  • Every customer has its own instance of application

  • Least development efforts required for moving on this architecture

  • Reduces hardware cost & improve performance

    2.2.2. SaaS Level 2

    In this level each customer has its own instance of the application but application is not customer specific rather customizations are made through configurations instead of having different code for each customer. [6]

    2.2.3 SaaS Level 3

    In this level, the vendor, instead of hosting a separate instance of the application for each customer, hosts a single instance and each customer uses that instance. UI is customizable per tenant. The only problem in this level is that it is not scalable. [6]

    2.2.4. SaaS Level 4

    In this level, the vendor hosts multiple customers on a load-balanced farm of identical instances, with each customer's data being kept separate. This level is more like level 3 but now supports scalability. [6]

    • One tenant and multiple instance instances of that tenant to balance the load
    • Scalable and auto load balancer - you can either increase or decrease servers looking at the requirement, but it won't have any impact on the actual application architecture or functionality
    • Pharming possible with this architecture

    2.3. Service Oriented Architecture

    A set of web based services that coordinate with other required services to perform certain business operation is termed as service oriented architecture. The rationale of shifting to this architecture is to make a service/functionality available for all authorize personnel as and when required but it has a price to it. We need a solution to simplify business processes with a minimum of effort and a maximum of performance. The problem is that for a service, complexity in terms of user experience will increase i.e. number of inputs from a user. [7] Below is the diagrammatic view of basic SOA architecture.

    3. RESULTS

    This section consists of the technique that has been proposed. Based on the best of our knowledge about the topic, the proposed technique is yet another technique to transform to SaaS based software on the service oriented architecture.

    3.1. Decide the architecture for SaaS application

    First tread in converting a legacy system to SaaS entails to decide upon architecture of the application. SaaS being a delivery model is not dependent on how the application is structured. It is important for the application to be loosely coupled to increase the efficiency of the system.

    Recent developments in SOA (Service Oriented Architecture) has been highlighted the most; being loosely coupled, services work independently and provides XML output which gives platform independency. Encompassed the same in mind, we have used SOA as base architecture for KOHA library management system to transform to SaaS Maturity Level -1.

    3.2. Evaluate the legacy code block for reusability

    The next step is to trace out the functionalities to be transformed. On hand legacy code of these functionalities can be appraised for its reusability; so as to ensure if the on hand code is object oriented and built on at least 3GL or 4GL. A code block built on the predecessor language would not work with the architecture.

    Mentioned in the figure 3 are the functionalities that were ripped off from the original code (one by one), and were checked separately i.e. the code block of the cataloging was located from the source code of KOHA. Once that code block was located, the module was estranged and tested with different inputs and output. This tread is to ensure its working condition for transformation process to SaaS.

    Similarly, all the functionalities will undergo this process and will get tested. Due to certain limitation we cannot test the actual code to ensure that the output is correct. KOHA, being one of the most popular open source library management systems, should work flawlessly in normal condition. Assuming these block of codes work as desired, we moved on with the transformation process to the next step.

    3.3. Wrapping the legacy code

    Once we know the extracted legacy code block is in good working conditions, the next step to wrap it up. The goal of the wrapping process is to provide the component extracted from the legacy code with a WSDL interface. The technique used is to transform each entry into a method and to transform each parameter into an XML data element.

    Method is created for that block of code with an interface that can work with the WSDL. For example if we consider a function of search, it will accept the search query from the WSDL interface and return the result in XML based format.

    The pseudo code illustrates the point further

    search (searchquery)


    // search book from available books

    return books;


    result would look like



    Artifical Intelligence



    John mcarthy





    World Wide Web



    Tim Burners Lee



    This XML based output can be then displayed on interface as desired.

    3.4. Identification of core-business processes

    Once the functions have been wrapped they need to be grouped according to business processes. Functionalities will be grouped to form a business process so as to be accessible as a service.

    For example Issue, Reserve, Return, Fine calculation is grouped to Transactions, and transactions service will provide all of the above functionalities. Services that we have identified for KOHA software are transaction, cataloging, reports and search.

    3.5. Transforming Web services as a process

    When business processes have been indentified, techniques are clustered together based on these processes. Services are deployed according to the business processes identified in the previous process. To implement the functionalities, 4 services must be initiated; transaction, search, reports & cataloging. This step completes 80% of the work required to transform legacy software to SaaS. At this stage, the desired application has been ported to Service Oriented Architecture (SOA).

    Web Services offered within the framework of a Service Oriented Architecture promise to make applications more flexible, easier to compose and cheaper to develop. In this paper it has been demonstrated how legacy code can be reused to help construct such web services. It would be unwise to ignore the vast amount of proven legacy software available within corporations and public administrations, when migrating to service oriented architecture.

    3.6. Multi-tenancy model

    SaaS Level - 1 as discussed above requires client to have separate instances of the application and database. With web-enabled applications where instances are already separated, there is a need to separate the database. With the below model, each customer will have its own database.

    3.7. Resolving the tenancy

    One of the key features of SaaS is multi-tenancy support with multi user option. To resolve the concern of login for both, we can use extended login dialog where user type user id, password and company name. Once user have logged in, this information can be captured and stored for later use during the same session. The other approach could be deploying an agent within the service that automatically identifies the user and redirect it to the desired services.

    3.8. Deployment

    Final tread is to deploy the application once services have been deployed and multi-tenancy is resolved. The only thing left was to have multiple instances for databases for each tenant.

    This delivery model provides the solution as SaaS Level -1. We could move to a further level as well, but moving a system as small as a library management system to advanced maturity levels of SaaS would only add on the complexity of the system in terms of deployment and cost.


    The proposed technique might not be the most proficient one, but it's a simple solution to uplift the legacy system to SaaS. This technique provides an alternate delivery model for the legacy software industry. The treads defined above, if followed accordingly, can lead to achieve basic maturity level of SaaS. Any library management system possessing these functionalities can fully incorporate this structure as a mature solution to their current software infrastructure. Moreover, any IT solution offering any such functionality will be able to take advantage of this proposed model. There might be companies desiring to deploy SaaS based IT solution without switching to service oriented architecture (SOA) but switching to SOA before going further will ease up the development process and will set a pace for moving with the new architecture.

    The proposed technique was to transform to level 1 of SaaS so as to make implementation and development process simple and effective. It could be transformed to other maturity levels also depending on the target size and user acceptance.

    SaaS can definitely replace legacy softwares, as it has all the benefits of legacy software with lower cost and hardware requirement. There is no licensing or upgrade fee, just subscriptions fees for the time the service is being first used. Moreover, it opens a new door for vendors to provide such service that reduces the agony of cost for the companies; it is a complete new domain and soon software will be delivered via a service instead of Software as a Product (SaaP).


    The proposed technique in this paper is to transform legacy software to SaaS using SOA as the base architecture. Moreover, the technique is proposed based on the study of an open source library management system KOHA. It might not work for software that does not possess similar functionality but can provide essential knowledge of the transformation process.

    The technique proposed in this paper is to transform legacy software to maturity level-1 of SaaS. We can move to advanced levels of SaaS as well but that would entail more cost and complexity to the system.


    With the courtesy and enduring guidance of our research supervisor Mr. Zeeshan Arshad, the chaotic process of conducting a research got simple and easy for us.  Moreover, for the technical assistance and support Mr. Asim Riaz, our faculty advisor was there to steer us and pave our way to accomplish this study. We are highly obliged for their time and efforts they put-in for us. 


    [1]  (July, 2008). "A Brief History of SaaS".

    [2] Faisal Bin Bashir, (August, 1998). "What is Legacy Software?". Retrieved January 14, 2010, from

    [3] Nitu (December, 2005). "Configurability in SaaS (Software as a Service) Applications".

    [4] (January, 2009). "Software as a Service". Retrieved January 14, 2010, from

    [5] (January, 2009). "About KOHA". Retrieved January 14, 2010, from

    [6] Gianpaolo, (January, 2009). "SaaS Simple Maturity Levels". Retrieved January 14, 2010, from

    [7] Harry M. Sneed (December, 2005)."Wrapping Legacy Software for Reuse in a SOA".

    [8] Manuel Permuy, (September, 2004). "Inside Trivadis Framework". Retrieved January 14, 2010, from