Software Architecture in Practice

Another book chapter we have been reading is chapter 4 from the book Software Architecture in Practice titled "Understanding Quality Attributes". The chapter starts by discussing architecture in relation to functionality as well as "quality attributes". The authors, like the authors of beautiful architecture argues that non-functional requirements must be the main driver of the architecture of a system. They make the interesting observation that systems are usually not redesigned or even rewritten because of lacking functionality, but because of quality deficiencies. The then argue that if functionality is the only requirement of a system then the system could be written as a monolithic block of code without structure.

One thing I noticed is that the authors consistently refer to such requirements as "quality attributes" as opposed to the more common term "non-functional requirements". The distinction may seem irrelevant, but I believe such language can be important as one would be less inclined to write programs that are without quality attributes than programs without non-functionality (This argument is actually the same as the one Donald Knuth made for calling the programming style he has championed "Literal programming" as no-one will want to write illiterate programs).

Later the chapter tries to provide a more concrete and measurable/testable framework for stating the quality attribute requirements of a system in the form of quality attribute scenarios. These scenarios consist of a source of stimuli, the stimuli itself, an artifact being affected (the system, a subset of it, etc.), a response and a concrete measure of the response that must be met. The last I think is very important when stating such requirements or else the requirement is open up for interpretation and thus becomes nearly void. Or, as the lean manufacturing people say, "In God we trust, everyone else must bring numbers".

The system quality attributes that the authors identify and provide scenario "templates" for are availability, maintainability, performance, security, testability and usability. These are all areas that are often left very vague in system specifications, but that are all possible to provide very concrete measures for in terms of units such as time, user acceptance scores and others.

At first glance I found the inclusion of usability as a first-order concern of the architecture to be a bit strange. Of course usability is important, the right layout or the right library abstractions will greatly enhance the user experience, but how does it drive the architecture? When one thinks about it in more depth however, as the authors go on to discuss, it makes perfect sense when it comes to things such as the ability to cancel operations or to get information on their progress (which sometimes even require the introduction of parallelism or at least simulated concurrency to allow the user to issue commands while tasks are being performed). As anyone who has implemented undo-functionality in an application with more than one capability will know, such things are much easier to design in than to add later.

Finally the chapter discusses business related attributes that affect the systems architecture. However, I would not say that these directly influence the system architecture, but rather help determine the relative importance of the system quality attributes. In class we discussed the taxonomy of the different attributes and it was pointed out that it seems inconsistent to put testability with the system attributes and buildability with the business attributes. This is not quite the division the authors use as they place buildability in a third category of architecture quality attributes, but the point still remains and I do question whether testability, the way it is described in the chapter, and maybe even maintainability shouldn't be in the same category as buildability.