Along with these, gone are any associated tools that make life easier – that enabled software providers to build applications faster and cheaper by having a consolidated foundation.
Not a pleasant thought, is it?
This would mean we would be in a world of redundancy and tediousness. Each time we had to write a new application, our engineers would have to reinvent the wheel. Without an OS, engineers would write and re-write driver and hardware abstraction systems. Without application servers, web applications would be built to take care of resource management, socket cleanup, and instance management.
The reason we as a community do not live in this world is because we are lazy, and rightfully so. We enjoy having pieces of the puzzle abstracted away so we can focus on what’s important. Foundational systems like the application server are the result of the natural convergence within IT to remove redundancy and improve time-to-market.
Today, software as a service (SaaS) is rapidly emerging as the next major industry shift. As expected, a new breed of foundational system is being borne with the goal of catalyzing this shift – say hello to the SaaS Platform.
Building enterprise grade SaaS applications that meet the stringent requirements of business customers is difficult, to say the least. B2B SaaS applications need to embody the 365x24x7 mantra, and need to do so in a safe, performant, efficient and economical fashion.
A SaaS provider is responsible for architecting the application to meet these requirements. This means building out an appropriate infrastructure, dealing with operational headaches, ensuring security, providing flawless updates and bug fixes, as well as writing the software to be as efficient as possible to maximize tightening margins. Putting it all together, one can see that creating a B2B SaaS application adds plenty more to the already full software vendor plate. In essence, SaaS introduces a sort of “SaaS Tax” to the traditional software business and development equation.
Software vendors are in the business of providing value to their customers and a majority of that value is rooted in the functionality of the software. Having to detract from the core competency of delivering that functionality to deal with SaaS overhead increases time to market as well as associated operational costs. The Tax is something that all SaaS enablement concepts intend to either subsidize or repeal.
The brashest of the enablement concepts is that of the SaaS platform. A SaaS platform provides vendors with a foundation on top of which they can build their applications in a single-customer fashion, but distribute it to thousands of users at once with little effort. The vendor pays for using the platform in an on-demand fashion as well.
The concept behind the platform is powerful – abstract as much of the SaaS distribution model away from software vendor and their application, while at the same time acting as a communal gathering ground for the creation of a well-saturated ecosystem of suppliers and consumers.
That’s an optimistic mouthful that begs for explanation. To grasp the concept of dumping this SaaS Tax through a SaaS platform, it would be wise to dissect the platform concept itself. From a thousand-mile bird’s eye view, most SaaS platforms intend to provide:
• Tenancy – The ability to distinguish one user from another in the data and execution aspects of a hosted application is a major tenet of SaaS. Generally, the concept of tenancy is void in traditional on-premise installs and can complicate architectures beyond what was traditionally accepted.
• Flexible Monetization & Metering – Being able to charge for your SaaS application independent of the software code, and meter it appropriately, is something that your application shouldn’t have to deal with directly.
• Scalability – The idea that a successful application will buckle under its own popularity is never good. Being able to accommodate your aggregated customer base is a must, and planning for success is a requirement.
• Reliability – What good is a SaaS application that isn’t up?
• Hardware Infrastructure – As a vendor, one of the operational headaches of SaaS applications is dealing with an enterprise-grade hardware infrastructure.
• Value Added Services – A good platform should endow the application it hosts with value beyond what was developed by the vendor. The value should either benefit the vendor or the end user.
• Ecosystem – As the number of vendors that host their applications on a given platform increases, and as the number of users using those applications increases, an ecosystem begins to develop. Ideally, this ecosystem allows all parties the ability to investigate and exercise their right to connections between ecosystem members, deriving value beyond that offered by any single SaaS offering.
At the end of the day, a software vendor should be able to get away with writing the business logic of their application and provide an interface to use the application, and that’s all. No SaaS overhead, no major added expenses, no added time to already long project schedules, but only business as usual – writing quality software for consumption.