In the 1990s, analysts proclaimed ASP the future of software. Application Service Providers offered software over the Internet, a revolutionary model that would take over the industry. Unfortunately, customers insist on modifying their enterprise applications, preferring to make the software fit their business rather than the other way around. The ASP vendors of the day offered only limited means of customization. And when customers demanded this functionality, the cost of implementing customizations on a per customer basis destroyed the business model.
Then Salesforce popularized SaaS, software as a service. Salesforce, a CRM application, enabled customers to customize the application on their own through the web interface. Indeed, Salesforce has gone so far in enabling customization that it now justifiably positions its services as PaaS, platform as a service.
While simplifying, I’d say there a few essential characteristics that make Salesforce a platform as well as a CRM application:
- The ability to create new entities to represent business concepts (such as customers and accounts), attributes for describing these entities, relationships between these entities, and web forms to represent these entities.
- A flexible, robust security model.
- Functionality for users to create reports and dashboards.
- A web service interface with methods for CRUD (create, read, updated, and delete records) and search.
- A capability for business logic extensions, hooks in the application where it makes calls out to external code that can perform custom business logic.
So we have transitioned from the age of ASP to the age of SaaS; the flexible have won out over the inflexible. But customers should remain wary. Obviously, SaaS vendors vary in the degree of customizations that they can accommodate. And enterprises need to be able to customize extensively. Enterprises must be able to integrate new systems in the cloud with legacy systems in the enterprise. Even if the need for customization is not immediately apparent to those selecting a vendor, the need will become apparent as users encounter the application and demand changes.
I’d go as far as to say that enterprise customers should not choose a SaaS vendor unless its application has been built upon a platform that is also available to the customer as a service. Without an underlying PaaS, enterprises will find SaaS too restrictive. Indeed, a vendor offering SaaS without PaaS may not differ all that much from those long gone ASP vendors.
Anybody have relevant experience with SaaS to share?
I see that the biggest difference between ASP and SaaS is that the ASP vendors were hosting applications they didn’t develop on the architecture of their choice.
With SaaS, the software vendor also owns the architecture and so can focus its efforts on a single platform, update, upgrade and maintain the whole stack.
This obviously lead to a different proposal for the customer and reflect in the quality of the end-product.
Don’t you agree?
Thanks for the comment. That’s a really good point about the ASP vendors. I do recall some of the ASP providers of the time did build their own software specifically for online delivery, but most did not. And, obviously, that posed limitations. I agree that building out a software architecture specifically for the cloud does create the potential for greater value to the customer. But SaaS vendors must deliver on that promise. The architecture must support rich customization and integration. Most enterprise projects, which aim for process improvement and business innovation, require a platform, rather than just an application.
[…] for online delivery, but most did not. So we have transitioned from the age of ASP to the age of Saas; the flexible have won out over the inflexible. But customers should remain wary. Obviously, […]