Beyond the buzzword: SaaS and innovation
Posted by Nick Mehta on Sun, Jun 01, 2008 @ 08:10 PM
As a longtime NFL fan, I've gotten used to the perennial ritual of sports writers identifying "seminal" changes that are "redefining the game of football." Some of these analyses pass the test of time and turn out to be legitimate evolutionary points in the game (e.g., the "era of the passing game" with QB-friendly rules and refs). Others are eventually called out for what they truly are - cool new phrases to describe things that have been happening for some time (the term "post-free-agency era" comes to mind; geez - that happened in 1989 so we're pretty squarely in the era!)
Now enter the IT industry, where buzzwords flutter around faster than the West Coast offense. Customers (and vendors sometimes) ask: which trends are real? And which ones are simply the result of marketing teams desperately relabeling old ideas to make new headlines.
With that in mind, I'm enjoying taking a critical eye to what's truly different about Software-as-a-Service (SaaS).
Having been in the tech world for a while, I entered LiveOffice with a healthy skepticism over how much is unique about SaaS. After all, the 101 highway in Silicon Valley near my house was littered in 1999 with ASPs, MSPs and ISPs before they all went RIP. And the idea of running centralized servers and delivering service over data lines is kind of the Internet in general, no?
Yes and no. I'm going to write a few posts over the coming months on some of the truly unique aspects of what I'm seeing, as a recovering "licensed software guy" reformed to this new world.
As anyone who has run an on site software product team in the past can attest, what always kills you is when you realize how much of your resources go to things that don't help the customer's business problem for which they are talking to you in the first place. Obviously it's a trade off. On site software provides great value and can be tightly integrated into your network. But I'm now learning some of the challenges in terms of providing innovation for customers:
- Compatibility. One of the biggest issues any on site vendor has to deal with in terms of development and testing is managing the huge matrix of possible systems in the customer environment with which the vendor's product may have to integrate. In the archiving world this often means [# of Server OS versions] * [# of Client OS versions] * [# of Email Server versions] * [# of Email Client versions] * [# of Storage versions] * [# of Database versions] * ... You'd be amazed how much time this testing and development takes - especially when you consider how many service packs of Windows, security patches for storage arrays, and database versions, etc. there are out there. Obviously a SaaS vendor has one internal environment against which to test. This simplifies development and testing dramatically.
- Management Tools. Over time, as an on-site vendor, you need to invest not only in customer-facing functionality but also into tools to help the customer manage your technology. These tools are very important to the IT user of the product and are critical for solution success. However, at the end of the day, they don't help the business get incremental value - they simply help deliver on the core value of what they already purchased. In contrast, a SaaS vendor only has to build management tools for its own operations team (for the most part), which means significantly-less effort.
- Instant Upgrades. One of things that always blew me away as an on site vendor was how long it would take for a customer to get the new functionality that we built. We'd ship a new release and it would take 1 year+ in many cases for customers to (a) find out about the new functionality, (b) get the software, (c) plan the required hardware changes and upgrade schedule, (d) test the changes and (e) upgrade. In contrast, when a SaaS vendor upgrades, its customers are generally on the latest version right away. This can often mean 1 year+ difference in the "time to new functionality" for a customer.
- Legacy Version Support. When an on site product vendor identifies a bug or issue, it often has to fix it in many different releases at once. Because of the pain of upgrades, many customers ask vendors to support products for several years after they are released. Hence, vendors often have many "supported" versions out in the field. This is good for the customer on paper but means the vendor needs to recode each bug fix in several "code trees" in parallel. Again, this takes away from the innovation the vendor can provide. Obviously, a SaaS vendor can instantly deliver a fix for all customers with one code change.
What does this all mean? Well, all of the above "non-innovation" development work adds up. From experience, "keeping the lights on" tasks can consume 80% of R&D resources in a mature organization. No matter how many people you have in your team, that's a lot of lost functionality.
As I said upfront, Software-as-a-Service is a trade-off and not panacea. But one of the big benefits you get, for customers that are able and willing to receive services rather than on site software, is that the vendor can spend more time innovating for the customer and less time maintaining.
I'll continue this theme on what's different about SaaS in future posts. I welcome your feedback.