In many organizations, the title "Software Architect" exists. It is often used to signal technical maturity — both internally and externally. But maturity doesn't come from naming. It comes from the organizational anchoring of the function.
Architecture is a design function. It requires context, influence, time, and a clear mandate. If any of these is missing, architecture doesn't emerge — instead, what emerges is the sum of local decisions that no one holds together.
The question is therefore not: "Do we have an architect?"
But rather: "Do we have the conditions for architecture to actually happen?"
Architecture rarely fails due to a lack of competence.
It fails due to a lack of organizational honesty.
Architecture Is Not Implementation with More Experience
A common misconception is the assumption that a software architect is simply a particularly experienced developer — a "Senior Developer Plus."
Of course, an architect needs technical experience. A great deal of it, in fact.
But their primary task is not writing code.
Ralph Johnson put it succinctly in a widely cited discussion, later referenced by Martin Fowler in his essay "Who Needs an Architect?": "Architecture is the decisions that you wish you could get right early in a project." Why? Because they are hard to change later.
The architect's task, then, is to make exactly these decisions — decisions that make the code possible and sustainable in the first place:
- How should the system evolve over the years?
- What structure allows growth without exponential complexity?
- Which decisions are reversible — and which are not?
- Where do future risks arise (scaling, security, operations, compliance)?
- What dependencies are we building right now — and what long-term costs do they create?
These are not implementation questions.
These are questions of structure, direction, and sustainability.
Mark Richards and Neal Ford articulated the first law of software architecture: "Everything in software architecture is a trade-off." And the corollary: "If you think you've found something that isn't a trade-off, you probably just haven't identified the trade-off yet."
A senior developer optimizes the solution.
A software architect shapes the solution space.
The difference lies not in the ability to implement, but in the focus of responsibility.
The Structural Tension: Responsibility Here, Decisions Everywhere
If architecture concerns this type of decision, the real question is not competence — but whether the organization actually enables these decisions to be made.
Architecture requires that someone can see and understand the big picture. Not in the sense of control, but in the sense of overview: What capabilities already exist? What initiatives are running in parallel? What integrations, data flows, and operational assumptions are in play?
In many organizations, responsibilities appear to be neatly divided: Business decides the what, engineering managers organize the teams, tech leads own day-to-day delivery — and the architect takes care of "the structure."
Sounds tidy. Often doesn't work.
Because architecture is not an isolated responsibility. It is the result of decisions being made everywhere:
- When the business decides to expand into new markets, that has architectural consequences.
- When the team structure changes, it affects whether microservices make sense or a monolith is the better choice.
- When one team introduces a new programming language, another picks a new framework, and a third builds its own deployment pipeline — that creates exactly the island landscape that architecture is supposed to prevent.
- How an application is deployed is an architectural decision. Team boundaries, system boundaries, repository structure, and deployment capabilities are tightly coupled — often as a cycle that extends into SLAs, availability, and compliance.
Conway articulated this as early as 1968: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." And Ruth Malan stated the consequence: "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins."
This creates a structural tension: The responsibility for long-term system evolution lies with architecture. The decision-shaping factors, however, are distributed across the organization. The expectation that "the architect will take care of it" exists — even when they weren't involved. And the mandate to participate in the relevant decisions is missing or unclear.
When these things don't align, a fatal situation arises: Architecture is expected but cannot be actively shaped. It reacts to decisions that have already been made, instead of co-shaping them in advance.
This is not a competence problem. It is an organizational-structural pattern.
That is why a software architect must at least be involved in all these areas — not to decide the "whether," but to raise "what does this mean for the system?" in time. Everything that extends beyond a single team should be architecturally visible. Not as an approval process. Not as bureaucracy. But because someone needs to maintain the overview.
Depending on team size and complexity, architecture can be practiced as a centralized, distributed, or rotating role. The title doesn't matter. What matters is that the function exists and is organizationally anchored.
When this doesn't happen, you don't see it immediately in the code — but in patterns: Locally sensible solutions emerge that don't fit together globally. Similar things are built multiple times because no one knows they already exist. Every solution brings its own terminology, data models, and interfaces. Integration and operations become more expensive with every island.
From the outside, this can look as if architecture is "unnecessary." Not because architecture has no value, but because the organization doesn't use it as a connecting function. Then architecture remains a collection of individual decisions that don't arise from a shared vision, but from accidental sequencing and local pressure.
This is not a criticism of individual developers — it is an observation about organizational mechanics.
A Practical Example
A system manages campaigns with start and end dates. In the beginning, a simple DateTime field suffices. The assumption: All users are in the same time zone, deadlines mean "end of the day," and nobody asks which day exactly is meant.
This works — as long as the assumption holds.
Then international customers arrive. A user in New York enters "June 5th" as a deadline. A user in Vienna sees the same date — but whose midnight applies? The system doesn't know, because the DateTime type doesn't carry this information. It stores a number without context.
Each team solves the problem locally:
- The backend team silently converts everything to UTC — but loses the information about which time zone the user intended.
- The frontend team displays dates in the browser's time zone — which may differ from the server's.
- A third team builds a reporting export that outputs the database values directly — in UTC, without conversion.
No team made a mistake. Every decision was locally reasonable. But the system now displays three different times for the same event — depending on where you look.
The real problem lies deeper: "What is a date in our system?" was never asked as a question. Is it a point on the timeline? A calendar day in the user's sense? A deadline that requires a time zone? A recurring event governed by local rules? These are fundamentally different concepts — but the data model treats them all the same: as a single column of type timestamp.
Technically, all of this is solvable. But no longer easily. The data model must be split. Existing data must be migrated — without knowing which time zone was intended at the time of entry. Every interface, every report, every display must be reviewed.
The feature wasn't complex. The missing architectural embedding was. A single early decision — "What types of time exist in our system, and how do we model them?" — would have prevented the entire downstream effort.
And this is precisely where it becomes clear: Architecture without context can only manage islands — but cannot shape systems.
Architecture Needs Focus and Feedback
Architectural work doesn't happen in the context switch between two bug fixes. It emerges through analysis, modeling, evaluating alternatives, mentally playing through scenarios, and making deliberate decisions under uncertainty.
Typical components include:
- Documenting decisions (e.g., ADRs)
- Evaluating trade-offs
- Defining guardrails
- Evolution paths and refactoring strategies
- Risk analysis
- Dependency and integration maps
- Communication and alignment across teams
When 90% of working time is reserved for feature implementation, there is effectively no room for any of this. Then architecture isn't shaped — it emerges as a byproduct. Then a DateTime field becomes a system-wide problem — not because the question was hard, but because nobody had the time to ask it. And that is one of the most expensive states a software system can be in.
At the same time, architecture also fails at the other extreme: when architects work far removed from day-to-day development. They define guidelines and design target states — without truly knowing the practical constraints of implementation. The result is "ivory tower architecture."
Good architecture therefore needs both:
- Strategic distance, to think long-term.
- Practical proximity, to stay realistic.
An architect doesn't code because features need to be delivered.
They code because architecture must be real — to validate assumptions, make risks visible, and test structures.
If either is missing, architecture becomes either reactive — or detached from reality.
One might argue that reactive architecture can be intentional. Modern architectural approaches deliberately follow the principle of deferring decisions as long as possible — until more information is available.
The difference lies not in the timing, but in the reason:
- Strategy: We could decide earlier but intentionally choose to decide later. Example: We leave the storage technology open but define clear interfaces and performance checks until load profiles are measurable.
- Constraint: We have to react now because we previously lacked information, influence, or time. Example: We pick "some" technology under time pressure, without load assumptions, without guardrails, without an exit path.
Both look "reactive" from the outside. But they are fundamentally different.
How to Recognize That Architecture Doesn't Truly Exist
Not as a title. But as a lived function.
- Are structural decisions consciously documented — or just implemented?
- Is there explicit time for architectural work — or does it happen "when there's a gap"?
- Are architects involved in strategic product decisions?
- Are major changes made visible across teams before implementation?
- Is there transparency about which capabilities and modules already exist?
- Are technical guardrails actively defined — or do they emerge implicitly?
- Are there planned evolution paths — or only refactoring when needed?
- Are long-term risks actively discussed — or only visible when they occur?
If most answers are "no," architecture probably doesn't exist as a shaping function.
And emergence is no substitute for responsibility.
Conclusion
A software architect is not simply a senior developer with a different title.
They are responsible for the structure, direction, and future viability of a system.
For this, they need context, influence, time, and a mandate. If any of these is missing, they cannot fulfill their role — no matter how competent they are.
That is why every organization that uses the title "Software Architect" should ask itself a simple question:
Do we truly want to shape architecture?
Or do we just want to pretend it exists?
Top comments (0)