Software Architecture

In this chapter we took a look at the concept of software architecture. As it says, we are comparing the ancient activity of constructing buildings with bricks, to the more recently created activity of building software and systems.

And we think of software as the combination of several components that will create a bigger system, just as we have done with bricks, cement and other materials to create a bigger building and not just a collection of walls, roofs and doors.

While making a building, we can create our own vision. The same thing applies to software creation, each programmer has a different vision. The real issue comes when people that haven’t been involved with the creation of the software comes along and tries to understand the system. If the system has a well-defined architecture and clear components, it will be easier for new developers to modify and create new components. On the contrary, if the architecture is messy, then it can become a real nightmare for any new developer that has to extend the code.

This is a problem commonly found in real life programming teams, since the programmers might move on from project to project or might involve new developers into their teams as the system keep changing and evolving.

The concept of software architecture is useful not just for future programmers, but actually can be the very foundation of how the software will be built.  It can help programmers to identify the necessary parts and if all the requirements are actually fulfilled. It’s also the way programmers will communicate the shape of the system. It helps to keep consistency within the system.

So, this helps to clearly identify each component and its function, to eliminate duplicate functions and have clear goals of what each component should do.

As the author says “In a well-designed system, there should be neither too few nor too many components”. So finding the right balance for this is key to avoid running into too much trouble later.