Goal Oriented Diagrams

April 25, 2011 | ,

A few years back we presented for the first time at the Open Group Architecture Practitioners Conference in Miami, FL. I spoke about a topic about which we are passionate: UML as an Enterprise Architecture diagramming notation.

The presentation was very well received, and all seemed to be going swimmingly until the Q&A phase of the presentation, at which time I was fortunate enough to attract a heckler.

He suggested that if we had not considered the UML Profile for Schedulability, Performance, and Time, then we were “giving people tools to build bridges that fall down“. The suggestion was off base as the profile extends UML support for real-time systems modeling and the presentation was recommending UML for enterprise-level logical architecture diagrams, but it did cause me to consider (post panic) the importance of “scope”and “goal” when producing design artifacts.

All architecture design collateral should be created with the goal in mind, and if it is not clear to you what the goal is, then you need to step back and ponder; otherwise you are not creating a design diagram, you are just playing with pictures.

Our goal has never been to “design bridges that fall down”. In fact, it has never been to design bridges at all. An enterprise architect creates views targeted at ensuring consensus and clarity across a wide group of business and technology stakeholders. Sometimes they are business focused and sometimes technology focused, but they have never been bridge focused. Even if one accepts the analogy, an enterprise architect is more likely to identify that someone needs a bridge, and based on the environment, the required length of the bridge, the traffic it will need to sustain, and recommend what type of bridge should be built.

Proper scope is one of the most important and most elusive elements of visual modeling. The prerequisite for scope is understanding the goal or purpose of the diagram. The most effective diagrams are created by clearly determining what the diagram is intended to communicate, then omitting anything that does not contribute to the goal.

Some tips for goal oriented diagramming:

  1. Don’t start your diagram until you have determined its goal. Ask yourself for whom the diagram is intended and what is it meant to communicate.
  2. Include only the elements that contribute to the goal. Include a minimum of additional information. It is likely that there will be some additional information likely needed to provide context and continuity. It is easier to understand a door knob if it is depicted on a door.
  3. Do not attempt to be “complete”. Focus on elements significant to that which you are attempting to communicate.
  4. Once you have completed a diagram, review it again to confirm that every last box, line, and label contributes to clearly communicating and remove anything else; it is just noise that distracts the target audience from the intended message.

Also, avoid any bridges designed by me. :o

See Systems Flow’s publications or other articles on diagramming and diplomacy for more on our “special sauce”, and contact us if you want to learn!

The following two tabs change content below.

Dan Hughes

Was a principal consultant at Systems Flow, Inc.

Latest posts by Dan Hughes (see all)


Comments are closed.