Software Architecture

The chapter starts with a special and interesting quote, expressing that the architecture is the art of how to waste space. The whole article uses metaphors related to the buildings design and architecture procedures. I think the metaphor about the previous procedures that an architect needs to consider before start working is precise, as software architects we need to consider what the buildings architecture consider too but focused in our TI activities.

For example, the blueprints as the article explains, show the primary level of information about the system, not how we’ll implement them or what it’s supposing to do, just the components that will be part and in conjunction will define the product itself, also how these components will interact and the “meaning” of each one. When we “map” something, we are in our first chance to define the “real world problem” what the product is attempting to solve and define its solution domain.

The most specific is our description at the architectural level, the less hard it will be the implementation and design stages. Something not obvious, but useful because we may think that the most important phase is the design or maybe the implementation phase. Some important blueprints we need to consider at this level are the conceptual view that show us the “connected” parts, the implementation will help us to know how the modules are going to be implemented, the process view show us how occur the tasks, processes and communications and finally the deployment view show the task of the physical nodes.

The mean purpose of the chapter is to explain why is important the architecture phase, to help us avoid bad practices, as duplicate work, waste effort or have redundancy in our processes. The chapter finally explain us why this phase is important because it may help us to define the problem or risky areas and how to define a strategy to minimize their impact between the components and their connections.