I made a comment the other day on the EBizQ Cloud Camp panel that was off-the-cuff (meaning, I hadn’t prepared to say something like this, in fact, it kinda just rolled out of my brain on the spot).
It had to do with the difference between SOA infrastructure and the Cloud. I mentioned that cloud computing offers benefits of agility and time-to-market, and was called-out on the fact that that’s what vendors said the benefits were to SOA. What’s the difference? Why is Cloud going to be different?
My answer was that Cloud is going to force a lot of issues because as an external service provider, there can’t be any informal handshake agreements as their would be within an enterprise. Being formalized, cloud providers will have to figure out a way to do the governance... only the solutions they deliver to market are going to have to reflect the true cost. That is, the cost of the service plus the governance of the service.
@KevinJervis asked me to followup with what I meant. How will cloud force these issues?
In short, cloud companies need a valid business plan... reflecting the costs of the service they provide, and governance of the service. Innovative features are critical - easy versioning, rapid root-cause analysis, flexible and customizable security contracts, and personalized SLA’s. Critical for differentiation and for creating satisfied customers. These features come at a price... and their business plans need to reflect the costs of the “whole product.”
I’ve seen the following situation happen over-and-over. A customer plans a project. That project includes a “grand vision” of what they’d “like to accomplish.” Reality sets in and they find ways to do without. Perhaps they cut back on redundancy or they share servers with another project. They cut out “management” (gosh I hate that word) figuring that at first, they won’t have many users of the service, therefore “management” can come later. This happens “intrinsically” as well... shortcuts are taken in the development of the service just to “get it out the door.”
The problem is that these short cuts are often not really explicitly declared. Or, they are declared and conveniently forgotten.
These short cuts save costs and reduce functionality... yet when functionality is expected, the costs are not remembered. I hope I don’t sound bitter but I am frustrated. This technology stuff is hard, and we forget that because the baseline is so low to get started. But, to elevate it to an art-form... takes a seemingly-disproportionate amount of work.
So, what happens? A service oriented project is planned. As part of the planning, a “full” governance solution is designed. However, for the sake of time-to-market and cost, the governance stuff is left out until a later phase. Service levels are delivered through one-off agreements and over-capacitization (putting in a heck of a lot of capacity for not so much use - after all, you can’t buy 1/2 a server, right?). And, governance is forgotten. Service levels are met, until they’re not. Often, “cost-free” arrangements get project teams part way there. To some extent, you can use existing management systems, with manual configuration to get some of this stuff done. And, after all, why put in the capacity for versioning easily when you’ve not even deployed your first version?
I admit that this approach within the enterprise is normal - natural even considering business reality. It might even work for a year or two, or at least until, as with so many applications, the cost of ownership goes up. Services are shared much more than they were initially and manual procedures don’t work. So many things have been moved into and out of production, that you can’t trust anything but log files... and we all know how hard it is to troubleshoot a distributed application checking log-files across hundreds of machines.
Cloud providers can’t do this. Just to stay in business they’ll have many users very quickly. And, they’ll probably have custom service level agreement requirements from the beginning, they’ll need to decouple these customers from each other by default. They can’t have “informal handshake agreements” between teams to “do their best” to make this all work.
Even if they don’t have a “full blown solution” up front, they do need to make sure the right costs are built into their business model. And, that’s where it differs from within the enterprise. There is less rigor within the enterprise for building a proper business model. Many may disagree but I believe this to be true. (Not unreasonably so... it’s very difficult to account for everything that goes into a project, some costs are just assumed... but an assumed cost to a business unit directly hits a cloud provider in their bottom line).
Let me leave with an analogy this time.
We’ve all heard the idea of behaving in a way that wouldn’t leave us embarrassed if it ended up on the front page of a newspaper. Truth is, in the past much of our behavior would have no chance of getting that much air time.
Social technology changes that. We’ve all see videos of people throwing tantrums in airports, listened to recordings of obnoxious people on the phone, and even seen emails that executives presumed would stay within their company.
I believe this is one of the chief benefits of social technology. We will all be accustomed to always being on our best behavior because you never know when someone with a camera phone is watching.
It’s the same thing in enterprise technology. As soon as someone breaks a piece of something out of the enterprise, and offers it as a service, all the costs, implicit and explicit need to be reflected in the business model. These costs become exposed just like people’s worst behavior. Sometimes this exposure is OK because a specialist can perhaps do things cheaper than a company for which the activity is not their core business. However... in this case, we’ve been fooling ourselves into thinking we have been truly governing our services, when in fact, that is anything but the case. Cloud providers have no choice, and their business models will have to reflect that.
I know this is a long post, and I hope I’ve answered Kevin’s question well. As always, you can find me at @djbressler for followup questions and conversation on this topic.
