The last post ended with a question: which slice? If the way out of the pilot graveyard is creating the four conditions in one real place at a time, one boundary with production inside it, then everything depends on where you draw that boundary. And here’s the problem: most organizations can’t answer the question because they are thinking in the wrong unit. They think in applications.
So before we can find the seams, we have to break a thirty-year habit.
When You Hear “Application,” Hear “Monolithic Container”
An application is not a thing. It’s packaging. It’s how a set of business capabilities happened to get bundled together: by a vendor’s roadmap, by an acquisition, by a decade of “just put it in the same codebase because that’s where the team was.” When somebody says we need to modernize the ERP, or we have to get off the AS/400, they are talking about the box, not what’s in it.
And what’s in it? Everything. We’ve run capability analysis against a lot of these systems, and the honest description of what comes back is an antique mall: live capabilities next to dead ones, duplicates of things that exist in three other systems, the genuinely differentiating logic of the business sitting in the same container as commodity functions you could buy off the shelf tomorrow. The application is a La Brea tar pit with all the bones in it. The bones don’t belong together. They just sank in the same place.
You cannot create the four conditions around a container like that. You can’t encapsulate everything. You can’t assign one team to own all of it. The application is exactly the tangle we’ve spent two posts saying you can’t automate.
Capabilities Are the Unit of Decision
A business capability is a thing your company does: take an order, screen a candidate, dispatch a crew, price a policy. Capabilities decompose cleanly: domains, subdomains, bounded contexts, all the way down to the data. And unlike applications, capabilities have natural edges. A bounded context is precisely the line where one definition of customer ends and another begins. Those edges are where encapsulation is possible. Which means those edges are where the four conditions can actually be created: where a team can own something, where data can be validated at its source, and where an agent can work inside a boundary instead of drowning in a container.
This is the answer to which slice. A slice is a capability, cut at its natural seam, taken all the way down through the code and the data.
Nobody Knows What’s in These Things
Here’s the objection, and it’s a legitimate one: nobody in your organization can tell you what capabilities live in the estate. The containers are dark. The people who packed them are gone. The documentation lies.
This is where AI earns its first honest paycheck, before a single agent writes a line of production code. Point it at a legacy codebase and AI-assisted capability extraction can map the domains and subdomains, cluster what changes together, and surface the duplicates. In our experience it comes back about 80% right, with humans judging the rest. Work that used to take months of archaeology compresses into days. Notice what that is: AI as navigator, making the estate visible, not AI as easy button rewriting it. That distinction is the whole subject of the next post.
Better Seams to Cut
Once you can see capabilities instead of applications, a strategic question replaces a technical one. For each capability, ask: is this where we win, or is this table stakes? Where you differentiate, it deserves to be custom: encapsulated, owned, evolved, eventually agentic. Where you don’t, it belongs in a system you already have. Most of what’s inside that AS/400 isn’t going to be custom software in your future. It’s going into the ERP, the GIS, the platforms already on your floor.
All of which exposes lift-and-shift for what it is: repackaging the tar pit. Point AI at the whole container, rewrite it, and you get a new big application nobody understands, still unintegrated, with all the hard decisions still unmade. The alternative isn’t heroic. Draw out the cuts before you touch anything: this piece to SAP, this piece retired, this piece custom because it’s how we compete. Then cut one seam.
So what’s the recommendation here? Exactly what it sounds like: build the capability map. You don’t need to boil the ocean. Pick the area of the business where the pain lives and map that. It’s the first artifact of everything that follows, and it’s the one deliverable you keep no matter what you decide to do next.
Stop modernizing applications. Start liberating capabilities. The next post is about what AI actually does once a capability is free: what it’s genuinely good at inside a clean boundary, what it can’t do, and why the answer is neither replace the engineers nor just a better autocomplete.
This is Part 4 of a seven-part series. Start with Part 1 here.
