Enterprise Stratigraphy

There is a concept in geology called stratigraphy—the study of rock layers. Geologists read those layers the way historians read archives. Each layer tells a story about the conditions that produced it, the pressures that shaped it, and what came before and after. The oldest layers sit at the bottom. Newer ones accumulate on top. And the boundary between layers—what geologists call an unconformity—is often where the most interesting things happen.

Organizations form in much the same way.

Every institution accumulates layers over time. A platform built during a period of rapid growth. A data structure that reflects a merger from fifteen years ago. A governance policy that made sense under a previous administration and gradually hardened into habit. A workflow that nobody intentionally designed—it just grew.

If you've worked inside any large organization long enough, you start to see these layers everywhere.

Most frameworks for thinking about enterprise architecture rely on spatial metaphors. They describe landscapes, domains, tiers, and stacks. Those models are useful for showing what exists. But they are less helpful at explaining why something exists, when it formed, and the conditions that produced it.

Stratigraphy introduces another dimension: time.

And once you start looking at organizations through time, the interpretation changes.

A legacy system is not just technical debt. It is a sediment layer that formed under a particular set of constraints—business priorities, budget cycles, leadership decisions, regulatory realities. Understanding those conditions tells you something important: whether the layer is load-bearing, mostly cosmetic, or a fault line where stress in the organization tends to surface.

Enterprise Stratigraphy is simply the practice of reading those layers before you start changing them.

It asks a different set of questions than traditional architecture work. Not just: what systems do we have? But: when did this form, and why? What problem was it solving at the time? What trade-offs were accepted? Is the layer still doing meaningful work, or is it mostly holding up something newer that now depends on it?

Those questions tend to change what you build next.

Consider something simple: a data integration layer everyone complains about. It looks inefficient. Redundant. Outdated. But if you trace its origin, you may discover it was built during a merger, when two systems had to coexist for operational or regulatory reasons. The layer might still be quietly holding those worlds together.

Remove it too quickly and you haven't modernized the system—you've destabilized it.

This is one of the most common reasons enterprise transformations fail. Not because the new technology is wrong, but because the organization never understood what the old layer was actually doing.

Once you start looking at organizations this way, you begin to notice patterns. Certain layers tend to carry structural weight. Others quietly accumulate risk. And some exist mostly because no one has revisited the conditions that produced them.

Stratigraphy is not an argument for preserving everything. It is an argument for understanding what you are standing on before you start digging.

The organizations that build most durably are the ones that know the ground beneath their feet.