- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
The dawn of a post-legacy world
It’s easy to be fatalistic when you work in enterprise technology.
Of course the great big programme will go wrong: great big programmes always go wrong. Of course the infrastructure will fail: infrastructure always fails. And of course we will always have legacy technology: technology becomes legacy the moment it is deployed.
Sometimes this fatalism is cynical: it is the world weary shrug of people who have lived through many failures. Fortunately, though, this fatalism is more often realistic, practical and active, and prompts us to create mechanisms to deal with inevitable failure.
Great big programmes always go wrong: that’s why we break them up into smaller pieces, manage our work through backlogs, and adjust our plans after each iteration.
Infrastructure always fails: that’s why we design reliability and resilience into our solutions, and treat infrastructure failure as an expected operating condition.
Except for legacy.
Three predictions: probably wrong; possibly useful
Why make predictions about technology at all? I am writing this from a train which was predicted to be at its destination half an hour ago, but is still stuck between stations. If we can’t make accurate predictions about a well-known system with years worth of data, how could we possibly make predictions about the ever-changing field of technology?
Yet the process of attempting to make predictions tells us something, even if individual predictions are wrong. This particular train might not arrive as predicted, but I expect that there is a model somewhere which predicts the overall number of trains that will be delayed - and this delay may be consistent with that prediction. Somebody had to develop that model, and that process will have found something interesting about the factors that affect the reliability of trains.
Similarly, while it’s hard to make predictions about the future of technology, the process of attempting to figure out what’s coming next can be useful. It forces us to use our imaginations, to think about the consequences of choices we are making today, and to recognise the limitations of our own knowledge.
Things aren’t always what they seem: cloud, ML and the duty to explain
Many things have surprised me since I started writing these articles in 2018: perhaps it is a condition of 21st century life to be in a state of constant surprise. But there are three things that have surprised me most of all, and have taught me to think differently about the field of enterprise technology. These ideas may seem obvious, but sometimes it is the apparently obvious that surprises you the most.
Cloud is not just infrastructure
Back in 2018 I was working for a large, global bank which was just getting started on public cloud. Although that was only five years ago, it feels much longer: questions about whether regulated industries such as banking would ever be allowed to run on public cloud were far from settled, and there was a lot of scepticism.
The fox and the hedgehog
A fox knows many things, but a hedgehog knows one big thing.
I am sure that you have heard this saying before: it’s attributed to the Greek poet Archilochus, who lived in the 7th century BCE, so it’s been around for a while.
I think that this saying is useful in enterprise technology: we work in a field full of foxes (technology capable of doing many things) and hedgehogs (technology which is good at doing one big thing). It is often difficult to tell foxes and hedgehogs apart, especially when we are also surrounded by people who want to convince that their hedgehog is a fox: that it’s not just a great piece of technology that can solve one big problem, but that it can solve all our problems. If you have been working in the technology field for a while, then you will have seen several technologies and approaches promoted as the answer to everything, before they either faded away, or settled down into the life of happy hedgehogs (ESBs, anyone?).
The technology hierarchy of needs
The theory has been criticised and challenged, but has a continuing intuitive appeal, and is often taught on management courses. If you’ve done any management or leadership training in your career, you have likely seen that pyramid many times.
I believe that we can borrow the concept of the hierarchy of needs to help us understand the answer to a related question: why do anything with enterprise technology? And, more importantly, which things matter most?
Enterprise technology is a field of continuous, strenuous activity. The digital service that you consume as an end user may look simple and elegant, but behind the scenes there will be people writing code, testing systems, managing deployments, building infrastructure, probing security, negotiating contracts, defining architecture, making decisions and so on. And there will be more people managing and leading the first set of people, gathering data, reading reports, assessing risk, allocating funding, finding resources and so on. Over time, some of this work will become automated or delegated to service providers, but the total amount of work never seems to reduce: there is always something else to do, and there is never quite enough budget or resource to go around.
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.
Who said that adopting the cloud was going to be fair?
It’s not fair!
The cry of the outraged sibling through the ages. Why is my older sibling allowed to go places that I’m not allowed to go? Why is my younger sibling tolerated and indulged, when I would be punished for the same behaviour?
I suspect that many enterprise technologists feel the same way about the treatment of public cloud in their organisations, compared to the treatment of their on-premise infrastructure, even though they are too professional to wail, It’s not fair!
Why is it, they ask, that they are made to jump through multiple hoops to ensure that their encryption standards and approaches to key management are watertight on cloud, while on-premise, most of their data is unencrypted? Why is it, they go on to ask, that their risk teams fret about the distance between zones and regions, when their on-premise infrastructure is crammed into twin data centres which are overdue for refurbishment? Why is it, they lament (they’re on a roll now), that everything they do must be automated and instrumented, while on-premise infrastructure is still maintained through manual processes that take weeks to complete - if they are ever completed at all?
The Line: the simplest cloud architecture diagram you will ever use
There are a lot of diagrams which attempt to explain cloud, ranging from the classic ‘staircase’ depiction of the shared responsibility model to many, many elaborate diagrams covered in the logos of cloud services. I’d like to add to that stock of diagrams by introducing one more, which I hope will be helpful. I call it ‘the line’:
No, the graphics in this article have not glitched: that really is a single, horizontal line.
A diagram this sparse needs a few words of explanation. Your cloud provider lives below the line. You live above the line. The line is made of APIs.
A diagram this simple also needs a few words of justification. We all know that adopting a public cloud platform involves a separation of concerns: that there is work that you do and work that your cloud provider does. Do we really need another reminder of that?
Danger zones on the way to cloud: the Mists of Confusion, the Mountains of No, and the Swamps of Error
‘We’ve tried this before. It didn’t work then. What makes this time different?’
Are there any more dispiriting words to hear when you’re leading transformation? If you’ve been in that job, the scene is familiar. You have built the business case. You have secured the investment for the programme. You have found your partners. You have prepared your slides and you have organised the launch meeting. You are ready to inspire, organise and motivate. You have delivered your pitch and you have opened the floor for questions.
The first hand that goes up is from a veteran member of the team. They have lived through many changes. They know the systems inside out. Their support is vital: other people will follow their lead. And then they ask that dreaded question.
There’s plenty of room on the cloud: enough room to make mistakes?
We all make mistakes, especially when we are building and running enterprise technology.
Sometimes mistakes happen because we simply get something wrong (remember that time that you ran the script to delete test data, forgetting you were working on the production system?).
Sometimes mistakes happen because we haven’t got enough information to be right (remember that package you bought just before the vendor was acquired and the product discontinued?).
Sometime mistakes happen because we haven’t acquired enough experience to know how to avoid them (remember when you kept applying the old security policies to the new environment before realizing that they weren’t needed any more?).
Going to the cloud? Make sure you’ve packed enough leadership and thought
Surely by now we must know how to enact transformation within large organisations. We obtain loads of funding, appoint the programme director, set up the PMO, build the programme plan, set up governance and so on and so on.
If, like me, you have lived through many such large transformation programmes, your heart may sink at thought of all of the paraphernalia of change. All those things are important (it’s hard to organise lots of people to do complicated things, and hard to get them to stay organised), but they are necessary rather than sufficient. Have you ever attempted a transformation programme where you set up all the necessary mechanics, and yet the programme failed to fire? The processes were there, but the momentum required to sustain true change was never achieved?
How do I get there from here? Two first rungs on the ladder to cloud?
If only we hadn’t called it ‘cloud’. I sometimes wish that the technology industry had come up with a better term for the global, hyperscale, software defined platforms that I believe will form the dominant computing infrastructure of tomorrow. ‘Cloud’ implies something nebulous, light and airy, something that is impossible to touch or pin down. In real life, the physical implementation of cloud is a long way from this image: it is made of servers, storage arrays, network equipment, cables and physical facilities. The cloud is something you can weigh.
However, there is one way in which the term ‘cloud’ is useful. When we think of a cloud we think of something which is way up in the sky, something that is difficult to reach for mere earthbound mortals. The reason that I think that this image is useful is that it represents something true about cloud: that answering the question, ‘how do I get there from here?’ is difficult. To reach a real cloud, you would need a very long ladder and you would have nothing to lean it against. Getting to the computing cloud from your on premise starting point can seem like just as much of an acrobatic balancing act.