
Hi,
this week I started reading this book, since software architecture is the computer science’s area that I like most. It’s too early to give my real opinion about it, but it has a very good reading. After the introduction chapters, I was able to understand the real concept of Software Architecture, its business cycle, known as ABC, and what makes a good architecture. So, let’s do it in parts.
Software architecture has emerged as a crucial part of the design process, representing a summary result of a set of business and technical decisions. It is defined as follows:
“The software architecture of a program is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.“
So, the architecture defines components, their nature, the relationship among them, the significance of each relationship, the significance of the layout and the data and control flow through the system.
After the definition, it’s time to understand the architecture business cycle. Here is how it works:
-
The architecture affects the structure of the developing organization: teams are formed for each software unit; schedules and budgets allocate resources in chunks corresponding to the units.
-
The architecture can affect the enterprise goals of the developing organization: a succesfull system can enable a company to establish a foothold in a particular area.
-
The architecture can affect the customers requirements for the next system by presenting the customer with the opportunity to receive an upgrade system (based on the same architecture) in a more reliable, timely and economical way than building a system from scratch.
-
The process of building the system will affect the architect’s experience for subsequent systems.
-
A few systems will influnce and actually change the software engineering culture.
Finally, the answer that everyone wants to know: What makes a good architecture? Unfortunately, there is no such thing as an inherently good or bad architecture, but a software architecture that fits more or less for some stated purpose. Even so, there is some process/structural roles when creating a system architecture, as described below:
-
The architecture should be the product of a single architect or a small group of architects with an identified leader.
-
The architect should have the technical requirements for the system.
-
The architecture should be well documented.
-
The architecture should be circulated to the system’s steakholders, who should be actively involved in its review.
-
The architecture should feature well-defined modules whose functional responsabilities are allocated on the principles of information hiding and separation of concerns.
-
The architect should never depend upon a particular version of a comercial product or tool.
-
The architecure should feature a small number of simple interaction patterns.
Well, I’ve just read three chapters and in a close future we will have a lot of other things to discuss here.
See you.
–
Fernando