Toward Boxology

Shaw and Clements propose that the choice of architectural style can be a function of control and data issues. On the outset, I'm not sure I would have come up with the same classifications. Having read their work though, I do think it makes some sense. I just question the ability to fit every project neatly into one of these boxes. Functional and quality requirements can be so different for each situation. I think this classification of architectural styles should simply be treated as another tool in the toolbox so to speak.

The one point that the authors highlighted that I appreciated were that the community needs to work towards a common language for speaking about architectural styles.

A Tale of Two Systems (BA ch 2)

While reading this chapter, I almost started to break out in a cold sweat. I worked on a project that was The Metropolis. If you have been fortunate enough (or are young enough) to not have had the pleasure of working on such a project ... good for you. For those of us who have, you know that the experience is something that you will never forget. To this day that code still haunts me! Having survived it however, I will say that I think everyone needs to have the experience at least once in their lifetime to truly appreciate the benefits of a good architecture and development team.

As for the Design Town project, there were a couple of points the author brought up that I thought were interesting:

• Technical Debt - I like the concept. While I have never used this particular approach on any of my projects, I think it has potential.
• YAGNI - I see it all the time. Developers like to "over engineer" by nature. Yes, I understand that someday you may need it, but why not refactor the code when that day comes?
• Development Team Morale - I think organizations tend to underestimate the impact of morale on employee productivity and product quality. The relationship between architectural quality and morale is a two way street. A poor architecture leads to poor morale and poor morale leads to a poor architecture.

Understanding Quality Attributes (SAIP ch 4)

The chapter was a good read. I think the authors did a good job of laying out a high level framework for identifying various quality attributes. I particularly like the focus the authors placed on the impact of business drivers in the software development lifecycle. From my experiences, these drivers are of increasing importance (many times even more so than other quality attributes).

I would like to see a written list of concrete scenarios for an actual project. It seems like the list could grow rather quickly with all of the permutations of variables.

What is Architecture? (BA ch 1)

At a high level, I think Spinellis and Gousios did a good job of introducing the concept of software architecture. When I first picked up the book, I wasn't aware of the fact that many of the subsequent chapters were actually based on "real world" architectures. After having read the first chapter, I am definitely excited to read on and see what else the book has to offer.

Having said all that, everything can't be sunshine and roses! There were a couple of points in the first chapter that either I didn't fully agree with or wish that the authors could have provided more concrete examples to help explain. Here are a couple of the highlights:

• On page 10, the authors claim that an architect's first concern is not the functionality of the system. Instead, it is the quality concerns that an architect should begin with. While I agree with this in principal, it is my experience that this is not typically the case. I wholeheartedly believe that a good architect should think this way. However, for every good architect I think there are tens (maybe hundreds? :)) of bad architects. Why is this? I think it stems from the fact of how architects are promoted within Corporate America. Typically, they are not necessarily the most skilled individuals on the project team ... just the ones who have been there the longest! Most either have no or very limited formal training on how to perform their jobs effectively. (Hmmm .... I wonder if this is how developers working on projects where I have served as the lead architect feel?!@?)
• Something that is not really discussed in much detail in the chapter which I feel is important is in regards to the cost-benefit trade offs of quality concerns. Does it cost more to build systems that are highly available, scalable, easy to test, have great performance, etc., etc.? I think that these systems definitely tend to be more complex, but it is not always easy to determine the impacts to costs or the monetized benefits of such a design. For example, people who wear suits like to perform cost benefit analysis exercises. For things like increases in performance, this may be fairly easy. With Architecture A, I can support Y transactions per second, but with architecture B that only costs me $1 more I can support Y+20 transactions per second which equates to $1 million / year in added sales. Yeah! But how do we quantify the realized benefits of a system that is highly scalable or easily modifiable?