The-Business-of-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. ...

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. ...

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: ...

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. ...

Like companies producing any kind of offering, software companies require three elements in order to successfully deliver: knowing what to build, knowing how to build it, and knowing how to deliver it to the customer. When each of these three functions - research, engineering, and delivery - does its job independently, you get slow progress and uninspired, sub-par products. But when all three functions work together in a customer-centric fashion, you get excellence - in implementation, innovation - in concept, and world-class results - by delivering those two to the customer. ...

Traditional descriptions of cloud computing and the various cloud operating models - IaaS, PaaS, SaaS - focus on the locus of responsibility for various layers of the system: facilities, network, storage, servers, etc. But these descriptions typically omit a critical element. Can you spot it in the diagram below? The missing layer is the only layer that really matters - the customer. Ensuring that your application can actually be consumed - that delivery can be successful - is a critical part of providing your value. Your application’s facilities, network, and storage may be running properly, but will your customers actually benefit? Without a properly staffed, trained, equipped, and managed operations team, your service won’t last long enough for customers to care. If your customer is important, then so is your operations team. ...

The owner of a home-based baking business once described his marketing strategy to me as “my cookies speak for themselves.” True, they were delicious cookies. But he completely neglected marketing so his customer base never grew beyond friends and family, and his business failed as a result. At a recent client meeting I was reminded of that baker. The CEO of a fledgeling tech business said to me, “our differentiating factor will be our superior service quality.” ...

A very good repeat client introduced me to his own customer, CEO of a fast-growing company, with the words “you should talk to Shlomo - he does wonders.” When I get an enthusiastic referral like that - which happens often, as most of my business is via referrals - I move fast to see how I can help. The CEO and I met and began to explore important areas of his business that I typically help with: usage of cloud resources, leveraging the data collected, streamlining processes and team dynamics. The discussion was progressing quickly - in fact, too easily, too rapidly - toward defining a potential project. I sensed something was wrong. He couldn’t describe why he wanted these things to get done; all he could say was, “this is the next issue we need to tackle.” ...

Today I presented at the Enterprise Cloud Summit at the Interop conference. The talk was officially entitled Ten Cloud Design Patterns, but because my focus is on the application, I re-titled it. And I mention more than ten patterns, hence the final title Many Cloud App Design Patterns. I explore a number of important issues for cloud applications. Application state and behavior must both be scaled. Availability is dependent on MTTR and MTTF - but one of them is much more important than the other in the cloud. Single Points of Failure are the nemesis of availability, and I walk through some typical patterns for reducing SPOFs in the cloud. ...

The need for cloud provider price transparency. What is a workload and how to move it. “Open"ness and what it means for a cloud service. Various libraries, APIs, and SLAs. These are some of the engaging discussions that developed at the Platforms and Ecosystems “Birds of a Feather”/“Unconference”, held on Tuesday evening March 8th during the CloudConnect 2011 conference. What about the BOF worked? What didn’t? What should be done differently in the future? Below are some observations gathered from early feedback; please leave your comments, too. ...