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.

Beautiful Architecture - Chapter 1

So I have been reading the first chapter of beautiful architecture for the cs527 course. The chapter tries to identify what constitutes architecture and an architect in different fields before focusing on the architecture of computer systems. As both Ralph Johnson and Jason Danielson have pointed out in their blogs the first part of the chapter does throw some controversial statements out into the air, while the latter part goes into a discussion on different "views" of a system, both static and dynamic, that together forms the architecture of that system.

Jason Danielson raises an interesting discussion about the importance of functional versus non-functional requirements. The book takes the view that non-functional concerns such as performance (response times), scalability and security are the first concern of an Architect, ahead of the functional requirements. Jason argues that it is foolish to think of architecture without considering the functionality first and foremost.

I'll take the book's side here and argue that beginning with the non-functional requirements in mind and then adjust the architecture to allow for different functionality is far easier and more likely to give a solid and fairly stable architecture than the alternative. The alternative would be to start by mapping out the tens, hundreds or even thousands of possible functional requirements and then create a structure/architecture to handle these. Then, after mapping out this architecture, one would have to force this structure to allow for greater response times, be more scalable or be secure. The latter would be harder as the non-functional requirements are not really features that can be added to a system, but fundamental properties that are very difficult (read: expensive) to work in after the fact.

Imagine the following two scenarios. I have a system that is fast enough and that can handle the millions of required users in Jason's scenario. My claim is that it will be far easier to add a new functionality, such as a blogging section (or pictures), to this system than it will be to add performance and scalability to a system (or the architectural plans of a system) that already has a lot of functionality.

Of course, like Jason, a reasonable person would really want to understand at least a subset of what the system should do before starting to develop it, but that does not change the fact that starting with the cross-cutting concerns in mind is likely to be easier and yield a better architecture than the reverse.

Finally, I would like to mention a similarity between music and software architecture that I found interesting. With both music and software the end user will likely not care much about the architecture of it directly, but the user experience is likely to be heavily influenced by it.