Customization: an enemy of SaaS? (part 1)
Today I shall examine the issue of Customization on a SaaS (focus on multi-Tenant) environment, where the SaaS application is a business application and not a tool. By the term “customization” I do not mean the Localization (e.g. regional settings per user, area-specific rules such as taxes, VAT etc.); for simplicity reasons, I shall assume that all Localization issues have been resolved and examine only various aspects of Customization.
This post intends to give IT managers and SaaS Buyers in general an idea of the possible challenges there may face when they “board the SaaS vehicle”.
In order to illustrate the issues, I have selected some quite common “Customization Requests” that SaaS Buyers raise (remember that we are talking about a business application):
Example #1: Functionality enhancements – part 1
When we are talking about high-end business applications, such as an accounting system, a sales & invoicing system, a retail banking system etc, we can assume that the Buyer will use this application for its Core Business Functions. Also, supposing that this Buyer is a leader or innovator or otherwise pioneer in his field, we can assume that he may present a series of a Change Requests that will significantly affect the SaaS system (in his effort to maintain the leadership and innovative thinking, in his market).
In this case, heavy customization will be required and this can only be done on a project basis: the software vendor or another consultant must work closely with the Buyer and build up a Project. We know how this is done with on-premise applications. But what about SaaS? After the analysis is complete the software vendor may find that the changes required are huge (this is not the main problem) and that they may conflict with other Tenants’ specifications (this is the problem). Consider the example where a warehouse system has a 3-level structure to define an Item in the Master Catalogue and a new Buyer requires that this is extended to 4 levels. What is the solution? You cannot stick to 3 but if you want to make it 4, then you should consider what will happen with the other Tenants. Will you enforce the new 4-level logic on them? Probably not. You most likely have to devise a way to make this 3/4-level structure, parametrical. So, each Tenant will be able to select whether he wishes his warehouse to work with 3 or 4 levels. This can be done, no doubt. All you need is good programmers and EXTRA MONEY. This is the catch. The Change Request of the new Tenant can be served but the cost is significantly higher than the customization of a presumed in-premise application!
Example #2: Functionality enhancements – part 2
Now, let’s assume that the previous Change Request, although complex and costly, has found its way through the “corridors” of the technical analysis and budget approval. The software vendor is now ready to start working and in a few days/weeks/months the Change will be delivered on the server. Right? Wrong! It is very probable that the vendor has more “heavy” requests like yours, in the pipeline. And it is very probable that he is pushed to deliver in short time by other Tenants, just like you push him! This may result in an endless cycle of Version Design & Control: The vendor will keep trying to fit all these big requests in a time schedule that doesn’t find you (or the other Buyers) in agreement. And so, your Change Request is postponed and pushed to the next release and, and, and…
The above gave you a couple of examples of how complex requests can a) cost more and b) be delivered late, in a SaaS model. Lesson learnt for Buyers: Try to rationalize your volume and complexity of Change Requests. Otherwise, seriously consider the in-premise delivery model.
There are other examples of Change Requests (of bigger or smaller complexity) that we shall tackle in a future post. If, however, you really need these Customizations, then there is another solution… Until then… keep your users on a tight leash (that didn’t sound that bad, did it?)
This post intends to give IT managers and SaaS Buyers in general an idea of the possible challenges there may face when they “board the SaaS vehicle”.
In order to illustrate the issues, I have selected some quite common “Customization Requests” that SaaS Buyers raise (remember that we are talking about a business application):
Example #1: Functionality enhancements – part 1
When we are talking about high-end business applications, such as an accounting system, a sales & invoicing system, a retail banking system etc, we can assume that the Buyer will use this application for its Core Business Functions. Also, supposing that this Buyer is a leader or innovator or otherwise pioneer in his field, we can assume that he may present a series of a Change Requests that will significantly affect the SaaS system (in his effort to maintain the leadership and innovative thinking, in his market).
In this case, heavy customization will be required and this can only be done on a project basis: the software vendor or another consultant must work closely with the Buyer and build up a Project. We know how this is done with on-premise applications. But what about SaaS? After the analysis is complete the software vendor may find that the changes required are huge (this is not the main problem) and that they may conflict with other Tenants’ specifications (this is the problem). Consider the example where a warehouse system has a 3-level structure to define an Item in the Master Catalogue and a new Buyer requires that this is extended to 4 levels. What is the solution? You cannot stick to 3 but if you want to make it 4, then you should consider what will happen with the other Tenants. Will you enforce the new 4-level logic on them? Probably not. You most likely have to devise a way to make this 3/4-level structure, parametrical. So, each Tenant will be able to select whether he wishes his warehouse to work with 3 or 4 levels. This can be done, no doubt. All you need is good programmers and EXTRA MONEY. This is the catch. The Change Request of the new Tenant can be served but the cost is significantly higher than the customization of a presumed in-premise application!
Example #2: Functionality enhancements – part 2
Now, let’s assume that the previous Change Request, although complex and costly, has found its way through the “corridors” of the technical analysis and budget approval. The software vendor is now ready to start working and in a few days/weeks/months the Change will be delivered on the server. Right? Wrong! It is very probable that the vendor has more “heavy” requests like yours, in the pipeline. And it is very probable that he is pushed to deliver in short time by other Tenants, just like you push him! This may result in an endless cycle of Version Design & Control: The vendor will keep trying to fit all these big requests in a time schedule that doesn’t find you (or the other Buyers) in agreement. And so, your Change Request is postponed and pushed to the next release and, and, and…
The above gave you a couple of examples of how complex requests can a) cost more and b) be delivered late, in a SaaS model. Lesson learnt for Buyers: Try to rationalize your volume and complexity of Change Requests. Otherwise, seriously consider the in-premise delivery model.
There are other examples of Change Requests (of bigger or smaller complexity) that we shall tackle in a future post. If, however, you really need these Customizations, then there is another solution… Until then… keep your users on a tight leash (that didn’t sound that bad, did it?)
great post, although not complete. I'm waiting for "part 2"
ReplyDeleteWaiting for part2 too
ReplyDeletethanks for your commitment
best
Stephan