SW Design, Architecture & Clarity at Scale • Sam Newman, Jacqui Read & Simon Rohrer • GOTO 2025

Summary — SW design, architecture & clarity at scale (GOTO 2025 panel)

This document captures the key themes, practical guidance, templates/tools, and takeaways from the GOTO 2025 panel on software design and architecture at scale.

Core themes

• Software design is cross-cutting Design happens at every level (context → architecture → engineering) and across multiple timeframes. Design and architecture are continuous, fractal, and are best approached in vertical slices rather than as a one-time waterfall step.

• Architecture is decisions and a social process Architecture consists of explicit decisions and the social practices around them. Good practice records why decisions were made and actively involves stakeholders — facilitation is as important as the technical work.

• Communication and repetition are critical To spread architectural decisions at scale, use multiple channels and make decisions visible where people already look.

Practical practices and guidance

Decision records / ADRs (Architecture/Decision Records)

• Purpose: record context, options considered, and why a decision was made so later reviewers can challenge, supersede, or learn from it.
• Make ADRs readable at a glance:
  • Headline / decision first
  • Short summary
  • Detailed context, options, risks
  • Put the answer (the decision) at the top
• Use statuses (draft → proposed → accepted) to invite contribution. Drafts encourage feedback; final/proposed can feel closed.
• Keep ADRs at the right level:
  • Short-form for quick decisions
  • Long-form for high-impact, hard-to-change choices
• Store ADRs where readers already work: repo, Confluence/Notion/SharePoint, Slack/Teams pinned links — don’t create a new place people will ignore.
• Link to supporting artifacts (spreadsheets, OpenAPI specs) rather than embedding everything. For financial analyses, summarize in the ADR and link to the full work.
• Make ADRs part of onboarding and regular delivery rituals so they remain discoverable and current.

Documentation & maintenance

• Document only as much detail as needed: higher-level docs change less; low-level names/URLs change frequently.
• Automate where possible (OpenAPI for APIs, generated docs) to reduce documentation drift.
• If a question repeats, create/update a single canonical answer and link to it rather than re-answering inline.

Collaborating: architects + engineers

• Co-create architectures with teams. Architects should act as facilitators: sketch drafts (using a sketchy visual language and tentative styles) and invite critique.
• Use vertical slices and incremental design — do enough design/architecture to enable engineering, then iterate.
• Consider “habitability”: architecture shapes the environment developers live in; account for cognitive load and developer experience.
• Use breakout subgroups and a “parking lot” to prevent meetings from devolving into implementation minutiae or endless hypotheticals. Assign follow-up owners.

Standardization and platform engineering

• Standardize only where it reduces unnecessary cognitive load/cost. Platform engineering surfaces “the architecture” as a product.
• Before standardizing, consider the future cost of change. High-cost-to-change items require more deliberate thought.
• Allow contextual variation — avoid over-standardizing where flexibility is valuable.

Avoiding over-engineering

• Aim for the “best simple system for now” — prefer simple, observable systems and iterate.
• Use design rules and guardrails rather than heavy-handed mandates.
• Follow principles such as KISS and pragmatic incrementalism.

Feedback loops & observability

• Establish feedback loops: engineering → architecture → design → business, and ensure information flows upward as well as downward.
• Use observability tools at scale (production metrics, traces, logs) to validate architectural assumptions and trigger ADR re-evaluation.
• Treat ADRs as living artifacts; revisit them after production learning.

Templates, tools, and references

• ADR structure suggestions:
  • Headline/decision first
  • Context, options, rationale
  • Status and comments
  • Keep short and long variants depending on need
• Automate API docs using OpenAPI to prevent documentation drift.
• Recommended resources:
  • Jackie Read — Communication Patterns (includes ADR templates and visual communication guidance); see jackiereaded.com / “knowledge vault”
  • “Sooner, Safer, Happier” (panel contributor mention)
  • Dan North — concept of the “best simple system for now” and related talks/blogs
  • Platform engineering writings (e.g., Gregor Hohpe and others)
  • Ruth Malan — intention vs reflection in visual documentation
  • David Marquet — intent-based leadership (aligning enterprise architecture with agility)
• Note: some names in the auto-generated transcript may be slightly garbled.

Practical takeaways (quick checklist)

• Use ADRs consistently: short answer up front, draft status to invite feedback, and store them where people look.
• Make architecture collaborative: sketch-first, co-create, and facilitate stakeholder conversations.
• Standardize via platform where it reduces friction; avoid over-standardizing.
• Automate low-level docs; keep high-level docs concise and maintained.
• Create observable feedback loops and revisit ADRs based on production learning.

Main speakers / sources

• Sam Newman — moderator
• Jacqui (Jackie) Read — author of Communication Patterns; Ministry of Software Design
• Simon Rohrer — Head of Enterprise Architecture, Saxo Bank

(End of summary)