SW Design, Architecture & Clarity at Scale • Sam Newman, Jacqui Read & Simon Rohrer
Experts Sam Newman, Jacqui Read, and Simon Rohrer explore the nuances of software design, its intersection with architecture, and the critical role of communication in scaling technical clarity. The discussion covers practical advice on implementing Architectural Decision Records (ADRs), the evolving role of the architect as a facilitator, and strategies for creating agile enterprise architectures.
What is Software Design?
Software design is a pervasive activity that cuts across the entire software development lifecycle, from the highest-level business context down to the engineering details. It’s not confined to UI/UX or low-level code structure. As Jacqui Read explains, you have to “design at every single level.” This involves a continuous flow of decisions influenced by the surrounding context—be it laws and regulations at the enterprise level or internal policies and applications at the team level.
The core of design is making choices based on the needs of all stakeholders, not just end-users. It’s about understanding what the business requires and translating that into technical and architectural decisions. It’s the thoughtful, deliberate process that is often sacrificed under pressure, with teams defaulting to “just code” to meet deadlines.
The Role of Communication and Decision Records
A central theme is that effective design and architecture at scale are fundamentally communication problems. Simon Rohrer highlights a key takeaway from a Pat Kua talk:
For software design, ‘Don’t Repeat Yourself’ is important. For communication, ‘Continually Repeat Yourself’ is crucial.
To effectively cascade decisions and context through a large organization, you cannot just say something once; the message must be repeated across multiple channels until it is heard and internalized.
Architectural Decision Records (ADRs)
Architectural Decision Records (ADRs) are a powerful tool for communication and clarity. Their primary purpose is to document the why behind a decision, capturing the context, the options considered, and the rationale for the choice. This serves several functions:
- Future Clarity: When a decision is questioned later, the ADR provides the context. This prevents “whack-a-mole” decisions where the same questions are re-litigated, saving significant time.
- Evolvability: By understanding the original context, teams can confidently supersede an old decision when that context is no longer relevant.
- Onboarding: New team members can be directed to key ADRs to quickly understand the critical technical history of a project.
The process of creating an ADR is as valuable as the artifact itself. It should be a collaborative conversation, not a top-down decree. Involving stakeholders in the discussion builds alignment and shared understanding. To encourage this collaboration, it’s better to label an in-progress ADR as a “Draft” rather than “Proposed,” as it feels more open to contribution.
For ADRs to be successful, they must be accessible and integrated into existing workflows. Store them where the relevant audience will naturally find them—in a service’s repository for local decisions, or a shared wiki (Confluence, Notion) for cross-team decisions.
The Architect’s Role: Facilitator and Enabler
The panel reframed the architect’s role from a solitary decision-maker to that of a facilitator. Architects are accountable for the architecture, but the most effective way to fulfill that responsibility is through co-creation with engineering teams.
An architect’s decisions create the environment in which developers work—a concept known as habitability. A good architecture makes developers’ lives easier and more productive. Therefore, architects must listen, read body language, and ensure their proposals are presented as tentative sketches to invite feedback, rather than as final edicts.
Key responsibilities for a modern architect include:
- Delegating Decisions: Empowering teams with the most detailed knowledge to make local decisions. Architects should focus on decisions that require cross-team standardization or have long-term strategic impact.
- Managing Standardization: Standardizing a technology or pattern increases the cost of changing it later. Therefore, standardization should be applied thoughtfully to things that are hard to change or where consistency provides significant value (e.g., via a platform engineering team). The goal is to remove “needless creativity” in foundational areas so developers can focus on solving business problems.
- Thinking in Time Scales: Recognizing that decisions have different lifespans. Enterprise architects may operate on longer time horizons, but their role is not to conflict with agility. Instead, modern enterprise architecture should create the space for agility by providing a “humble North Star”—a long-term, guiding vision that is not overly predictive or prescriptive.
Establishing Feedback Loops
A system’s design is not static. To ensure architecture evolves correctly, robust feedback loops are essential. Communication must flow in both directions—not just from the business down to engineering, but also from engineering back up to architecture and the business.
This can be achieved through:
- Observability at Scale: Enterprise architects should use observability tools to see how their architectural decisions perform in production.
- Direct Communication: Regularly talking to teams to understand the real-world impact of decisions, including the cognitive load they impose.
By combining quantitative data from observability with qualitative feedback from teams, architects can ensure that the systems they design are not only technically sound but also sustainable and effective for the people building and operating them.