Seeing Beyond the Boxes and Arrows
Two recent design discussions at work left me reflecting on a handful of recurring patterns that can prevent architecture conversations from moving forward.
In both cases, the people involved were trying to simplify the diagrams used to guide the conversation and make it easier to reason about. That is usually the right instinct. Diagrams become unusable when they contain every detail, while conversations become unwieldy when they expand to include large parts of the system.
The difficulty begins when simplification removes the distinctions needed to make the decision in front of us. A diagram looks clean, a service name feels natural, an existing system boundary appears authoritative, or an arrow seems to explain a relationship. The representation feels clear, but the clarity is deceptive. Important responsibilities, dependencies, models and trade-offs have been compressed into shapes that no longer help us ask the right questions.
This series will explore several patterns I noticed across those two discussions. It is not intended to be an exhaustive catalogue of architecture problems, nor am I suggesting that these are the most important issues facing every organisation. They are simply familiar patterns that resurfaced in those particular encounters and seemed useful enough to examine more closely.
One lens on architecture
Architecture is broader than the structures represented in software diagrams. Business strategy shapes which outcomes matter. Understanding the problem space helps us discover meaningful capabilities and boundaries. Organisational structures, incentives, ownership and cognitive load influence how those boundaries evolve. Operational realities raise concerns such as resilience, observability, and failure recovery, while AI introduces further questions about probabilistic behaviour, context, and semantic consistency. All of those concerns matter, and I explore many of them elsewhere on this blog.
This series focuses on one particular lens: how we represent and reason about the technical structure of software systems. It examines views, boundaries, runtime relationships, deployment structures, existing-system constraints and dependencies—and how those representations shape the decisions we make.
Other posts on this blog will explore the wider business, organisational, operational and sociotechnical forces. The narrower scope here is deliberate because clearer reasoning often begins by knowing which question a view is intended to answer.
The patterns this series will explore
The common thread across the series is false clarity: representations that appear simple and authoritative while hiding distinctions that matter to architectural reasoning.
Each pattern looks different on the surface. One is about diagrams, another about names, another about existing systems, and another about arrows between components. But they all create the same risk: they make one interpretation of the system feel more complete than it really is.
The False Clarity of Collapsed Architecture Views
The first post looks at what happens when physical, development, process and logical concerns are compressed into a single diagram.
A component may be one deployment unit, one runtime process and one codebase without necessarily being one coherent logical boundary. Those views can legitimately take different shapes because they exist to answer different questions.
The problem is not simplification itself. A useful diagram must leave things out. The problem begins when a simplified view is used to support decisions that depend on the distinctions it has removed.
One System, Many Views, Better Design Decisions
Recognising that multiple views exist is only the starting point. The next question is how to use them deliberately.
This post will introduce Kruchten’s 4+1 view model and explore how different views can help us address different architectural concerns without forcing one structural answer onto all of them.
For example, one view may favour a single codebase or deployment unit, while another reveals several logical responsibilities. The value lies in understanding which question each view helps us answer and how the resulting decisions affect the system as a whole.
Service Names Are Boundary Decisions
Names are often treated as labels applied after the design has been decided. In practice, they influence the design itself.
A name chosen too early can narrow the conversation before the responsibilities are properly understood. A generic name can become a bucket into which almost anything fits. An entity-based name can make a data concept look like a natural service boundary, even when different parts of the system use that concept in very different ways.
This post will examine how service names shape what people believe belongs together and why naming is therefore part of boundary design, not merely presentation.
Current Systems Are Constraints, Not the Model
Existing systems matter. They contain live data, integrations, operational dependencies and years of accumulated decisions. Any realistic design must take those constraints seriously. But the current implementation is not necessarily an accurate model of the underlying problem.
This post will explore what happens when existing technical boundaries are introduced too early in modelling. Historical choices begin to look like domain truths, accidental coupling begins to look intentional, and the system we happen to have starts defining the system we are able to imagine.
The aim is not to ignore the current estate, but to distinguish between constraints we must work with and boundaries we should continue to question.
Beyond the Arrows: The Flows Your Diagram Doesn’t Show
Most architecture diagrams are good at showing that one component communicates with another. They are less effective at showing what that relationship means.
An arrow may represent a call, a message, an event, a contract or a dependency. Even when it is labelled, it may not reveal whose model is crossing the boundary, who owns the language, who is upstream or downstream, or how much influence one context has over another.
This post will move beyond call flow to examine model flow and influence flow. It will explore what ordinary arrows leave implicit, and why transport-level decoupling can still conceal deep semantic and organisational dependencies.
What I hope the series will do
These posts are not intended to argue that every service should be split, that every diagram should contain every detail, or that every existing boundary is wrong.
Physical consolidation may be sensible. One codebase may be the right choice. A broad service may be an acceptable transitional design. A simplified diagram may be exactly what a particular discussion needs. The aim is to make those choices more visible and deliberate.
Architecture conversations improve when we can distinguish what is logically cohesive from what is merely co-located, what is an intentional dependency from what is historical, and what a model reveals from what it leaves out.
The diagrams, service names and system boundaries we use are not neutral. They shape the questions we ask and the options we can see.
This series examines places where apparent simplicity can conceal important design choices and explores how making those choices visible can lead to more thoughtful architectural decisions.