Breaking the Cloud Barrier
On October 14th, 1947, Chuck Yeager became the first human to break the sound barrier, flying the Bell X-1 experimental plane. Prior to that event, there had been serious doubt about whether it was possible to break the sound barrier at all: aircraft approaching the barrier had experienced buffeting, instability and even crashes. However, Yeager’s flight was remarkably smooth: his plane had been designed for supersonic flight. Yeager later said, ‘I realized that the mission had to end in a let-down because the real barrier wasn’t in the sky but in our knowledge and experience of supersonic flight.’ Your and my definition of a let-down may vary from Yeager’s definition.
I believe that the experience of human efforts to break the sound barrier is analogous to enterprise efforts to adopt new technology. Right now, this is particularly apparent in the adoption of public cloud. Despite being convinced of the advantages of software defined, elastic, on-demand platforms, every organisation seems to have its own version of the sound barrier when it comes to cloud. Let’s call it the cloud barrier.
For example, a very cautious organisation may say that they’re happy to run development and test environments on public cloud, but they would never run production workloads. Another may be prepared to run production workloads, but not systems that they would class as ‘critical’. Still another may be comfortable running critical systems, but not storing confidential data.
These barriers and reservations are typically rooted in rational concerns: they are intended to protect the organisation, its systems and the customers that depend on them. However, just like the sound barrier, these concerns often turn out not to be true barriers at all: they are simply considerations that can be addressed with the necessary knowledge and experience. I believe that the right thing to do when we meet such ‘barriers’ is to ask ourselves how we acquire that knowledge and experience, and what changes we need to make to our architecture and engineering.
There is a further, and possibly even more important, reason for overcoming these barriers. Supersonic flight threatens aircraft which are not designed for it because, as they travel through the air, they create waves of pressure in front of them. These waves can only travel away as fast as the speed of sound (after all, that’s what sound is: the passage of pressure waves through the air). As you approach the speed of sound, the waves builds up with nowhere to go. This means that the point of crossing the barrier is also the point of maximum instability.
领英推荐
Similarly, organisations find themselves approaching barriers to cloud when they are partway through their change programmes. They have already signed contracts, trained teams, launched projects and migrated their first workloads. They are in flight and approaching the point of maximum instability. The waves of change are building up in front of them. This is a dangerous place to stop - and a good place to work out how to reconfigure, cross the barrier, and reach smooth air.
I’ve used cloud as an example because cloud transformation programmes are currently very common, and because many enterprises are encountering their own version of the cloud barrier. However, I don’t believe that this phenomenon is confined to cloud. Most enterprises possess as much archaeology as they do architecture: they manage landscapes with many approaches to application, data and infrastructure. For example, if you examine any sizeable enterprise, you will normally find applications hosted on dedicated infrastructure, virtual machines, on-premise container platforms and public cloud platforms. Each of these hosting patterns was a good idea at the time, and each was intended to become the standard for the organisation - yet never managed to become universally adopted. They all met their own barriers and, in many cases, never managed to traverse them. This means they are suspended at the point of maximum complexity in multiple dimensions at the same time.
We should not ignore barriers and crash through them recklessly. However, we should recognise that, to paraphrase Yeager, these barriers aren’t in our architectures, they’re in our knowledge and experience. If we acquire that knowledge and experience, adjust our architecture and engineering, we can traverse those barriers as if they are not there, and achieve supersonic flight.
(Views in this article are my own.)
Architecting your data in the Cloud | Enterprise Blueprints | Part of Bain and Company| Chief Data Architect
1 年David Knott, there's much to learn from this article. But not as much as how you use stories and metaphors to present your points. Another gem! Thanks for sharing your thoughts.