Software Architecture - more than documents

As I read the following sentence in an IT magazine some days ago it immediately caught my attention: „Also, in smaller projects architecture (the documentation of the software solution) is obligatory. “.

That is, where I have to object: architecture is not only the documentation. Architecture even exists without any documentation, and it can be a good one, mind you. These days, many people tend to overly concentrate on the documentation of the architecture rather than on the methods and processes needed to conceive it. For instance, the arc42 template is a good one (and I don’t want to be misunderstood on that) but it also only focuses on documentation.

According to my understanding (and I am talking mainly about software architecture here – as opposed to business architecture, for instance), architecture refers to three different aspects:

-         the process of conception of the software system (some people call that “technical design”)

-         the inner structure of a software system (and its sources)

-         the documents needed to describe that structure (e.g. component view)

These three aspects are correlated. The following diagram depicts this relationship.

Picture 1: The three aspects of software architecture

Although correct and sound documentation is necessary to understand and communicate the architecture, it is not the same as the architecture. If we would conceive, design and build an app with an excellent architecture and install it and after that throw away all the documentation, the architecture would still be in existence, would still be splendid and would hopefully still exhibit all the nice quality criteria it was designed to. Our app would still be very stable and would respond to user input very quickly.

As I wrote in another post, software architecture is a set of concepts which resolve the functional and non-functional requirements of the system (cf. http://juriswritings.blogspot.de/2012/03/what-is-software-architecture.html). Therefore, these decisions must be safe and sound. In order to make sensible decisions the architects above all need experience and good requirements documentation (e.g. domain models and use cases).

As the project progresses and the bigger the project gets, the architects also need models of the architecture, because they may have to make decisions which change parts of the architecture already discussed. Thus, documentation is important, not only to help new people to get on the project and to let people do maintenance later. But – and that is my point here – it is not the same as the architecture and it is also not the first thing which needs to be created. Architects have to decide and they have to invent sensible concepts. Documentation is merely a tool to help them do their work – and we should keep that in mind when documenting.

BTW: the said article is “Architecture for eternity” in “Entwickler Magazin 04/2013” by Nils Arndt. The sentence is below the fourth sub heading, which is on page 2 of the article.