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, very little of it was inside the build. Most of it was in the space between.
The platform worked. The service worked. The data layer worked, roughly. What slipped was the word “ready,” which meant a slightly different thing to each team that said it, and nobody on the program had been paid to reconcile those definitions.
I've started calling those reconciliation points the seams.
What a seam is
Every enterprise system sits on a stack of interfaces that never appear on the architecture diagram. A few from the last year of work:
- Engineering's view of what a new capability is allowed to do, sitting next to the system-of-record team's view of what they're willing to accept from it.
- Security's formal risk posture, next to the informal risk posture the business already accepted by making a promise to a customer.
- “Works in our sandbox,” next to “operations can wake up and triage it at 3 a.m.”
- A designed workflow, next to the actual one users fall into when the first friction point hits.
- A vendor's product roadmap, next to the implementation team's reality.
Every one of those is organizational. A small negotiation between two groups that don't share a vocabulary, which has to close before the larger system can work reliably.
Why the boxes get the attention
Enterprise architecture diagrams get 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 before anyone starts to build. Seam 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 programs down right now. The build takes longer than anyone planned for, and the program slips even longer on top of that. The gap is almost always seam work that nobody owned: what the thing is allowed to do, what happens when it misbehaves, who wears the outcome, and how any of that gets explained to a help desk agent on a Tuesday.
The work between the work
The shape of the problem is familiar from software estimation. Dave Stewart has a good piece arguing that the “actual” work on a project is often as little as a fifth of total effort. The rest is scattered across admin, preparation, iteration, changes, and problems that weren't visible when the estimate went in.
Enterprise architecture has similar proportions, and the invisible share is mostly seam work. Translating business outcomes into technical posture. Translating engineering constraints back into trade-offs the sponsor can actually make a call on. Turning a security objection into a menu of options, each with its operational cost written next to it. Turning a vendor capability list into a concrete prediction about what will and won't hold up in our environment.
Most of the job looks like moving information between three or four languages that happen to be spoken inside the same company. The code-and-diagram share is smaller than the job title implies. The deliverables are sentences. Decision records, short memos, a one-pager that saves a month of rework later.
Habits that hold up
A few things I've come to rely on for seam work.
The first is writing the operations runbook before the architecture gets 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 hasn't handled. A runbook that won't write usually means a design that isn't done.
The second is getting the integration contract between any two teams onto paper before the roadmap commits. That contract is where assumptions quietly die. Write it, circulate it, get everyone to sign off, and do it while changing it is still cheap.
The third is making trade-offs part of the decision record. An ADR that only captures what got chosen is half an ADR. The part that matters to the next architect is what got given up, and why.
The fourth is assuming handoffs lose information. Between platform team and operations, between operations and the people who end up using the thing. Treat that loss as a property of the interface and plan around it.
The last is treating “that's a people problem” as where architecture work starts. Most seams show up as people problems first: who decides, who signs off, who gets paged. If that's where the work is, that's where the calendar has to go.
The real deliverable
What caught me off guard when I moved into this kind of role was how little the diagram mattered. The diagram is a byproduct of the actual deliverable.
The actual deliverable 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 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.
The pattern is broader than AI. Large programs have always looked this way. AI raises the stakes because the pace of capability change keeps pressuring assumptions that used to sit comfortably unexamined for years. The programs that land and the programs that stall mostly differ in how well their seams got held.