Too much fluff

Given the "novelty" of cloud - principally as a concept rather than with any technology - I have found a strong need to level set whenever doing anything of consequence with it. Whilst this often is received gratefully, there are many times when level set is written off as "too much fluff" and unnecessary. Where concepts, models, architectures and technologies are well understood, level set is not as important or necessary. Yet with the nebulousness of the cloud - made apparent when it takes a year for the industry to agree to the otherwise self-evident definitions of SaaS, PaaS and IaaS - level set is critical to starting any endeavour, investigation, reporting of results, or other activity. A high degree of FUD still permeates cloud, and not clearing it away through a level set only leads to poor decisions. 

It is a common phenomenon in engineering to focus on detail to the exception of all else. This is a factor of decomposition, yet when details command most or all of the attention for solving a problem, the overall direction is lost. Sun Tzu's statement, "Strategy without tactics is the slowest route to victory; tactics without strategy is the noise before defeat" is just as applicable to engineering as to war. Without an understanding of the problem to be solved and the strategy to solve it, the details are only noise. One must understand both well to be an effective technical leader; one must understand what is the strategy and overall directon to be an effective engineer. 

Still have doubts? Let me tell you a story: A vendor of desktop software solutions not too long ago began to explore cloud as a high-level strategy to lower TCO for both themselves and their customers, largely as a reaction to pressure from Google. The vendor understood the benefits of developing cloud services for their product, but lacked a coherent understanding and strategy for making the transition. There was no level set, and as a result, all thinking delved directly into details - what technologies to use/build, what features were needed, how and where to deploy. The result was an exclusive focus on technology and loss of sight of the problem to be solved. The technology decision was made first, and all subsequent decisions had to fit that technology set. Time and resources were badly wasted trying make something that few users wanted to needed work with the chosen technology; the vendor ended up reinventing in poor form an number of technologies outside their core competencies; the pilot projects failed and were scrapped; and the vendor was set back by several years in their efforts to compete. At very least, the detritus was salvaged toward another, far more limited project which, with the expensive lessons of excessive detail and technology focus, has been able to enjoy a measure (albeit muted) degree of success. All this from "setting the cart before the horse."

The first lesson of the story is the danger of taking technology decisions outside any framework of the problem to be solved and a strategy to address it. When the vendor committed themselves to a particular technology choice outside of any problem/solution context, they limited every decision and direction they could subsequently take, and turned their focus to square pegging everything to that technology. If a particular feature set was not available for that technology, they built it themselves, rather than stray outside the technology base. This was justified with the argument that it would simply be "prohibitive" for their engineers to learn anything new and to not maximise existing experience, which is not unheard of in IT. Failure was guaranteed from the beginning. 

The second lesson is the danger of not level setting so as to ease the understanding of the problem to be solved and how to approach it. Nearly no one in the vendor's technical staff could agree on direction, measures of success, or even what was cloud. Technology focus was offered as comfort food, empty calories to provide a sense of direction where there was none. Since no one could agree on anything other than the technology being used and the issues inherent with that technology, it demanded all attention, and the elephant in the room was never acknowledged. 

It is far more dangerous to not level set than it is to face the slings and arrows of "too much fluff" from those who only want to hear about the details. My advice: Don't get caught up in the "too much fluff" argument. Level set first; permeate understanding of the problem to be solved, the strategy and direction which provide the framework within which to delve into the details. Without this, one is just showing off how well they understand technical details, and not seeking to solve any real, practical or even academic problems. If someone is saying there's "too much fluff" in your strategy, model or architecture proposal (that covers a new or nebulous concept like CC), more often than not, it is really a compliment - it means you're doing enough level setting. IMHO, for topics such as CC where there are few standards and little to no shared consensus, you really cannot do too much level setting. You need to "set the cart behind the horse, not before."

Additionally, with CC, the level of confusion and misinformation is to an extent where level setting is critical. One may think they "get it", but until CC is well defined and at least started on the path to standardisation, it is important to go over the basics so that everyone understands the context. Saying "I get it, let's just dive into the details" misses the chance to prevent major misunderstandings and context switches later on. When people claiming to be architects making statements as, "Cloud? SaaS? That's easy - all I need is J2EE - I can just make my EJBs into services" (which, to the uninitiated, makes as much sense as, "I can see Russia from my house"), it is obvious there is much to cut through to really know what one is talking about with CC. 

So, when talking CC, "too much fluff" feedback likely means you are providing just enough level setting. That's not to say that the same feedback for a well-defined, well-standardised topic should not be taken literally. ;)

Comments

[Alex Williams]

But how do IT people even know what to see when it comes to cloud computing? People don't know the basic definitions for cloud computing terms.

Poor decisions are inevitable when the level of knowledge is so thin. Add on top of that what you describe and the results can be disastrous.

Charlton - I'd be interested in talking with you at some point about guest blogging on this topic.

[charltonb]

Thanks, Alex. This is the heart of the problem. With the industry so opaque on Cloud, IT's understanding depends on what blog(s) they read, which vendors they work with - they will get different definitions from different parties. Without the proper level setting, any discussion on Cloud gets lost in a conceptual mismatch.
Despite the occasional negative reaction I receive for level setting, I insist on it because of this mismatch.
Let's talk further, let me know what works for you.