I recently had the opportunity and pleasure to speak on a panel held at Oracle HQ in Redwood City, CA. It was a small conference – sponsored by Oracle – and attended by current Oracle ISVs to discuss the issues of converting and/or building a SaaS business. The panel was moderated by Kevin Dobbs with Montclair Advisors .
Joining me on the panel were Byron Deeter, a GP at Bessemer Ventures and Joel York, CMO at Xignite. I really enjoyed the panel members and the audience interaction and was reminded again just how bright the people are throughout Silicon Valley and how fortunate I have been to work in an industry where the US still continues to lead the rest of the world.
Some of the topics the panel bandied about regarding the SaaS business model reminded me of lessons I have personally learned that I thought were worth repeating here.
The first big question thrown at the panel is whether a company can successfully negotiate a hybrid model that embraces both SaaS and traditional software delivery.
My point of view – based upon personal experience and observing other companies attempting to do it – is “no”. While a number have tried (e.g. Microsoft, SAP, Oracle), I still haven’t seen any existing company do it very well, at least not yet.
The problem is at least two-fold:
- The SaaS model demands that a company not only be a software development organization but it must also take on the responsibility for running the sofware 24/7. It requires a different way of thinking about how you develop, market and deploy your products v traditional software.
- The differences between the business models drives completely different comp plans, completely different behavior throughout the company and different expectations by Wall Street/investors. For example, a traditional software model is sales capacity driven, a SaaS model is typically marketing/demand driven. It’s hard enough for large ISVs to address this schism let alone a small company with extremely finite resources – while I haven’t seen any company do it successfully to date, I’m willing to keep an open mind here and if you have great examples of companies doing this well, please tell me about them and how they are doing it.
In addition to these basic structural issues, I think back to when I took over Siebel’s CRMOnDemand division after returning from a long sabbatical. I found myself having to learn a different vernacular and to develop an instinct for managing a different set of operating terms (e.g. CMRR, ACV, Churn, CAC Ratios, etc.).
In addition, we had to create a different organizational structure to manage the business model. For example, I created a Customer Success function in order to ensure someone woke up every morning worried about customer usage and adoption to manage Churn. In a traditional model, this responsibility was largely an issue/expense that the customer bore.
Where I had no cost of labor associated with managing software in a traditional model, the SaaS model demanded that with every new customer Ihad to ensure that performance did not diminish. This meant putting in more CPU, more storage, and doing a lot of SQL optimization work – especially for our analytics/reporting modules – whatever it took to ensure our customers were happy.
Of course, this is all “old hat” for execs at pure SaaS companies but for those ISVs who are just now contemplating deploying a SaaS solution, this will be new ground to cover.
The point I – and many others – have made is that embracing SaaS is just not as simple as doing a technical overhaul to make a product “multi-tenant” or to virtualize it – virtualization is the Larry Ellison method of delivering SaaS which Gartner now “endorses” as another viable form. Remember when it was sacreligious to say you were a SaaS company if your underlying architecture wasn’t multi-tenant? It must be those high fees Oracle pays Gartner.
Actually, to Larry’s credit, he is right about the fact that companies don’t like commingling their data with others. Some market reports I have seen show there is demand for companies to deliver a “private” SaaS offering where each company’s data is guaranteed to be kept separate. Those reports also show that companies are willing to pay more for this offering.
Another big question asked of the panel was if/when the Back Office/Mission Critical applications (e.g. ERP, etc.) would open up to a SaaS delivery model. The key constraints that most of the attendees identified as impediments to the sales cycle for these types of solutions today revolve around objections regarding performance, reliability, scalability and security.
These objections reminded me of a lesson I learned at Oracle back in 1987.
At the time, I worked for a recently anointed Oracle VP – Tom Siebel – in the newly formed Product Line Division. Under Tom were DEC VMS (Oracle’s biggest product line at the time), IBM MVS/VM, DG AOS, Unix and PC organizations. I was given the responsibility to run the Unix division – a nascent product line.
One of the great value propositions that Oracle provided was that you could take an application built to run on top of Oracle (e.g IAP/IAG and its sucessor SQL*Forms), and run it on top of an Oracle RDBMS irrespective of the operating system/hardware platform.
In 1987, Unix was a fledgling commercial operating system and was primarily used in academic and/or scientific environments. It had few mainstream commercial applications. Then, Unix lacked a lot of what enterprises felt were basic requirements – clustering, disaster recovery, fault tolerance, scalability, etc.
A number of Unix systems start ups emerged to take advantage of the fact that Unix was relatively “cheap” to license and they could instead focus their engineering dollars on delivering fast, relatively inexpensive hardware systems. Companies such as Pyramid, Sequent, AT&T Information Systems, began to take on the mini/mainframe computer markets with these low cost systems – low cost when compared against a DEC VAX, IBM Mainframe, etc. vis a vis price/performance.
However, these new systems lacked commercial applications.
My strategy – er, Larry’s strategy – was to go after the Unix systems manufacturers and to get them to license Oracle so that they could then take applications written on top of Oracle for DEC and/or IBM and have them immediately run on their machines for substantially less.
It turned out that the “magic” ratio was 10:1. Once the Unix vendors could offer an Oracle solution for 10x less than a comparable DEC Vax Oracle solution, many of the issues of security, reliability, etc. that previously plagued the Unix vendors selling into a commercial environment began to evaporate.
Instead, companies found areas where they could use an Oracle/Unix combination that wasn’t as dependent upon security, reliability, etc. and Unix vendors used the profits from these sales to fund R&D to plug the commercial gaps. A classic Innovator’s Dilemma cycle occurred.
We all now know how it ended up – Unix is now the standard operating environment for many/most commercial applications. Many Unix vendors were acquired and many incumbents disappeared – the computer systems landscape was irrevocably transformed.
I think it is easy to use this history lesson to predict where “cloud computing” is going to end up. Today, many large enterprise IT departments decry cloud computing as not reliable, not secure, not scalable, etc. However, with recent price/performance ratios tipping 10:1, we are beginning to see cloud computing enter the periphery of the enterprise and we will see a lot more in the next couple years.
It started first with front office applications. Now, it’s penetrating the back office at several different levels that include applications (e.g. Workday) and infrastructure (e.g. AWS, Rackspace, etc.).
If history repeats itself – and I do not believe there is any reason for it not to do so in this case – I predict that within 5 years, private clouds and public clouds will achieve massive penetration inside the Global 2000 and completely disrupt the way computing is deployed and managed. It will also change the vendor landscape, irrevocably.
However, as much chaos as this will introduce now, in 10 years, I doubt that cloud computing will be a big topic of discussion because it will be de rigueur; just as Unix is today.