Why SW Architecture is Mostly Communication • David Whitney, Ian Cooper & Hannes Lowette • GOTO 2025
Three experienced software engineers—Ian Cooper, David Whitney, and Hannes Lowette—deconstruct the evolution of software architecture from a top-down, "ivory tower" practice to a modern, collaborative discipline. They explore the dynamics between emergent and intentional design, the importance of sustainable development over "slash-and-burn" cycles, and how architectural strategies must adapt to organizational scale. The conversation emphasizes that the architect's primary role has shifted to coaching, fostering a shared language, and managing trade-offs, concluding that all significant architectural challenges are ultimately people problems rooted in communication, empathy, and culture.
Software architecture inevitably exists in any system, whether it is deliberately designed or emerges organically over time. The modern practice of architecture has moved away from the “ivory tower” model—the bearded sage dictating immutable laws—towards a more collaborative and dynamic role. The core of this practice revolves around identifying and managing “architecturally significant design decisions,” as defined by Grady Booch: those that are costly to change or fundamentally impact how we reason about the system.
Without intentional design, a system’s architecture becomes an emergent property, often reflecting past organizational structures, technological fads, and short-term fixes. This can be likened to the organic, winding streets of London, which evolved over centuries, versus the planned grid of New York. While charming, an unplanned architecture is often inefficient and difficult to navigate.
Sustainable vs. Slash-and-Burn Architecture
A crucial choice businesses must make, often implicitly, is between two development approaches, analogous to farming techniques:
- Slash-and-Burn: This approach prioritizes immediate delivery by exhausting the system’s design, adding features until the entire edifice becomes unmaintainable and requires a “big rewrite.” This can be a valid strategy for applications with a very short lifespan, such as in digital marketing.
- Sustainable: This model treats the system as a long-term asset. It requires continuous reinvestment—like fertilizing soil—to adapt the architecture as business needs evolve. A sustainable architecture must change to reflect the new reality of the business, which is a conscious and deliberate process.
The Modern Architect’s Role: Coach and Facilitator
The modern architect’s job is less about dictating solutions and more about helping teams avoid backing themselves into corners. It’s about enabling them to navigate the perpetual motion of software development. A key mental model is distinguishing between two types of decisions:
- Type 1 Decisions: Easily and cheaply reversible. These should be made quickly with minimal overhead.
- Type 2 Decisions: Expensive, time-consuming, or nearly impossible to unmake. These require careful consideration, deliberation, and a deep understanding of trade-offs.
Much of an architect’s work involves guiding technical leads to articulate these trade-offs. The goal is not to provide blessing and anointment but to build the team’s capability to make sound design decisions. This is achieved by establishing a shared language and mental model, allowing everyone to discuss software design with a common understanding.
Scaling Architecture with Organizational Growth
Architectural needs are fundamentally tied to scale. A startup with 12 people in a room can rely on informal, high-bandwidth communication. As an organization grows to 300 or 1,500 engineers, this model breaks down. Newcomers lack the historical context of past decisions, and inconsistencies between teams create systemic friction.
For example, if one team chooses gRPC for communication and another chooses Kafka, they create an integration problem that requires a higher-level, systemic decision. At scale, you cannot tolerate infinite local optima; some standardization becomes necessary to ensure interoperability.
To manage this without creating a bottleneck, organizations can adopt frameworks like an “Architecture Advice Forum.” In this model:
- Teams propose changes via an Architecture Decision Record (ADR) or RFC.
- Impacted stakeholders and experts provide feedback.
- The proposing team must formally acknowledge and respond to the feedback, motivating their final decision.
This process forces rigorous thinking and accountability, preventing decisions from being made in a vacuum.
The Pattern Problem and True Design Wisdom
A significant danger in modern software development is the cargo-culting of architectural patterns. Patterns like Clean Architecture or CQRS are codified design wisdom, but they are not universal solutions. Mandating a single pattern for all teams often leads to over-engineering and unnecessary ceremony, causing developers to resent the architecture.
The proper use of patterns is to reach for them when you encounter the specific problem they were designed to solve. A team should start with their problem, and as complexity grows, they might recognize a pain point—for example, the need to separate domain logic from infrastructure—and then adopt a pattern like Ports and Adapters as the solution. The pattern should be pulled in by a real need, not pushed from a template.
Great software design is about creating a form that expresses intent. Like an artist who masters classical techniques before developing a unique style, the best designers understand the fundamentals before subverting them to create elegant and idiomatic solutions.
Conclusion: It’s All a People Problem
Ultimately, the shift from a senior engineer to an architect is a transition from solving purely technical problems to solving people problems. The goal is not to be an autonomous decision-maker but to build a culture of sound engineering. This involves coaching, providing tools instead of rules, and fostering an environment where teams are empowered to make good decisions.
The architect cannot be in every room. Success, therefore, is creating a culture where, in their absence, teams will make the decisions the architect would have wanted them to make. This is built on a foundation of empathy, communication, and a shared understanding of the system’s goals and constraints. Every significant architectural challenge is, at its core, a human challenge.