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.