Beautiful Architecture - Chapter 1

I disagree with the author's statement,

"That's right -- the first concern of a software architect is not the functionality of the system",

because a high-level understanding of a system's functionality is usually needed to drive quality concerns. With any system, one has to consider the quality attribute trade-offs so depending on the functionality of the system, one would choose one trade-off over another. I agree that decomposing the system into functional requirements is more difficult but I'm arguing that you need to have some idea of the system's functionality before you begin. The author even contradicts himself when he gives the example,

"Or perhaps our application is a web-based telephone and we need to make the phone 'ring'. If you need to send true asynchronous events from the server to the web page to satisfy performance requirements, an architecture based on servlets might be more testable and modifiable."

This is an example of knowing some functionality about the system, and then making an architectural decision based on it. I'm not saying that all functional requirements should be done before quality requirements. I'm saying that you should start with a high-level understanding, then dig into the quality requirements, then do the functional requirements, and then repeat the same process. It should be an iterative process.

@Richard Young. I agree that business needs often drive the architecture of a solution but, unfortunately, sometimes businesses do not understand the technical ramifications of making certain decisions. Many times, they'll ship out rushed code in order to win in the market (without considering other architectural alternatives), but that usually leads to more defects in the field and code that's expensive to maintain in the long run.

@Michael Davidson. I'm not sure if I agree with the 'Minimize Mechanisms' philosophy. Although I agree that you shouldn't waste time and effort trying to search for the 'best solution', one shouldn't just settle for the first solution that meets their needs. If developers could spend just a few more cycles investigating other solutions (my rule of thumb is no more than 3), they might encounter something that's even BETTER than one would've imagined. It could also save one the embarrassment of presenting their solution to an audience that asks them why they didn't consider the 'BETTER' solution (audience knows the better solution because they googled it ! ).

@AWANA81. I do think that all developers should have some knowledge of the software architecture of the system because they would be more likely to bring up critical issues than if there were confined into their own little world. Also, Ralph Johnson mentioned that for a small team of about 4, it doesn't make sense to have a dedicated architect. This is a case where it's crucial for all developers to know the architecture well.