I’ll be moderating a panel of OpenStack leaders next week at the OpenStack Israel 2013 event in Tel Aviv. Last year’s OpenStack Israel event was excellent, and this year’s gathering looks like it will knock it out of the park. Over 350 people are already registered for the conference, and the two days of technical training following the conference are already full. If you’re in the area you shouldn’t miss this conference. And make sure to introduce yourself to me as well.

In preparation for next week’s event I’ve been formulating tough questions to ask the OpenStack leaders. So far I’ve received great suggestions from Nati Shalom, Randy Bias, and George Reese. Here are some of the questions I’ll put to the panel:

• How committed are you to ensuring compatibility of OpenStack clouds across different providers? What about between versions?
• Why is it so difficult to operate OpenStack in practice? How do you plan to address this?
• Is OpenStack the code or is it the APIs?
• Public cloud providers are naturally incentivized to differentiate by adding proprietary features to their services, thereby increasing lock-in. Doesn’t this pressure to differentiate conflict with OpenStack’s mission to create multiple, interoperable clouds? And, doesn’t this pressure towards fragmentation undermine the value of OpenStack as an alternative to the Amazon Web Services ecosystem? What do you plan to do about this?
• What existing systems are being replaced by OpenStack implementations?
• For the vendors among you (e.g. IBM, HP), how do you plan to make money from OpenStack?
• Why is OpenStack Foundation membership so expensive? What’s wrong with following the model provided by the Apache Foundation? Is the high barrier to entry in the Foundation really necessary?

Do you have a question you’d like to hear the OpenStack leadership address? Let me know, and I’ll report back on their answers.

Before you ask yourself “what can and can’t I do in the cloud,” stop to consider the larger picture. How will your customers know that you have adopted cloud computing? What resulting radical improvement will delight your customers? These questions help you focus on the impact you want to achieve with your initiative. The answers help you understand the facets that you’ll need to address – technology, skills, procedures, and behaviors – in order to achieve and measure that impact. Then you’ll be ready to talk nuts and bolts about vendors, tools, and cloud-appropriate workloads.

For example, my client, CIO of a media company, was enthusiastic about using cloud computing and wanted to get right down to details: what should he move into the cloud, how long would it take, who could help, and so on. After walking through the questions mentioned above we made several important discoveries:

• External customers wanted a streamlined billing process.
• Internal customers wanted to eliminate boring, error-prone manual work.
• Neither group of customers cared what technology was used.
• He didn’t know the effects of the current billing process on satisfaction, retention, and revenue.

It was clear that the project was more properly regarded as a customer retention initiative, not as a technology adoption effort. As a result, the CIO immediately knew what he had to do: measure the effects of billing on customer satisfaction, retention, and revenue; and he needed to recast the cloud computing adoption program as a program to substantially improve customer satisfaction. These guidelines provided the business context within which his staff was able to make intelligent, focused decisions about implementation details.

Next time you find yourself asking about what workloads to move to the cloud, think about the only thing that matters: what will delight customers?

Whether you operate IaaS, PaaS, or a SaaS service, watch out for these three pitfalls to the success of cloud offerings:

1. Encouraging the wrong thing. Measuring the success of the offering by looking only at utilization metrics damages sales. One cloud service provider measured the success of its IaaS service – and compensated its sales force – based on virtual machine usage. Little surprise that, for all the years that this practice continued, the provider could not land strategically important accounts. Like in any mature sales operation, your prospective cloud service clients should be evaluated based on several criteria, including:
   • strategic fit
   • urgency
   • reputation
   • visibility
   • cost of sale
   • short-term sales potential
   • long-term sales potential.

   Make sure you evaluate all these elements, and that you prioritize your sales and marketing efforts toward prospects with the right combinations of all these factors.

2. Ignoring the relationship. On-demand and pay-as-you-go are not simply usage models; they are components of a new type of customer relationship based on transparency and immediacy. Make sure your customer relationships allow for:
   • Seeing usage and  billing easily, and up-to-the-minute.
   • Setting custom notifications and enforceable consumption limits based on both usage and cost.
   • Getting quick notice of service degradations and their ongoing status.
   • Being reassured after service disruptions that you have identified the cause and taken steps to prevent a reoccurrence.

   Your service may have other ways to build a customer relationship based on transparency and immediacy. Identify and exploit them.

3. Focusing on infrastructure reliability. Selling a cloud IaaS service that differentiates with higher level of service reliability is not sustainable; instead high-SLA workloads must be built using cloud-appropriate designs. Any IaaS provider who tries to compete against the commodity non-reliable infrastructure clouds by offering a higher SLA engages in an unwinnable battle: the cost structure will make it impossible to compete against commodity offerings. As computing services become more commoditized, previously established patterns of infrastructure usage (aka “best practices”) that called for highly reliable hardware and “N+1″ architectures are architecturally moot. Following those patterns in the cloud will not increase overall workload reliability. Instead, workloads that use cloud infrastructure need to be designed for scale-out and rapid recovery from infrastructure failure, providing overall workload reliability via software. The overall cost of reengineering workloads for cloud-appropriate architecture will, in the end, be less than the cost of building and operating a cloud that delivers a “classic” hardware-based HA.

Don’t make these mistakes. They could be killing your cloud business.

This coming year tens of thousands of medium and large companies will conduct initiatives to adopt cloud computing – and most of these will fail. The cause of these project failures will be unrealistic expectations. The inoculation is a hefty dose of reality. Get your vaccine here.

No one questions the fact that IT is undergoing a revolution and cloud is at its center. You need only glance at the article titles in any business and tech publication to see this. Cloud is a critical element in achieving unprecedented agility and supply-chain optimization.

However, will cloud alone get you these purported benefits? No, it won’t. Nor will any single vendor’s solution. Nor will the time and resource investment required to get there be small, as I’ve discussed previously. Shame on the vendors, analysts, and pundits who claim so or set this expectation in meetings with their prospective customers.

Reality. The flu vaccine for cloud-high cloud project expectations.

Let’s set some proper expectations. Real change requires serious investment, time, resources, and oversight. The larger the ship, the more difficult it is to adjust course. Here’s what to expect a successful cloud adoption program to look like:

• It will be a multi-year effort.
• It will require investing a significant percentage of your current IT budget just to properly plan. And significantly more than that to execute.
• It will require adopting new technology and changing the way your people work.
• It will demand the participation of your customers – internal and external.
• It will demand executive-level leadership, involvement, support, and prioritization.
• It will fail if you think otherwise.

The cloud adoption flu season is upon us. The best way to protect yourself is to understand the reality of cloud adoption initiatives – that’s the vaccine.

Meeting business and technical requirements is important, but to what extent is your organization ready to accept the changes that your new initiative will introduce? In my work with global clients I’ve identified three critical elements that govern the success or failure of these initiatives:

• Diet: How much is risk-taking accepted, encouraged, and rewarded?
• Taste: How much does past experience support or undermine the changes that will be introduced?
• Appetite: To what degree do people see their jobs getting easier as a result?

Like we (should!) do with our eating habits, we should create a change program that respects the diet, taste, and appetite of the organization – or changes those elements if needed – to ensure maximum health. Only when you and your organization are in good health can you maximize your success and capitalize on unforeseen opportunities.

It may sound strange, but your organization does not need a strategy for cloud computing. You no more need a strategy for cloud computing than you need a strategy for toothbrushing: as long as your teeth are healthy, who cares if you brush from top to bottom or from left to right, or what brand of toothpaste you use!

So it is with cloud computing: your organization has a business strategy (if not, give me a call). Does that strategy include developing enhanced agility, improved time to market, and increased innovation? If so, then take a deeper look at cloud computing, and build a concrete plan to use cloud computing to fulfill your business strategy.

You don’t need a cloud strategy. You need a business strategy, and a concrete plan to achieve it. If cloud supports that business strategy – then go for it.

Building and operating a private cloud ourselves is simple, right? Give our experienced IT folks a budget for hardware and software, a clear mandate, and deadlines, and we’re likely to succeed. That’s what we’ve always done, and it’s worked out tolerably well. Private cloud isn’t so different from running our own virtual machine environment, and we do that already, so why wouldn’t we succeed? I hear this sentiment expressed often so it seems to be a widely held belief. But it’s wrong precisely 97.73 percent of the time – I measured. Unfortunately, too many organizations act on this mistaken belief and experience unnecessary hurt as a result.

My good friend Keith Hudgins made this point cogently in his presentation at the CloudConnect conference in Chicago. Keith is one of the few people who really knows what it takes to build and run a cloud: he was part of the core team with me building KT’s public cloud service in South Korea, and he is currently Senior Cloud Engineer at enStratus where he helps enterprises get their private clouds to work properly. Keith’s presentation was sobering for the audience members, several of whom said they plan to reevaluate their private cloud initiatives as a result.

If you want to succeed at your own private cloud you need to consider these four critical aspects: your users, your competition, your skills, and your technology. Know these four and you have a fighting chance to make it. If not, get help – or prepare for disappointment.

Know your users

Different users need different applications, and your cloud must be designed to support the required applications. Private clouds might have three different types of users:

• Regular desktop users, the kind of user most likely found in your Finance, HR, Sales, and Marketing organizations, will need your cloud to support the applications your IT department currently supports already: CRM, accounting, ERP, and business applications your IT department is already familiar with.
• Software R&D staff will need your cloud to support the development environment, tools, and deployment processes they’re already using. This group will also likely need training to properly architect and operate reliable applications in a distributed environment.
• IT staff will need your cloud to support core capabilities such as backup, directory management, and file sharing.

Know your competition

Odds are your users already use public cloud services, and – like it or not – your own private cloud will be competing against those public alternatives. How well do public cloud services meet your users’ needs?

• How reliable is their service? How does this compare to your own historical reliability?
• How easy are they to use? Do public cloud service customers need multiple levels of corporate approval to acquire resources, or is the ordering and fulfillment process seamless and extremely short – a few minutes at most from order to delivery? Can you deliver the same or better usability?
• How good is their support? Are there multiple sources for expertise and communities where users can share solutions and experience?
• How rich is their ecosystem? How easy is it to employ a vast variety of tools and seamlessly integrated value-added services?

Know your skills

The skills required to build and operate a cloud are not taught in classes, they’re learned by experience. These include:

• System administration. Okay, this one is taught in classes, but the issues you’ll experience in a cloud environment are much more complicated and at a larger scale than you will normally encounter elsewhere. Keith suggested that OpenStack and Eucalyptus will be a challenge for your team if they lack linux administration skills.
• Storage management skills are critical because storage is the most complicated technical aspect of a cloud. Keith emphasized the importance of NAS and iSCSI setup and management experience.
• Networking is a key element of the cloud and networking expertise must be a part of your core cloud engineering team.
• Automation will dictate how quickly you can recover from problems, so you must be experienced in its use and integrating automation tools into your workflow. Identical inputs (that is, identical hardware revisions) must always yield identical outputs, and that is only possible at a large scale with automation. Keith pointed out that automation takes time to produce. Make sure your team is proficient with the automation tools that work best with your technology choices.

Get these skills if you don’t have them. They will influence your choice of hardware and software.

Know your technology

Cloud is powered by technology, so you’ll need expertise in at least the following four technical areas to build and run it yourself.

• Cloud Management Software is the layer that provisions cloud guests and sits between the API and the hypervisor. If you can’t explain the differences between the four major cloud management software options – CloudStack, OpenStack, Eucalyptus, and OpenNebula, then you do not have the expertise to choose the right one for your needs.
• Storage, Keith pointed out, is by far the most complicated technical aspect to get right in a cloud. Local guest storage is the simplest to build and operate, but limits the range of applications that can be easily supported on the cloud. Attached storage increases flexibility at the cost of complexity. And object storage requires lots and lots of disks. Your options will be influenced by your choice of cloud management software, and any change to the default configurations will require serious development and testing to get it right.
• Hardware and the way you manage it is the most important choice you can make. Of all the components in a cloud the hardware is what is going to break, so the ease with which you can replace hardware will dictate the maintenance headache. Keith provided some hard-won tips: make sure your hardware vendor can supply identical hardware down to the BIOS revision, create (automated) procedures to verify or reject hardware as it is delivered, and diligently avoid hardware inconsistencies since they greatly increase the complexity of the endeavor.

Do you have what it takes?

The above four aspects are critical to successfully building and operating your own private cloud. There are other success factors – know your strategy, know your business model, and use effective project management – that are part of any successful technological change. But the above four are critical in any private cloud initiative. So, how do you rate on these aspects?

Odds are, you don’t have the expertise required to do it yourself.

Back in the early days of computers, or so the legend goes, when an entire room housed less computing power than in today’s iPhone, a large government agency had a serious problem: their computer system stopped working. Though it was only three weeks since the system had been certified, the startup sequence refused to complete, leaving the agency lacking critical operational capabilities. Work on the project ground to a halt while every engineer on staff checked and rechecked wiring, tubes, and relays to find the issue. But two weeks of troubleshooting amounted to nothing, and the Director of the agency was beside himself with frustration. He decided to hire the worldwide expert on such computer systems, a retired professor who was known for his sense of humor.

The professor arrived on site in a white lab coat, was briefed by the Director, and immediately asked to be given access to the computer room. Once there, he proceeded to walk around the room from cabinet to cabinet. The Director and his staff watched with increasing curiosity as the professor paused before each cabinet for a moment, scratched his beard, muttered under his breath, and moved on to the next cabinet. Finally, after forty five long minutes of this, the professor stood up more erect, smiled at the Director and his staff, withdrew a piece of chalk from his coat pocket, walked over to one machine cabinet and marked a large “X” on the side of the cabinet. “Your problem is in here,” he said confidently. And, sure enough, as the technicians opened up the marked cabinet, they discovered a subtle wiring issue that had been missed by all previous inspections. Gratefully, they fixed the problem and were able to resume operation. “Please, send me your bill – whatever it is, I’ll see that it is paid promptly,” said the Director.

The professor sent a bill to the agency, a one-line invoice for “troubleshooting: $1000″. Unfortunately, as government policy dictated, the Director needed a detailed itemized invoice, and he was forced to delay payment and request the proper details from the professor. The professor’s corrected invoice arrived, and it read as follows:

One piece of chalk, with which to mark the problem: $0.01
Knowing where to place the mark: $999.99

The real value to your customers is in knowing how to fulfill their needs. All the rest is a commodity.

Simon Wardley recently satirized the typical response of corporate IT departments to technology change as follows:  Ignore, ignore, ignore, “no”, “no”, “I said ‘no,’ dammit”, “Oh no”, “Oh, f**k”. It reminds me of the classic Toys-R-Us TV commercial from the 1980s featuring children singing about not wanting to grow up. Resistance to change is not unique to children or to IT departments – it is a feature of every organization. How can you help your organization avoid being stuck, and instead drive change before it’s unnecessarily painful to “grow up”? The key is urgency. Growing up is a good metaphor for organizational change: both are normal, both feature resistance, and in both the stakes increase over time. Immature people, like immature organizations, do not reliably achieve their goals. And the longer that inertia dominates, the further behind they remain. Failure to adapt – getting stuck – can be fatal, as it was for the Eastman Kodak Company. In personal as in organizational growth the pressure to change – the urgency – is fostered by discomfort. To increase urgency you need to cause people to feel discomfort with the current state of affairs. John P. Kotter’s seminal work Leading Change offers several kinds of tactics to increase urgency:

• Show that the present isn’t working: Allow a crisis to happen, publicize poor results, force encounters with unhappy customers, publicize lost opportunities.
• Change the metrics: Create performance targets that are high enough and/or broad enough they can’t be reached with business-as-usual.

These tactics to increase urgency all work by fostering discomfort with the present. A client found himself spending inordinate lengths of time evaluating opportunities and procrastinating a decision on which ones to pursue. When I showed him how his lengthy decision process was limiting the number and quality of opportunities that presented themselves, he realized that he could grow his business significantly by streamlining this process. He saw the urgency of addressing the issue, we worked together to fix it, and his business has grown threefold since.

Creating a sense of urgency is the first step in a successful change program. Kotter describes further steps to a successful change effort, but urgency underlies them all.

In short:

Ouch! Now, change.

An informal survey of my application developer friends revealed four main types of motivations driving developers. These four types of motivations are represented in this diagram:

Individual developers can be motivated more or less altruistically. Individual developers can also be focused on the external manifestations of success – such as appreciative customers – or on the internal manifestations – such as more power or money. The diagram above is not a judgement of “better” or “worse” motivations – it is simply meant to capture two personality factors and their expression among individual developers. Also note that developers may have different motivations at different times, or even simultaneously in combination.

Just as individual developers can have varying motivations, organizations can also be more or less altruistic, and focused more internally or externally. Internally focused organizations spend an undue proportion of their energy and resources doing work (or inventing work to do) that will not be visible to the outside world, while externally focused organizations measure their results based on their effect on the outside world – market share, profit, and customer satisfaction.

Where do you rate your organization on the above diagram? Most business leaders want organizations firmly motivated by providing value to the customer, and software businesses are no different. Developing software is all about delivering value. Your software development efforts can only provide value if they are successfully delivered to the customer – and in today’s “as-a-serivce” world, that value is constantly provided via the internet. This means that you should spend significant effort ensuring your customer can actually reach your service to receive the value. It means automating your deliveries. It means measuring and improving your delivery speed and success rates. It means involving your customer early on so that you know the value they seek and so you can provide it. It means making sure all your teams work together to get this to happen.

Because ultimately, it means a developer’s job is not finished until the customer has derived value.