Open Agile Architecture Practitioner cheat sheet

Open Agile Architecture (O-AA) is an Open Group standard that reframes enterprise architecture as a continuous, product-centric discipline combining Agile delivery with architecture governance.

Two complementary halves: the Agile Architecture body of knowledge (Agile Enterprise Architecture) and the Agile Organization body of knowledge (transformation and operating model).

Core premise: architecture is done continuously by the teams building products, not in a separate upfront phase; the architect's role shifts from gatekeeper to enabler and coach.

Key O-AA themes include customer-centricity, product over project, autonomous empowered teams, continuous delivery, and evolutionary architecture with fitness functions.

O-AA positions architecture runway work as intentional, just-enough, just-in-time design that supports near-term delivery rather than a complete target-state blueprint.

The O-AA body of knowledge is organized into a set of practices and techniques (e.g., Agile Architecture, Agile Strategy, Agile Organization) rather than fixed phases or a rigid metamodel.

O-AA aligns with Agile/Lean principles and complements frameworks such as SAFe, Scrum, and DevOps; it is not a replacement for TOGAF but a complementary Agile mindset extension.

Practitioner level emphasizes applying O-AA practices in real contexts: facilitating architecture decisions, enabling teams, and evolving the operating model.

Agile Architecture practices cover decision-making, architecture runway, intentional architecture, emergent design, and architecture as code.

Agile Strategy practices cover value streams, strategy-to-execution alignment, outcome-based roadmaps, and OKRs linking enterprise goals to team backlogs.

Agile Organization practices cover team topologies, autonomous teams, organizing around value, and the transformation roadmap for the operating model.

Intentional architecture: deliberate, high-level structural decisions made early; emergent design: structure that evolves through delivery feedback; both coexist.

Fitness functions are automated or repeatable checks that verify architectural characteristics (e.g., performance, security, modularity) remain intact as the system evolves.

Architecture runway is the backlog of architecture work needed to keep teams unblocked for the next few iterations; it is time-boxed and demand-driven.

Architecture as code: expressing architecture decisions, models, and constraints as versioned artifacts in the same repository and pipeline as software.

Decision records (e.g., ADRs) capture context, decision, and consequences; they are lightweight, versioned, and owned by the teams making the decision.

Value streams map end-to-end flow of value to the customer; they are the primary unit for aligning strategy, architecture, and delivery.

OKRs connect enterprise outcomes to team-level objectives; architecture work is justified by the outcomes it enables, not by completeness of a blueprint.

Organizing around value means structuring teams by value stream or product rather than by functional silo or technology layer.

Team topologies (stream-aligned, platform, enabling, complicated-subsystem) define interaction modes and reduce cognitive load on delivery teams.

Autonomous, cross-functional teams own their architecture decisions within guardrails; architects provide principles, standards, and coaching rather than approvals.

Transformation roadmap sequences operating-model changes (structure, governance, funding, culture) alongside technology changes.

Funding shifts from project-based to product/value-stream-based, enabling continuous flow and reducing stop-start delivery.

Governance becomes lightweight and outcome-focused: principles, guardrails, and fitness functions replace stage-gate architecture reviews.

Agile governance uses principles and guardrails to enable autonomy; decisions are decentralized to the lowest competent level.

Architecture reviews become continuous and collaborative (e.g., lightweight decision forums, office hours) rather than periodic gate approvals.

Continuous delivery practices (CI/CD, automated testing, trunk-based development) are architectural enablers, not afterthoughts; architecture must support deployability.

Evolutionary architecture: design for change by decoupling components, using fitness functions, and avoiding irreversible big-bang decisions.

Practitioner competencies include facilitation, coaching, systems thinking, stakeholder communication, and the ability to balance intentional and emergent design.

Metrics for Agile architecture focus on flow (lead time, deployment frequency), outcome achievement, and fitness-function health rather than document completeness.

Anti-patterns: big upfront design, architecture review boards as bottlenecks, ivory-tower architects, and architecture documentation that is not maintained.

Practitioner exam readiness: know the O-AA practices by name, their purpose, and how to apply them to align strategy, organization, and delivery.

When starting, identify value streams and outcomes first; derive architecture runway and fitness functions from the delivery teams' near-term needs.

Choose intentional vs emergent design based on reversibility: irreversible, high-cost decisions get intentional treatment; reversible ones emerge.

Establish guardrails (principles, standards, fitness functions) before decentralizing decisions; guardrails must be testable and owned.

Use ADRs to record decisions with context and consequences; store them with code and review them as part of delivery flow.

Balance team autonomy with platform teams that provide self-service capabilities and reduce duplicated effort.

Align funding and governance to value streams to avoid project-based stop-start; measure outcomes, not output.

Coach teams to own architecture; architects shift from approving to enabling, facilitating, and building fitness functions.

Iterate the operating model: transformation is continuous, sequenced by value and risk, with feedback loops from delivery.

If a decision is hard to reverse and affects many teams, treat it as intentional architecture and document it with an ADR.

If a decision is easily reversible and local to a team, let it emerge through delivery and fitness functions.

If teams are blocked by missing platform capability, add it to the architecture runway and prioritize by delivery impact.

If a standard cannot be automated as a fitness function, it is a principle or guideline, not a hard guardrail.

If governance is slowing delivery, move decisions to the lowest competent level and replace approvals with guardrails.

If strategy is unclear, map value streams and outcomes before committing architecture runway.

If teams are overloaded, use team topologies to reduce cognitive load and clarify interaction modes.

If transformation stalls, sequence operating-model changes by value and risk, and measure outcomes.

O-AA is an Open Group standard; it complements TOGAF and Agile frameworks rather than replacing them.

The body of knowledge has two halves: Agile Architecture and Agile Organization.

Agile Architecture practices include decision-making, runway, intentional/emergent design, and architecture as code.

Agile Strategy practices include value streams, OKRs, and outcome-based roadmaps.

Agile Organization practices include team topologies, autonomous teams, and transformation roadmaps.

Fitness functions verify architectural characteristics continuously; they are the backbone of evolutionary architecture.

Architecture runway is time-boxed and demand-driven, keeping teams unblocked for near-term iterations.

Practitioner competencies: facilitation, coaching, systems thinking, communication, and balancing intentional/emergent design.

Pitfall: big upfront design. Avoid by using just-enough intentional architecture plus emergent design.

Pitfall: architecture review board as bottleneck. Avoid by decentralizing decisions with guardrails and fitness functions.

Pitfall: ivory-tower architects. Avoid by embedding architects in teams and coaching rather than approving.

Pitfall: stale documentation. Avoid by treating architecture as code and keeping ADRs with the codebase.

Pitfall: project-based funding causing stop-start. Avoid by funding value streams/products.

Pitfall: unmeasurable standards. Avoid by expressing standards as automated fitness functions where possible.

Pitfall: overloaded teams. Avoid by applying team topologies and platform self-service.

Pitfall: transformation as a one-off. Avoid by iterating the operating model with feedback loops.

Scenario: teams blocked by missing shared capability. Action: add to architecture runway, prioritize by impact, assign platform team.

Scenario: conflicting architecture decisions across teams. Action: facilitate a decision forum, record ADR, publish guardrail.

Scenario: strategy unclear. Action: map value streams and outcomes, then derive runway and fitness functions.

Scenario: governance slowing delivery. Action: move decisions to lowest competent level, replace approvals with guardrails.

Scenario: standards not followed. Action: automate as fitness functions; if not automatable, treat as guideline.

Scenario: transformation stalled. Action: sequence operating-model changes by value and risk, measure outcomes.

Scenario: architects disconnected from delivery. Action: embed architects in teams, shift to coaching and enabling.

Scenario: funding stop-start. Action: shift to product/value-stream funding with continuous flow.

O-AA = Agile Architecture + Agile Organization, an Open Group standard complementing TOGAF and Agile frameworks.

Architecture is continuous, product-centric, and owned by delivery teams within guardrails.

Intentional architecture for irreversible, high-impact decisions; emergent design for reversible, local ones.

Fitness functions automate verification of architectural characteristics; guardrails must be testable.

Architecture runway is time-boxed, demand-driven work keeping teams unblocked.

Value streams and OKRs align strategy, architecture, and delivery around outcomes.

Team topologies and autonomous teams reduce cognitive load and enable flow.

Governance is lightweight, decentralized, and outcome-focused; architects enable and coach.