Lean and agile enterprise architecture

The tension

Traditional EA grew up in a world of annual plans, big projects, and long design phases. Most engineering organizations now deliver continuously, in small increments, with autonomous teams. Put the two together carelessly and you get one of two failures:

• EA as a gate: teams wait weeks for architecture approval, then route around it.
• EA as irrelevant: teams move fast without coherence, and the estate fragments.

Lean and agile EA aims for a middle path: just enough intentional architecture to keep the enterprise coherent, with emergent design within it. SAFe describes this as the balance between intentional architecture and emergent design.

The underlying shift is from controlling decisions to shaping the environment in which teams decide.

Architecture Decision Records

An Architecture Decision Record (ADR) is a short document capturing one significant decision. The format popularized by Michael Nygard has five parts:

# ADR-012: Use a single identity provider for all customer-facing products

Status: Accepted (2026-03-14)

Context
  Customers log in separately to the core platform and FixIt Pro. EU launch
  requires single sign-on, GDPR-compliant consent, and EU data residency.
  Options considered: (1) extend the core platform's auth; (2) adopt a managed
  identity provider; (3) keep separate logins and federate.

Decision
  Adopt a managed identity provider, deployed in the EU region, for all
  customer-facing products.

Consequences
  + SSO across products; MFA and consent handled consistently
  + Removes an in-house auth system we'd otherwise have to scale
  − Per-user licensing cost (~£X/year at current volumes)
  − FixIt Pro migration needed; dispensation granted until T2

Many teams extend this with a structured options section, as in MADR (Markdown Any Decision Records).

Which decisions need an ADR?

Ask two questions:

1. How expensive is it to reverse? Database, identity, and integration-style choices are expensive. Library choices inside one service usually aren’t.
2. How far does it reach? One team, or many?

	One team	Many teams
Expensive to reverse	Team ADR	Enterprise ADR (EA involved)
Cheap to reverse	Just decide	Team ADR, shared for visibility

Making ADRs work

• Store them where people work: alongside code for team ADRs, and in one discoverable place for enterprise ADRs.
• Never edit an accepted ADR: supersede it with a new one that links back. The history is the point.
• Write them before the decision is final, as a proposal. The ADR becomes the discussion document.
• Keep them short. One to two pages. If it’s longer, it’s a design doc.

Guardrails over gates

A gate says “stop and ask permission.” A guardrail says “go ahead, within these boundaries.” Guardrails scale; gates don’t.

Gate	Guardrail equivalent
Architecture review before choosing a database	Approved list of databases on the radar; review only for anything outside it
Security sign-off before every release	Automated dependency, secrets, and container scanning in CI
Manual check that services don’t call each other’s databases	An automated dependency rule that fails the build
Approval for every new cloud resource	Policy-as-code that blocks non-compliant resources (e.g. outside EU regions)

Paved roads

A paved road (or golden path) is a well-supported default way of doing something: a service template with logging, auth, CI/CD, and observability already wired in. Teams can go off-road, but the paved road is so much easier that most don’t.

Paved roads are often built by a platform team. EA’s role is to make sure the paved road embodies the principles and standards, which is far more effective than documenting them.

Fitness functions

From Building Evolutionary Architectures (Ford, Parsons, Kua): a fitness function is an objective check of how well a system meets an architectural characteristic. Examples:

• p95 latency of the payments API stays under 300 ms (performance test in the pipeline)
• No service in the tenancy domain imports from payments internals (dependency rule)
• All personal data stores are tagged and in EU regions (cloud policy check)

Fitness functions turn architectural intent into something continuously verified, not occasionally reviewed.

When a review is still right

Guardrails can’t cover everything. Keep human review for decisions that are novel, high-impact, and hard to reverse, such as a new core platform, a major vendor contract, or a significant data architecture change. Make those reviews advisory and fast: a forum where teams bring ADRs for discussion, with a clear decision owner.

Technology radar

A technology radar, popularized by Thoughtworks, is a regularly updated view of technologies and techniques, each placed in a ring:

Ring	Meaning
Adopt	Proven here; use it by default
Trial	Use on real work where the risk is manageable; we’re building experience
Assess	Worth exploring; spikes and proofs of concept only
Hold	Don’t start new work with it

It’s usually split into quadrants such as techniques, tools, platforms, and languages & frameworks.

Running it in a federated community

• Crowdsource proposals from engineers and tech leads, not just architects.
• Decide in a regular session (quarterly is common) with representatives from across teams.
• Write a short rationale for every blip. The reasoning is more valuable than the placement.
• Use it in governance: Adopt and Trial items need no review; anything else is a conversation.

SAFe and enterprise architecture

The Scaled Agile Framework (SAFe) is widely used in larger organizations, so you’ll meet its vocabulary:

• Enterprise Architect: works across value streams on strategic themes, technology strategy, and enterprise-wide architecture.
• Solution / System Architects: work within a solution or Agile Release Train on its architecture.
• Architectural runway: the existing code, components, and infrastructure needed to implement near-term features without excessive redesign.
• Enablers: backlog items that build runway (exploration, architecture, infrastructure, compliance).

Even if your organization doesn’t use SAFe, runway is a useful concept: EA helps make sure the runway exists before the features that need it arrive.

TOGAF and agile

TOGAF and agile aren’t opposites. The ADM can run at different speeds and levels at once: a strategic cycle setting direction over years, and many small, fast cycles inside it. TOGAF’s Series Guides include guidance on agile use. The Open Group also publishes a separate standard, the Open Agile Architecture (O-AA), aimed at architecture in agile, digital organizations.

At Quillfeather

Your lean EA toolkit, six months in:

• Enterprise ADRs: 14 written, in a single repository with an index page. The SSO decision above was ADR-012.
• Paved road: you worked with the platform team to add EU-region deployment, the identity provider integration, and the notification platform client to the service template. Three new services adopted it with no architecture review needed.
• Fitness functions: a cloud policy blocking personal-data stores outside approved regions, and a dependency rule stopping new direct calls into PayNest’s database.
• Radar: first edition with 40 blips, built in a two-hour session with 12 tech leads. Two of the three notification libraries went straight to Hold.
• Architecture forum: fortnightly, 45 minutes, ADRs only. Average time from ADR proposal to decision: 9 days, down from “whenever the CTO has time.”

Reflection

• What are the gates in your organization today? Which could become guardrails?
• What does your organization’s paved road look like, if it has one? Who owns it?
• Write an ADR for a decision your team made in the last six months. How long did it take? What did you learn by writing it down?