Every Software Org is Dysfunctional • R. Parsons, G. Hohpe, B. O'Reilly & A. Harmel-Law • GOTO 2025
A panel of distinguished architects—Rebecca Parsons, Gregor Hohpe, Barry O'Reilly, and Andrew Harmel-Law—discuss the multifaceted world of software architecture. They explore the inevitability of organizational dysfunction, the critical role of architects in decision-making, and the impact of non-deterministic technologies like Generative AI and quantum computing on system design and organizational change.
The Nature of Organizational Dysfunction
A recurring theme is that organizational dysfunction is not a bug, but a feature of any system involving humans. Barry O’Reilly points out that technologists, who are often logicians and mathematicians, view the inherently irrational and complex human world as dysfunctional. The architect’s role is not to eliminate this dysfunction but to learn how to operate and build resilient software within it. Gregor Hohpe adds that organizations are never in a perfect state; what is optimal today is suboptimal tomorrow. This reality shifts the architect’s focus from painting a perfect target picture to understanding the starting point and its constraints. He suggests a “schizophrenic” approach, working on both fast (weekly/monthly) and slow (yearly) change cycles to make progress without hitting organizational walls.
The Architect as a Decision-Maker and Diplomat
The panel emphasizes that how a decision is made and propagated is often more critical than the decision itself. Gregor Hohpe argues that a lack of shared understanding and poor feedback cycles are where most initiatives fail, not in choosing the “wrong” cloud vendor or technology.
A key skill for architects is navigating the line between technical and business decisions. Barry O’Reilly highlights the stress junior architects face when this line becomes blurry, often because business stakeholders find ambiguity convenient. The architect’s job is to clarify these boundaries, translating technical risks into business terms like revenue impact, legal exposure, and reputational harm. Rebecca Parsons notes the importance of educating business leaders on the technical realities that challenge their mental models, such as eventual consistency and the non-determinism of AI, to facilitate informed trade-offs.
Embracing Non-Determinism: From LLMs to Quantum Computing
The introduction of non-deterministic systems like LLMs into deterministic software architectures presents a significant paradigm shift. Andrew Harmel-Law contrasts the traditional architectural approach of careful, upfront design with the reality of integrating a non-deterministic component that has “opinions” on many things beyond its primary function. This necessitates a shift towards making smaller, incremental decisions and relying on fast feedback loops.
Looking ahead to the 100th anniversary of quantum mechanics, the panel speculates on its architectural implications.
- Gregor Hohpe uses the “flying cars” analogy: we often expect revolutionary leaps, but innovation tends to trickle in through smaller, more profound changes that loosen existing constraints (e.g., the mobile phone’s impact vs. the lack of flying cars).
- Barry O’Reilly suggests the primary impact of technologies like GenAI and quantum computing may be on the architect’s mindset. By forcing practitioners to engage with concepts outside of traditional logic—like consciousness, free will, and quantum uncertainty—these fields can help dissolve rigid, structuralist thinking.
The Impact of AI on the Architectural Process
The panel discusses how AI coding agents will influence the practice of architecture.
- Amplifier, Not a Fixer: Gregor Hohpe posits that AI will amplify existing strengths but won’t compensate for weaknesses. If an organization is poor at domain modeling, an LLM will likely exacerbate the problem by generating more disconnected code, not solve the underlying issue.
- A Tool for Thought (or an Excuse Not To): Andrew Harmel-Law expresses concern that AI could become an excuse “to not think,” undermining the deep, contextual understanding required for good design. However, it could also be a powerful assistant for ensuring architectural ideas and ubiquitous language are correctly implemented in the code.
- An External Stressor: Barry O’Reilly offers a contrarian view, seeing GenAI not as part of the software system but as a powerful, external force that stresses the architecture. Whether in the hands of a developer or a product owner asking for a “statistically average” feature, it’s something the architect must protect the system against to maintain deterministic integrity. Gregor Hohpe builds on this, noting that a 5x productivity boost in development would break every other part of the organization—from management to strategy—that isn’t designed to operate at that speed.