Two stakeholder groups raise concerns that pull the architecture in opposite directions — for example a compliance officer demanding full encryption and immutable audit of every transaction, and a trading desk demanding sub-millisecond latency. How do you resolve that, and what do you record?
answer
- conflict resolution IS the architecture; never average
- quantify both, then split constraint vs negotiable target
- dissolve first: split path / data / region / go async
- ATAM: sensitivity point, trade-off point, risk
- escalate the ranking; record rejected options + risk owner + revisit trigger
basics
~20 sDo not average the two. Make both concerns measurable, separate hard constraints (law, safety) from negotiable targets, scope the design so each need is met where it applies, let the accountable sponsor rank what remains, then record the decision, the rejected option, and the residual risk.
solid answer
~60 sConflicting concerns are not a failure of elicitation — resolving them *is* the architecture. The method: (1) quantify both sides as quality-attribute scenarios with response measures, so "secure" and "fast" become falsifiable numbers; (2) classify each as a **constraint** (regulatory, legal, safety — non-negotiable) or a **negotiable target**; (3) look for a scoping move before a trade-off — often the conflict dissolves when you split the path (synchronous hot path stays lean, audit and encryption move to an asynchronous, durable side channel with a defined maximum lag) or split the data (only regulated fields get the heavy treatment); (4) if a genuine trade-off remains, model or prototype it so the cost of each option is measured, not asserted; (5) escalate the *ranking* — not the design — to the accountable stakeholder, typically the sponsor or a design authority, because relative priority is a business decision; (6) record it as an architecture decision with the alternatives rejected, the rationale, the residual risk, its owner, and the trigger for revisiting. ATAM names these **trade-off points**, **sensitivity points**, and **risks**, and they should appear explicitly in the architecture description.
code
text · 24 linesADR-041 Audit + encryption on the order hot path
Context
Compliance : tamper-evident audit of every settled trade,
encrypted at rest, <=5 s to durable store, 7 y retention. [CONSTRAINT - statutory]
Trading : order ack p99 <= 900 us at 50k orders/s at market open. [TARGET - negotiable to 1.2 ms]
Conflict : synchronous encrypted audit write measured at +2.4 ms p99. [TRADE-OFF POINT]
Options
A synchronous audit write ack p99 ~3.3 ms -> misses target by 3x
B fire-and-forget async audit ack p99 ~880 us -> audit loss on crash: FAILS constraint
C hot path appends to local WAL (hash-chained), async shipper encrypts
and persists off-path; lag SLO p99 < 2 s, alert at 4 s
ack p99 ~910 us -> both met <-- CHOSEN
Rejected A (latency), B (violates statutory durability)
Residual risk
Node loss before shipping: <=2 s window of un-shipped audit records.
Mitigated by replicated WAL. ACCEPTED by: Head of Compliance (name), 2026-03-11.
Revisit when
regulator mandates synchronous attestation, OR ack budget drops below 500 us,
OR shipper lag SLO breached twice in a quarter.go deeper
Say that both sides must be made concrete and measurable, that you would not just pick one, and that the decision plus the reason should be written down and made by whoever owns the business priority.
Add the constraint-versus-target distinction, propose at least one concrete scoping move such as taking audit off the synchronous path, and mention measuring options rather than asserting costs.
Use ATAM vocabulary (sensitivity point, trade-off point, risk), present costed options with residual risk, drive an explicit decision with an accountable owner, and record an ADR with rejected alternatives and a revisit trigger.
Treat it as governance: who arbitrates across business units, how residual risk is formally accepted and owned, how recurring perspective conflicts (security vs latency, availability vs consistency) are anticipated as policy, when to declare a conflict irreconcilable, and how to scale analysis effort to reversibility rather than to anxiety.
## Framing: conflict is the normal case If every stakeholder concern could be satisfied simultaneously, there would be nothing to decide and no architect needed. Architecture *is* the accumulation of decisions made where concerns conflict. So the goal is not to eliminate conflict but to resolve each one **explicitly, with evidence, by an accountable party, with the reasoning recorded**. ## Step 1 — make both sides falsifiable Vague concerns cannot be traded off, because both sides claim infinity. Convert each into a **quality-attribute scenario** (source, stimulus, artifact, environment, response, response measure): - Compliance: *"Every trade that settles must have a tamper-evident audit record persisted durably within 5 seconds, encrypted at rest, retained 7 years, retrievable within 1 business day."* - Trading desk: *"Order acknowledgement returns within 900 µs at p99 during market open, at 50k orders/second."* Notice what happened: written this way, the conflict *shrank*. The compliance requirement never said "synchronously on the hot path" — that was an assumed implementation. This is the single most valuable move in the whole process. ## Step 2 — separate constraints from targets - **Constraints** are non-negotiable: statute and regulation, safety certification, contractual SLA with penalties, platform mandates. You design *around* them; you do not trade them away. (You may still challenge the *interpretation* — legal teams frequently over-state what a regulation requires — but that is a fact-finding exercise, not a trade.) - **Targets** are negotiable and have a cost curve. Sub-millisecond is a target with a very steep curve; 5 ms may cost a tenth as much. Being rigorous here prevents the two classic failures: treating a legal requirement as negotiable, and treating a nice-to-have latency number as sacred. ## Step 3 — try to dissolve before you trade Most apparent conflicts are artifacts of one assumed design. Standard dissolving moves: - **Split the path.** Keep the latency-critical path minimal; move encryption, audit writes, and enrichment to an asynchronous durable pipeline with a bounded lag SLO and a guaranteed-delivery mechanism. The concern "audit must exist" is met; "audit must be inline" was never the requirement. - **Split the data.** Apply heavy controls only to the regulated subset of fields/entities; public reference data takes the fast path. - **Split the tenant/customer/region.** Different regulatory regimes get different topologies rather than a global worst-case design. - **Move the cost off the critical moment.** Pre-compute, pre-authorize, batch, or verify after the fact with compensations. - **Change the unit of measurement.** "Immutable audit" can be satisfied by hash-chaining or write-once storage, which is far cheaper than synchronous durable replication of every field. - **Relax elsewhere.** Buy the latency budget back by spending it somewhere the other stakeholder does not feel it. If a dissolving move works, the outcome is not a compromise — it is a strictly better design, and it should still be recorded, because the reasoning is exactly what protects it from being "simplified" later. ## Step 4 — measure the residual trade-off When a real trade-off survives, replace assertion with evidence: - prototype or spike the expensive option and measure it; - build a small performance model (queueing, service-time budget breakdown) so everyone sees where the microseconds go; - run the security side's analysis properly (threat model, risk rating) so its demand is proportional to real risk rather than to anxiety; - price the options in money and time, not adjectives. ATAM vocabulary is useful and worth using explicitly: - **Sensitivity point** — a decision where one quality attribute is strongly affected by a parameter. - **Trade-off point** — a decision that is a sensitivity point for *two or more* attributes moving in opposite directions. Exactly our case. - **Risk** / **non-risk** — decisions that are dangerous or safe given the stated drivers. ## Step 5 — escalate the ranking, not the design The architect's job is to present costed options; deciding *which stakeholder's concern wins* when both are legitimate is a **business** decision. Escalate to the accountable party — sponsor, product owner, design authority, or architecture review board — with: - the two scenarios and their measures, - 2–3 costed options (not just A vs B; include the scoped/dissolved option), - the risk each option leaves behind, - your recommendation. Anti-patterns here: quietly picking a middle point that satisfies nobody; letting seniority or volume decide; endless meetings with no forcing function; or the architect absorbing a business risk they have no mandate to accept. ## Step 6 — record the decision so it survives ISO/IEC 42010 explicitly provides for recording architecture **decisions** and **rationale**, including alternatives considered and their justification, and for tracing decisions to the concerns that drove them. An architecture decision record (ADR) for a trade-off should contain: 1. **Context** — the two concerns, quantified, and their stakeholders. 2. **Decision** — what was chosen, precisely. 3. **Alternatives rejected** — and *why*, with the numbers. 4. **Consequences / residual risk** — what is now worse, who owns that risk, and whether they have formally accepted it. 5. **Revisit trigger** — the condition that reopens the decision ("if the regulator mandates synchronous attestation, or if p99 budget drops below 500 µs"). The residual-risk owner matters enormously: an accepted risk with a named owner is governance; an accepted risk with no owner is an accident waiting to be blamed on the architect. ## Trade-offs and edge cases - **Irreconcilable conflicts exist.** Occasionally the honest answer is "you cannot have both; choose, or fund a different system" — for example, strict data-residency in a jurisdiction with no local capacity versus a global single-cluster design. Saying so early is the value you add. - **Conflicts between *perspectives*, not just people.** Security vs performance, availability vs consistency (a CAP-style choice), evolvability vs efficiency — these recur so predictably they should be anticipated in the design, not discovered at review. - **Time-boxing.** Trade-off analysis can consume a project. Match the analysis effort to reversibility: cheap-to-reverse decisions should be made fast and revisited; one-way doors deserve prototypes and formal review. - **Political conflicts wearing technical clothes.** "We need our own database" is sometimes a team-autonomy concern. Naming the real concern is a prerequisite to solving it. - **Re-litigation.** Without a recorded decision and rationale, the same argument recurs every quarter with new participants. The ADR is not paperwork; it is the mechanism that stops the loop.
- The compliance officer refuses to quantify their requirement and simply says "it must be fully compliant". How do you proceed?Go to the source text of the regulation or contract with them and derive the actual obligations — retention period, tamper-evidence, encryption scope, retrieval time. Regulations are almost always stated in outcomes, not mechanisms, and the assumed mechanism is usually where the conflict lives. Produce a written interpretation, get it confirmed by whoever is accountable for compliance risk, and treat that confirmed interpretation as the constraint. If they will not confirm it, that itself is a risk to escalate, since it means nobody owns the requirement.
- Who should make the final call when two legitimate concerns cannot both be met?The party accountable for the business outcome — sponsor, product owner, or a design authority or architecture board where the conflict spans organizations. The architect's role is to present quantified options with costs, risks, and a recommendation, not to unilaterally decide whose business priority wins. What the architect must not do is silently pick a midpoint, let seniority or volume decide, or absorb a risk they have no mandate to accept.
- How much analysis effort should a given conflict get?Scale it to reversibility and blast radius. One-way doors — data model, persistence choice, public API shape, regional topology — deserve prototypes, measurement, and formal review. Cheap-to-reverse decisions should be made quickly with a stated assumption and a revisit trigger, because the analysis cost would exceed the cost of being wrong. Spending three weeks on a decision you could change in an afternoon is itself an architectural failure.
An airliner's designers face weight versus safety margin versus fuel cost. Nobody resolves that by averaging the three. Regulatory minimums are fixed constraints; the rest is measured, costed, and signed off by someone accountable, and the reasoning is filed so the next engineer does not quietly shave the margin ten years later.
saying these in an interview costs you the question
- Averaging the two positions into a middle design that satisfies neither and that no stakeholder endorsed.
- Treating a legal or safety constraint as a negotiable trade-off, or conversely treating an aspirational latency number as immovable.
- Trading off before quantifying, so both sides argue with adjectives instead of measurements.
- Assuming the conflict is real without first trying to dissolve it by scoping — splitting the hot path, the data, or the region.
- The architect deciding whose business priority wins instead of escalating the ranking to an accountable owner.
- Accepting a residual risk with no named owner and no formal acceptance.
- Recording only the chosen option, omitting rejected alternatives and rationale, which guarantees the argument is re-litigated later.
- Letting the loudest, most senior, or most present stakeholder win by default.