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).