Software architecture

In this entry of the book is good to know that Software Architecture really means both of its parts, that it uses real architecture and building as an analogy of how the development should be, from the blueprint, detailing all the modules and how they connect one to another, just like in the blueprints used in buildings, to even the point of view that in my opinion are not as closely based, it says they are based on different points of view of the building, one from structure, wiring, plumbing, etc., and they are comparing it to the conceptual, implementation, process and deployment, I can se the relation but I don’t think is as close as talking about the 1 to 1 that are blueprints.

Apart from the blueprints they also talk about requirements and how the arquitects must know super well the primal need of their clients, and have a clear view of the project, because bad decisions early are much cheaper that bad decisions in a later stage of the game with the error running through all the project

Also it was relevant to me the description about the components and its connections, that the components or how they are considered components vary from project to project and what they are talking about, mostly the define it as a cumulative of something that either works or not by itself and can connect to others to provide more functionality, and connections are just that the relationships between the modules or the components and how they interact with each other, how they contact each other, what are they allowed to see, what resources they share, what resources are independent, the inputs outputs, if it is asynchronous, in essence control all the flow of the system and ensure it is as smooth as possible