Stakeholder Management & the Architecture Repository

Architecture artifacts are only useful if the right people can find them and trust that they’re current — that requires active stakeholder management and a living architecture repository.

At a glance

• What it is: Tailoring architecture communication to different audiences, backed by a single, kept-current architecture repository.
• Why it matters: A stale diagram or roadmap doesn’t just fail to help — it actively misleads people who trust it.
• For developers: the technical standard you write will likely be read by non-engineers as an executive summary first — a short “what/why/impact” paragraph up top makes it far more likely to get approved and adopted.
• When to use it: Continuously, alongside every architecture decision — not as a one-time documentation exercise.
• When not to use it: Never skip it — even a small EA practice needs some form of shared, current record.
• Prerequisites: Architecture Governance, since repository updates are tied to the same approval process.

Mental model

flowchart LR
    Repo["Architecture repository<br/>(single source of truth)"] --> L["Leadership<br/>roadmaps, investment trade-offs"]
    Repo --> E["Engineers<br/>standards, reference architectures"]
    Repo --> C["Risk / Compliance<br/>governance records"]

The same underlying decisions, tailored to what each audience actually needs to act on.

Step-by-step walkthrough

1. Identify the stakeholders affected by a decision, then classify each by power (ability to influence the outcome) and interest (how much the outcome affects them) — TOGAF’s stakeholder management technique arranges this into a 2×2 grid: Manage Closely (high power, high interest), Keep Satisfied (high power, low interest), Keep Informed (low power, high interest), Monitor (low power, low interest).
2. Tailor the artifact to each audience’s concerns — an executive roadmap summary versus a detailed technology standard — matching engagement effort to the stakeholder’s grid quadrant rather than communicating identically to everyone.
3. Publish artifacts into a single, living architecture repository.
4. Update the repository as part of the same governance process that approves the underlying change — not as a separate, optional step.
5. Point new projects and new architects to the repository as the starting reference, rather than letting decisions be rediscovered.

Worked example

A decision to adopt a new identity provider needs to reach three audiences:

• Leadership gets a one-page summary of cost and risk trade-offs.
• Engineers get the detailed technology standard and integration guide.
• Risk/Compliance gets the governance record showing the decision was reviewed and approved.

All three come from the same underlying decision, recorded once in the repository.

Common use cases

Use case	When to use	Notes
Communicating a new standard	Standard just approved by governance	Publish both an executive summary and a detailed version
Onboarding a new architect	Joining an existing EA practice	Point them at the repository instead of re-explaining prior decisions
Audit or compliance review	External or internal audit	Governance records in the repository serve as the evidence trail

Advanced details

• Different artifact types are tailored to their audience even when they describe the same underlying decision — this isn’t duplication, it’s translation.
• Power/interest grid: a stakeholder in Manage Closely needs direct engagement and sign-off before a decision is finalized; one in Monitor needs no more than a passing mention in a status update. Under-engaging a high-power stakeholder creates a blocker discovered too late; over-engaging a low-interest one wastes their time and yours.
• The repository is updated as part of the governance process (see Architecture Governance), not as an afterthought.
• Repository ownership matters: without a clear owner, artifacts drift out of date silently.

Quick reference

Audience	Primary concern	Typical artifact
Leadership	Roadmaps, investment trade-offs	Executive summary, roadmap
Engineers	How to build/integrate correctly	Standards, reference architectures
Risk / Compliance	Was this reviewed and approved?	Governance records

Troubleshooting

Symptom	Likely cause	Fix
Nobody trusts the diagrams	Repository wasn’t updated when decisions changed	Tie repository updates to the same governance approval step
Leadership ignores architecture communication	Artifacts weren’t tailored to their level of detail	Produce an audience-specific summary, not the full technical document
New architects keep re-discovering old decisions	No expectation to start from the repository	Make the repository the mandatory starting point for onboarding
A key stakeholder blocks a decision after it’s already been made	They were never classified as high-power/high-interest, so weren’t engaged directly beforehand	Run stakeholders through the power/interest grid before choosing a communication plan, not after a decision stalls

Check your understanding

• Why can the same architecture decision need three different artifacts for three different audiences?
• What’s the risk of treating the architecture repository as a one-time deliverable instead of a living store?

Related pages

Part of Introduction to Enterprise Architecture. See Architecture Governance for how repository updates are tied to approval, Target Operating Model & Roadmapping for the roadmap artifact stakeholders most often consume, and the Glossary for term definitions.