The Line: the simplest cloud architecture diagram you’ll 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?

I think that the answer is yes. I think that the line has profound implications for the way we organise and run technology within enterprises, but that many enterprises do not realise these implications until they are some years into their cloud journey. Some never do.

Let’s explore three types of separation implied by the line: heterogeneity from homogeneity; value from hygiene; and capability from services.

Heterogeneity and homogeneity

Despite strong governance controls and complex approval processes, despite layers of architecture review boards and purchasing panels, most enterprises are plagued by heterogeneity at all layers of their architecture. It’s very common, when discussing the architecture of a large enterprise to hear the rueful lament, ‘Of course, we’ve got one of everything.’

Heterogeneity at some layers of the architecture is not necessarily bad. A highly diverse and adaptable set of applications which process data in interesting ways can be a sign of a flexible, product-oriented and innovative business which allows teams high levels of autonomy.

But heterogeneity at the infrastructure layer rarely achieves anything but complexity, cost and risk. One of the distinguishing features of the digital giants which have created the cloud industry is homogenous, abstracted infrastructure, enabling them to scale with speed and confidence. This capability is now available to cloud tenants.

Below the line, homogenous, software defined infrastructure.

Above the line, heterogenous business capabilities adapted to evolving needs.

Value and hygiene

It seems a great dis-service to classify the work that infrastructure teams do in large enterprises as ‘hygiene’, especially when I’ve spent large parts of my career doing such work myself. This work, often unnoticed, rarely recognised, powers the hidden engines of the world and enables our technology driven economies to operate.

Yet, if we are honest, it is difficult to classify it as anything other than hygiene: critical, essential work that has the capacity to break everything when it goes wrong, but which enables rather than creates business value. You notice it when it doesn’t work, but when it does work, it is invisible.

By contrast, work that uses data in interesting ways or which puts software in the hands of users and customers is a direct driver of value. However hard we work on our infrastructure, we should never forget that it is there to drive this value.

Value and hygiene are dependent on each other. Without reliable, secure, scalable infrastructure available when needed, software and data are worse than useless. But without software and data, infrastructure is nothing but cost.

On cloud, the line separates value and hygiene.

Below the line, secure, scalable, reliable infrastructure services.

Above the line, differentiating value from software and data.

Capability and services

By dividing value and hygiene, the line helps inform our sourcing choices. Such choices are often expressed by asking, ‘What are you going to do, and what are you going to ask other people to do?’ I think that we can go further than this, and ask ‘What are you going to be great at, and what great partnerships will you build?’

For many years, many large enterprises have chosen not to be great at software engineering and data science: they have chosen to buy these services from partners. However, this trend is now reversing, as companies realise that the way they build software and use data has a disproportionate impact on their business success. But most companies are finding that it is hard to rebuild this differentiating capability.

We all know that it’s hard to find and develop great people. It’s even harder to combine those people into high performing teams, and to build professional software and data practices across your organisation. And it’s harder still if you haven’t given priority to these capabilities for years. It needs education, recruitment, organisation, cultural change and new models of leadership.

Above all, it requires focus, and one of the virtues of the line is that it makes this focus possible: it enables you to choose to be great at software and data, to expend the effort required to achieve this greatness, and to build partnerships with platform providers for the rest of your capabilities.

Below the line, partnerships for services that need to be great.

Above the line, focus on building capabilities that you should be great at.

Of course, life is more complicated than this simple diagram implies. It is rare to find that reality truly resolves to a single sharp line. But I believe that, keeping this diagram in mind helps us to understand and remember the value we aim to realise from cloud. and prevents cloud from becoming yet another source of complexity and cost. Sometimes over-simplification is a useful provocation.

(Views in this article are my own.)