Goodreads: https://www.goodreads.com/book/show/27283384-designing-software-architectures
Amazon: https://www.amazon.com/Designing-Software-Architectures-Practical-Engineering/dp/0134390784
Attribute Driven Design (ADD) is, to our knowledge, the most comprehensive and most widely used documented architecture design method
What makes a decision "architectural"?
- A decision is architectural if it has non-local consequences and those consequences matter to the achievement of an architectural driver such
- The choice of a buffering strategy within a single element may have little effect on the rest of the system, in which case it is an implementation detail that is of no concern to anyone except the implementer or maintainer of that element.
- The choice of a buffering strategy, like most design choices, is neither inherently architectural nor inherently non-architectural. Instead, this distinction is completely dependent on the current and anticipated architectural drivers.
Architectural design vs development design?
- The elements that support these nonprimary use cases and their interfaces are identified as part of what we call element interaction design which follows architectural design
- The location and relationships of these elements, however, are constrained by the decisions that were made during architectural design.
- These elements can be units of work (i.e., modules)...
-
- (...) the architect should be involved in element interaction design, (...) ensures that the system’s important quality attributes are not compromised—for example, if the elements are not defined, located, and connected correctly.
- third level of design, which we call element internals design follows where the internals of previously identified elements are established
- architectural decisions can and do occur at the three levels of design
Allocation of functionality to modules in development vs during the design
- Decisions regarding the allocation of functionality that are made during architectural design establish a precedent for how the rest of the functionality should be allocated to modules as development progresses. This is usually not the work of the architect; instead, this activity is typically performed as part of the module interaction design process
- Finally, bad decisions that are made regarding the allocation of functionality result in the accumulation of technical debt.
More on architectural design vs development design - reiteration of previous points
- not all of the internal interfaces are identified during architectural design
- during architecture design process, you consider the primary use cases (..) and elements (usually modules) that support them
- This process will not uncover all of the elements and interfaces for the system that are required to support the entire set of use cases.
- This lack of specificity is intended: Architecture is about abstraction, so necessarily some information is less important, particularly in the earliest stages of design.
- the identification of the interfaces associated with the modules that support the nonprimary use cases is typically not your responsibility,
- This task, (element interaction design) usually performed after architectural design ends but before the development the modules begins. Although this task should be performed by other members in the development team, you play a critical role in it, since these interfaces must adhere to the architectural design that you established
Sales pitch for architecture
- By restricting design alternatives, architecture channels the creativity of developers, reducing design and system complexity.
- Freeman Dyson, the English physicist, once said the following: “A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible”
- Architecture is a key enabler of agility
- technical debt occurs for a variety of reasons, but (..) is the combination of a focus on features (...) and the inability of architects and project managers to measure the return on investment of good architectural practices
- Without architecture, the benefits that the system is supposed to bring will be far harder to realize.
- architecture can be a transferable, reusable model that forms the heart of a product line
Analysis techniques
