Documenting Software Architectures

Following on from my earlier post The Trouble with Documentation I went off and bought the SEI book by Paul Clements et al. I’m now working my way through the book with the intention of applying much of what it says. My hope is that this will help to kill off, or at least calm down, some of the on-going arguments that always seem to ensue. How detailed is high level design? What should we put in the design documentation? So how long is this design work going to take?

If the blurb on the back cover is anything to go by then help is at hand. I’m just hoping that the book can deliver on the promise.

I’m going to try and blog some of the interesting points I come across, mainly so that I don’t forget them, but also to explore them a little more. I’m not going to reproduce the book, that would be both illegal and rather pointless, but I do want to dig around some of the key ideas. I like to think that I’m a fairly practical architect, in that I work on projects with customers the whole time. Having tried out many approaches and techniques over the years I often find that while the theory is great the rigour tends to tail off when you get down to the practicalities. Given the authors and heritage of this book I’m hopeful this won’t happen.

To be continued….

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

This entry was posted on 28/03/2008 at 06:43 pm and is filed under Views and Beyond, How to Architect. 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