And to those just tuning in - Private Cloud is a bad thing

Private Cloud, in itself, is not bad. Rather what I find is that companies are willing to blindly follow the Private Cloud mantra while heaping their own expectations of an Amazon AWS or Microsoft Azure solution on top. As a result the deliveries fall well short of the perceived goals leaving companies in a no win situation. The cause of this problem is the vendor push behind Private Cloud solutions which naturally want to make it sound like a pancea for taming the infrasructure beast. In reality Private Cloud is in its infancy and is about 5-7 years behind Public Cloud in maturity.

Private Cloud implementations often mask or ignore the following:

• Enterprise Cloud Strategy development
• Governance
• Migration costs
• Application development costs
• Learning curve
• Disaster recovery effectiveness
• Success metrics
• Accounting, Tax, and Finance change
• Legal impacts
• Data integration

I can understand the lure of a "private" cloud: COST SAVINGS! Who can shake a fist at that? IT is expensive, not as expensive as the manual labor it replaces, but more expensive than free. Executives would prefer an IT that costs nothing to maintain where more can be done with less until an infinite workload is accomplished with nothing.

A cost savings focus is a myopic view of the future which necessarily puts more important agendas like growth on the back burner. My father, a retired Fortune 10 executive, always says "You can't cut your way to growth". Yet today the vast majority of Private Cloud implementations are driven by expected cost savings. So what do I believe is the right view? Cloud as a revenue generator, a driver of new business opportunities by engendering models not realizable with current IT structures. But of course this view threatens the very safe, reliable foundation of today's IT.

So let me point out how Private Cloud falls short on cost savings:

First, private cloud increases risk by moving companies to adopt a single vendor's proprietary technology. No vendor today has a complete private cloud in a box or offering. Rather vendors have gathered together technologies from across their portfolio to provide a glimpse of cloud but what is really just virtualization. Virtualization is good, but it's not cloud. I have yet to see a private cloud vendor offering that addresses the 70% of cloud that virtualization does not: software services, SLA based management of applications, automated scaling of resources based on application use and need, automated recovery of services, etc. Some of these things you can do with those vendor solutions, but it's an afterthought and what is offered is such a weak solution few if any have implemented it. Ask the vendor for a list of installations and it looks impressive. As a vendor for the list of clients who use 100 or more instances and the sheet staring back at you will be blank. Vendors are following the analysts too; if they could see they'd be leading rather than following.

Second, Private Cloud pretends to be a holistic solution but it's not. Again nothing is provided for in migrating applications into the cloud, and without applications all private cloud does is create larger silos. Most often there is no consideration for future integration with public cloud locking out the opportunity to access the lowest cost resources available. In addition Private Cloud requires a company to grow an expertise base that cloud as easily be outsourced where the implementations from an availability, security, and performance point of view are generally accepted as better. Once the cloud is up and running it should take very little effort to operate it; otherwise it's not a cloud. The money should be spent in building up application layer expertise in cloud which is much more expensive.

Third and most important, Private Cloud failures, and there are plenty, give cloud a bad name creating conflict for future adoptions potentially alienating one of the most valuable technological movements since the development of the relational database or the Internet. Companies are already having to rationalize cloud solutions that are only five and sometimes only three years old. Nobody wants to present to the CIO that a new solution is already in jeopardy. When I ask people why they think this happens almost 100% say its because of undetected security issues which is incorrect. The real reason is the unrecognized need, complexity, and cost of integration.

So to those who are learning I say welcome! To those are surprised to learn that private clouds could be a bad thing please do your own analysis. Cloud computing is one area where you need to do your research not only on the topic but also on those to whom you rely for knowledge.

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.