Updated: Category: Architecture
The title “Enterprise Architect” carries many connotations, not all of them positive. Supposedly sitting high up in the ivory tower, detached from the reality down in the engine room, we are presumed to cement our power by wielding giant tapestry-like maps. Those magical maps give us unique insights into the IT estate that no one else has. Warren Buffet would call that an economic moat. If you asked GenAI to draw an ivory tower with a nice moat around it, I am sure you’d get fitting results.
These maps routinely point out highly defensible areas (“we’ve always done it this way”), no-go zones that spell certain doom (“serverless is cloud vendor witchwork whose sole purpose is to lock us in”), and thorny pathways to far-away, but brightly shining objects (“if the blockchain didn’t transform us, quantum surely will”).
Those architecture maps may remind us of illuminated manuscripts from the Middle Ages (the Getty Museum collection is really worth a visit), carefully crafted from colorful shapes, artistically interconnected in profound ways. The manuscripts took years to craft, similar to many enterprise architecture artifacts.
The notion of the Architect Elevator very much pulls the rug (or possibly the tapestry) from underneath the chairs high up in the ivory tower, opening up a deep shaft that leads straight down to the engine room, if you follow the metaphor.
But what should architects do with the tapestries? After all, someone’s got to have the proverbial “big picture” view of our IT estate and tells us which way we’re headed. Following my thought that architects don’t draw; they sketch, it’s time to rethink what type of artifacts architects should produce. And, yes, it involves numerous map metaphors.
Cartography
IT is ripe with references to terrain and maps thereof: we routinely discuss our “IT Landscape” with the business side commonly segmented into “areas” or “zones”. To better understand said landscape, we draw all sorts of maps like “Capability Maps” or “Process Maps” while we’re looking for “direction”.
The Software Architect Elevator includes a chapter on the IT world being flat, which plays of the fact that old maps tended to have more detail in the center while becoming rather fuzzy (and out of scale) around the periphery.
Comparing enterprise architects to cartographers, the folks who draw maps, isn’t particularly far fetched. After all, maps are models, which in turn are one of the most powerful tools to tackle the ever-present complexity. Some successful Enterprise Architecture tools fittingly proclaim to be the Google Maps of Enterprise Architecture, helping us navigate our IT landscape with the same amount of ease as driving through a city. If you still doubt the power of maps, I invite you to challenge Simon Wardley on that!
Vice versa, the absence of a reliable map is the backbone of most dystopian road movies (think Mad Max Fury Road) where the protagonist keeps traveling enormous distances in one direction, solely based on the promise of a precious resource in a far away region, be it water, fuel, ammunition, or other items that prove essential in dystopia. Although enterprise IT can appear dystopian at times (we embark on long, arduous journeys that may lead to lower cost, better governance, and higher uptime), we should at least have a map to avoid becoming a never-ending road movie.
And finally, one of my favorite movies of all time, Terry Gilliam’s Time Bandits, is all about the power of having a map. A troupe of dwarfs, hired to stuff holes in the universe, use the map to steal from historical figures like Napoleon or Agamemnon. For the rest, and to appreciate what the movie teaches us about enterprise architecture, you’ll have to watch yourself. And if Terry Gilliam isn’t your cup of tea, the protagonist in The English Patient was able to barter an aircraft for a set of desert maps.
Making Maps
Maps are enormously useful once you have them, in the real world as well as enterprise IT. But making maps is tricky:
-
They take time to make. You have to painstakingly survey the land and place its various details on a map. If the world is largely static, this is just a matter of tedium, but in a rapidly changing world it leads to outdated maps, which can be enormously frustrating.
-
Maps are models, so when we draw a map, we need to know what question we are looking to answer. For geographic cartographers, that question determines whether they’d be drawing a topographical map or a transport map. For IT maps, we generally still look for the one map to unify them all, which proves rather challenging.
-
Last, a map represents the territory (we know well that it isn’t the territory), but it doesn’t provide a decision or a strategy. You have to draw that part on top of the map. So, the map itself is only half the story. You still have to depict your strategy on it, whether that’s your cloud migration path, the shortest way home, or a battle plan.
We cross that bridge…
Most people in North America know the saying “we cross that bridge when we get there”. Now, to be precise, one does not cross the bridge but the river (iirc Jacques Barzun reminded us of that). But more importantly, we’d want to make sure that there will be a bridge once we get there–unless we are prepared to swim!
That’s where a map comes in super handy. A quick glance at the map will confirm whether there’s a bridge that can make crossing that river feasible. Big thanks to the cartographers! However, in times of rapid change and uncertainty (for example, if you want to send your troops across that river or integrate with a legacy system), you’re well advised to send some scouts out to see whether that bridge still actually exist and whether it provides safe passage (it might have been booby trapped by the enemy/disgruntled vendor).
Enterprise Architects as scouts
Luckily, enterprise IT doesn’t have to go to battle, but there’s many bridges–I mean rivers–we need to cross: modernizing or shutting down legacy systems, moving applications to the cloud, migrating from product to another, and many more. We also live in a rapidly changing and uncertain environment, so we should also send out some scouts to verify if those bridges actually exist and are safe to pass.
The critical differences between cartography and scouting are:
- A clear direction: cartography tries to give you information about any possible direction. Scouting looks in the specific direction that you are planning to go.
- Answering a concrete question: cartography builds a model that can answer a variety of questions. Scouting has a very specific question in mind, e.g., “can we cross the river at this location?”, “do we encounter traps or obstacles?”
- Bottom-up instead of top-down: scouts draw maps right from the ground (sometimes with your face in the mud) instead of looking from afar from the ivory tower. It’s much harder to hide things from a scout.
- Timeliness: Making maps takes time, often months or years. You send a scout right before you plan to move, so you can get the most up-to-date data.
- Cloak: Cartographers move about in the open, in enterprise circles they may even try to draw extra attention to their work (remember those valuable maps?). Scouts work primarily undetected; they are looking for the real answer, so they try to avoid disturbing their environment (and detection).
- Skin in the game: Whereas cartographers only deliver a map, scouts are part of the team and on the hook for a successful operation.
Having everything in a single map is very useful, and is often a suitable starting point for successful scouting. At least you’ll know where the river is, even though you’re not sure about the bridge or any perils along the way. So, as long as we accept a map as a “trust but check” device, doing cartography and being a scout can work in unison.
The biggest danger with the traditional cartography model is falling for the illusion of predictability:
If things were static and predictable, life would so much easier. We’re tempted to make this faulty assumption for the false sense of comfort that it provides.
Architects living in the first derivative™ of course know that taking static snapshots in a fast-moving world is risky business.
Being a good scout
What does it take for an enterprise architect to evolve from a cartographer to a scout? You might have invested years drawing beautiful maps and aren’t keen on scouting dangerous territory.
There is no single recipe, but a few aspects will surely help you do well in this new role:
- Get to the root of things. Good scouts aren’t easily detected and get to real lay of the land. In enterprise IT, you do easily end up in enemy territory, so it takes special nuance and skill to get around the initial lines of defense, which often come in the form of “let’s have an alignment meeting” or “this subsystem would take a long time to explain”.
- Anticipate challenges or traps. A long narrow valley? That doesn’t look good, just like a legacy system that’s been managed by an outsourcing provider for the last two decades.
- Leave no trace. Although you won’t be able to investigate the IT landscape entirely undetected, it can be helpful to keep some of your long-term objectives to yourself. That way you’ll minimize the risk of receiving “tailored” answers. This can be a fine line to walk–after all, you’re all working for the same company. You don’t want to mislead folks, but you want what market research would call an “unprompted response”.
- Think on your feet. You can’t anticipate what you will find, so you and your team must be able to handle a variety of technologies and artifacts. An Excel sheet over here, some Visual Basic and PL/1 over there? That’s OK, have a look, take note, and carry on.
- Management support. Once in a while it’s useful to have backing from high up while scouting to remove roadblocks. It’s a delicate maneuver as calling in support will generally reveal the scout’s position and objective, so use it wisely and sparingly.
Scouts don’t operate solo, but in a specific context. For them to go on a successful mission, they need to be given a suitable mission objective. Scouts operate autonomously, so just like other autonomous teams, they do need high alignment (funnily, the Spotify example also uses the example of crossing a river).
Scouts must also be highly trusted. Scouts who inject their own agenda into the maps can be extremely detrimental to the operations.
Last, as indicated above, the scout map is only the starting point of aligning on a strategy. It has to become the ubiquitous language among all stakeholders, so that the operation (e.g., migration, transformation) has broad support and stakeholders have uniform expectations.
Drawing a good scouting map
Scouts also produce maps, but not the cartography kind. Rather, scouting maps are more heavily abstracted, omitting as much noise as possible. Omitting more things actually makes them more valuable. Following my RTWP (“Read the Whole Paper”) principle, George box already reminded us that simpler maps are more valuable, right after the much-cited “All models are wrong” statement:
Simple but evocative models are the signature of the great scientist.
Suitable examples that highlight the contrast are proverbial treasure maps versus historical tapestries. Treasure maps are great models because they provide useful abstraction. The usually don’t even need a scale (sorry, cartographers) because treasure hunters will navigate by landmarks instead of GPS. They can abstract this much away because they answer a very specific question: “where is the treasure?”
In contrast, typical enterprise architecture models tend to resemble the Bayeux Tapestry of the Battle of Hastings. It’s truly impressive: over half a millennium old, it extends to almost 70 meters, stitched by hand (below is just a small fraction).
The downside is that despite being a great illustration, it isn’t a particularly useful decision model. But it does teach us one important aspect about enterprise architecture artifacts. The tapestry includes a time dimension, something missing from far too many EA artifacts: it recounts the story over time. Apparently, already the Normans knew that a single snapshot can’t tell the entire story.
Many thanks to Manlio Grillo, Michael Plöd, and Olaf Zimmermann for being my trusted scouts while writing this post.
Make More Impact as an Architect
The Software Architect Elevator helps architects and IT professionals to take their role to the next level. By sharing the real-life journey of a chief architect, it shows how to influence organizations at the intersection of business and technology. Buy it on Amazon US, Amazon UK, Amazon Europe
