Beautiful Architecture: A Tale of Two Systems...

2009-09-03T08:06:00.000-07:00

The author discusses the tale of two systems that are very similar but they end up in two different sides of the pole (One bad and one good).

What I really appreciate about this chapter is the fact that it emphasizes not only on the design aspect of the systems but also the people aspects of the system. In particular the book mentions..."There had been personality struggles in the original team, and so a few key programmers had begun to build their own little software empires".

I have had experienced this in many companies. The personality struggle is not confined to individuals only but also to groups/teams. This can be seen in large companies where products cross company have duplicated efforts where each one solving the similar issue differently. Millions of dollars goes to waste since one team wants to do the same job differently without collaboration with other teams or research to see if the problem has already been solved externally (e.g. open source).

I have also witnessed cases where the team or organization is not willing to let go of the architecture/design in order to find better alternatives that can help their product/ business. This again can be also be seen in larger groups as well.

I would say the solution to many architectural issues have already been solved one way or another. It is the architect+leadership that can bring either harmony or dissonance to the system.

By no means, I am lessening the other factors that the book has mentioned...upfront design, the quality of the designer, etc. Just wanted to point out the key source.

Your view, as always, is very much appreciated.

-Hilla

Advance Topic in CS and Beautiful Architecture (Part 1)

2009-08-30T10:36:00.000-07:00

I have decided to take an online course on Advance Topics in Computer Science at University of Illinois (Champagne Illinois). Luckily my instructor is Professor Ralph Johnson, one of the authors of Design Patterns. This course is mainly focused on software architecture and one of the topic it will eventually cover will be on "Parallelism" which has been one of my favorite topics.

As part of this course, we have to read the first four chapter of "Beautiful Architecture" by Diomidis Spinellis and Georgios Gousios (repeat those names multiple times if you can). I have just finished the first chapter and I will blog with you few topics that I found to be worth sharing.

The chapter tries to define the software architecture based on an old definition of architecture, which is beauty, firmness and utility. If I would have defined beauty, I would defined it by simplicity and ease of use. I have seen many architectures from monolithic to client/server architecture and so far I can say only a handful would be labeled as beautiful. I will definitely mentions those in later blogs.

Now lets get to the meaty part of the chapter and what the software architect need to address...

Meets customer requirements
Safely build-able on required schedule
It performs adequately
It is reliable
It is usable and safe to use
It is secure
It is affordable
It conforms to legal standards
It will outlast its predecessors and competitors

From this list, the one that stands out the most for me is "It will outlast its predecessors and competitors". Now predecessors part, I believe is easy for any architect to figure out, what I have noticed, in my experience, is that many architects fail to understand the competition. From my own experience, I have seen few reasons for this and one is, the architect is too focused on outlasting the predecessors, the architecture is so complicated that by the time it is released, the competition is two steps ahead, the architect doesn't communicate with rest of the organization as the chapter also touches on this point as one of the roles of an architect.

The chapter thens move on to common architectural concerns:

Functionality
Changeability
Performance
Capacity
EcoSystem
Modularity
Buildability
Producibility
Security

So for me, Changeability stood out the most. Changeability again is something that is very crucial but is easy to overlook and ignore. This has been one of the major reason for software refactoring. This problem can be reduced if we put more efforts on Functionality and Buildability. Of course, this could also become the cause of overly complicated system.

Now how does the architect deal with these concerns, the chapter mentions the need to organize the system into structures where each structure defines specific relationship among different types of component. And the structures are:

The Information Hiding Structure
The Uses Structure
The Process Structure
The Access Structure

The Information Hiding Structure reminds me of OO concept of class encapsulation and its relationship in relation to its super/sub class. The Uses Structure reminds me of callback routines/classes or RPCs. The Process Structure would be similar to threads that the system will spawn with their respective Access Structure which defines the limitation that those processes/threads will have in using resources.

The chapter continues with defining the Good Architecture and the fact that for a given set of functional and quality requirements, there is no single correct architecture and no single "right answer". The chapter ends by providing examples of known good architectures based on some of the criteria mentioned here plus the "test of time". The two worth mentioning here are the World Wide Web and Unix. I am sure we all have at least one architecture we consider good but of course most of them are not publicly shared for us to agree upon.

Overall, I found the chapter little too abstract but it does touch on prime areas of software architecture. I do however believe that we need to cover some of these topics in undergraduate courses in computer science for obvious reasons.

Please feel free to provide your feedback.

-Hilla

HillaTechno CS 527

Beautiful Architecture: A Tale of Two Systems...

Advance Topic in CS and Beautiful Architecture (Part 1)