Engineer Architecture common mistakes
Engineer Architecture · Understand the traps and how to avoid them.
Treating architecture as a stack of technology choices (frameworks, cloud services, patterns) and answering design questions by naming preferred products rather than stating the drivers, constraints, and the reasoning that connects them to a structure.
Most preparation material and day-to-day engineering work reward tool familiarity. Candidates carry that habit into an exam that scores architectural reasoning, so a technically fluent answer that never states drivers, alternatives, or consequences reads as unsupported opinion.
What to do instead
For every design question, force a four-part answer: (1) the architecturally significant requirements and constraints, (2) the structural decision, (3) at least one rejected alternative and why, (4) the consequence or risk accepted. Practice by writing this four-line skeleton for ten familiar systems before timed practice, so the reasoning pattern becomes automatic under pressure.
Confusing a functional requirement with a quality attribute and labelling performance, availability, or security statements as 'requirements' without making them measurable, or conversely writing a scenario with no stimulus, response, or measure.
Stakeholders naturally express non-functional needs as vague adjectives ('must be fast', 'highly available'). Candidates transcribe these faithfully instead of eliciting thresholds, and exam items that ask for a testable specification then expose the gap.
What to do instead
Convert every quality statement into a six-part scenario: source, stimulus, artifact, environment, response, response measure. Rehearse with a fixed template ('When [stimulus] occurs at [artifact] under [environment], the system shall [response] within [measure]'). If any of the six parts is missing, the requirement is not yet a requirement.
Answering stakeholder questions by assuming a single homogeneous 'user' group, ignoring operators, regulators, maintainers, acquirers, and negated stakeholders, and failing to record conflicting concerns and how they were resolved.
Development teams interact mostly with product owners and end users, so other viewpoints are invisible in daily work. Exam scenarios deliberately plant a stakeholder whose concern changes the architecture, and candidates miss it because they never enumerated viewpoints.
What to do instead
Before answering any elicitation or conflict item, list stakeholder classes from a checklist (acquirer, end user, operator, administrator, maintainer, regulator, security officer, negated stakeholder) and note one concern per class. Where concerns conflict, state the trade-off and the escalation or negotiation path rather than silently picking a winner.
Producing diagrams that are technically invalid for their viewpoint: mixing deployment nodes with logical components, showing data flow on a structure diagram, omitting interfaces or ports, or using a notation whose semantics the candidate cannot state.
Candidates learn notation as decoration rather than as a language with rules. Under time pressure they draw what feels communicative, and items that test whether a view is consistent with its viewpoint and its stakeholders' concerns catch the inconsistency.
What to do instead
For each view, be able to state its element types, relationship types, and the concerns it addresses, and check that nothing foreign appears. Practice redrawing one system as context, component-and-connector, deployment, and information views, and for each note explicitly what is intentionally excluded.
Treating integration as a late-phase wiring task: choosing point-to-point calls for every interaction, ignoring interface contracts, versioning, and semantic versus syntactic interoperability, and having no answer for partial failure or message ordering.
Incremental delivery encourages deferring cross-system concerns, and synchronous request-response is the default mental model. Exam items about loosely coupled integration, contract evolution, and failure propagation therefore find no prepared answer.
What to do instead
For each integration question, explicitly address contract (schema and semantics), interaction style (sync versus async, coupling implications), evolution (versioning and backward compatibility), and failure behaviour (timeouts, retries, idempotency, ordering). State which interoperability layer - technical, syntactic, or semantic - the decision affects.
Presenting a trade-off as a single winning option without naming the quality attributes in tension, the sensitivity points, or the conditions under which the rejected option would win.
Candidates equate a good architecture answer with a decisive recommendation. Evaluation items score the reasoning about tension, so an answer that asserts 'microservices are better' without naming what it costs in consistency, operability, or latency loses most of the credit.
What to do instead
Structure trade-off answers as: attributes in tension, the decision, sensitivity points and trade-off points, risks and non-risks, and the context that would reverse the decision. Use a lightweight method such as an attribute trade-off table or a scenario-based evaluation walkthrough to make the reasoning visible.
Treating documentation and governance as bureaucracy: describing documents only by title, omitting the audience and the decisions they must support, and answering governance items with 'hold a review' without naming entry and exit criteria, decision rights, or exception handling.
Documentation and governance are undervalued in fast-moving teams, so candidates have no concrete model of what these artifacts contain or who uses them. Abstract answers feel safe but demonstrate no operational knowledge.
What to do instead
For each artifact, state purpose, audience, viewpoint, and lifecycle (when created, when updated, when retired). For governance, name the decision type, who decides, the evidence required, the criteria for approval, and how exceptions and technical debt are recorded and revisited.
Stopping the architecture at design: giving no deployment topology, no environment and configuration strategy, no observability or capacity plan, and no plan for rollout, rollback, or operational handover.
Candidates separate 'architecture' from 'operations' and assume the exam shares that boundary. Items that test whether the architecture is realizable and operable expose the missing operational view.
What to do instead
Add an operational checklist to every design answer: environments and promotion path, configuration and secrets handling, deployment units and topology, health and telemetry signals, capacity and scaling assumptions, rollout and rollback, and runbook or handover obligations. State which operational risks the architecture accepts.
Ignoring the professional and ethical dimension: recommending a design that concentrates risk on users, omits data protection or accessibility obligations, hides uncertainty from decision-makers, or fails to disclose a conflict of interest or a competence limit.
Technical training rarely rehearses ethical reasoning, and candidates default to satisfying the loudest stakeholder. Items that probe professional responsibility then elicit an answer that is technically sound but professionally indefensible.
What to do instead
Before finalizing an answer, run three checks: who bears the risk if this fails, which legal or ethical obligations attach to the data and users, and what uncertainty or conflict must be disclosed to the decision-maker. State the obligation and the disclosure explicitly rather than assuming it is understood.
Managing exam time and question structure poorly: writing long essays for short-answer items, leaving scenario questions without an explicit recommendation, and not allocating time to return to flagged items.
Architecture candidates are used to explaining at length, and the exam mixes item types with different scoring expectations. Over-answering early items consumes the time needed for later scenario reasoning.
What to do instead
Adopt a per-item discipline: read the stem for the verb (state, compare, justify, evaluate) and answer only that verb at the depth requested. Budget time in blocks, flag uncertain items, and reserve the final minutes to add the missing recommendation or trade-off sentence to scenario answers.