SaaS customisation is not dead
Rajesh Ranjan looks at where to draw the line between configuration and customisation in SaaS
Some have suggested that SaaS customisation is dead, or that it has taken another form and meaning. But we need to answer another equally pertinent question: what is the limit of configuration?
I am not talking about the so-called configuration for branding, colours or themes, but more about the changing behaviour of the product. This could be called a customisation versus configuration debate, but there are wider issues to be addressed.
Let us look at the evolution of an idea into a SaaS product.
We must appreciate the basic principle of any offering. This is no different in the SaaS world: it must solve a business problem. This is more easily said than done and means innovation, technique, domain knowledge and engineering are required. The core of the business problem usually remains constant, though it is not easy to define. However, once defined, the solution can be derived.
Once the solution is found, it must be remembered that just one product must cater to a variety of customers. It is here that generalisation comes into play. The solution needs to be productised. This phase defines how a SaaS product is going to behave, and it involves detailed design and engineering.
A certain amount of business comes with customer-specific requirements that cannot be overlooked. Perhaps a particular customer is looking for a specific feature that is not available in the core product, and the customer is willing to pay a premium. Or maybe a customer that is important to the business has needs specific to location or vertical market. Here, the issue of customisation versus configuration comes into play, meaning differential pricing mechanisms must be worked out.
Where do you stop being flexible and configurable? After all, SaaS is a business model and core products will soon become a commodity, so where are the differentiators? Can one product really fit all, or do we need different variants? What if a large and important customer asks for additional features or the customisation of a feature?
These are just some of the questions that need to be addressed before a decision can be made on where configuration stops and customisation begins. I have read that configuration is UI whereas customisation is code. Is this applicable in SaaS products?
To have a decent SaaS product, it is important to look at this aspect.
Time to market can be critical, too. While the core product is being completed and announced, some work may be required on the SaaS product so it can be extended on a test basis. Such custom application on top of the core product should be covered by a different price.
Using SOA and service registry are routes to success, as is using dynamic process-binding based on the custom application. While they both work on the principle of having the same SaaS product serve all, there are also differences.
The service registry maintains multiple versions of same business services and invokes the appropriate one based on configuration, whereas dynamic binding allows the customisation to happen without overloading the core product.
Service registry with versioning allows customisation to happen within the product by using different services for different customers, while dynamic binding makes the customisation external to the core product.
So where does this leave configuration? You still need to set the customer up, provision the services purchased, and, in configuring the process, doing approval flows, as well as other tasks. This is part of the core offering and does not change the way the product works.
Through customisation, you can achieve extensibility and tailoring that cannot be achieved by configuration.
If your SaaS product does not do the multi-layer validations that a large customer needs, how will you address this? Will you let the customer go because SaaS doesn't allow customisation for one customer? Or will you allow the product to be extended?
But one thing is sure: customisation in SaaS is not dead. What are your thoughts?
Rajesh Ranjan is programme director for product engineering services at MindTree