“Late” to the Cloud?

The general perception is that being early to market with a product gives the vendor first mover advantage and lets them capture market share and mind share before any competitors get into the game. There’s certainly a lot of evidence that this advantage does play out for new products or sometimes even for businesses. SaaS isn’t really in the strictest sense a new product though, it’s a new business model and a new (well it was new, now it’s over 12 years old) way to deliver software. The first movers were companies like Salesforce.com and Netsuite, companies that led the innovation and helped define the model. Unlike a new, innovative product though, the move to establish SaaS as a viable way to consume software wasn’t an immediate run-a-way success. It took many years to convince mainstream IT to support the model and to get past their security and scalability concerns. As a part of the wild west days of SaaS, these new vendors developed the methods of delivery, the architecture and the business model. Things like multi-tenancy, which clearly has scalability advantages for the vendors, became the defacto standard for SaaS. Initial success in the marketplace, particularly for Salesforce.com, Taleo, SuccessFactors, and Ultimate, that is vendors that offered a compelling product for a specific set of end users, was mostly driven around corporate IT, not with it. The exception would be Netsuite, but in its case, the initial success was in the small and lower mid markets where the need and advantages far outweighed the objections.

By 2007-2008 the SaaS model, and cloud computing in general was getting a lot of attention and was starting to get more mainstream adoption, which even included support from more progressive IT organizations. It had not however, reached the tipping point for mainstream adoption. This tipping point, I believe was accelerated by the economic crisis of 2008, which forced companies to look at cloud computing, particularly SaaS, as a viable alternative to traditional software purchase. This was an economic decision, traditional software is purchased out of the capital budget while SaaS, with its subscription pricing model, is paid out of the operating budget. Part of the crisis was in fact the drying up of capital for many businesses, particularly financing for capital projects, so it became much easier to go with a SaaS product or nothing at all. Software is an important competitive advantage for many companies, particularly in this new social and hyper-connected business environment, so choosing to not invest in key projects like social CRM, employee collaboration, process automation, decision support and deep vertical industry functionality really wasn’t an option. So in that 2008-2010 timeframe SaaS crossed its tipping point.

Now look at traditional software vendors like Oracle, SAP, Microsoft and a host of midsize and small vendors. Their businesses were based on a very different revenue model, the combination of up front licensing fees, services and ongoing yearly maintenance fees that give customers access to product support and upgrades. Moving from this model to a subscription model is not an easy shift and one that most effectively is managed over a long transition period to create a smooth swap in revenue sources. There have been companies that made the switch in one bold move of course, but those stories are few and were fueled by other business pressures and issues.

Which strategy would you choose, rapid change over but risking current revenue for long term subscription revenue or a slow transition that only starts when it’s obvious that the model is the future of software? First I should point out the scale of the issue, we’re talking tens of billions of dollars, not a few million for the larger vendors. It seems pretty simple to me, I’d protect the largest source of my current revenue as long as possible and then add in the new sources as they proved themselves as viable. Cloud is clearly a different way of delivering software, or a different mindset over a traditional product license model, but is it really a different type of "DNA" from the traditional business of the software vendor? It certainly requires a high level of customer service and customer focus, but many of the traditional vendors already have the kernel of this attitude in their service and support organizations.

So if you’re a vendor in the later wave of rolling out cloud based software products how do you gain momentum and build a product portfolio? Can you buy your way in or do you have to move your current products over to the new model? For many traditional products, the move into a SaaS model requires some fairly significant re-architecting to make the products viable as SaaS. Now some vendors have simply offered existing products as hosted offerings and moved to a subscription based licensing approach. This has the advantage of quickly getting the vendor in the market but it comes at a price to both vendor and customer. Like most things in business there isn’t really a "best" one answer, but in fact a blended approach seems to be the most obvious choice, particularly if you’re a larger vendor. Building some new products on a native cloud architecture, while time and labor intensive, will yield some excellent long term benefits. That doesn’t preclude buying market share and expertise though. We’ve seen an aggressively consolidating software market over the last 6-7 years, with generally successful outcomes for the vendors and customers so repeating this with SaaS vendors is a natural continuation of the trend.

Consolidating current existing SaaS vendors into a broader product portfolio has some obvious benefits and some challenges. It increases the ramp rate for the acquirer, bringing more mature SaaS products (at least that would be the general assumption) with existing customers, a trained sales team, developers, operations staff, consultants, and product support expertise. For customers they most likely benefit from a relationship with a more stable vendor with more resources, potentially greater geographic reach and access to other product assets in the portfolio. The down side for the vendor can include the efforts to rationalize products / infrastructure / platforms, etc. that comes from adding products from multiple vendors. Re-platforming efforts can be expensive and/or complex. Integration into the existing product portfolio can as be challenging although it is generally a very important part of the post acquisition process. From a customer perspective there’s always some fear of vendor lock-in as there are simply less vendors to deal with due to consolidation. I hear lots of discussion around this topic but frankly more from other analysts than from vendors’ customers so maybe this is less of an issue / concern than some people believe.

Building new SaaS products (and perhaps moving existing products as well) now also comes with some added benefits. The original SaaS vendors are built on platforms and architectures that were defined and built over 12 years ago and while they certainly have been improved and modified during that time, they are getting old in technology terms. Look at what I’d call 3rd generation SaaS product architectures versus the 1st generation for example. Taking Workday as the most obvious example of 3rd gen, you can see many improvements that the older platforms simply don’t have, in-memory technology, for example. So moving / building now means the vendor can leverage newer and more modern architectures and technologies, including virtualization, which was nonexistent when the 1st gen products were designed. Many pure SaaS evangelists will call my next statements heresy but traditional vendors that are getting into SaaS are also offering customers choices in deployment models, as they can build products that are capable of being deployed both on premise and in the cloud in multi and single tenant virtualized models with the capability of moving from one model to another in the future. To me this just seems like goodness for customers, but I’m sure I’ll draw a few stones over it. One of the key objections I’ve heard to this choice model is the frequent release cycles that SaaS vendors hold to versus the much longer cycles of traditional software. The longer release cycles are due to a couple of things, the development model (usually waterfall) and the tolerance of on prem customers to upgrade cycles, which need to be longer since most companies couldn’t tolerate more than an upgrade every few years. There are ways around these issues though, and we’re starting to see wide spread adoption of agile dev models and efforts by vendors to sort out a way to provide frequent upgrades to the SaaS customers while giving the on prem customers ways to package up / save up upgrades to be implemented on longer cycles. This does lead to the old issue of supporting customers on multiple releases but if the vendor is willing to bear this burden (and can do so at little or no damage to the overall bottom line) then its none of my business to criticize them.

We’re in a transition period for customers and for vendors. There’s no magic switch to move vendor products and customer implementations to the cloud, it will take many, many years for that to happen. During the transition years giving customers options and choice seems like a very good thing to me. There are lots of advantages to moving to the cloud and companies are realizing these benefits but at the same time, many do not, or will not, move everything. For companies that have a substantial investment in core on prem systems that currently meet their needs, they will continue to operate those systems for the foreseeable future. When they add new systems, most will choose to do so in the cloud and integrate those to on prem systems as needed. Operating in a hybrid model is simply a reality for now…and that extends to many vendors as well.  So was being late bad, or was it simply "fashionable"?