A reflective review of Enterprise Architecture in 2025, covering asset management, policy integration, architecture frameworks, and the ongoing work of translating strategy into technology execution.

I’m working with my team on a typical, beautiful day in Texas when my phone rings. It’s my boss, and he’s not happy. An all-day planning session for a new, major program in one of our largest organizations is supposed to be starting. But, instead, they’re waiting for me. I wrap up quickly and head to the meeting. As I walk in, it’s clear my boss isn’t the only one upset.

I recently came across a post on LinkedIn about Enterprise Architecture. It started by listing all the major frameworks just to posit that a real practitioner must master all of them. This résumé disguised as scholarship never mentioned outcomes, results, or delivering value. It presumed the frameworks’ intrinsic value was what mattered, along with knowing them as thoroughly as the author.

There’s a faint echo of Max Horkheimer in the Zachman Framework: that if we categorize reality with enough intellectual discipline, the world will finally make sense. The Zachman Framework asserts that the totality of an enterprise can be rigorously divided and expressed through distinct architectural classifications. It asks you to take an unwise intellectual leap and is about as fun to read as a grand theorist’s 900-page dissertation that continually dares the reader to finish it.

In Defining Enterprise Architecture: A Practical Approach, we identified three essential responsibilities of Enterprise Architecture: Translate strategy into technology execution. Integrate policies from across the organization. Design solutions. It’s a straightforward list—useful and accurate. But it’s also incomplete. That's because doing these things requires more than just intent. It requires a structure and an approach. Foundational Constructs of Enterprise Architecture…

Enterprise Architecture, like any maturing discipline, is the product of evolving ideas—each a step toward translating strategy into technology execution. Since it is still an evolving discipline, it’s a good idea to know how we got to where we are. So before defining frameworks, methods, and methodologies in the next article, let’s look at their origins. We’ll explore the problems they addressed, how they evolved, and how they shape modern Enterprise Architecture.

I attended an EBC a few years ago at one of the big technology companies. After getting yelled at for an hour by a super-pumped guy, using his outside voice, about how the company works and its culture, we moved on to a much calmer session with a senior engineering leader. We had just heard in the previous session that the company’s software teams famously work without any standards, which, of course, everyone in tech already knew.

In addition to rules—which we covered in the article How Rules Translate Architectural Intent into Action—I use measures to make architecture requirements concrete. While rules state the specification, measures are used to determine effectiveness. By approaching architecture requirements this way, we gain structure with less rigidity. It gives us multiple ways to define and discuss what matters, and the linguistic flexibility to move between statements and questions to better articulate our intent.

In the article When Architecture Requirements Meet Organizational Politics, we discussed the need for architecture requirements and how they fit into the broader machinery of Enterprise Architecture. Now it’s time to work through what these requirements actually are and how to approach creating them. I recommend reading the article Effective Enterprise Architecture Principles—if you haven’t already—where we introduced the following structure:

We started with asset management and have now worked our way through principles and policies. All of this puts us on a trajectory that leads directly to establishing architecture requirements. I prefer to structure architecture requirements as rules and measures, which we will cover in the next few articles. But there are, of course, other ways to structure and define requirements.

We covered policy integration in the post Unstoppable Enterprise Architecture. That part of our discussion was about how to structurally insert Enterprise Architecture into an organization’s policy machinery and drive value through that intervention. But we still need to address policies specifically, and we will do that now. Again, let’s have a look at how a few of the major Enterprise Architecture approaches define and address policies:

In the post Key Steps for Effective Enterprise Architecture Programs we introduced the idea of a conventional structure for Enterprise Architecture methods, comprised of four parts within a hierarchy: We then focused on policy integration in the post Unstoppable Enterprise Architecture, emphasizing the value that Enterprise Architecture can provide, in a way that’s likely not addressed very well in a lot of organizations.

On any given day, I can scroll through my feeds and see posts about Enterprise Architecture. Most describe it as broad in scope, hard to define, and difficult to measure. Almost all will have an under...

In the post Defining Enterprise Architecture: A Practical Approach, we defined Enterprise Architecture as the discipline of aligning business strategy with the design and implementation of computer systems. We’ll call this Alignment and Focus. We’ve also established that there are three things we need to do: Translate Strategy into Technology Execution Integrate Policies from Across the Organization Design Solutions…

I recently reread a book on a popular Enterprise Architecture framework. I hadn’t finished it the first time because it read like watching a bad movie, in that you either leave or suffer through it, thinking it might get better. But this time I was determined to read it, and I had chosen the worst option. What Are We Supposed to Do, Exactly?