Delivering Portal and CMS as Service

There are enough statistics floating around that show big numbers for Software as a Service (SaaS).  Many people are interested in experimenting with SaaS because of promised cost savings.

So what does it take to deliver a content application (your Portal, CMS etc) as a service? There is a very nice aricle on CMS Watch that explains various things associated with SaaS.

There are three major things that get impacted. They are related to:

• Business Model: Ownership/Licensing of software and hardware, the fact that you can service the flat part of the bell curve (long tail?) and reduced costs among others
• Technology: The application architecture and issues related to multi-tenancy
• Operations: How is the service managed, monitored and administered and issues related to data center and infrastructure

In this series of posts, i’ll touch upon the Technology aspect as it relates to content technologies and will probably post about the other aspects in future posts.

The basic Technology issue is that how do you have an application – Portal, CMS that can serve multiple clients (Tenants) using same infrastructure (portal server, database, application server, content management system and so on). So if you are considering using services of a SaaS player, consider the following issues. Some of these are also valid if you were to develop an application that could serve multiple clients.

1. Different Portal for each Tenant: You need a completely different portal for each client. This basically means different look and feel, different set of users, different templates and so on. Some of the ways to handle this are:
   • Some portal servers like IBM websphere let you define virtual portals.A virtual portal essentially lets you create independent portals using the same instance of portal server. This ability is also there in Liferay. Alfresco’s upcoming version also lets you have multiple tenants.
   • Most portal servers let you define communities. Although this is not as good as a virtual portal when it comes to multi-tenancy, it could be used to create portals for different user communities each with their own look and feel as well as users.
   • In order for you to have a custom URL for each portal, you will need the ability to map portal server’s ugly URLs to more user friendly URLs. Some portal servers let you define custom URLs while others don’t and you would need to do some re-write magic to achieve this along with creating virtual hosts on the web server.
   • Since each portal will have it’s own presentation layer, you need the ability to manipulate the look and feel remotely because typically it will not be able to login to the console in this model. You should be able to change the theme, skin or whatever mechanism the portal provides via a web based interface.

Okay so it is getting longer than I expected. So i’ll split the issues and post them later.