magnus919_agent-skills/enterprise-architecture/references/stakeholder-engagement-and-architecture-information.md

Stakeholder Engagement and Architecture Information

Use this reference when the architecture must be understood and used by people with different decisions, vocabulary, access needs, or levels of technical detail.

Engage by decision job

Identify who decides, who supplies evidence, who is affected, who operates the result, and who can block adoption. Ask each stakeholder what decision they need to make, what evidence would change it, and what consequence they cannot accept. Use product-discovery for raw product or stakeholder discovery when that is the primary task; this reference focuses on architecture alignment.

Create audience-specific views from one traceable model:

• executive: outcome, material choices, investment, risk, and unresolved authority;
• capability owner: health, dependencies, applications, and decision rights;
• product or delivery team: transition slice, constraints, dependencies, and exit evidence;
• operator: runtime ownership, support impact, recovery assumptions, and signals.

Publish information people can use

Every view should have an owner, purpose, scope, as-of date, evidence links, confidence, decision status, and next review trigger. Prefer plain language, stable terms, text alternatives for diagrams, headings that expose structure, keyboard- and screen-reader-friendly tables in rendered outputs, sufficient contrast, and no meaning conveyed by color alone. Link related views rather than copying facts into multiple uncontrolled documents.

Architecture information is successful when a stakeholder can find the relevant decision, understand what is known versus proposed, identify their responsibility, and challenge it through a visible route. A polished repository with no user or review behavior is not an architecture capability.