The road to SaaS and other myths
Some estimates say that in a few years SaaS will be the preferred business model for most applications. I believe that’s true. I also believe that this transformation will favor ASPs (Application Service Provider) that meet three main characteristics:
- Profound knowledge of their domain.
- A comprehensive range of products.
- Investment capacity.
Domain complexity
For SaaS to be effective, it must take advantage of economies of scale. That means using the same software for everybody. This sounds great, but often your users need customization to differentiate themselves from their competitors.
How can we reconcile the need for customization with the goal of using the same software for everybody? In principle, it’s simple. It’s about offering customization as a feature so that users can personalize the system the way they want. Customization works best when users can do it for themselves.
However, in practice it’s highly complex because medium-sized software offers so much freedom. Either the development is so complicated that the task is impossible, or the results are so complicated that the software’s usability is compromised. This can largely negate the advantages of SaaS.
To win the SaaS race, you need to bring this complexity under control. And to do that, you need to identify what needs to be customized and help your customers to do it. ASPs that achieve this have a deep knowledge of their domain, plus the credibility to lead the way and win the trust of their customers.
Integration complexity
One common issue with large organizations is that they use many different products. Each product covers one part of the organization’s internal processes and has to be integrated with products that cover other parts – usually at great expense.
The need for simplification and cost reduction collides with the exponential complexity of integrating tens of different services. Often, the plumbing is more expensive than the features themselves.
When a company decides to adopt the SaaS model, a lot of the complexity of this integration falls back onto the vendor. The narrower the range of products, the more important the cost of integrating them becomes. Inevitably, some of this complexity also becomes perceptible to the customer.
Some companies try to mitigate the integration problem by adopting standards like ISO 20022 or FIX. However, these standards only cover the back end and there is still a lot of variability between systems.
What users want is a truly integrated system where they don’t have to switch from one application to another, learn how to use multiple systems, and so on. Again, the industry is working on integration frameworks for UIs, but the process is never smooth or cheap.
An ASP that meets their customers’ requirements fully can solve this problem at source. If company X can only provide front-office features, they will have to deal with back-office integration. Whereas if company Y has products for the front and the back-office, they can eliminate the complexity of integration for the customer entirely.
Even when the customer uses only a part of the solution, the vendor’s wider experience means they’re well placed to handle integration. In this case, integration becomes a feature like any other.
Different SaaS models
Investment capacity and a long-term horizon are also important. Very few companies who have the necessary know-how and richness of features started with SaaS in mind. The exceptions are companies like Google and Amazon, where offering SaaS products is their whole mission.
Many software vendors have built up tons of features and made their customers happy using other, non-SaaS business models. Now they want to continue making them happy by migrating their products smoothly to SaaS.
Around 2006, Microsoft set out a maturity model for SaaS. In practical terms, it’s not particularly useful but it does help to define and clarify the objectives. The Microsoft model has four levels:
- Lift and shift.
- Configurable.
- Multi-tenant.
- Scalable multi-tenant.
Lift and shift is about moving the software to the vendor’s data center. The SaaS software is largely the same as the on-premises version, but most of the operations are managed by the provider. It’s a first step but not a scalable business model. It’s not often profitable because the cost of ownership is just intermediated by the provider. Eventually, it ceases to be viable.
The configurable system is better because it’s normalized. All the customers – known as tenants – use the same version of the software. All the operations are automatic. The customization of the system is usually centralized, and sometimes even accessible to the customer. This approach significantly reduces the total cost of ownership and enables the organization to scale. The limitation is that more tenants means more instances of the software. This leads to inefficiencies in managing resources and it doesn’t let you leverage common operations. Each instance needs its own operating system, resources, and so on. Engaging new customers also entails a significant amount of work.
The final steps are the multi-tenant system. A single instance of the software serves all the tenants. It’s mostly self-service and typically it scales automatically (the fourth and final level). This is the best situation for everybody. It provides a great user experience and maximizes efficiency on the provider side.
Intuitively, the different levels are not evolutions of one another. They’re designed and deployed very differently. In other words, they’re different software and you can’t simply make a few changes and jump to the next level. Nor does Microsoft indicate a way to progress from one to another.
The bottom line is that moving from on-premises, ad hoc software to SaaS requires long-term investment, clarity on the path, and technical excellence.
Learn more about ION’s approach to SaaS and what products are already available.
