Building Evolutionary Architectures: Support Constant Change

by Neal Ford

but balancing the pros and cons of each architectural decision leads to the tradeoffs so commonly lamented by architects.

what if we build changeability into the architecture?

Historically, a portion of architecture has often been viewed as a governance activity, and architects have only recently accepted the notion of enabling change through architecture.

For example, if the project includes a relational database, the structure and relationship between database entities will evolve over time as well.

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.

April 1968, Melvin Conway submitted a paper to Harvard Business Review called, “How Do Committees Invent?”

it’s hard for someone to change something if the thing she wants to change is owned by someone else.

Structure teams to look like your target architecture, and it will be easier to achieve it.

Adapting implies finding some way to make something work regardless of the elegance or longevity of the solution.

A system is never the sum of its parts. It is the product of the interactions of its parts.

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.

Architects never know all important parts of the architecture at the beginning (the classic unknown unknowns problem

Making the wrong design choices that ultimately lead to building software that fails in its environment Making design choices that cost time and/or money but are unnecessary Not being able to evolve the system easily in the future when the environment changes

Old services aren’t forced to upgrade and can continue to call the original service as long as they need it.

Architects often fall into the trap of seeing software architecture as an equation they must solve. Much of the commercial tooling sold to software architects reinforces the mathematical illusion of certainty with boxes, lines, and arrows.

Testable

One of the bedeviling problems in component-based systems is component

Fast change to code implies fast changes to database schemas, but the database administrators are more concerned about stability because they are building a data warehouse.

To learn from users, the developers released a new version of the legacy application with logging enabled to track which menu features users actually used.

To successfully evolve software, developers must consider all the coupling points that could break.

Yet, creating common shared artifacts causes a host of problems, such as coupling, more difficult coordination, and increased complexity. The bounded context concept recognizes that each entity works best within a localized context.

project—make sure that all the terms on the team mean the same thing.

Eventually, we unrefactored the Listing class back into a single large entity, because the software project revolved around it.

Developers created highly coupled classes with poor modularity. Database schemas snaked into the UI and other parts of the system, effectively insulating them against change.

Architects don’t traditionally include data dependencies within the technical architecture for microkernels, so developers and DBAs must consider data evolution independently.

Once the core system is complete, most behavior should come from plug-ins, small units of deployment.

No one perspective on architecture is “correct,” but rather a reflection on the goals developers build into their projects.

Architects shouldn’t choose an architecture without evaluating it against the real problems they must solve.

Coding standards don’t help for this type of problem because developers have a hard time remembering bureaucratic policies in the heat of coding.

Architects quickly discover, however, that using the database as an integration point fossilizes the database schema across all sharing projects.

Thus, database vendors have secreted armies within enterprises all over the world, where loyalties lie with the vendor rather than the company. DBAs in this situation ignore tools and other development artifacts that don’t come from the mothership.

Software suffers from the unknown unknowns

For many developers, refactoring has become synonymous with change, but there are key differences.

It is exceedingly rare that a team refactors an architecture; rather, they restructure it,

Adding fitness functions to package software is perhaps the biggest hurdle to enable evolvability. Generally, tools of this ilk don’t expose enough internals to allow unit or component testing, making behavioral integration testing the last resort.

Most developers would rather write a framework than use a framework to create something useful: Meta-work is more interesting than work.

A decade later, their best developers worked in full-time maintenance mode, fixing their application server, adding features to their web framework, and other mundane chores.

All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections.

A common manifestation of this goal is the modern DevOps perspective on building immutable infrastructure.

Modern DevOps has solved the dynamic equilibrium problem locally by replacing snowflakes with immutable infrastructure. Snowflake computers are ones that have been manually crafted by an operations person, and all future maintenance is done by hand.

Building software systems that evolve means controlling as many unknown factors as possible.

“We know we’ll need a message queue for lots of stuff eventually, so let’s get the fanciest one we can now and grow into it later.” The problem with this approach is technical debt: stuff that’s part of your project that isn’t supposed to be there and is in the way of stuff that is supposed to be there.

Some development communities love preemptive layers of abstraction to a distracting degree but understanding suffers when you must call a Factory to get a proxy to a remote interface to a Thing.

Developers understand the benefits of everything and the tradeoffs of nothing! Rich Hickey, creator of Clojure

For example, set up an internal version-control repository to act as a third-party component store, and treat changes from the outside world as pull requests to that repository.

First, an antipattern is a practice that initially looks like a good idea, but turns out to be a mistake. Second, better alternatives exist for most antipatterns.

However, many organizations become overambitious with this category of software, leading to the vendor king antipattern, an architecture built entirely around a vendor product that pathologically couples the organization to a tool.

However, a lot of the time ERP tools can’t be customized enough to fully implement what is needed,

Developers are technically constrained by choices the vendor makes in terms of persistence, supported infrastructure, and a host of other constraints.

But abstractions come at a cost because no abstraction is perfect—if