Views and Viewpoints

This post is part of a series based on the book Documenting Software Architectures: Views and Beyond.

We are on to page 18 now for those keeping track of these things.

The core of the approach set out in the book is the use of viewpoints. This is that when we try to describe a system it is simply not possible, or even desirable to, to do this in just one way. The leap that we as architects need to make is to ensure that what we put down in writing addresses the need of the reader, not the writer.

To use the bus analogy (see Is it a bird Is it a building? No! It’s a bus!), what the maintenance team are interested in is not the same as the accountant. There may well be some common ground, say in on-going costs, but they are looking at the same solution from very different perspectives. I’m guessing here, having not read the whole book yet, that the key is to have a commonly agreed and standardised viewpoints. Having these pre-agreed means that the architects know what to produce and the stakeholders know what to expect. This is not as easy as it sounds in the real world. It is not uncommon to find that there is some standard defined, but that it is not sufficiently explicit or even worse no examples are available.

“Every project has to produce this document”.

“Can I see an example then?”

“Er.. no”

“Then what about all the previous projects? What did they do?”

Silence.

Sounds like madness, but I’ve been there. Back to the book. hopefully the use of the industrial strength documentation standards will start to address this problem.

This entry was posted on 24/04/2008 at 05:16 pm and is filed under Views and Beyond. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response or trackback from your own site.

| Print