SW Design, Architecture & Clarity at Scale • Sam Newman, Jacqui Read & Simon Rohrer • GOTO 2025
A panel discussion with Sam Newman, Jacqui Read, and Simon Rohrer exploring the intersection of software design and architecture. The conversation delves into the critical role of communication, the practical application of Architecture Decision Records (ADRs), strategies for bridging the gap between architects and developers, and modern approaches to standardization through platform engineering and creating agile enterprise architectures.
In a panel discussion at GOTO Copenhagen, Jacqui Read, Simon Rohrer, and Sam Newman explore the nuanced relationship between software design, architecture, and effective communication in organizations of all sizes.
Defining Software Design
Jacqui Read opens by defining software design not as a siloed activity like coding or UX, but as a cross-cutting concern that permeates the entire software development lifecycle. It starts with the business context and flows through every level of decision-making.
“You actually have to design at every single level. You have to work out what people want. That’s going to go into the architecture. In the architecture, you are doing forms of design. In your engineering, you are also doing forms of design.” - Jacqui Read
Design is the continuous process of making choices, but more importantly, it’s about deeply understanding the needs of all stakeholders—from the end customer to the business itself—before making those choices.
The Power of Decision Records
A central theme is the importance of documenting decisions. Jacqui Read advocates for expanding the concept of Architecture Decision Records (ADRs) to simply Decision Records, applying them to business strategy, finance, and hiring.
The primary purpose of a decision record is to capture the “why” behind a choice. This provides critical context for the future:
- Challenging Decisions: When the context changes, the record provides a basis for re-evaluation, allowing teams to supersede old decisions with new ones based on new information.
- Preventing “Whack-a-Mole” Questions: It saves significant time by preemptively answering recurring questions about why a system was built a certain way.
- Onboarding: New team members can quickly get up to speed on the most critical decisions that shaped the project.
Simon Rohrer adds that the process of creating the record is as valuable as the artifact itself. It’s a forcing function for conversation.
“The other half of the importance of architecture decision records and the process of them is the conversation. It’s getting the stakeholders involved… The etymology of ‘decide’ is about cutting off. So, you’re cutting off a bunch of stuff and they may be people’s favorite options. So getting them involved and in that dialogue as to why it’s this one and not the others is so important.” - Simon Rohrer
Bridging the Architect-Developer Divide
The panel addressed the common friction between architects and engineers. When an architect presents a high-level design, engineers can perceive it as a finalized mandate, stifling collaboration.
To mitigate this, the panelists suggest:
- Use Collaborative Language: Frame documents as a “draft” rather than “proposed” to invite contribution.
- Visualize Tentativeness: Use sketchy, hand-drawn diagram styles to communicate that a design is a thought-starter, not a final blueprint.
- Focus on Outcomes: Architects should define the desired outcomes and constraints, empowering development teams with the detailed knowledge of the language and tools to make the specific implementation decisions.
- Recognize Habitability: An architect’s decisions create the environment where developers will “live” for months or years. Co-creating the architecture is essential for making that environment productive and positive.
Standardization, Platform Engineering, and Cost of Change
When discussing how to standardize design across an enterprise, Simon Rohrer cautions against over-standardization. For necessary standards, Platform Engineering is the modern solution. The platform becomes the place “where the architecture lives,” removing “needless creativity” from developers on commodity choices (e.g., logging libraries, ORMs) so they can focus their creativity on solving business problems.
Sam Newman adds a crucial consideration: standardization increases the cost of changing your mind later. Therefore, decisions about standardization require more upfront thought, especially for choices that are difficult and expensive to reverse.
Documentation and Feedback Loops
To keep documentation from becoming stale, the panel advises:
- Document the “Why,” Not the “How”: High-level architectural intent changes far less frequently than low-level implementation details. Focus documentation efforts there.
- Automate Where Possible: Use tools like OpenAPI to generate documentation from code, ensuring it’s always up-to-date.
- Document by Link: When asked a question, don’t just answer. Create or update the documentation and share the link. This builds a valuable, living knowledge base.
Effective systems require feedback to flow in all directions. Engineering must provide feedback to architecture, which in turn informs design and business strategy. Simon Rohrer emphasizes that modern enterprise architecture is a large-scale feedback loop, using observability and direct communication to understand the real-world impact of decisions on both the technical systems and the people building them.