Though SaaS as a concept has been around for quite sometime now, its applications and architectural models are still evolving. There are various architectural approaches followed by SaaS application providers. Four of them are detailed below:
The first type is quite similar to traditional model of software delivery where each customer accesses the customized version of the software. There are various instances of the same application running on the servers. All users within an organization connect to a single instance of the application which is different from any other instance accessed by any other organization.
Most of the traditional client-server application providers are looking at this architectural model to enter the Saas market with their offerings. This architectural model would help them make the shift with little development effort and without re-architecting the application from scratch. This model does not offer the full benefits of a mature SaaS application, but it helps the vendors reduce costs by reusing portions of earlier code base and consolidating hardware resources. This would also help them in entering the SaaS market quickly with their existing application suite. The software administration still remains troublesome since any upgradation needs to be done for all the customized instances.
The second model is one where the customers access their own instance of the same application which is configured to suit individual needs. The requirements are customized in TYPE I whereas the requirements are configured in TYPE II. Detailed configuration options are provided to the customers that allow changes in the way application looks/ behaves to its users. Each instance used by each customer remains isolated from others and hence requires the same amount of hardware resource space as that of TYPE I.
Architecturally there is a single code base for all customers, which reduces the software service costs for the provider. Any upgradation is easily provided to all customers. However, shifting from traditional model requires lot more developmental work.
The third model is one where every customer accesses a single instance of the application, with metadata which is configured to give a unique experience to each user. Security policies and authorization procedures ensure that the information provided by each customer remains isolated from that of others. The end-user has no indication about the multi-tenancy of the data which occurs at the back end.
The vendor saves hardware costs since there is only one instance of the application running and hence not much storage space is required on the servers. Scalability is an issue since the server space and database space is shared among all users. As the number of users increases, upgradation of hardware resources becomes troublesome.
This is almost a fully mature model of architecture. The customers access identical instances with their databases separated and configured metadata to provide a unique user experience. The scalability issues of TYPE III are handled easily since the hardware and the number of instances can easily be increased at the back end to match the demand. Upgradation is also easy to roll out. Architecturally this is the most demanding of all the four. Cloud servers or Load-balancing servers are used by vendors to minimizze their costs.
Though ideally all SaaS vendors should seek to achieve TYPE IV, it is not always the case. The customer base and their data needs, type and complexity of applications serviced, costs and resources involved, developmental effort and time required and various other factors determine the architectural model followed by the vendors.