What Enterprise Architecture Got Right (And Why It Matters Now)

• enterprise architecture
• system design
• ai

I recently came across something called the Zachman Framework.

It’s one of those things that’s been around for a long time, mostly in the enterprise architecture world, and I probably would have skipped over it in the past. But reading it now, in the context of how I’ve been working and what I’ve been running into with AI, it landed differently.

At its core, it’s surprisingly simple. It’s basically a way of describing a system by answering a consistent set of questions: what, how, who, when, where, and why. More formally, it’s described as a structured schema for organizing and classifying the elements of a system so you can understand it as a whole. That alone isn’t that interesting.

What is interesting is what it implies.

Lately, I’ve been spending a lot of time building with AI tools - and watching other people do the same. The pattern is pretty consistent: you start with an idea, describe what you want, and very quickly you get something that looks like a working product. It has screens, interactions, maybe even some data flowing through it. It feels like real progress, and I’ve done this myself. It’s a bit of a rush.

But then you try to extend it. Add something new. Make it behave more like a real system. And things start to feel less clear, because you’re not really building forward anymore - you’re trying to understand what’s already there: what assumptions got made, what structure exists underneath, and why certain behaviors work the way they do. The system has already taken shape; you just didn’t define it explicitly.

Reading about Zachman, what stood out wasn’t the framework itself, but the idea behind it. It’s trying to force completeness - not in the sense of building everything upfront, but in the sense of describing a system from all of the angles that actually matter: data, behavior, actors, timing, rules, connections.

And it made me realize that a lot of what I’ve been running into isn’t really new. We’ve known for a long time that complex systems need to be described in a structured way, and that you can’t just define one part and expect the rest to fall into place cleanly. We just haven’t had to confront that as directly.

In the past, a lot of this was handled implicitly by the people involved. You could start with a set of user stories or a rough idea, and the system would get shaped over time by the team. Developers would fill in gaps. Architects would impose structure. Over time, things would stabilize. The definition of the system was distributed across people.

But when you’re using AI to generate large parts of that system, that dynamic changes. The model doesn’t share context. It doesn’t know what you meant beyond what you gave it. If something isn’t specified, it fills in the gaps.

And those gaps aren’t small.

They’re decisions about what data looks like, how behavior works, what rules apply, and how different parts of the system relate. Sometimes those decisions are reasonable. Sometimes they even look right on the surface. But they’re still decisions that you didn’t explicitly make, and once they’re there, they’re hard to unwind.

One thing that’s been clicking for me is that even if you adopt a more structured way of describing a system - something like what Zachman is pointing at - there’s still a piece that tends to get glossed over. We’re pretty good at thinking about what data exists, who interacts with it, and what rules apply. But we’re less explicit about behavior itself.

Not implementation-level behavior, but the underlying things the system needs to be able to do: assign a ticket, submit an application, schedule a visit. These kinds of actions show up everywhere. They appear in different user stories, across different parts of a system, and through different interfaces over time. If you don’t define them somewhere, they get recreated over and over again, slightly differently each time. That’s where systems start to drift - not because anything is obviously broken, but because the same idea keeps getting implemented in inconsistent ways.

Something similar happens with how that behavior is exposed. The same underlying action might show up in a UI, an internal tool, and an external API. Those aren’t different behaviors; they’re different ways of accessing the same behavior. But if you don’t separate those ideas, they get coupled together, and once they’re coupled, it’s harder to evolve one without affecting the others.

What I find interesting about all of this is that the core idea isn’t new at all. Frameworks like Zachman have been trying to give us a way to describe systems more completely for decades - a kind of shared structure for thinking about how all the pieces fit together.

What’s changed is the environment we’re operating in. We now have tools that can generate working systems very quickly, but those tools are extremely sensitive to the quality of the input they receive. If the system isn’t well defined, they don’t stop. They fill in the blanks, and that’s where the problems start to show up.

What I’ve been taking from this is that there’s a small but important step between having an idea and generating something that runs. Not a heavy process, and not a full architectural exercise. Just enough structure to make the system visible - what exists, what can happen, and what needs to be true - so that when something gets built, it’s not deciding those things on its own. It’s working from something that’s already been thought through.

That hasn’t slowed me down. If anything, it’s made it easier to keep going once something starts to take shape, because I’m not constantly trying to reverse-engineer what I already have. I’m building on something I understand.