Evolutionary Architecture
Designing for guided incremental change rather than for correctness on day one.
3 to work through
-
advanced
A design platform's rendering service was built for single-page exports. Over three years it accumulated video, animation, bulk export and print output - each bolted onto the same synchronous request path. Exports now time out unpredictably. How should evolutionary architecture have prevented this, and what do you do now?
2 min answer -
advanced
A frequently written table needs a column renamed and its type changed. The service runs many instances and cannot be stopped. How do you do it and remain able to roll back at every step?
3 min answer -
advanced
A services marketplace launches in one city with one category. Three years later it runs dozens of categories across many cities with different pricing and compliance rules. What should have been built on day one, and what should deliberately not have been?
2 min answer
4 terms in this topic
Architectural Debt
Structural compromises that increase the cost of all future change, distinguished from code-level debt by being expensive and slow to repay.
conceptEvolutionary Architecture
Designing for guided incremental change rather than for a correct end state, because the requirements that will matter most are not yet known.
practiceLast Responsible Moment
Defer an irreversible decision until the cost of deferring exceeds the cost of deciding - and define in advance the signal that says the moment has a…
practiceRule of Three
Hard-code the first case, copy for the second, abstract at the third - because only the third instance reveals which parts actually vary.
Neighbouring topics
Architecture Fundamentals
General material on what solution architecture is and what an architect is accountable for.
Requirements to Constraints
Turning stated requirements into the constraints that actually bound a design.
Functional vs Non-Functional
Behaviour versus quality of behaviour, and why only the second constrains structure.
Architectural Drivers
The small subset of requirements whose change would force the structure to change.
Quality Attributes
Availability, latency, throughput, security, cost — expressed as testable scenarios.
Architecture Principles
Durable agreed rules that rule options out, stated with rationale and implications.
Coupling
How much one component must know about, or change alongside, another.
Cohesion
Whether the things inside a boundary belong together and change for the same reason.
Modularity
Composing a system from parts that can be understood and replaced independently.
Separation of Concerns
Organising so that a change to one concern touches one place.
Abstraction & Encapsulation
Hiding mechanism behind contract, and protecting invariants by owning state.
Architecture Styles
System-level organising shapes, and how they differ from problem-level patterns.
Fitness Functions
Automated checks that an architectural characteristic still holds.
Architecture Documentation
What to write down, at what altitude, and what nobody will ever read.
Conway's Law
Systems mirroring the communication structure of the organisation that builds them.
Trade-off Fundamentals
Why every architecture is a set of purchases, and how to state what you gave up.
Technical Constraints
Existing estate, skills, licences and platforms as inputs rather than obstacles.
Architecture Roles
Solution, enterprise, domain and platform architecture, and where each is accountable.
Reference Models
Shared conceptual frames — layering, tiers, viewpoints — and their limits.