Pain in the SaaS
Pain in the SaaS? When your traditional software vendor hosts your application
by Tony Byrne
28-Jan-2008
I recently chatted separately with to two unhappy customers of established content management software vendors that had created hosted service offerings as an alternative to their traditional, installed products. Both customers had expected a more tightly packaged service, and both were surprised by escalating consulting and maintenance costs.
Of course, two customers doth not necessarily make a trend, but I've heard similar echoes before, and -- based on conversations with software vendors who seem to soft-pedal the problem -- I suspect there is more discontent out there about this model than generally known.
As a buyer you should understand that contracting with a supplier simply to host and customize traditional software is not the same thing as working with a well thought-through, "native" Software-as-a-Service (SaaS) solution that was built from the ground up by a company dedicated to providing such a service. There is a case to be made for outsourcing application hosting and support, as well as a case for true SaaS. Just make sure you know the difference -- and know what you're getting in either case.
The case for a hosted solution
I understand why Web CMS vendors, especially in the mid-market, would want to develop a SaaS version of their product. Recurring services revenue represents long-term value. Venture capitalists seem to like it. IBM, Microsoft, Oracle, EMC, and SAP have all come out with SaaS offerings in the past two years, And it has the added appeal of being sexy: SaaS models lie on nearly everyone's list (though not mine) of what constitutes "Web 2.0" and "Enterprise 2.0."
However, you the customer should understand that there is a big difference between a vendor supporting its traditional software products and supporting an operational service.
In fact, there is a broad spectrum of "hosted" services that for simplicity's sake, we can divide into three rough categories:
- Hosting. Basic "ping, power, pipe" -- many enterprises outsource this
- Managed Services. Supporting the hosted software, potentially including application development
- SaaS. Providing a service that was designed to run "on demand"
The software / service divide
To understand the difficulty in converting a traditional product into an on-demaind application, let's start with the software itself. Software that was not built purposely for multitenancy environments can be very difficult to adapt to a hosted approach. There are considerations from security to branding to repository models, and more. To accommodate diverse requirements -- and the limitations of their existing tool to support them efficiently at scale -- vendors converting their tool to a hosted environment almost inevitably develop multi-instance architectures, where many or even most customers get their own complete instance of the application.
At this point, the vendor really just becomes your hosting company or -- if they are handling the entire stack and customized application -- a "managed services provider" ("MSP") to contrast with "ASP," or application service provider. In my experience, neither customers nor vendors fully understand the implications of this.
I find some vendors underestimate what it takes to run a 24x7 service. They assume they can just load up their beloved software in a nice controlled environment and assign some support people on it. It rarely turns out quite that way.
Native SaaS vendors will tell you that the line between support and professional service becomes quite blurrier in this environment, and that clear agreements become essential. In general, SaaS suppliers -- at least in the Web CMS space -- undertake an inherently more intimate relationship with the customer, often getting involved in issues of design, migration, and business process. Both of the disgruntled customers I spoke to cited misunderstandings about pricing and SLAs with their suppliers, vendors who had more or less wandered into the hosted application space.
I can imagine it's difficult for the software vendors too; they may begin to see fewer economies of scale with the multi-instance model, run into greater difficulties at upgrade time, and ultimately come to realize that application hosting is not a core competency. Things go downhill from there.
It's precisely because the lines between software, hosting, and application customization can get so blurry that you want to carefully review any service contract, whether it's a pure SaaS approach or an MSP. In once case we know, the customer was in one country, and the provider, in another country, was threatening to shut them down. That's always unsettling in any supplier relationship, but in this case, the vendor had the customer in a painful spot indeed: a heavily customized application that could be completely zapped at any time. Experienced SaaS vendors like to talk about how they have to keep winning your business each month, but the reality is that your switching costs are just as high with a hosted solution as traditional software. And in a hosted environment, you have more eggs in one basket.
The case for managed services...done right
All that said, there is still an argument to be made for the Managed Services approach. You may prefer a particular software product, but do not possess the data center capacity (both physical and human) to host it, nor the human resources (developer and managerial) to customize it. This approach could, for example, help you quickly launch a micro-site. It could make very good sense if you want something simple and your expectations are metered.
But if you are going to commit a core enterprise website or application to it, do your diligence. If you're simply looking for reliable external hosting, then find someone good at that. But if you go the MSP route, be sure to sign on with a service provider who performs this regularly for customers with your level of application complexity. There's a very good chance that your favored software vendor actually does not have the right skill set (or business model) here.
In short, there is real promise for the hosted approach. Just get clear about the difference between native SaaS and the various flavors of MSPs, and in either case, make sure that you and your vendor know exactly what "as-a-service" really entails.