"Architect" in a software project is a fuzzy term. In some teams it's a dedicated person, in others it's the tech lead doing double duty, and in others still it's a senior developer who was handed the role "on top of everything else." But behind the word sits a concrete set of responsibilities that someone carries in any case.
Let's go through them one by one — what each is, why it matters, and what happens when it's missing.
Keeping the system map
Picture a company with ten microservices. A year later, nobody can confidently answer: "Who owns the users table? Which service publishes the payment event? Can I change this field without breaking anything?"
That means the system map has been lost. The map isn't necessarily a pretty diagram — it's the answers to those questions: who is responsible for what, who talks to whom, which data lives where.
The architect is responsible for making sure the map exists and doesn't go stale. Without it, every next decision is made blind.
Making architecture decisions — and recording them
Monolith or a separate service? Store data in a relational database or an analytical warehouse? A synchronous call or a queue? These are forks in the road with no universally correct answer — only "correct for our situation."
The architect's job isn't to "know the answer," but to run the decision through criteria: what data volume is expected, how many users, what team, what time horizon. Weigh it, choose, and write it down.
The record is called an ADR (Architecture Decision Record). It's a short document: the context, the decision itself, the alternatives, and the reasons they were rejected. A year later, when a new person joins and asks "why did we do it this way?" — the answer is in the ADR, not just in one person's head.
When decisions aren't recorded, they get rediscovered from scratch. The team holds a discussion it already held a year ago, and often reaches a different conclusion — not because anything important changed, but because nobody remembers why that particular path was chosen.
Designing service boundaries
One of the most painful questions in distributed systems: where does one service end and another begin?
If a boundary is drawn wrong, it seeps into everything: extra calls between services, shared databases (which makes services dependent on each other), confusion in terminology (in one service it's a "client," in another a "buyer," and nobody is sure whether they mean the same thing).
The architect decides where to draw the boundary — based on which data and processes change together and which change independently. This is one of the most expensive mistakes to make: a wrong boundary is discovered late and takes a long time to redo.
Seeing end-to-end processes
One service handles placing the order, another the warehouse, a third the delivery, a fourth the notifications. But who is responsible for the whole process, "from the button click to the parcel at the door"?
That's the architect's job — to see the processes that cross several services: where they start, who does what at each step, what happens on failure. Without this, each service only knows about its own piece, and nobody knows about the whole.
Such processes need to be described explicitly: who orchestrates them, how to compensate for an error at the third step, when to notify the user. Without that, failures come as a surprise.
Assessing the impact of changes
"Let's change the payment event format" — who does that affect? An answer of "nobody, I think" is the start of an incident.
The architect is responsible for making sure such questions have a verifiable answer. That's exactly what the map is for: knowing who consumes the event, you can assess the impact in advance and make a decision — apply the change, add versioning, or leave it alone entirely.
Without this, changes ship to production and break something nobody thought about. Not because the developers are careless — it's simply that without a map you can't hold all the connections of a large system in your head.
Watching for consistency
Systems accumulate inconsistencies slowly. One service starts naming an entity differently. Two services declare themselves the owner of the same field. Specs go stale and no longer match the code.
Taken one at a time, these are trivial. Accumulated, they make the map useless and make work harder.
The architect periodically checks for consistency: terminology is unified, data ownership doesn't overlap, descriptions are current. This is grunt work that rarely finds the time — which is why it usually doesn't get done until it becomes too painful.
Turning decisions into standards
An architecture decision that isn't pinned down anywhere lasts two sprints. The team agreed that synchronous calls between services go only through a dedicated gateway. A month later the rule is broken, because a new developer didn't know about it and the old ones forgot.
The architect's job is to turn decisions into verifiable rules: standards, conventions, templates. A rule that gets checked at every review survives; a rule that was merely "agreed on" does not.
How to set up such a check is a separate topic: executable engineering standards.
Architect vs tech lead vs developer
In small teams, one person combines several roles. The important thing to understand is that the architect's responsibilities don't disappear when that happens — they simply land on someone specific.
If the team has no dedicated architect, it helps to agree explicitly: who keeps the system map, who documents decisions, who watches for consistency. When that's not done, the responsibilities go unmet — and over time invisible problems pile up.
The main characteristic of architecture work: its results aren't visible immediately. Good architecture goes unnoticed — the system just works and changes without pain. Bad architecture becomes visible a year later, when any change takes a week instead of hours.
In short
- The architect is a set of responsibilities, not necessarily a job title: in small teams the tech lead or a senior developer takes them on.
- The system map is the foundation: who owns what, who talks to whom, where the data lives. Without it, decisions are made blind.
- Architecture decisions need to be recorded — otherwise they get rediscovered from scratch. That's what the ADR is for.
- Service boundaries are one of the most expensive design mistakes: a wrong boundary seeps into contracts, data, and the organization.
- End-to-end processes are seen by nobody but the architect — each service only knows about its own piece.
- Assessing impact of changes requires a map: without it, "probably won't affect anyone" is the start of an incident.
- Standards only work when they're checked, not merely "agreed on."
What to read next
- ADR — how to write up and store architecture decisions.
- Synchronous and asynchronous communication — one of the typical forks an architect resolves.
- The C4 model — a diagram language for the system map.
- Executable engineering standards — how to turn decisions into rules that are checked automatically.