Wednesday, August 19, 2009

Software Architecture Zen?

Okay so why software architecture zen? According to Wikipedia Zen "...de-emphasizes theoretical knowledge in favor of direct, experiential realization through meditation...". So, my goal here is the practical application of software architecture, based on my own and others hard earned experiences in both doing and teaching out in the real-world. I got the idea from one of my favorite blogs, Presentation Zen. which is all about creating great presentations based on simplicity and "cleanliness" of design.

For a great exposition on Zen as applied to software architecture see this paper by Philippe Kruchten from 2001. My favorite bit is:

The architect doesn't talk, she acts.
When this is done,
the team says, "Amazing:
we did it, all by ourselves!"

Friday, August 7, 2009

Two diagrams all Software Architects need

I'm not a great fan of “architecture by PowerPoint” however there are two diagrams which do lend themselves well to being created using PowerPoint (or any other drawing tool). These happen to be the two diagrams which any architect should have in their back pocket ready to pull out at any time to explain the scope and the structure of their current project. They are the System Context and the Architecture Overview. Both of these diagrams are usually drawn as part of a more complete artefact, which will include a key to the diagrams as well as descriptive text explaining them. However the key part of these artefacts is the diagrams themselves.

The System Context represents the system under development as a single entity and identifies all the interfaces between the system and external entities (i.e. users and other systems).

The Architecture Overview provides an overview of the significant structural, and possibly dynamic, elements of the architecture. It is not meant to be a full specification of the architecture which could be taken by someone and implemented but rather a high level view of the system showing its essential elements. Its main purpose if one of communication, to stakeholders.

The System Context is essentially a “black-box” view of the system under development whilst the architecture overview is a “white-box” view (i.e. showing the major subsystems and components of the system under development. The key thing to remember about a System Context is that it sets the boundary of the system; so everything outside the boundary is presumed to exist already or to be provided by another project. Everything inside the boundary is assumed to be part of the development project that will deliver the new system. The diagram below shows a typical System Context for a new claims processing system. I'll leave it as an exercise for the reader to envisage what the Architecture Overview for the system might look like (or you could see another example on p195 of this book).