Not all Web Apps are created equal and many people don’t understand the difference between ASP vs SaaS or Software-as-a-Service.
ASP vs SaaS – What’s the difference and why is ASP a failed business model?
This post was originally written in 2009 and – while still very relevant – I suggest you also read this post for a more up-to-date take on the Business Architecture discussion: Software Vendors: The Cloud is Not Magic (but it can be very Profitable!)
The difference between Application Service Provider (ASP) and SaaS is quite significant, but since both are “hosted” the two models are often confused. ASP is much closer to Legacy Software than SaaS.
ASP vs SaaS – A Living History
While the Revenue Model for access to the Legacy Software delivered via ASP versus that which is deployed on-premises might be different, in either case the Revenue Model is disconnected from the software itself. So at its core, software delivered via the ASP model is generally a Single-Instance, Single-Tenant Legacy Software application. The Revenue Model is very much like renting a server with an application installed on it.
ASP is a failed model because it lacks scalability for the vendor, there is too much customization, generally a single Revenue Model, no inbuilt aggregation of data, and no network effect data to collect and aggregate. Are there vendors that have found success with the ASP model?
Of course, but that success has been limited due the difficulties dealing with scalability and customization between systems. Next Generation ASP, or ASP 2.0, based on Virtualization and Cloud Computing, is just as bad as its predecessor.
This Should End the ASP vs SaaS Confusion
SaaS, as an all-inclusive Business Architecture, is a Value Delivery Method rather than a Software Delivery Method. Due to its inbuilt Multi-Tenancy which allows for shared resources and shared infrastructure, SaaS is scalable and allows for the vendor to take advantage of true economies of scale, reducing overall operational costs and complexities, especially with customizations. However, the more efficient use of resources, reduced overall cost, etc., associated with SaaS is just one benefit to the Vendor.
The real benefit to the Vendor, as well as the Client, comes from the SaaS Business Architecture’s inbuilt Multi-Tenancy, which can be leveraged to help Improve Customer Service and Retention, Reduce Sales Cycles and Accelerate Revenue, Gain and Maintain Competitive Advantage, Improve Strategic Planning Abilities, and even Directly Monetize Beyond the Application.
A reality check is that most of the time, when an application is deployed in a Single-Tenant or ASP model, its because the core product was not built to support Multi-Tenancy and the vendor simply does not want to take the time to re-architect the product.
What this also means is that the product was not properly commercialized, not thought about as a business rather than as software, and therefore revenue model support, advanced metering and billing, etc., are probably not inbuilt.
Finally, the product was probably not built to adequately capture important usage and other data outside of the core product. In other words, Multi-Tenancy is often the red herring that everyone argues about.
The reality is that the since Single-Tenant applications are generally not architected properly to support the Business Requirements around the SaaS Business Architecture anyway, so the argument is moot.
I suggest you also read Software Vendors: The Cloud is Not Magic (but it can be very Profitable!)
About Lincoln Murphy
