Evolutionary Architecture

Design evolution

In The Evolution of Useful Things [Pet92], Henry Petroski argues that the old dictum “Form follows function” is false. In its place, he offers the rule of design evolution, “Form follows failure.” That is, changes in the design of such commonplace things as forks and paper clips are motivated more by the things early designs do poorly than those things they do well. Not even the humble paper clip sprang into existence in its present form. Each new attempt differs from its predecessor mainly in its attempts to correct flaws.

The fledgling system must do some things right, or it would not have been launched, and it might do other things as well as the designers could conceive. Other features might work as built but not as intended, or they might be more difficult than they should be. In essence, there are gaps and protrusions between the shape of the system and the solution space it’s meant to occupy. In this section, we’ll look at how the system’s architecture can make it easier to adapt over time.

Evolutionary architecture

In Building Evolutionary Architectures [FPK17], Neal Ford, Rebecca Parsons, and Patrick Kua define an evolutionary architecture as one that “supports incremental, guided change as a first principle across multiple dimensions.” Given that definition, we might reasonably ask why anyone would build a non-evolutionary architecture. Sadly, it turns out that many of the most basic architecture styles inhibit that incremental, guided change. For example, the typical enterprise application uses a layered architecture like the one ...