Architecture in a hot air balloon

There is a joke that I sometimes like to refer to, more as an allegorical story than anything else.  This version is from AJokeADay.com:

A man in a hot air balloon realized he was lost. He reduced altitude and spotted a woman below. He descended a bit more and shouted,” Excuse me, can you help? I promised a friend I would meet him an hour ago, but I don't know where I am."

The woman below thought carefully for five minutes, and then replied, "You are in a hot air balloon hovering approximately 30 feet above the ground. You are between 40 and 41 degrees north latitude and between 59 and 60 degrees west longitude."

"You must be an engineer," said the balloonist.

"I am," replied the woman. "How did you know?"

"Well," answered the balloonist, "you took a long time to respond, and everything you told me is technically correct, but it is of no value to my problem.  I am still lost.  Frankly, you've not been much help so far."

The woman below responded, "You must be in management."

"I am," replied the balloonist, "but how did you know?"

"Well," said the woman, "you don't know where you are or where you are going. You have risen to where you are, due to a large quantity of hot air. You made a promise which you have no idea how to keep, and you expect people beneath you to solve your problems. The fact is you are in exactly the same position you were in before we met, but now, somehow, it's my fault!"

So it’s funny, but it is a useful story as well. 

All architecture, in any real sense, is an attempt to communicate a complex set of ideas.

Architecture is an answer to a question.  So many architects strive for accuracy in their “answers” (the architectural diagrams they produce), and we see countless discussions of the “correct” way to model this thing or that… but while accuracy is great, usefulness is so much more important. 

In some ways, that is what the IEEE 1471 / ISO 42010 standard is all about.  For those of you not familiar with IEEE 1471, it is a metamodel for all architecture.  This simple document frames architecture as an attempt to communicate, using the language of architectural models. 

But what is more important in the standard is not that architecture communicates… it is the fact that architecture, in order to succeed, must communicate to the specific concerns of specific stakeholders.   In other words, you must consider the needs of the audience before delivering the requested information, and then deliver what they need in a clear manner, even if it is not technically what they asked for.

In the joke, an engineer responds to the question from stranded businessman that he is 30 feet off the ground.  Accurate but unhelpful.  An architect would consider the businessman to be a stakeholder, and would take his concerns into account. 

Instead of replying with data that is of no value, the architect would toss up a cell phone to allow the businessman to call his friend and reschedule.  The businessman would still be lost, and hovering in a balloon… but at least his pressing concerns would be met. 

Honestly, what else could you ask for?

Comments

• Anonymous
  February 17, 2009
  PingBack from http://www.structuredmethods.com/wp/?p=72

• Anonymous
  March 02, 2009
  Or better still the engineer could have stopped at trying to being clever and told the business man exactly what he needed to know i.e. where he was.  Throwing up a cell phone for him to phone up his friend would have been an added bonus of extra help, allowing the business man to then make his own decision as to whether he wanted to proceed once he had told his friend where he was or to reschedule. My added conclusion is that sometimes people just try to be too clever and mystify the answer to what is otherwise a relatively simple question. However, I would agree that the context and concerns should be taken into account.

• Anonymous
  March 05, 2009
  The comment has been removed