The Not So Obvious Advantages of a SaaS Platform

Oct 29, 2007 by Sinclair Schuller

I’ve written about many of the obvious advantages of a SaaS platform before: harnessing a platform to reduce implementation time, cost of implementation and/or transition (for you ISVs with existing product lines), reduction in operational costs, and the list goes on. But what about not so obvious advantages? After some fruitful discussion with individuals at various organizations, I’ve identified some not so obvious advantages to building your next offering atop a SaaS platform (where the SaaS platform encapsulates a delivery, execution, and business services stack):

1. Cross Team Knowledge: In larger ISVs and corporations, multiple teams develop products in parallel and many times inadvertently duplicate efforts and functionality if good communications don’t exist between teams. If an ISV is pursuing multiple SaaS offerings across teams, standardizing on a SaaS platform (in-house or otherwise) creates common, transferable knowledge across teams. This creates baseline knowledge compatibility and teams can be useful to each other as they learn to exploit various parts of the platforms functionality.
2. Long Term Flexibility: Having a true SaaS platform as a foundation for a SaaS offerings creates a level of natural decoupling between the SaaS delivery stack and the products built on it. This allows for future products to be built atop the delivery platform since the platform tends toward abstraction rather than specialization. As a result, the flexibility of reusing the delivery mechanisms becomes a reality. In situations where the delivery stack and service are fused together, it becomes very difficult to use just the delivery platform. Far too often, the delivery stack was designed to fit the specific needs of the offering.
3. Independent Evolution: When infrastructure or non-strategic software is baked into a product, it takes an evolutionary back seat to strategic code that directly affects the value proposition of the offering. As a result, that part of the product never evolves, and new efficiencies end up being lost opportunities. Utilizing a decoupled platform allows for a powerful stack to evolve independently of the business functionality it hosts. This creates a powerful mutualism between the host and hosted software. What’s even more interesting is that using a third party rather than in-house platform can balloon this benefit since the platform evolves with wide and varied community input rather than in isolation.
4. Insulation via Isolation: Isolating delivery platform from product code creates an insulative (warning: insulative is a made up word) effect allowing for some degree of code portability as well as project creep safety. Having a baked in delivery stack results in a higher yield of bugs creeping up from the stack or down from the product, making quality control more difficult than necessary.

I’m sure that there are many more non-obvious benefits (I can think of a few more, but I think you get the point). Given these as well as the obvious benefits, it seems natural that over time the prevailing implementation choice would be to decouple the delivery stack from the strategic code, much like application and web servers did in the past. Do you agree or disagree? Has anyone experienced negative side-effects of baking the delivery and execution stack directly into the product? Feel free to comment!