Over the years since the SaaS acronym was identified, there has been a preconceived notion that hundreds, if not thousands, of SaaS applications would be spawned by independent software vendors (ISVs) from their packaged, on-premise products. It just seemed natural. Why wouldn’t vendors want to jump on the bandwagon heading into the cloud?
The truth is though, there are still thousands of business-to-business (B2B) applications that have not transitioned and many vendors who have no plans to move their products to SaaS. I found this recent quote relating to hosting for ISVs interesting:
There are thousands of ISVs that have not deployed their application or offered their application as a service. In fact, only now are ISVs and their customers moving in greater numbers to deploy in a hosting provider’s data center. The majority of applications in use today are still installed on-premise.
Even more interesting, there are at least hundreds that either made the transition and then withdrew their products or never really embraced the business model, choosing instead to “test the waters” with hosted, single-customer implementations of the same software they sell to their on-premise customers. With all the marketing hype about users adopting SaaS and success in the market for cloud-based services, it is fair to ask:
What’s Going On?
First, let me say, I am not one of those who has a strict definition of “Real SaaS.” Can SaaS architecture be anything other than multi-tenant? In my world, yes. Multi-tenancy has great value for both the vendor and the user community it supports, but that doesn’t make products that are not architected that way automatically less sustainable. Should all SaaS be configurable instead of customized to fit individual needs? I’d say it is preferable but that doesn’t mean there aren’t many other supportable ways to allow customization in a SaaS application. Shouldn’t all SaaS products embrace the social and community product management model we see emerging? I’d say it would be foolish not to consider it, but that doesn’t mean there aren’t many places where it doesn’t fit. But perhaps most controversially, I’ll stick my neck out and say not all SaaS is directly subscription-based nor should it be.
My possibly heretical point of view comes from a simple observation of what we have seen coming to our door. There are many companies today, extending their business models to include online applications. Their customers may pay for access to those applications in addition to their regular service fees, but in many if not most cases, they do not. These applications provide automated access to repetitive services, quick access to online expertise, and process-based systems based on the business services the vendor provides. Are these implementations any less of a Software as a Service application than those of a vendor whose only service is the application itself? Are these services not SaaS because they are bundled into a group of direct services? In fact, because these businesses have fully embraced a service-based business model, is it actually more natural for a them to be successful at SaaS than an ISV?
So, if you haven’t caught on yet, what kind of companies am I writing about? It could be almost any service in any industry. Legal, travel, medical, financial – you name it. Naturally, most will follow the mold of the majority of SaaS companies today and are B2B, but that doesn’t mean that their end users don’t regard themselves as ordinary consumers. Imagine a medical group, that is contracted by an employer, provides online access to medical advice, scheduling, and preventive care through an Internet-based application. It is paid for by the employer as a part of benefits and used by the employer’s staff and their families. What is the difference between that and the same service provided direct to consumers for a subscription fee by the medical group? In essence, the difference is the sign up, the payer and perhaps the method of billing. The service itself is just as critical. If the employer-subscribed members aren’t satisfied, they will tell their bosses or HR department. But of course, the same medical group also provides direct medical services and if they offer the subscription-based service through an application to the general public, it can become an “on-ramp” for new clients.
Service In Their Genes?
But that brings up another thought. Do ISVs have the “service-based DNA” necessary for success in SaaS? Do they clearly see not just the advantage of hosting an application for their clients but also of extending the services that would raise an application beyond a commodity that could be easily replaced by another vendor? Honestly, that is a difficult question. Whether they like it or not, most ISVs are locked in a cyclic-product development mode by their business model. Transitioning to an incremental cash flow with continuous product enhancements is very difficult. Every part of their business is set up to support a fundamentally different direction. We’ve found repeatedly, even when the desire is there, it is very hard for an ISV to change boats in the middle of the stream.
That doesn’t mean that ISVs can’t or won’t transition to SaaS, but I’d say at this point, if they haven’t – the likelihood is increasingly small. On the other hand, if we stop focusing on ISVs and startups as the primary drivers of new SaaS products, we will quickly see there are even more opportunities on the horizon that don’t fit the media-led definition of SaaS. The simple fact is, most companies don’t have to be told what defines the expertise and services they sell. What they need help understanding are the tools and services they can leverage if they want use an internet-based application as a part of their product mix that will lower their development effort and related costs. They need to know about platforms, cloud-based infrastructure, and development for cloud stacks like those offered by Google, Azure or Amazon. They need to understand current application user experience patterns and the methods behind SaaS products that are easy to use and adopt. Of course, there is one more thing – they are likely to want other services with the technical expertise to develop and deploy Internet-based applications to fill in the blanks while they continue to focus on their core business.
Do we need another acronym to describe these companies or their online applications? After all - they are much harder to identify than ISVs. There are many more service companies in the market that could decide to extend their business online but they don’t fit an easily identifiable profile. Should we call them “Service-Based Applications” or something? As tempting as it might be – NO. It is easier to open the definitions of SaaS and cloud-based services to include their business models than it is to come up with an alternative or to just be straight-forward and call them Internet-based applications.
The Bottom Line
The point is we in the industry have to stop being so self-centered. Software developers are not the only ones who can fund, plan and implement a service online. ISVs don’t have a natural or the only path to becoming online service providers. Subscription-based, self-configured, multi-tenant applications are not automatically successful services. Online services are enabled by technology, but generally are not successful as business models if they are based solely on technology. We have to open the doors and let some air in. When we do, we will see there is a lot more opportunity out there than we ever imagined.
So next time you find yourself talking down to ISVs that “don’t get it” – stop and consider. Is it me? Am I cutting out a much larger opportunity for SaaS just because I haven’t included the most likely success stories?