On BA chapter 1

Chapter one is trying to shed light on the question of what software architecture is. While being very similar to building architecture in the way that it consists of a set of structures designed to help the stakeholders see how their concerns are satisfied, software architecture is still fundamentally different through its dynamic and interactive nature, where the number of interactive components, the environment where they are running and the way the performers interact with the system play a major role.

In the context of software, because it highlights some details by abstracting away from others, the architecture is then seen as a subset of design. In other words, architecture is concerned with the relationship between components, and the externally visible properties of the system components, while design is additionally concerned with their internal structure.

Getting a solid architecture is about making the right decisions. These decisions should be made intentionally rather than just “letting the architecture emerge”. Early decisions, documented, made explicitly with the view in mind of the entire system, its stakeholders and its evolution, are key to getting a good architecture. Having the architecture reflect one set of design ideas as opposed to many good but uncoordinated and independent set of ideas confers that system conceptual integrity (Brooks 1995), which makes the architecture maintainable. There is also a bidirectional relationship between architectures with conceptual integrity and the organizational pattern in a way that good architecture can influence organization and good organization results in conceptual integrity.

As confusing as it may sound, the first concern of the architect is neither functionality or quality, but understanding the stakeholders and their concerns and prioritizing them. Funders, architects, developers, project managers, marketing, users, testers and technical support may all have something to say about the chosen architecture. Furthermore, beside functional and quality requirements, individual systems may have their own additional critical concerns (as changeability, capacity, security, etc.)

In the end the authors go over architectural structures, which are formal means of addressing each particular concern, by specifying relationships between individual components of a system. The most notable types of structures are the ones dealing with information hiding, data access, structures dealing with relationships between processes and Uses structures, dealing with relationships between programs in a system.

The overall impression from the chapter is probably the one most of us already experienced. There is no single correct architecture and no single correct answer, it is all a game of trade-offs and compromises that only make the architecture good, relative to the stakeholders involved and their own specific concerns.