Between the seams
Someone asks how far along the program is. The team lead says 90%. Next week, 90%. Another week after that, still 90%. Eventually the thing ships, and when I trace back what actually ate the time, almost none of it was in the thing we were building. Most of it was in the spaces between.
The model was fine. The API worked. The data pipeline was fine too, give or take. The problem was that the word fine meant a slightly different thing to a slightly different team in each place, and nobody on the program had been paid to reconcile those definitions.
I've started calling those reconciliation points the seams.
What lives in the seams
Every enterprise system has a stack of interfaces that don't appear on the architecture diagram. A few examples from the last year of work:
- What the AI team thinks the agent is allowed to do, versus what the system of record is actually willing to accept from a non-human caller.
- Security's formal risk posture, versus the informal risk posture the business has already accepted by making a promise to a customer.
- “This works in our sandbox” versus “this is something operations can wake up and triage at 3 a.m.”
- The model's output, versus the user's actual workflow, where trust, friction, and overrides live.
- The vendor's product roadmap, versus the implementation team's reality.
None of these is a piece of technology. Each is a small negotiation between two groups that don't share a vocabulary, and each has to be closed before the larger system can reliably work.
Why the boxes get all the attention
Enterprise architecture diagrams, by design, are drawn in boxes. Boxes are easy to fund. A platform team owns one. A product team owns one. Vendors sell them.
Seams don't get that kind of treatment. They cross reporting lines. No RFP I've ever read asks whether the proposed platform will reduce translation debt between security and engineering. No quarterly plan has a line item for agreeing what “ready” means in one program before you go build it. That work shows up in slipped timelines, 2 a.m. incidents, and eventually in a retrospective slide. Rarely in a roadmap.
This is most of what I see slowing enterprise AI down right now. The model itself isn't the hard part. The model is bought, or rented, or good enough out of the box. The hard part is deciding what it's allowed to do, what happens when it gets something wrong, who owns the outcome, and how any of that gets explained to a help desk agent on a Tuesday. Every one of those decisions is a seam.
Translation is most of the job
When I describe what an enterprise architect actually does to someone outside the field, I've mostly stopped saying “system design.” Too clean. I tend to say “translation” instead.
The shape of the work on a given day:
- A business outcome like “reduce average handle time by 20%” has to become a technical posture the engineering team can push back on.
- An engineering constraint like “the vendor's rate limit is sixty calls per minute per tenant” has to become a business trade-off the sponsor can actually make a call on.
- A security objection like “we can't let an agent call that API” has to become a menu of options, each with a different operational and risk cost attached.
- A vendor's abstract capability list has to become a concrete prediction about what's going to work in our environment and what isn't.
That isn't “design” in the sense of drawing a diagram. It's moving information between three or four languages that happen to be spoken inside the same company. Writing code is a smaller share of the work than the title implies. Most of the deliverables are sentences. Decision records, short memos, the occasional email that saves a month of rework later on.
Working in the seams
A few habits that have held up for me.
The first is writing the operations runbook before the architecture is finalized. If I can describe how operations will triage a failure in concrete terms (what they see, what they do, what access they need), I almost always find a seam the design didn't handle. If the runbook won't write, the design isn't actually done.
The second is getting the integration contract between any two teams onto paper before the roadmap gets committed. That contract is where assumptions quietly die. Write it, circulate it, get everyone to sign off on it, and do it while changing it is still cheap.
The third is putting trade-offs next to decisions in the record. An ADR that only captures what we chose is half an ADR. The part that matters to the next person is what we gave up, and why.
The fourth is assuming that every handoff loses some information in translation. Between AI team and platform team, between platform and operations, between operations and the users who will live with the system. That loss isn't a failure of the interface. It's a property of it, and it has to be planned for.
The last is treating “that's a people problem” as where the architect's work starts. Most seams show up as people problems first, because they're about who decides, who signs off, who gets paged. If that's where the work is, that's where my time needs to go.
The real deliverable
What caught me off guard when I moved into this kind of role is that the architecture diagram isn't actually the thing I'm being paid for. The diagram is a byproduct.
What I'm being paid for is shared understanding. A business sponsor who knows what they're buying, in the concrete terms their team will live with. An engineering group that understands why the constraints are what they are, and is therefore equipped to push back when it matters. An operations team that knows what to do when the system misbehaves in the ways it's allowed to misbehave. A security reviewer who knows which trade-offs have already been made on their behalf, and which are still open.
When that shared understanding is in place, the diagram mostly draws itself. Without it, no diagram saves anyone.
This is especially visible in generative AI work right now. The models are astonishing. They're also commoditizing fast. The differentiator isn't in the box labeled “LLM.” It's in knowing which questions need translating, for whom, and in what direction. Which is another way of saying the work is still mostly between the seams.