It’s that time of year again where I realise that I need to resolve to start blogging again. Luckily this year my inspiration was provided on new years day by a conversation on twitter sparked by Randy Bias over whether NIST is a fail or not (contained in his excellent cloud retrospective post).
I completely agreed with Simon Wardley’s view that as a mechanistic description NIST wholly fails to address the fundamental reasons cloud is important, summarised by these two tweets from the discussion:
“The definition helped to try and identify what is cloud but did nothing to explain why. It was pure mechanistic drivel…”
“… and that’s the real problem. If you think you understand cloud from reading NIST, you’re going to make horrendous mistakes.”
Falling transaction costs, the melting of enterprise boundaries, the shift to service business models and accelerating commoditisation – as examples of the ‘why’ of cloud – are not covered at all and therefore it would be all too easy to take these mechanistic descriptions and implement something that looks like them but which has not been created to address such wider business imperatives.
Without understanding why you need to address the impacts of cloud it is all too easy to re-name your existing stuff or build something that appears the right shape without actually creating something that meets the extraordinary business challenges that cloud is unfolding. Such efforts invariably become about polishing existing enterprise IT models and not about a re-evaluation of your enterprise business models backed up by new technology architectures to leverage the fundamental disruption in the way business capabilities are supplied and consumed. This is also my fundamental issue with many private cloud implementations – most have nothing whatsoever to do with ‘cloud’ as a disruption but are merely mechanistic implementations driven by people who don’t understand the why.
Simon (and indeed Randy in his original post) are completely correct to point out that definitions that purport to ‘define’ cloud without providing the context to enable you to understand the ‘why’ (and therefore the potential impacts and necessary business strategy required to respond) are in my view not just a fail but fundamentally dangerous. For me this danger exists at both the micro and macro levels – at the micro level single organisations will implement stupid solutions due to misplaced confidence and a lack of understanding of the forces they are facing, while at the macro level vast numbers of organisations will waste 1000s of years of effort and billions in investment building the wrong things or generating hot air discussing pointless virtualisation and infrastructure topics (often considered de facto as “cloud” due to the lack of a sufficiently multifaceted understanding of what cloud actually represents.)
All of this comes back to the need to think about why, what and how and the interplay between them. Simplistically we can consider that why shapes what you need to deliver and what shapes the scope of your how. From my experiences in business architecture I can say that most organisations seem mired in the endless management of hows and have lost sight of both what and why – from that perspective being given a set of abstract whats to fulfil by an organisation like NIST would appear to be a good start as it at least allows people to realign their hows to fit the definition and declare “cloud” success.
This is the overwhelming danger, however, and the reason I would agree that the NIST cloud definition is a fail. In reality “successes” declared as a result of simply aligning to the NIST definitions will be massive failures of strategy without either an independently developed, deep understanding of the broader disruption or a startling case of serendipity.
The reality of cloud is the accelerating disruption of every industry as commoditisation and a shift to service models plays out; simply rebadging your existing IT or meeting your existing challenges with investment in ‘better’ technology will simply not cut it.
This is why NIST is fundamentally a fail from my perspective – not because of the definitions per se but because they present a structure to act without understanding. Structuring your cloud efforts around a mechanical definition without fundamentally understanding the wider disruption that makes your existing models obsolete will just consume a lot of expense to deliver outcomes with wholly the wrong profiles – leading me to genuinely question whether some organisations who do this could founder.
I guess in some respects people may feel it is unfair to brand the NIST definitions a fail for these reasons and point to the failure of consuming organisations to properly understand the context in which they should be applied – there may be some truth to this rebuke but organisations are often ‘stupid’ (or at least blind to change) as they were designed for a different purpose. From this perspective providing a definition that can seemingly be satisfied with a polished status quo – especially given entrenched interests within the IT department and some suppliers – without forcing people to confront the dire consequences could be considered irresponsible. Given the state of the art, the position of NIST, the ambivalence of many incumbent technology suppliers and the maturity of adopting enterprises, taking such a position seems to me a little like blaming blast damage on a toddler who is given a gun rather than the adult who hands it over. With great power does indeed come great responsibility, lol.
So the core lesson for me is that people need models and taxonomies that place the elements of cloud into some kind of framework for describing both why and what in order to enable understanding, reasoned separation of business models and discussions about innovation in the how. It has saddened me over the last few years how few people – like Randy, Simon and Krishnan in their twitter conversation and wider writings – are truly wrestling with the difficult why of cloud vs the slightly larger number of worthies thinking out of context about the what of cloud vs the vast number of rudderless and noisy idiots who have flooded the web with the half-arsed, contextless how of cloud (which inevitably has something to do with virtualisation, sigh).
UPDATE: After my original post I had an interesting debate with Christofer Hoff who had used the same ‘why, what and how’ structure to argue the complete opposite point in a blog post I missed. I’d recommend reading his “When A FAIL is A WIN” post as well to see the other side of the argument.