Map vs. the Landscape

Architects think in maps. Unlike real-world building architects, though, most IT architects cannot just walk to the construction site and get a feeling of the environment. Plus, the time is shorter to cover the spatial dimension of the system. In a time, where high speed links become standard and our perception of the state of a system is like "a star that burned out 50.000 years ago" IT architects need to fly high to cover the distance, even quite literally if they need to coordinate worldwide distributed systems, development teams and clients.

The maps we currently have of systems are not capable of showing the right dimensions. We might even say that UML only covers the obvious parts, the IDE-supported parts, the fine-granular building blueprint instead of the actual, visionary architecture. Mapping functional, parallel, non-structured elements in UML is possible but loses any visually helpful information in the process.  If we look at the interesting systems, the large systems, the old proverb  "The most alluring part of a map is that which is unmappable" becomes true again.

20 years ago the Agile Manifest was the spearhead of a movement that banned documentation as chronically outdated. 20 years later, with emergent, fault-tolerant architectures we need to be able to look at the runtime state of a system, judging its functional and technical change over time, it's clients and connected systems, rather than arranging the building blocks upfront. Process Mining, Architecture Integrity Control (and adapt) and Continuous Refactoring become crucial. Evaluation becomes the key step of an architecture, not design. The architect becomes an explorer with an idea, rather than a supervisor with a plan.

How could we map this changing landscape?

And I expected it to be wonderful - it was.
I expected the world to be sad - and it was.
I just didn't expect it to be so big.
XKCD/1110