08Stage 8 of 8 · Evolution
What do we learn for the next step?
Here you plan the further development of your architecture based on new requirements and experiences.
You need
- Operational signals and insights
- New requirements
Who
Product owner leads
with Payment module owner, Platform team, Operations
How to proceed
- 1
Evaluate the need for change and technical debt.
- 2
Check boundaries and decisions based on the new findings.
- 3
Plan migrations and the next checking steps.
In the shop
Evolve the shop step by step
- Fitness function
- A test flags unauthorised database access between the order, shipping and invoice modules.
- Debt
- The shipping module reads order tables directly; status changes need coordination.
- Strangler
- Only invoice lookup is moving gradually to a new service.
- Migration
- Create the invoice identifier as optional first, then read it as mandatory later.
This creates
- Updated decisions
- Development measures
- New requirements
Tools for this:Architecture reviewArchitecture fitness functionThreat ModelingArchitecture risk registerAll under “Validate” →
Done when
- Need for change and debt have been assessed.
- Decisions are updated in light of new insights.
- Next migration steps and checks are planned.
Appropriate Building Blocks
Evolution · ConceptTechnical debtHere you learn how technical debt arises and how to assess its later change costs.Evolution · PatternStrangler migrationStrangler migration gradually replaces capabilities of an existing system with a new implementation.Evolution · ActivityData migrationData migration coordinates changes to data models with software versions running in parallel.Evolution · RiskArchitecture erosionArchitecture erosion shows how implementation gradually diverges from agreed boundaries.Communication · MechanismAPI versioningAPI versioning makes interface changes predictable for existing users.
New requirements start the next round. To: Requirements →