One of the Hidden Challenges of Cloud - the Blank

I spent many years as a developer in embedded systems, working on control systems to run everything from washing machines and ice makers to engines and transmissions. I learned in that time to make a product great required people who were able to forsee and avoid issues, and those who were able to debug and fix problems. As I transitioned into enterprise IT I found the same rules applied. That combination of talent is behind all great solutions from bridges and governments to iPod's and operating systems.

Considering the technological breadth and depth of cloud which crosses every technology boundary and impacts elements in every layer, no one person can be a one stop solution shop. It will take time and experience, successes and failures, before even the smartest gain the insight to know instinctively what works and what doesn't. And therefore like all new grand experiments we need to start off with the soundest foundation we can which gives us the greatest flexibility to adjust as we learn.

Inherent in this approach is having two talents at our disposal: the cloud architect who views cloud from the business point of view as a technology implementation of a business process; and the blank. It's not a sexy term, the blank, but it's very appropriate. Most organizations have architects, or at least an architect, who is responsible for ensuring technology is implemented logically according to a master design which aligns with the business strategy. These architects are always focusing on the future with limited feedback on how things are working today. However I have yet to find a company or person whose sole job it is to identify and resolve issues and inefficiencies; someone focused on today and how to make things better in the future.

Today when an issue arises it goes to a committee of people: application and data gurus, infrastructure engineers, architects, security shaman. There is no role responsible for capturing a problem, identifying the cost of the problem, then resolving the problem if its worth resolving. As a result the tools we employ to identify and debug problems is deplorable. Our infrastructure teams have gone the furthest down this route in both methodology with ITIL and tools including instrumentation and health monitoring. What about the other three fourths of the world: applications, data, and integration?

Cloud computing only works when the user uses the application. Whatever process it is the user wants to execute must come to a complete and acceptable resolution for the user to continue using the application. Cloud solutions are inherently complex leveraging a dynamic set of services across a dynamic infrastructure with a combination of static and potentially dynamic data sources. Yet for the most part the only tools available for tracing the cause of a problem end at the boundary. If the process doesn't end at the boundary neither can the debugging. If we can't resolve the problem quickly the application provides no value to the user, and tolerance continues to dwindle.

Today we rely on the hero model; that really smart person or group of people who combine intelligence and experience to sweep in and save the day. In the cloud we need to reset that experience to near zero while at least doubling the breadth of the issue. Our only option for survival is to start emphasizing the need for robust tools. However without a focal point, a role whose success depends on such tools, the tools will continue to stop at the domain boundaries: infrastructure, applications, data, and integration.

We need the blank, or perhaps a better name is Quality Architect, a role across domains responsible for ensuring our systems can be debugged, our knowledge is increased and captured, and for being the person in charge when a serious issue arises.

Today it's a blind spot we survive by luck and hard work. In the cloud with it's ability to rapidly scale and morph, that blind spot will become a killing field with the careers of well intended but unsupported IT experts littering the ground.

The CIO, the train, and the tracks

In today's IT world the center of the universe is the CIO. They are tasked with ensuring IT is aligned with and delivers on the business mission. Today's CIO's are very business savvy with experience across multiple operations and support units. Often they know how the business operates, the underlying processes and compliance requirements, better than the line of business executives and sometimes better than the COO. However what has been lost over the past 15yrs is a fundamental understanding of technology. I recently had a CIO tell me at a conference "This job is great because I don't have to understand any of the technology stuff; I have a staff to do that. If I had to understand it all I'd be out of a job". What she doesn't realize is she has been laying the tracks to her own destruction for years by not learning about the technology and soon the Cloud Computing train is going to run her down, run her over, and keep on running.

A CIO needs to be a balance between business acumen and technology expertise. They don't need to be an expert in either, but they need to blend in on both sides somewhat like a chameleon. How many COO's know how to operate a stamping press, extruder or fork truck? Probably more than you realize but certainly not all. However they know what the equipment does, why it does it, it's value in the production chain, and often how it operates. I grew up the son of an operations executive in the food industry and I can tell you he knew how every part fit together. Why? Because when bad things happened he invariably got the phone call. Many of our new CIO's have never spent a day in IT prior to becoming an executive. Nobody appreciates the balance between the portal, application, enterprise service bus, and database and the underlying utilities, operating systems, processors, storage arrays, networks, and security appliances who hasn't served in an IT operations role. And think of everything I'm leaving out: architecture, quality assurance, requirements, SDLC, etc, etc, etc.

People today see technology as so complex and difficult to understand and yet they use it in their daily life without a moment of pause. The reality is technology is not complex in its implementation. The complexity is in developing new technologies, a business the vast number of CIO's are not and will never be involved in. So this false wall they hide behind is inexcusable. They should be a technology expert as much as a business expert. They should be held accountable for the architecture as much as the budget. They should be able to explain how a database operates as easily as how depreciation is applied to hardware.

We need to raise the bar!

The train is already on the tracks and it's accelerating. I predict cloud computing will end the careers of 50% or more of the current Fortune 1000 CIO's. Why? For several reasons:

1. Some will be held accountable for not researching and implementing these technologies when they started appearing in the 2001-2005 timeframe. Think of all the lost value that accumulated over the five year period from 2005 to 2010 as companies ignored cloud.
2. Many will simply be outpaced by their younger, nimbler competition who understand that CIO's need a balance of skills and can operate as their equal on the business side while still having deep technology knowledge and experience.
3. Most will be held accountable for a series of failed implementations because they waited to long or never did develop a cloud strategy. So many of the implementations today have been built to a vision with no supporting strategy. Already companies are scrambling to remedy siloed cloud implementations and rationalize multiple instances of the same cloud service.

Whether or not my prediction comes true is largely based on how the media covers cloud, how well CEO's hold their CIO's accountable, and vocal shareholders become. CIO's already have low tenure so my belief is it won't take much to tip the balance.

If I were a CIO I'd be sure to get educated, identify a successor, and get my finances in order.

Cloud is a Good Thing - Vendor Lock-in Is Not

I equate vendor lock-in to anti-cloud. The entire purpose and value proposition of cloud rests on it having dynamically defined borders. Such an open architecture requires, by nature, strong standards to facilitate the interchange of data, processes, and policies. However underscoring the lack of available expertise in the market and the willingness of leaders to attack without understanding, companies are moving headstrong with short-sighted tactics (I dare not call them strategies for the amount of thinking support the tactic is barely enough to call it more than a whim!). Companies are simply mortgaging their future for benefits today.

The landscape today is Private Cloud. I have yet to see interoperability standards proposed by or supported by a Private Cloud vendor, whether a software provider such as VMWare or a service provider such as Amazon. It was only a few years ago where the cost of virtualization software was so high it was cheaper to add physical servers. Adopting a proprietary platform today is likely not only to lead to higher overall costs, but solution isolation without the adoption of interoperability standards.

As is most often the case I believe it will fall to the open source world to define, build and adopt open standards. Xen came in to existence to duplicate VMWare without the high cost, bloat, and closed architecture. Look at what Amazon AWS has done with Xen! A full slate of tools of in development in the open source community along with improvements in open source operating systems which will subsume many of the capabilities paid for in VMWare, Hyper-V and other solutions today. What today is a service or software will become a component and foundation.

I'm not ready to short the stocks of EMC (VWWare's parent), Microsoft or Citrix (owner of Xen), but I'm watching closely!