Don't Stretch The Architecture Metaphors

Architects like to deal with metaphors. They provide nice concrete handles on subjects that are often abstract, complex and moving targets. Whether it is communicating with the rest of the team or talking through the architecture with the end-user it is so tempting to find something tangible or physical to use as a metaphor for what you are trying to build.

This usually starts well, in that a common language can evolve where people start to feel that things are moving in the right direction. The metaphor develops and grows over time until it takes on a life of it's own. People feel good about the metaphor - we're making progress! What usually happens is that the metaphor for the architecture now becomes dangerous. Here's how it can turn on it's Architect creators:

Example: We're building a 'transport system like a ship travelling between a series of docks'. You think container ships crossing the Pacific. I was actually thinking a rowing boat in a swimming pool, with possibly one oar.

Example: We said it's like a filing cabinet so of course we have to show it to the user alphabetically. I know it's a filing cabinet with six dimensions and of infinite length and clock built in to it, but we've done the icon now - so it has to be a filing cabinet...

Example: Why does the Billing Factory object create a Port channel for the Rowing boat system? Surely it it should return a Pomegranate view for the Hub Bus? What do you mean you're new here?

So remember, don't fall in love with your system metaphor - only use it for exploratory communication purposes and don't let it turn on you.