Architecture Communication and Review Board Scenarios
Architecture Communication and Review Board Scenarios
This domain tests whether you can explain and defend a solution to different audiences, and survive structured challenge. In a review board scenario you present a solution to a panel of architects, then answer questions and hypotheticals. The panel is assessing judgment and communication, not recall.
Communicate for the audience
- Executives: outcomes, cost, risk, timeline - one page, decision-oriented.
- Engineers: interfaces, data contracts, sequence diagrams, error paths.
- Diagrams: context (C4 level 1), container, sequence for integrations, entity relationship, state transitions. Each diagram answers one question.
- Artifacts: architecture decision records, risk and assumption logs, open-questions list.
Structuring the presentation
Situation and requirements → constraints → options considered → decision → risks and mitigations → expected outcomes. Lead with the conclusion, then support it. The trade-off must be visible: a solution with no stated downside reads as unexamined.
Handling challenge
Expect hypotheticals: volume multiplied by ten, a new channel, an acquisition, a new regulation. Answer with a scaling story - what breaks first, what you would change, what it costs. Answer the question actually asked, then stop. Acknowledge weaknesses openly; defensiveness reads as poor judgment. Park detail you cannot cover and offer it afterwards.
Worked example
The panel asks: "What if the client acquires a company that already runs Salesforce?" A weak answer describes migration tooling. A strong answer classifies first: merge, coexist, or federate. Merge when the customer master must be unified and processes converge. Coexist with a canonical integration layer when processes genuinely differ. Federate when regulation or data residency forbids consolidation. Then state the criteria you would apply, what you would need to know, and the interim risk - duplicate customer records until the canonical model is live. That structure demonstrates judgment under uncertainty, which is the actual test.
Traps that cost marks
Diving into code-level detail when the panel asked about strategy. No quantification anywhere. Ignoring a constraint the panel already stated. Refusing to commit to a recommendation. Blaming the client or the previous architect. Overrunning time and losing the summary. Drawing diagrams with no legend or scope.
Key points
- Lead with the conclusion, then the reasoning.
- Always show the trade-off, including what you rejected.
- Have a scaling story ready for volume, channel, and acquisition hypotheticals.
- Acknowledge weaknesses; defensiveness destroys credibility.
- One diagram, one question - context, container, sequence, ERD.