Evolutionary architecture preserves the ability to change through small, incremental, rapid modifications. It assumes platform decisions will change as technologies, customer expectations, inefficiencies, and available services evolve; therefore, platform architectures have no fixed end state. section 1.3.3 section 2.3
Design for change by:
- Preserving the ability to change each functional attribute and integration point. section 1.3.3
- Making architectural requirements part of every tool, vendor, infrastructure, and implementation decision. section 2.3
- Implementing capabilities only to the needed degree and reducing the cost of changing strategy later. section 2.3
- Favoring smaller technologies that interoperate well over bloated stacks that encourage vendor lock-in. section 5.3.2
- Continuously measuring whether platform domains remain valid, including loose coupling, service-interface-first design, and release independence. section 3.5.4
Observability platform choices
An observability platform can combine several focused technologies rather than adopting a large do-it-all stack. A flexible hosted service may provide faster time to value and support, while an in-house solution may provide more control but require substantial labor. The architectural choice should preserve future options while weighing cost, time, control, and lock-in. section 5.3.2
Figure 1.5 Software defined is placed in the middle because it is a core attribute of everything the platform engineer delivers. The rest of the principles share a connection because they continuously evolve, and decisions made in applying these surrounding principles can affect the requirements of the others.
Use the connected-principles diagram to see evolutionary architecture alongside software-defined delivery, self-service, metrics-driven success, and related platform concerns. section 1.3.3
