Solutions Engineer and Architect playbook
Turn architecture assumptions into testable boundaries, healthy comparisons, and measurable validation.
Primary responsibility
Solutions Engineers and architects connect the symptom to the system design. Their contribution is strongest when architecture becomes testable: which layer should behave differently if a hypothesis is true, which healthy path provides a fair comparison, and what evidence would move the boundary.
Build the current-state map
Map the affected workload, dependencies, control planes, data paths, identity boundaries, shared services, and operational owners. Keep the map at the level required for the incident. A complete enterprise diagram is not useful if the failure sits in one request path.
Design evidence, not demonstrations
A demo proves that something can work under selected conditions. Incident evidence must explain the affected condition. Define the comparison population, expected signal, access requirement, and interpretation before collecting data. Avoid post-hoc tests that can be interpreted in any direction.
Expected outputs
- Current-state and affected-path map.
- Candidate boundary set.
- Healthy-versus-affected comparison plan.
- Validation design tied to the original impact.
- Architecture constraints and residual risks.
Handoff rule
The architecture owner should make the next owner obvious. A boundary such as "network" is too broad when the evidence supports a specific path, policy, interface, or dependency owner.