We hear this morning that Oracle is going to buy Micros Systems, a primary provider of software to retail/hospitality users. What should we think? Well, everyone knows the “Law of Large Numbers”, and most know that the term is applied to so many things it’s fair to say there’s a “large number” of the laws. I want to contribute a couple new ones in analyzing this deal.
First is the Law of Mass-Market Numbers, which says that you can create a mass market only from “average” people by definition. Our thoughts about the cloud violate common sense because they focus on IaaS, a cloud service option that’s unlikely to be consumed by the “average” buyer, meaning the SMB. The fact is that the mass market for cloud services has to be one for SaaS because that’s something that can be consumed without a strong technical support foundation.
Oracle’s cloud strategy may have evolved through canny planning or been forced on them by tardiness, but whichever was the case they are likely on the right track. What you need to be a cloud success, most of all, is something you can sell as SaaS, and Micros brings that to the table. You have a large prospect base, widely distributed, and it’s a market that can be weaned into the cloud easily from the premises framework that now dominates.
Retail/hospitality isn’t the only example of this model, either. There are dozens of verticals that have a homogeneous core-system requirements set of their own, verticals that could be credibly addressed by having a package that gets decent market share as a sale-of-software provider. Oracle could jump from Micros into other spaces, and all the easier if everyone keeps their head in the IaaS gutter instead of in the real clouds.
Of course, there’s still the question of how you create an effective SaaS strategy. If you look around in the market today, you can see that we have three different “roles” emerging regarding the SaaS cloud, and Oracle and every other player will ultimately have to bet on one.
The first role is that of the software-overlay supplier. Micros/Oracle clearly fits in this role; they can offer the application that when cloud-hosted becomes SaaS. By taking this position in the cloud, Oracle could promote SaaS to cloud operators and at the same time promote cloud migration to end users via IaaS or PaaS. If you have a really strong software position you have a hope of obtaining decent margins, but if you don’t offer the underlying cloud infrastructure yourself, you’re forced to rely on and share revenue with those who are prepared to do that. Some of those “others” might field ineffective infrastructure that could taint the SaaS application’s reputation.
The second possible role is that of the full-spectrum SaaS provider, the company who builds out a cloud and populates it with their own applications to create SaaS. This role has the obvious advantage of capturing all the cloud revenue and eliminating dependence on others in creating the retail offering or sustaining it at a credible level of QoE. It has the obvious disadvantage of introducing a very low-margin component, the IaaS foundation.
This is where our second “law of large numbers” comes in, the “Law of Respectable Infrastructure Scale”. While it’s not true that doubling the size of your resource pool doubles your economy of scale (it’s an Erlang Cumulative Density Function so it converges on a plateau level of efficiency) it is true that you need to have enough capacity to absorb customers, support cloudbursting, provide for geographic diversity, and increase server utilization as close to 100% as you can attain. With this second SaaS model, you’re going to likely have a very significant positioning investment (what carriers call “first cost”) just to get your service coverage what you need it to be. That delays the realization of real profits from the model. Even when you reach full efficiency, you may well have found that you’ve made two-thirds of your total capital investment at something that’s going to yield less ROI than your target level, which means you’re dragging down your overall ROI.
But the third option is even worse; you can become a hardware cloud provider, someone who offers basic IaaS or some form of augmented PaaS to independent software vendors, who they share revenue with you in some way when their software is converted to SaaS. Here you have the same ROI issues that the second model presented without any good way of sweetening the pot with add-on retail software. You end up having to support the business goals of the SaaS software vendor of the first model but at a lower ROI than they have!
And yet it gets worse, because of the third “large-numbers” law: “The operational cost of a system of components is proportional to the number of components (N) raised to a power greater than 1.” That means that opex of large clouds designed to support large numbers of dynamic application components and users will increase faster than linear. My model says that cloud opex will become a larger factor in cloud cost than component capital costs well before maximum efficiency levels are reached. Building a truly effective cloud is more a management problem than a matter of assembling a resource pool. And building a multi-layer cloud profit model with hardware, OS/middleware, and application software players will be even more complicated to operationalize.
I think there’s an important lesson here. We are going to have to do a lot more work in operationalizing cloud infrastructure and services. We are going to need a whole new spectrum of automated tools, tools that do more than just expose management interfaces but rather provide automated responses. It’s facile to say that we have to move to “policy-based” operations, but at the very least we have to move to operations that’s driven more by policy than what we have today. So, for Oracle, the key to their Micros success may be what they’re willing to do to automate the cloud they hope to deploy it in.