Complete firstArchitecture decision or systemnot in catalog
An existing or planned architecture decision needs to be communicated to multiple stakeholder groups.
Without: Without a communicable architecture, the canvas is self-purpose.
RunsheetArchitecture
Architecture Communication Canvas
ComplexityMedium
Time60-120 min
Participants2-8
FormatWorkshop + async
MaturityEmerging
01
Prerequisite
What needs to be finished first
Complete firstStakeholder Mapping
The communication target groups are identified and classified by influence and interest.
Without: Without stakeholder mapping, communication becomes one-size-fits-all and misses different needs.
02
Preparation
What needs to be ready before start
Materials
Whiteboard or Miro with canvas fields (target groups, messages, format, channel, frequency, responsibility, success criterion); template; examples of existing architecture artifacts (ADR, diagrams, whitepaper).
People / roles
One architect; one communications owner, for example PMO, Product Marketing, or Engineering Lead; 2-4 participants from Engineering, Product, and stakeholder areas; scribe.
Pre-read
Stakeholder list with roles; existing communication formats; known stakeholder expectations, for example detail level, language, technical level; communication failures from the past.
Time needed
2-3 h
Setup
Put the canvas on the wall. One line per target group. Rule: each target group gets a tailored combination of message, format, and channel.
03
Core question
The one question this method answers
Which architecture message reaches which target group in which format, so that decisions, acceptance, or implementation are supported?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Segment target groups | 30 min | List target groups (Exec, Eng teams, Operations, Security, external partners, customers). Add role, need, and existing knowledge level per group. | If everyone ends up in one target group, the communication is not differentiated. There should be at least three target groups. |
2Phase 2: Messages per target group | 45 min | Write the central message for each target group in 1-2 sentences (outcome, not technology). Add secondary messages. What should they understand and what should they do? | Execs need business outcome, not architecture patterns. Engineering needs patterns and trade-offs. The message must be differentiated. |
3Phase 3: Format and channel | 30 min | Choose a suitable format per target group (brief, ADR, diagram, demo, Q-and-A, talk) and channel (email, wiki, workshop, all-hands). Define frequency. | The format should fit the attention span. Execs read a one-pager, not an ADR. Engineering wants code proximity. |
4Phase 4: Responsibility and cadence | 30 min | Define an owner for communication, frequency, and success criterion per target group, for example acceptance rate or feedback count. Put dates in the calendar. | Communication without an owner will drift, and nobody will feel responsible. The owner must have access to the target group. |
5Phase 5: Pilot and feedback | 15 min | Run the first iteration as a pilot with one target group. Add a feedback mechanism, for example Q-and-A or survey. Review after 2 weeks. | Pilot before scaling prevents large waste. If the pilot group does not understand the message, iteration is needed. |
05
Artifact
What comes out at the end
Form
Architecture Communication Canvas as a table with columns target group, message, format, channel, frequency, owner, success criterion. Add materials per format and a feedback pipeline.
Versioning / ownership
Canvas with date, version, and owner. Changes to messages or channels need a rationale. Add success metrics, such as acceptance and feedback, per iteration.
Tool alternatives
- Miro with canvas template
- Confluence or Notion table
- Markdown in the docs/architecture/communication folder
- Spreadsheet such as Google Sheets or Excel for repeated updates
- Linear or Jira with communication tickets per target group
architecture-communication-canvas-working-template.md
Compact working template for Architecture Communication Canvas with context, input, output artifacts, and next step.
Architecture Communication Canvas Canvas
Context
What is this method used for?
Core question
Which question should be answered at the end?
Input
Which data, observations, or materials are available?
Working area
- Area 1:
- Area 2:
- Area 3:
- Relationships / patterns:
Output artifacts
- Communication Canvas:
- Stakeholder Messages:
- Architecture Communication Plan:
Open questions
- ...
Next step
Owner, date, success signal.
06
Example output
Concrete filled scenario, fictional example
architecture-communication-canvas-beispiel.md
Concrete filled scenario, fictional example
Architecture Communication Canvas - Booking API v2 rollout, May 2026
| Target group | Message | Format | Channel | Frequency | Owner | Success criterion |
|---|---|---|---|---|---|---|
| Exec (CEO, CFO) | Booking API v2 enables 5x volume and partner onboarding in 5 person days. Investment EUR 350k. | One-pager with outcome table | Email + quarterly review | Quarterly | @julia (CTO) | Budget approval in Q3 |
| Engineering org (4 teams) | Migration in 3 releases, guided by ADR-014 and ADR-015, migration playbook from 01.06. | Tech talk plus ADR collection | All-hands + wiki | 1x all-hands + ongoing | @ben (architect) | Fewer than 5 open questions 2 weeks after the talk |
| SRE and Operations | Multi-region deployment from phase 2, RPO 5 min, new runbook section. | Runbook + pairing session | Confluence + 1:1 | Before phase 2 | @marcus (SRE lead) | Successful drill by 30.07. |
| Security | OAuth2 migration, rate limit policy, audit log changes. | Security review doc | Workshop + wiki | 1x | @anna (security champion) | Security sign-off by 15.06. |
| Partner (B2B) | Sandbox environment available, migration by 30.09., support channel. | Partner newsletter + webinar | Email + webinar | Monthly | @lisa (partner manager) | 80% partner migration by 30.09. |
Pilot: Tech talk on 30.05. with Team Booking. Feedback form after the talk. Iterate if understanding is below 70%.
07
Pitfalls
Recognize symptoms and steer against them
Trap
One message for everyone
Symptom
The same slide deck is used for Exec, Engineering, and partners. Nobody fully connects.
What to do
Tailor message and format per target group. An Exec one-pager is structurally different from an Engineering tech talk.
Trap
No feedback loop
Symptom
Communication runs, but nobody knows whether it lands.
What to do
Define a success criterion and a feedback mechanism per target group, for example survey, Q-and-A, or observation of follow-up decisions.
Trap
Owner not clear
Symptom
Communication drifts away and frequency is not kept.
What to do
An owner is mandatory per target group. Put dates in the calendar. Review communication results quarterly.
Trap
Technology instead of outcome for Execs
Symptom
Execs hear pattern names but do not understand the business value.
What to do
Keep Exec messages strictly outcome-centered. Architecture patterns stay backstage; what shows up is what changes the business.
Trap
Channel does not fit
Symptom
Engineering is informed about complex architecture by email and nobody reads it.
What to do
Match the channel to the attention pattern. Engineering: tech talk plus wiki, not an email blast. Exec: short brief plus Q-and-A.
08
Stop criteria
Done signals checkable in under a minute
No concrete architecture can be communicated, so communication planning is premature.
Stakeholders are unknown or cannot be segmented.
No owner can be named per target group.
Feedback mechanisms are rejected, so effect cannot be measured.
Communication budget or resources are missing.
Architecture is highly contested internally, so communication would become theater instead of clarity.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.