Pretend you are the solutions architect so integration fiction, scope theater, and delivery risk fail before an enterprise design package absorbs them.
Optimistic delivery packages optimize for "the architecture will hold." The solutions architect seat does the opposite. It asks which integration still lacks a named owner, which non-functional requirement was demoted to a footnote, which "phase two" dependency is actually on the critical path, and which security review is still scheduled after go-live. A neat diagram is not evidence that the design can clear procurement, security, and ops without silent scope growth.
Give the seat a job
Name a real mandate: underwrite an integration plan without inventing capacity, clear a non-functional checklist that procurement will actually ask for, or defend a phased delivery without dual-counted engineering weeks. Give constraints: the evidence standard for interface contracts, the environments you will refuse to skip, and the third-party dependencies you will not hide behind a logo slide. Without constraints the seat becomes cartoonish. With constraints it produces questions you might actually hear in a technical win room, a security questionnaire review, or a fight over who owns the cutover weekend.
Prompt example: "Solutions architect: list the top reasons to delay this design package, the integration with the weakest owner, the non-functional claim that worries you most, and the ten diligence questions you would send after review. Stay inside a realistic mandate."
What you should leave with
- Top reasons to challenge, delay, or rewrite this design package.
- The architecture claim that looks strongest and is least evidenced.
- The integration, environment, or stakeholder that would break first.
- What would make you accept residual delivery risk in writing.
- The ten hardest follow-up questions after the meeting.
Run that brief in Pingpong against the real solution brief, interface contracts, security questionnaire, and open risk list. Follow with a home-team response pass so you leave with edits and source packs. When the decision is a public launch date, run this seat after security and implementation attacks so it can use earlier objections as ammunition.
When the plan leans on a single integration hero, a single "we will stub it" promise, or a single customer environment that nobody has tested, force the seat to price concentration risk in writing. Ask what happens if the third-party API changes, if the hero is out, or if the security review lands the week of cutover. Pair with pretend you are the implementation lead, pretend you are the CTO, war-game an enterprise RFP, war-game a security questionnaire, and the war-game decisions hub. See how to run a Pingpong.
If the package coincides with a migration or a new region launch, ask the solutions architect seat to map every claim that still assumes last quarter's topology. Runbooks, capacity plans, and partner diagrams count. A design that looks clean in a slide while the environments still name retired services will fail on the first escalated weekend.