Let’s Get Beyond The Tired, Out-Of-Date EA Metaphors

The current metaphors for EA can be useful at a conceptual level to help non EAs understand what all the fuss is about. Most people understand the role of the building architect and the city planner and can make at least a rough association to what enterprise architects do. But many architects take these metaphors much too literally and much too seriously. They try to fashion their practice to align with the metaphor instead of taking the metaphor concept and creating a new way to apply it in their IT or business space.

 The enterprise architect as building architect

I use this metaphor myself when I am talking with non architects. Conceptually, it is a very rich metaphor that almost everyone can identify with. Even though most people have never seen a complete set of blueprints, they have seen enough examples to get the point. Unfortunately, this metaphor breaks down pretty fast.

  • First of all, building architects get paid for creating architecture, not buildings. In most cases the architect gets paid when the blueprints are complete. It doesn’t matter if their blueprints get put on the shelf - they are on to the next project. EAs are accountable (or should be) for implementation too. Enterprise architects whose architectures become shelf-ware are considered failures.
  • Building architects work from requirements. No one says “go architect what I need”. Their clients provide very specific requirements for what they want to be designed. EAs on the other hand generally have to figure out what they are architecting and then sell it to the client.
  • Building architects start with a green field. Unless they are designing a renovation, building architects don’t have to worry about existing structures and legacy architectures. Consequently, they need to create a complete set of blueprints. EAs almost never work in a green field environment (though I would love to some day). Most of what they do at the enterprise level is renovation. They really don’t need a complete set of blueprints.


The enterprise architect as city planner

Though not quite as rich a metaphor as the building architect, city planning is a concept that most people can understand. Again, it breaks down pretty fast.

  • City planners work on long-term visions. City planners work at a glacial pace compared to the typical enterprise architect. In the physical world things change relatively slowly. City planners generally think in decades. Not sure I have ever seen a ten-year EA plan. It would certainly be unusual. Even the most strategic businesses use three to five years as their planning horizon. Most EAs would consider themselves lucky to get that.  
  • City planners build plans, not cities. Just like building architects, city planners aren’t actually accountable for executing the plan. Your city might have a great plan, but if no one is building, who cares?
  • City planners have laws that back up what they say. Needless to say, EAs don’t.


So what would be a better metaphor for EA or do we really need one at all? And metaphor or not, shouldn’t we be defining the practice of EA by what we do, instead of what we named it?


I wouldn't give up on the

I wouldn't give up on the city planner metaphor, but how about also exploring this one: enterprise architect as cartographer? http://en.wikipedia.org/wiki/Cartography

Very good point

Very good point

EA Metaphors

Metaphors continue to be useful. I still like, and use the EA as a building architect and EA as the city planner but I too am getting tired of these and haven't found anything much better. I have a presentation on Gothic architecture and the role of the master builder, as one introduction to why EA is needed. It makes the building architect metaphor a little more interesting.

Still, some days as EA I feel like a gardener or an ecologist who is tending to an IT ecosystem. As a garden it's full of weeds, and as an ecosystem it's often not self-regulating.

Other days, I feel like an industrial mechanic or millwright working on single production line within the context of a large manufacturing system.

Some days, I feel more like a relationship mediator working to achieve a degree of alignment, to eliminate the asymmetry that often exists between business and IT.

Finally some days, I feel more like an conductor of an orchestra, trying to harmonize disparate pockets of technology, much as I imagine a conductor must harmonize the strings section with the brass etc.

I look forward to reading some of the other comments on this one.

EA Metaphors - (Chemical) Process Plant Designer?

I had been thinking about this for a long time. I could draw parallels with (chemical) process engineer / plant designer.
Process engineers define basic layout of the plant they want constructed to deliver an end-product from given raw material. When dealing with petrochemicals, mix of raw material and possible combinations of end-products makes it interesting to compare with IT.
The process engineer is not responsible for constructing/building the plant, but define blueprint for the plant and major parameters that controls the design of individual components as well as end product. In that line of business, almost all discipline leads are equally accountable, but almost all engineering decisions are derived from process engineers' blueprint.
Process engineers do get a chance to work on green-field projects, but many a time, it's renovation / expansion of existing units.
Even though they start with some requirements, I think it is as good as saying "go architect what I need" given the twist nature can throw into raw material, plant location, etc.
Counter thoughts?

A new metaphor for EA

Some really great metaphors proposed here. I like the cartographer metaphor but it isn’t directive enough for me. I think wagon train trail boss is more accurate (if completely outdated). Think Clint Eastwood in Rawhide. Not following a map, but clearly aiming at a common goal, leading a group of sometimes reluctant travelers though ever changing and often dangerous territory. I tried to work this into more of an Indiana Jones metaphor but couldn’t quite get it to work.

I also like the process plant designer metaphor. In a lot of ways it is a combination of city planner and building architect. I worked in the engineering office of a huge paper mill one summer so I can connect with this one very well. This might be a good metaphor for architects themselves but I don’t think it will resonate with their stakeholders as most of them don’t really understand the role of a plant designer. So, more accurate but perhaps less useful?

Dennis really gets to the heart of the problem. Gardener, ecologist, industrial mechanic, millwright, mediator, orchestra conductor: are all roles we play and points out that we are different things at differ times and in different situations.

My current thought is strategy activist. Though more descriptive of where I think EAs should head than an accurate metaphor of the current role, it gets to the heart of EA – create forward looking strategies and work hard to get the organization behind them to create broad, far-reaching change.

What do you think?


I'm not sure what could be more directive than "This is how you get from here to there." Isn't a key point of Enterprise Architecture to get away from that "not following a map" approach to one where you have better (if always imperfect) information to help guide your decisions? (I just saw an exhibition at the Library of Congress that includes a series of world maps. It was fascinating to see how they changed over time.)

Strategy Activist - I like that

" My current thought is strategy activist. Though more descriptive of where I think EAs should head than an accurate metaphor of the current role, it gets to the heart of EA – create forward looking strategies and work hard to get the organization behind them to create broad, far-reaching change."

@Jeff, well said. I often use the term proponent, but activist seems to be a more apt description. Too often, thinking beyond the current project or budget year seems to go against the very grain of IT and business unit organizations, where strategic thinking is reserved for those at the very top of top of the corporation. Like an activist, we are arguing for a new way of looking at things, a new way of thinking.

I would suggest that creating forward looking strategies is not saying enough. Those strategies need to have degrees of alignment with the overall corporate strategy and the goals and objectives of the business units.

Like an activist, I am passionate. I am passionate not about technology for its own sake, rather its the intersection where technology is used to enable or enhance; operational efficiencies, the ability of the business to sense (BI) and respond to change (IT agility), customer experience (customer and intermediary interfaces).

Atratgy Activist

"I would suggest that creating forward looking strategies is not saying enough. Those strategies need to have degrees of alignment with the overall corporate strategy and the goals and objectives of the business units."

Well put. It is the "right" strategies: those that support business and IT goals and create more value for the organization.

Strategy Activist

Harmony, on that one.

Nothing like metaphors to explore the core of what it is we are trying to achieve, and why we are doing it. I think now I will go chain myself to the corporate gates, until real change is achieved.

Map making versus navigating

Scott, As I understand it cartographers make maps but they don’t say “you should go here, by this route” Having a map of the United States tells me all the ways I can get to places but it doesn’t tell me the best cities to visit or the best route to get to a specific city.

Maybe a better metaphor would be a ship’s navigator. They plot the most efficient course to meet the business’s goal (take this cargo to London) taking into account the ships characteristics, weather, sea conditions, etc. As conditions change, the navigator updates the course (even though the map stays the same).

What do you think?

Do our business partners

Do our business partners typically want us to say, "You should go here, by this route"? Surely, you've used Google Maps to find and compare routes and to locate items of interest. It takes modern cartography to allow you to do that.

Anyway, I'm enjoying the conversation - not trying to insist...

I just really like Wikipedia's description of cartography: "combining science, aesthetics, and technique, cartography builds on the premise that reality can be modeled in ways that communicate spatial information effectively." Just strike "spatial" for enterprise architecture. The ideas about editing for context, generalization for relevance, and designing to convey a message are all applicable.

And I'm by no means suggesting this is a complete metaphor, only that it's one more that may be useful. I'm reminded of the blind men and the elephant.

EA as a Cartographer

"context, generalization for relevance and designing to convey a message are all applicable"

@Scott- good points. This is a really important part of what we do. Too often, decisions are a made without that map on the wall. If we can't draw the map, in a way that is understandable to those that are navigating, we are often lost, often making the less than optimal decisions about our direction.

There is an interesting book, if you want extend this idea even further.

"The Ghost Map: The Story of London's Most Terrifying Epidemic--and How It Changed Science, Cities, and the Modern World"

For those that haven't read it. It tells the story that until someone drew a map, showing the locations and timing of people that died from the plague in London, the experts were drawing all the wrong conclusions and consequently making decisions that compounded the problem. It was a map that showed the truth of what was really happening. Good read.

Good EA: Boring story

I have used the “Novelist” metaphor and that seemed to resonate.

Novelists create story and at the heart of good story is conflict. That conflict rises as the story progresses so that each obstacle the hero faces gets bigger and bigger.

If the Enterprise Architect was a novelist, and the EA was doing a good job, no one would bother reading their stories. It would be too boring.

The novelist guides a cast of characters, through action, to a logical and satisfying conclusion. To thoroughly enjoy the trip the reader must understand the problem the hero is trying solve, and progress through the scenes as the story question gets resolved.
In terms of what makes story satisfying, is it the overall plot? Is it the characters? Is the individual scenes where the action happens? Or, is it the way the individual sentences are constructed to build the scenes that build the plot?

EA’s need to clarify the story questions, so the solution architects can build the right scenes, and the technical architects can put the sentences together in the right way.

The EA’s stories will always be full of conflict, and unusual characters, and intense action – but done well, the satisfying conclusion we are working toward should be boringly clear to everyone involved.

EA reality = interesting story

James - I love it. What a creative and vivid view of the overall EA process. I agree if all was as it "should" be, then the EA story would be boring, but since EA is almost never as it should be the story is quite interesting. In EA reality, the characters keep modifying the plot without telling the other characters or the writer. Predictable stories are boring, unpredictable ones are interesting. Maybe that's why so many EAs like their job even with all the challenges.

Good EA Boring Story

Well done, James.

"The novelist guides a cast of characters, through action to a logical and satisfying conclusion". I have often thought of playing a game of chess, pieces on the board but the novelist metaphor is much richer, and more life-like.

plot, characters, scenes, sentences and an author are all great elements to work with.

Why Do We Have to Resort to Metaphors?

This discussion reminds me of the old saw "if what you're doing isn't working, don't do it harder, do something different".

Why do we have to resort to metaphors to explain what we do? Because we can't explain what we do in language that the people we're talking to understand. So we say what we do "is like" something else that's already been explained in language that they do understand. The problem with this is that every metaphor carries unwanted baggage, and we don't spend any time explaining how what we do isn't like something else. Metaphors are very simple minded models, and as such their value, and in some sense their "truth", is entirely determined by how well they help us understand what is being modeled. Most metaphors for EA have very limited value in this respect.

So, rather than find better metaphors, I suggest what we need to do is find a better way of saying what we do, not what we do is like, and that a better way entails doing so in language that the people we are talking to understand.

Lately I have taken to explaining what I do by saying that enterprise architecture is about ensuring that an enterprise's assets and capabilities always serve its vision, mission and strategy. I often do so in more words of fewer syllables, but the gist is the same. And I have found that almost everyone not only understands what this means, but also understands its value. For example, my niece, asking what I did that required me to travel so much, and who was considering setting up her own small business, immediately said "can you do that for me?".