Are we there yet? When can we stop mapping our technology architecture?
Photo credit: Tabea Schimpf via Unsplash
In his short story On Exactitude in Science, Jorge Luis Borges writes about a historical Empire so taken with cartography that it makes a map of itself at a 1:1 scale: so big that it covers the territory it describes. Such a map is, of course, useless, and it is allowed to decay into tattered ruins.
This story raises a common question faced by technology architects: when does it make sense to stop mapping?
I believe that the discipline of technology architecture first arose from the desire for a map. Back in the 20th century, when we had been building software for long enough that things were starting to get complicated, but not so long that they were impossible to understand, people realised that it might be a good idea if we had some sort of systematic explanation of how things worked. So, we started modelling and mapping, and building repositories, and producing diagrams, and creating methods, and inventing governance structures, and all the other things that we do to keep us busy.
Some of the products of this activity are useful. They help us make plans, solve problems and make decisions. Many of these products are less useful, though: they fill shelves, and decorate walls, but are rarely used. The difficulty is knowing, ahead of time, which will be useful and which will end up, like the map in Borges’ story, as scraps in the wasteland.
As usual, I don’t have a perfect answer to this question. However, over a few decades of attempting to do technology architecture, I have learnt a few lessons: here are three thoughts which might be helpful.
There is no end to mapping, if mapping is the end
Architecture teams often lament that people in their organisation are taking terrible decisions. They are duplicating capabilities that already exist; they are overusing assets which are already in demand, and underusing assets which are sitting idle. They are neglecting the old while fixating on the new, and revisiting decisions which have already been made.
Sometimes such architects make the case for a grand mapping exercise. If only we knew where everything was, what it meant and what it was used for; if only we could make that information available to everybody, then surely we could make rational decisions and the world would be a better place.
And the architects build their map . . . and go on building their map . . . and go on building their map. And the world turns and mistakes are still made.
Such architects (and I speak as somebody who has been one) have not just mistaken the map for the territory, they have mistaken the means for the end. We can help ourselves by remembering that mapping is a tool, not a goal.
Gathering data is not the same as making sense
It might seem that we have entered an age where the problem of mapping is solved by software defined platforms and pervasive instrumentation. As we move to cloud, our technology assets are described by metadata and can be queried in real time by APIs. Surely I should be able to construct a dynamic map of my technology architecture whenever I need one.
And this is true - as long as what I want is a map of the architecture from a particular perspective. It is as if I was the administrator of a building, and had instruments which could tell me about the structural integrity of every brick, the water moving through the pipes, the temperature and airflow. Those data points would tell me a lot - but they would not tell me everything about the occupants of the building: their relationships, their goals, their faults, their desires.
Even with pervasive instrumentation, we have to do some mapping - we have to do the work to make sense of the data we receive. Sometimes gathering more data adds no more value if it makes no more sense.
The scale of the map depends on the journey
When we relied on paper maps for navigation, one of the most important steps in a journey was choosing which scale map to use. Picking the wrong scale might result in your navigator struggling with acres of paper, or squinting to make out details that were far too small. These days, we rarely face such problems, but we still have to pinch and zoom to find the right scale.
I think that, as technology architects, we spend a lot of our time trying to figure out the right scale to have a conversation. Sometimes we can communicate effectively and take good decisions using three boxes and some lines scribbled on a whiteboard. Sometimes we need detailed dependency diagrams with accurate, real-time data. Sometimes we may even need to use our data to train a model, mapping our architecture in the connections of a neural network rather than in words and pictures.
The scale of the map is determined by the journey we are taking. This means that, as ever, one of the key roles of technology architects is to help figure out what journey we are on - before we figure out what map we need.
Borges’ story itself is a good example. Like much of Borges’ writing, it is astonishingly brief: just 156 words (in English translation) in a single paragraph. Yet in those few words it creates an atmosphere, evokes a mythology and instils ideas and questions. As a final lesson, when we are spilling vats of digital ink, building maps and models of towering, elaborate architectures, we should ask ourselves: could we say more with less?
