You need a non-technical steering committee to approve a choice between two architecture options - for example, building a custom integration in-house versus buying a third-party platform. How do you present the trade-off so they can actually make an informed decision and sign off?

## The translation problem Getting a non-technical steering committee to sign off on an architecture trade-off is fundamentally a **translation problem**: the underlying decision - build vs. buy, monolith vs. microservices, sync vs. async integration - is technical, but the people with authority to approve it think and vote in business terms: cost, time, risk, strategic control. The architect's job is not to teach the committee software architecture; it's to translate each option's consequences into the vocabulary the committee already uses to make decisions, so they're voting on real trade-offs rather than reacting to unfamiliar jargon or the architect's confidence. ## What to put in front of them Mechanically, this means stripping the presentation down to a small number of viable options - almost never more than two or three, since more overwhelms decision-makers and signals the architect hasn't done the filtering work - and for each option, stating what the business gains, gives up, and pays, in comparable units. For a build-vs-buy integration: - **Build in-house** costs an estimated N engineer-months and gives full control over behavior and roadmap, but ties up a scarce team and carries schedule risk. - **Buying** ships in weeks and offloads maintenance, but adds a recurring license cost and potential lock-in. Critically, both sides of each option need to be shown - presenting the recommended option's strengths against the alternative's weaknesses is not a trade-off, it's advocacy dressed as analysis, and technically literate people in the room will notice. ## Naming reversibility A second mechanism worth naming explicitly is **decision reversibility**, sometimes called one-way-door versus two-way-door decisions. A choice that's cheap to reverse later doesn't need the same scrutiny as one that's expensive or impossible to reverse, like standardizing on a cloud provider or a data model many downstream systems will depend on. Naming this explicitly helps a committee calibrate diligence, preventing both over-scrutinizing cheap decisions and under-scrutinizing expensive ones. ## Why skipping the translation goes badly This exists because architecture decisions routinely get made badly when this translation is skipped. Reading a technical comparison directly, a committee either: - **defers entirely to the architect's judgment** - eroding real accountability, since if it goes wrong, no one who could have caught the risk actually engaged with it - or - **pushes back on surface-level concerns** unrelated to the real trade-off, because that's the only thing they could evaluate. ## The trade-off The trade-off in doing this well is time and precision. Producing solid estimates for each option takes real analysis upfront, and simplifying technical nuance into business language always loses some fidelity - a conditional, complex risk can get flattened into a single rating that under- or overstates real exposure. A skilled architect keeps the detailed technical analysis available as backup for anyone who wants to dig in, while the primary presentation stays at the level the committee can act on. ## Failure modes - **Decision theater.** The most common failure mode is 'decision theater' - a polished deck presented after the real decision was already made informally, where questions are treated as an obstacle rather than genuine input. This shows up as a decision that technically got 'signed off' but that key stakeholders never actually understood or bought into, so the moment the project hits its first cost overrun, the sign-off evaporates and the architect is re-litigating a decision supposedly closed months earlier. - **Too many options.** Another failure mode is presenting so many options or so much caveat-laden nuance that the committee can't converge, and the project stalls waiting for a call no one will make. ## Where it shows up A concrete real-world pattern: enterprise architecture review boards frequently require exactly this shape of artifact - a short options memo with two or three real alternatives, explicit cost/risk/time trade-offs on both sides, a stated recommendation, and a record of what was decided and why - precisely because it's the format that lets a mixed technical/business audience reach an accountable decision instead of a rubber stamp.