Field Guide to Boxology

I found this paper very interesting because it pretty much provides "a checklist of topics to consider, thereby setting expectations for elements to include in the design". This could be a good reference whenever we're given a very general problem to solve. Also, I feel the "vocabulary used to describe styles more precise and shareable among software architects" is probably the most important thing that comes out of this classification; similar to what Design Patterns provides us.

Considering that this paper was published in 1996, why isn't there a popular book that transcends these concepts for decades to come? Maybe Ralph Johnson can get the Gang of Four team back together and write one for Architecture Styles. Or maybe they already did ...

I'm familiar with the Unix Pipes & Filters and Pipeline data flow styles but did anyone else find it weird to see the word "Transducer" as a constituent component? As a hardware guy, it’s obviously a device that transforms one form of energy into another like a thermometer or a microphone. In the context of the paper, it’s a dataflow network style where, "components are elements that asynchronously transform input into output with minimal retained state". Never heard of this term used in the software world.

In Table 2, they make the distinction between write-time & compile time. Aren't these the same? Also, can anyone tell me what's the difference between invocation & run-time? They pretty much sound the same to me.

And finally, did anyone find it annoying that they made several incorrect references to Table 1 when they meant Table 2 and vice-versa? I was worried I had read something for half-an-hour and not understood a thing!

Software Architecture in Practice: Chapter 4

I'm not sure if conceptual integrity is a good phrase for describing consistency in a system's design, but I absolutely agree that it's better to have uniformity that to have "certain anomalous features and improvements"; and it seems that most people agree. The difficulty with this is that you can have a situation where several team members will aggressively hold on to their ideas that will cause a debate for hours. In which case, an assigned architect would be helpful to make the final call. So I would also add to expect wasted hours in effort to the quote,

"make the architect available. If no one is identified with that role, it is a sign that conceptual integrity may be lacking"

If Buildability is the quality that, among other things, measures how much parallelism can occur in development, then conforming to the object-oriented principle of designing to interfaces is crucial. I've been a part of several projects where teams don't do this and we end up with spaghetti code that takes several hours to make a small change.

Finally, the author states that buildability also has to do with how much knowledge the team has about the problem.

"A design that casts a solution in terms of well-understood concepts is thus more buildable than one that introduces new concepts"

Although I agree with this, a team has to start somewhere. A company can buy another company that has the expertise of a domain, or they can gain it through years of experience of selling solutions of this domain. In which case, their ability to deliver a solution should be expected to be delayed. It seems that when companies invest on pet projects to get expertise on some domain is when they're most successful (think Google). It might be because they're not pressured to release a product any time soon and, therefore, aren't forced to compromise architectural qualities that will come back to haunt them later. Any thoughts?

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.

Test Post

Just checking to make sure this works.