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?
No comments:
Post a Comment