SaaS Means Innovation, Delivered Continuously to Customers

Innovation - ongoing and continuous innovation in software functionality, infrastructure and capability - is SaaS's biggest distinctdive benefit to customers over the long term, and it's almost always overlooked by SaaS buyers.

On-premise software simply cannot deliver innovation to customers because of a triple-whammy of on-premise innovation shutdown:

• Maintaining many old versions on a myriad of platforms: As explained elsewhere on this blog, on-premise software vendors have to dedicate an enormous amount of resources to maintaining old versions of their software, across lots of computing platforms. Rather than focusing upwards 70-90% of development resources on maintenance as on-premise vendors do, SaaS providers can dedicate 80+% of their development resources on new features and value to customers.
• IT's no-change philosophy: Once on-premise software is up and running the customer's data center, it is beholden to the IT philosophy of minimizing changes - if something works, lock it down. This is entirely appropriate for internal IT because upgrades can involve huge re-customization and re-testing projects, so the application's ROI goes down the more frequently upgrades are performed. In addition, if the IT group invests in improving the software's capabilities, it only benefits one company, which means very few improvement projects return a sufficient ROI. Joel on Software describes the frustration of being an IT worker who has to stop improving in-house software built for a single company, which ensures the software is barely sufficient in terms of functionality, performance and usability.
• Decade-long upgrade cycles: Another result of single-company ROI and painful upgrades is that on-premise software is rarely upgraded, staying on old versions for 3, 5, or even 10 years, so even delivered innovations take forever to deliver benefits to the customer base. [This also causes frustration from the on-premise vendors' developers - they work on a cool new feature or value-add technology, and the majority of customers won't be using it for many years.]

Bottom line is that customers and users don't gain innovation benefits from their on-premise software providers, forcing many IT shops to invest in their own R&D labs. Even if the on-premise software vendors actually start to deliver on their talk about innovation, the fundamentals won't change - it will take many years for the majority of customers and end-users to gain any benefits.

The SaaS model eliminates these problems.  [Actually, only true SaaS solutions qualify, beware of SaaS pretenders who don't actually deliver the benefits of ongoing continuous innovation.] The true SaaS model has three key characteristics that deliver innovation benefits to all customers, instantly and continuously:

• Frequent Automatic Upgrades: Upgrades are zero-effort for customers, they gain instant access to new capabilities and can turn them on whenever it makes sense for them. And since upgrades are deployed to all customers automatically, the entire customer base can start gaining benefits right away.
• High Investment: SaaS providerse can apply almost all their technology effort to new functionality and capabilities, since they only have to maintain one version and infrastructure. Even more importantly, innovation investments generate benefits across the entire customer base, so the SaaS provider can justify many improvements in usability, performance, functionality and configurability that a single customer could not justify.
• Fast-Cycle Innovation: SaaS providers know where to target innovations because they know how their software is being used by the customers and what the user experience is, in real-time. This allows them to target innovations that will most help the user population right now, and gain feedback in days about the uptake and impact of a new or improved feature. This quick cycle allows experimenting, refactoring, optimizing and continually improving the software's capabilities, keeping the solution fresh - both functionality and infrastructure. On-premise software, with its 18-month or more release cycles and multi-year upgrade cycles, has a feedback loop that is so long it's almost non-existent.

What does this look like in practice? Well, we have many Fortune 500 customrs who have been using our SaaS solution for over five years, and in that time they've received the benefits of (at no additional charge): internationalization with multiple languages and localizations to dozens of countries, a new always-real-time reporting module with WYSIWYG formatting in Microsoft Word, BPEL-based workflow definitions and execution, addition of Firefox and Safari as supported browsers, continuous performance improvements even as volumes tripled each year, and literally thousands of small improvements suggested by customers and users.

So, in contrast to SAP, which is commended because it only took 6 months to support the iPhone (and for a very small portion of its product set), our entire application supported the iPhone the day the iPhone was introduced.

Comments

[Andrew Biss]

You are right about IT's no-change philosophy:

In 2006 I was negotiating with a customer about a new support and maintenance agreement. This was a long-time customer and I knew which versions of our product (a development tool) had been shipped to them over the years. The question was -- which version were they actually running in production?

I suspected that they might not be totally current with the latest version. I was rather surprised, however, when they told me that in fact they were running in production the very first version of the product. This version had been shipped to them around 1983!

The product had been so stable over the years that they had just been filing the updates that they had received over the years. They had never installed them and kept the original version running. They had been paying maintenance all that time and had never installed any updates.

What would have happened if they had really had a production problem with this development tool and they wanted support on a product version that was more than 25 years out of date?

This was a classic example of the approach which we so often see in many IT departments: “If it isn’t broken then don’t fix it!”