Open Agile Architecture Practitioner common mistakes
Open Agile Architecture Practitioner · Understand the traps and how to avoid them.
Treating the O-AA 'Agile Architecture' and 'Enterprise Architecture' halves as two separate playbooks, so answers describe either sprint-level design or portfolio-level governance but never connect them.
Candidates come from either an agile delivery background or a traditional EA background and default to the vocabulary and scope of their own experience; the exam consistently tests the integration of the two.
What to do instead
For every practice question, ask 'what does this look like at the team/sprint level AND at the enterprise/portfolio level?' and write answers that explicitly bridge the two, naming the mechanism (e.g., architecture runway, guardrails, decision rights) that links them.
Answering with generic agile ceremony advice (more retrospectives, shorter sprints) when the question is about architecture-specific practices such as intentional architecture, emergent design, or architecture debt.
The word 'agile' in the exam title primes candidates to reach for Scrum/SAFe content they already know instead of the architecture-specific concepts the question is probing.
What to do instead
Before answering, identify whether the stem names an architecture artifact or decision (e.g., architecture runway, fitness function, decision record). If it does, answer with architecture practice, not team process.
Describing architecture as a gate or approval checkpoint that teams must pass before delivering, even when the scenario asks how to scale agile architecture.
Governance-as-gate is the default mental model from traditional EA, and it feels like the 'safe' answer that shows control.
What to do instead
Frame architecture as enabling constraints and shared decision-making: continuous architecture, decentralized decisions within guardrails, and architects embedded with teams. Reserve gating language only for genuinely irreversible or regulated decisions, and say why.
Confusing the roles and responsibilities of the architect, the product owner, and the engineering lead in scenario questions, attributing architecture decisions to whoever 'owns the backlog'.
Role boundaries are fuzzy in real organizations, so candidates project their own org chart onto the exam rather than the model the exam expects.
What to do instead
Build a one-page role map from the O-AA material: who sets direction, who decides, who is consulted, who is informed. Practice classifying each scenario action against that map before choosing an answer.
Giving a single 'best practice' answer to a question that asks for a trade-off, without stating the context that makes the choice appropriate.
Candidates optimize for sounding decisive and correct, but architecture questions are usually context-dependent and reward conditional reasoning.
What to do instead
Use an 'it depends on X, because Y, so choose Z when...' structure. Explicitly name the forces (coupling, reversibility, cost of delay, regulatory exposure) that drive the recommendation.
Treating architecture debt as only technical debt in code and ignoring intentional, deliberate debt taken on for speed with a documented repayment plan.
Technical-debt vocabulary from engineering is more familiar, and the word 'debt' triggers code-level associations.
What to do instead
Distinguish inadvertent vs. deliberate debt, and require that deliberate debt be recorded with rationale, owner, and a review trigger. Practice writing a short debt entry that includes those fields.
Producing architecture documentation as a static, exhaustive deliverable instead of a set of lightweight, living artifacts tied to decisions and change.
Traditional EA training rewards comprehensive document sets, and candidates equate thoroughness with quality.
What to do instead
Answer with the minimum sufficient set: decision records, a context/landscape view, and fitness functions or principles that are versioned and revisited. State the cadence at which each artifact is reviewed.
Ignoring the human and organizational side of architecture change-team topologies, cognitive load, incentives, and skills-when the scenario is clearly about adoption failing.
Candidates focus on the technical solution and treat organizational resistance as a communication problem to be handled with a presentation.
What to do instead
For adoption scenarios, always diagnose structure and incentives first: does the org design, funding model, or team boundary make the desired architecture rational for the people involved? Then propose structural changes, not just messaging.
Answering questions about measuring architecture value with activity metrics (number of documents, number of reviews, architecture board meetings held) instead of outcome metrics.
Activity metrics are easy to count and appear in many governance templates, so they surface first under exam pressure.
What to do instead
Tie every metric to an outcome the business cares about: lead time to change, change failure rate, time to onboard a team, cost of a dependency, reduction in cross-team coordination. Name the baseline and the target direction.
Misreading multi-part or 'choose the best two' questions and selecting answers that are individually true but do not address the specific constraint in the stem.
Under time pressure candidates pattern-match on familiar phrases in the options rather than re-reading the stem's constraint (e.g., regulated, legacy, distributed teams).
What to do instead
Underline the constraint words in the stem before looking at options, then eliminate any option that is true in general but ignores that constraint. If two options remain, pick the one that changes the decision, not the one that only describes the situation.