In the Seams

I liked to use an ice breaker when meeting new enterprise clients dealing with modernization. I would tell them "show me your org chart, your architecture diagram, or your workflow, and I'll tell you where the risk is with no discovery." If they didn't have any of those, no problem. The risk lived in the same place either way. 

Things Fall Apart at the Seams

A long time ago in a galaxy far, far away, I was a product line manager and eventually technical and engineering lead for a globally distributed Electronic Medical Record (EMR) system tracking healthcare data for 10 million beneficiaries. The system was a suite of interoperable components that ultimately had to deliver a longitudinal patient record. The primary data platform sat in a state-of-the-art data center in Virginia, but the applications that captured those records had to run in some of the world's hardest places to reach: battalion aid stations in warzones, submarines, afloat vessels, and aircraft, all air-gapped, all over the world.

Modernization was rough. The components were mostly solid. The data layer, though, was already a seam. The schema was relational and slightly different per component, so interoperability required complex transformations, and schema changes broke interfaces nearly every time. Features arrived through regressions, scheduling headaches, and fights between developers, testers, and user reps. Then they hit our deployment partners, independent program offices for each military branch plus the Coast Guard, and one severity-one issue or unacceptable workaround sent us back into another round of code delivery, lab booking, and defect adjudication. A feature could take 9 months to a year. For people depending on that software to deliver care, that was unacceptable.

So why was it so hard?

As is nearly always the case, the friction was in the seams. The handoffs, the data exchanges, the transformations, the competing priorities. Think of a busy restaurant on a Saturday night. The cook's plate is perfect, the runner is at the pass, the table is set. The meal still goes out cold because the handoff happened a beat too late. The food was never the problem; the seam was. Integration is the collection of things that turns point solutions and components into something valuable.

When I joined, every component and point solution had its own product lead and engineering team. For major releases, each team worked on their changes and we met frequently (who doesn't love a good meeting, and boy, we had a lot of meetings) to stay in sync. An integration team (I led this before taking over the overall system) was responsible for deploying the components together and maintaining interoperability. Each team tested its deliverables; the integrator collected those and re-tested the whole. When the integrated product was ready, we booked the test lab, where a fully independent contracted test team was paid to find new issues, and boy did they ever.

After several painful iterations, the software would finally ship to deployment partners. It was really hard to get working software into customers' hands despite 80+ engineers, an eight-figure budget, and product leadership with decades of healthcare-systems experience. The shape isn't unique to that scale. I've watched the same play out in a two-person startup where the founders split product and engineering, and they were already paying the seam tax on every release.

The newest version of this plays out with AI agents. Every chat window with a coding agent is its own seam: memory, context, tools, renegotiated each session unless platform capabilities like agentic memory, skills, and MCP absorb them. I'd wager that if you look around, the same shape is in your org chart somewhere: a build/integrate handoff, an independent test surface, stakeholders with their own definitions of done. The story is the same; the uniforms changed.

The Org Chart Made The System

Goldratt's theory of constraints says you don't move the needle unless you're aimed at your actual bottlenecks. We had bottlenecks aplenty: too much tech debt, too much bureaucracy, too many real tradeoffs. But after some organizational upheaval, things did get better.

Remember those independent component teams feeding changes into our integrators? A major reorg around us let us collapse all that into one team. Everyone owned end-to-end delivery into customers' hands. The old way rewarded "our component worked fine on its own!" The new org chart rewarded users actually getting enhancements.

Same with those independent deployment program offices. Their requirements were our requirements, and treating them as independent seams was probably the biggest bottleneck in our pipeline. The reorg brought them inside the tent, where they became teammates rather than rightfully cranky external stakeholders.

Those changes really did make things run smoother. After a brief storming phase, we were getting software into customers' hands a little bit quicker. What we couldn't do was reverse years (decades) of technical debt. Conway's Law says your systems end up looking like your org chart, for better or worse. We'd remodeled the kitchen without moving the load-bearing wall: nicer cabinets, same awkward layout.

The Power of Platform

Knowing what I know now, I wouldn't start by reorganizing the people. I'd start by asking a different question: what if the integration plane wasn't somebody's job?

For most of my career, integration was a team. The integration team, the test integration lab, the deployment program offices. Each one was an organizational answer to pieces that didn't naturally fit. Each one was also a seam. And every seam was a place where a feature could stall for a week, a quarter, a year.

A platform changes the question. Instead of asking "how do we get all these components to interoperate cleanly enough to ship," you ask "what would it take for interoperation to be a property of the substrate, not a project?" When you ask that question for a real system, the substrate is almost always the data layer. When data is something each component team replicates, transforms, and reconciles, the seams compound. When data is the substrate (one durable source the components read and write through a shared contract), the integration plane stops being a place where features stall. Observability, security, deployment, identity follow the same shape: each one becomes something the platform provides on a contract you can engineer against, not something teams renegotiate every release.

The skeptic puts up a hand. "Aren't you just renaming the seams? Every platform has APIs, SLAs, version negotiations. The platform team is the new integration team." Fair shot. Yes, sort of. A platform doesn't eliminate seams; it collapses many fuzzy, every-release-renegotiated seams into one well-defined seam you can engineer, monitor, and evolve on a predictable cadence. It's the difference between negotiating a treaty before every shipment and shipping under one that's already signed.

The other allergy a reader of a certain vintage will have is to the word "platform" itself. We've heard this song before. Service-oriented architecture, enterprise service buses, microservices: all sold the same promise, most under-delivered. The difference, when platforms work, is ownership. A successful platform isn't a layer in the architecture; it's a team with a product, a roadmap, and a duty of care to the people building on top. Microservices (at their worst) distributed the complexity without giving anyone responsibility for the substrate. Platform-as-product reverses that. The payoff: your application teams stop spending their best hours integrating and start building. 

One more honest disclosure: a platform isn't only something you build. Most enterprise platforms are partly bought (a cloud provider, a data platform, a developer experience layer someone else maintains) and partly built. The shift is that the integration work moves up a level. Instead of re-integrating a dozen components every release, you're composing a smaller number of shared platforms with your conventions on top. That doesn't remove complexity, but it does make the seams more explicit, more durable, and easier to engineer against.

The next decade's version of this story is being written in AI applications, and the substrate question is sharper there than it has ever been. For an AI application, data and context are the seam everything else rides on. A model is only as useful as the context it operates over, and the context is the data: durable memory, retrievable knowledge, the shared truth the agents read and write through. When data is a substrate the application teams compose against, the seams are engineered and the application is fast. When data is something each agent renegotiates per session and each team transforms per release, you're back to the EMR. The agentic chat window from earlier is the same story at micro-scale, with the same answer: platform capabilities that absorb the seam rather than offload it to every session.

If we'd had that frame in the 2000s, I think we'd have spent less time scheduling integration test labs and more time shipping features to the people in those aid stations. We can't redo it. But the leaders building for the next decade can. The right question isn't "what's our architecture diagram." It isn't even "where are the seams." It's this: what complexity can we shield our best people from, so they spend their hours building for the customer instead of negotiating with the substrate? That's the question the org chart, the architecture diagram, and the workflow all turn out to be asking. The platform is the most honest answer we've found.