More on this book
Community
Kindle Notes & Highlights
That’s why software architecture is defined as the “parts hard to change later.”
Architects build layers to isolate change.
continual architecture: building architectures that have no end state and are designed to evolve with the ever-changing software development ecosystem, and including built-in protections around important architectural characteristics.
An evolutionary architecture supports guided, incremental change across multiple dimensions.
incremental change at the architectural level: the original service can run alongside the new one as long as other services need it. Teams can migrate to new behavior at their leisure (or as need dictates), and the old version is automatically garbage collected.
A fitness function is an objective function used to summarize how close a prospective design solution is to achieving the set aims.
When an architect identifies an architectural characteristic they want to protect as things evolve, they define one or more fitness functions to protect that feature.
Evolutionary architecture is not an unconstrained, irresponsible approach to software development. Rather, it is an approach that balances the need for rapid change and the need for rigor around systems and architectural characteristics. The fitness function drives architectural decision making, guiding the architecture while allowing the changes needed to support changing business and technology environments.
Some dimensions fit into what are often called architectural concerns (the list of “-ilities” above), but dimensions are actually broader, encapsulating things traditionally outside the purview of technical architecture.
the 4 + 1 architecture View Model, which focuses on different perspectives from different roles and was incorporated into the IEEE definition of software architecture, splits the ecosystem into logical, development, process, and physical views.
the architect must still protect that dimension.
To build an evolvable system, architects must think about how the system might evolve across all the important dimensions.
Conway introduced the notion that the social structures, particularly the communication paths between people, inevitably influence final product design.
Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. Melvin Conway
In his paper, Conway was effectively warning software architects to pay attention not only to the architecture and design of the software, but also the delegation, assignment, and coordination of the work between teams.
Software architects should pay attention to how work is divided and delegated to align architectural goals with team structure.
Structure teams to look like your target architecture, and it will be easier to achieve it.
The definition of evolutionary architecture that we state here includes two critical characteristics: incremental and guided.
We prefer the word evolutionary over adaptable because we are interested in architectures that undergo fundamental evolutionary change, not ones that have been patched and adapted into increasingly incomprehensible accidental complexity.
evolutionary is about the process of having a system that is fit for purpose and can survive the ever-changing environment in which it operates.
An evolutionary architecture consists of three primary aspects: incremental change, fitness functions, and appropriate coupling.
An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).
the systemwide fitness function as a collection of fitness functions with each function corresponding to one or more dimensions of the architecture.
Tradeoffs dominate much of an architect’s headaches during the struggle to reconcile opposing forces, such as scalability and performance.
A system is never the sum of its parts. It is the product of the interactions of its parts. Dr. Russel Ackoff
as with acceptance criteria in agile software development, the fitness functions for evolutionary architecture may not be implementable in software (e.g., a required manual process for regulatory reasons), but architects must still define manual fitness functions to help guide the evolution of the system.
While we can’t necessarily run a single script and say “our architecture currently has a composite fitness score of 42,” we can have precise and unambiguous conversations about the state of the architecture relative to the systemwide fitness function. We can also entertain discussions about the changes that might incur on the architecture’s fitness.
Finally, when we say an evolutionary architecture is guided by the fitness function, we mean we evaluate individual architectural choices against the individual and the systemwide fitness function to determine the impact of the change.
Fitness functions unify many existing concepts into a single mechanism, allowing architects to think in a uniform way about many existing (often ad hoc) “non-functional requirements” tests. Collecting important architecture thresholds and requirements as fitness functions allows for a more concrete representation for previously fuzzy, subjective evaluation criteria.
Atomic fitness functions run against a singular context and exercise one particular aspect of the architecture.
Holistic fitness functions run against a shared context and exercise a combination of architectural aspects such as security and scalability.
cannot test every possible combination of architecture elements, so architects use holistic fitness functions selectively to test important interactions.
Triggered fitness functions run based on a particular event, such as a developer executing a unit test, a deployment pipeline running unit tests, or a QA person performing exploratory testing.
Continual tests don’t run on a schedule, but instead execute constant verification of architectural aspect(s)
MDD uses monitors in production to assess both technical and business health.
Static fitness functions have a fixed result, such as the binary pass/fail of a unit test.
Dynamic fitness functions rely on a shifting definition based on extra context.
While architects will define most fitness functions at project inception as they elucidate the characteristics of the architecture, some fitness functions will emerge during development of the system. Architects never know all important parts of the architecture at the beginning (the classic unknown unknowns problem we address in Chapter 6) and thus must identify fitness functions as the system evolves.
Teams should identify fitness functions as part of their initial understanding of the overall architecture concerns that their design must support. They should also identify their system fitness function early to help determine the sort of change that they want to support.
Without identifying fitness functions this early, a team may end up with these responsibilities scattered throughout the entire codebase, requiring a broader impact analysis to understand change and driving up the overall cost of modification.
Keep knowledge of key and relevant fitness functions alive by posting the results of executing fitness functions somewhere visible or in a shared space so that developers remember to consider them in day-to-day coding.
Classifying fitness functions into categories helps prioritize design decisions.
Evolutionary design in databases occurs when developers can build and evolve the structure of the database as requirements change over time.
The key to evolving database design lies in evolving schemas alongside code.
Using this pattern, developers have a starting state and an end state, maintaining both the old and new states during the transition. This transition state allows for backwards compatibility and also gives other systems in the enterprise enough time to catch up with the change.
Developers encounter transactions as coupling points when attempting to translate heavily transactional systems to inappropriate architectural patterns like microservices, which impose heavy decoupling burdens. Service-based architectures, with much less strict service boundary and data partitioning requirements, fit transactional systems better.
