“The Art of Visualising Software Architecture” is a book written by Simon Brown to discuss the problem of the representation of software architecture. For the author, software developers mostly lack the skills needed for an effective visual communication of their software architecture.
The book splits the software architecture in four layers: context, container, component and class. There is a chapter for each layer that explains what should be the intent and the audience of the different architecture diagrams used to represent it. A common example is used throughout the book for the diagrams. The most interesting part of the book discusses the relationship between the architecture diagrams and the code. The final section presents the different tools that you could use to represent your software architecture.
The book is well written and the diagrams are easy to understand. The Art of Visualising Software Architecture is a book that I recommend to every software architect and software developer.
Source: The Art of Visualising Software Architecture, Simon Brown, Leanpub, https://leanpub.com/visualising-software-architecture
Quotes
Given all of the progress in recent years, many software teams lack the ability to communicate software architecture before, during and after the construction of that software. The result is often that these same teams seem to lack technical leadership, direction and consistency. If you want to ensure that everybody is contributing to the same end-goal, you need to be able to effectively communicate the vision of what it is you’re building. And if you want agility and the ability to move fast, you need to be able to communicate that vision efficiently too.
Determining which software systems to include on the diagram requires to you ask yourself which software systems sit outside the scope or boundary of your software system. This basically comes down to ownership or understanding whether you have responsibility for maintaining the software system in question. Who owns the software system? Who looks after it?
One of the biggest problems I see with software architecture diagrams is that they never quite match the code. Sometimes the diagrams are horribly out of date, perhaps because the overhead in maintaining them is too high, but at other times the abstractions being shown in the diagram don’t actually reflect the code. And this is especially prevalent at the component level.
There are a number of benefits to thinking about a software system in terms of components, but essentially it allows us to think and talk about the software as a small number of high level abstractions rather than the hundreds and thousands of individual classes that make up most enterprise object-oriented systems. Abstractions help us to reason about a big and/or complex software system.