The enterprise architect in an evolutionary practice
In a traditional model the enterprise architect defines target states, maintains standards documents, and approves designs at review boards. In an evolutionary model the job shifts toward setting direction, defining what “good” means, and automating the checks, while teams make most of the decisions.
How the role changes
Section titled “How the role changes”| Traditional | Evolutionary |
|---|---|
| Fixed target-state architecture | Direction plus fitness functions; target state is revised as you learn |
| Standards documents | Guardrails and policies as code, plus golden paths |
| Architecture review board approves designs | Pipelines enforce the objective rules; humans discuss the hard trade-offs |
| Architect decides | Teams decide, with advice; decisions are recorded |
| One standard technology per category | A range of options with clear criteria (“goldilocks governance”) |
| Long-range roadmap | Short planning horizons, options kept open |
Tools of the practice
Section titled “Tools of the practice”- Architecture Decision Records (ADRs). Short documents capturing context, decision, and consequences (Michael Nygard’s format is common). They make reasoning visible and make it easier to revisit decisions later. See the worked AWS ADRs.
- Fitness functions and guardrails. The enterprise-wide ones (security, compliance, cost, resilience) are a natural EA responsibility.
- Technology radar. Thoughtworks’ Adopt / Trial / Assess / Hold format works well internally to communicate direction without hard mandates.
- The advice process. From Andrew Harmel-Law’s work: anyone can make an architectural decision as long as they seek advice from those affected and from people with expertise. The architect becomes a key adviser rather than a gate.
- Architectural characteristics workshops. Help teams identify and rank the “-ilities” that matter for their system.
- Architecture katas. Practice exercises for building architectural thinking across teams.
Where an EA focused on cloud platforms adds value
Section titled “Where an EA focused on cloud platforms adds value”- Define the enterprise-wide fitness functions (security baseline, data residency, resilience tiers, cost accountability) and make sure they’re implemented as code.
- Shape the lower platform layers (account structure, network, identity), where decisions are hardest to reverse.
- Keep the coupling between business capabilities appropriate, so teams and quanta can evolve independently.
- Track evolvability metrics across the portfolio (DORA, golden-path adoption, exception counts).
- Make trade-offs explicit, especially around vendor lock-in versus speed.