Unstoppable Enterprise Architecture

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 underlying problematic theme of trying to find and effectively show the value of Enterprise Architecture within an organization.

I also regularly hear from colleagues who have suddenly found their Enterprise Architecture program losing influence because of a senior leadership change. For example, a new CIO may not find value in Enterprise Architecture and we’re not able to quantify and express that value effectively as a response.

This type of situation can occur for many reasons. We’re going to start with two, each focused on value:

1. Enterprise Architecture does not add value to the delivery of technology solutions.
2. The value Enterprise Architecture provides to the delivery of technology solutions is not apparent.

If you’re thinking, “Great, it’s the second one—just a messaging problem,” chances are it’s more than that.

This disconnect is because while some things are challenging to objectively measure and convey, many are not. And there is a lot more to having an enterprise-wide focus than just loosely representing the different needs from across the business.  

The thing is, an Enterprise Architecture program can go in several directions, but the mix should include tangible outcomes alongside the less tangible ones.

But if we want an Enterprise Architecture program that’s Unstoppable, we need to focus heavily on the former while also paving the way for the latter.

The Value Problem in Enterprise Architecture

In large organizations, Enterprise Architecture is essentially an attempt to view the enterprise as a whole, to balance the representations of varied stakeholders, and to juggle long-term strategic objectives with the immediate priorities of the business. Doing all of this effectively is challenging—for a lot of reasons—but mostly because it’s just really hard to do.

The “enterprise” part is especially challenging, both organizationally and politically. While Enterprise Architecture has its own lane, it’s also, by definition, in other people’s lanes as well. This encroachment on other people’s turf will inevitably cause friction. We touched on some of this in the post Creating the Structural Foundation for Enterprise Architecture.

What Makes Enterprise Architecture Effective

In the post Defining Enterprise Architecture: A Practical Approach, we established that there are three things we need to do to be effective with Enterprise Architecture. Here they are again: 

1. Translate Strategy into Technology Execution
2. Integrate Policies From Across the Organization
3. Design Solutions

There may be others in your organization, but let’s work with these three for now. 

And now, we will put those three things into action, starting with the second, Integrate Policies from Across the Organization.  

Why Asset Management Is Foundational to Enterprise Architecture

In the posts, Maximizing Value in Technology and Architecture Assets, Effective Asset Classification for Enterprise Architecture Governance, and The Role of Asset Management in Enterprise Architecture, we covered asset management and how to use assets structurally to align Enterprise Architecture with the entire organization from an ownership and responsibilities standpoint. Recall that the tiered asset model is the forcing function.

Policy Integration: The Missing Discipline in Enterprise Architecture

Large organizations tend to not be very good at policy integration, and Enterprise Architecture is in a unique position to address that challenge. Doing so is also a great way to concretely demonstrate the meaning of “Enterprise” in the name. 

Most Enterprise Architecture approaches treat policy in a manner that’s limited to architecture policies—you know, the ones that look great but maybe no one pays attention to.

While architecture policies are part of making Enterprise Architecture unstoppable, they are just one piece. That’s because when I say policy integration, I mean policies from across the entire organization—that is to say, the enterprise.

But what do I really mean by policy integration?

Well, policies can come from a lot of places in a large organization, likely beginning with InfoSec (Privacy, Security, and Compliance). But they can also originate from other areas, including Finance, Legal, HR, and Operations. There will also likely be a need for Enterprise Architecture policies, as well. 

What Is Architecturally Significant?

Have you ever read a dense policy document that’s a full-scale interpretation of regulatory compliance concerns with specified requirements? Or, a better question, have you ever done that and then made a computer do something that’s in line with that policy?

Those are not trick questions. Someone has to actually do that. . .

So, how do we integrate policies? 

Policy integration means cataloging, reconciling, and integrating enterprise-wide policies—and, where needed, distilling them into architectural requirements.

I like to call those requirements rules and incorporate measurement criteria for each that is systematic and obsessively objective. We will cover how to do this in future posts. 

It’s also important to be very clear that policy integration does not mean the policies from across the enterprise are being generally interpreted and/or that the responsibility for their compliance rests solely with Enterprise Architecture.

We’re simply carving out what is architecturally significant, codifying that into architecture requirements, and implementing processes that set those requirements into motion.

Turning Enterprise Policy into Architecture Requirements

So, we’re primarily focused on what can be distilled into architecture requirements, and those architectural requirements also typically align with nonfunctional requirements. Not exclusively, but mostly.

This work is also primarily focused on the technology side of the policies. It will likely include some of the process parts of the policies (e.g., confirming regular completion of penetration testing by asset type). But it probably won’t cover much, if any, of the people-related aspects (e.g., handoffs between development and deployment) unless those things are codified and automated.

With that in place, you also build architecture programs, taking into consideration the other two things we need to do—Translate Strategy into Technology Execution and Design Solutions. But you’re building those programs on a solid foundation that is likely not already done, or at least not already done well. You’re also doing that along with the structural forcing function of asset management, especially asset ownership.

How Enterprise Architecture Becomes Unstoppable

So what’s Unstoppable about this?

First and most importantly, we’re adding tremendous value by solving a complex puzzle most large organizations struggle with: effectuating policies. This work is also measurable.

Next up, though, is that after a few audit and examination cycles, Enterprise Architecture will be codified in the privacy, security, and compliance mechanisms the organization follows.

This means that Asset Management, Policy Integration, and Architecture Requirements will, in part, be used to demonstrate to regulators and auditors how the organization is positioned from a GRC standpoint—that is, Enterprise Architecture will be used to position the organization from a GRC standpoint. 

Lastly, you can build the rest of the Enterprise Architecture program from there. That includes the usual suspects like architecture reviews, technology selection, design standards, patterns, and whatever else you want to incorporate into the Enterprise Architecture program.

It also means that if you’re firmly rooted in the TOGAF way, for example, that’s perfectly fine. You can still do business architectures, conceptual things that may or may not matter, etc. But you will be doing those things—or whatever else you may bring to the table—with the foundational staying power and forcing functions provided by our three pillars of architecture oversight and governance: 

1. Asset Management
2. Policy Integration
3. Architecture Requirements

Bringing these three things together in a meaningful, measurable way creates immense value for large organizations—and it’s that value, reinforced by structural mechanisms, that makes Enterprise Architecture unstoppable.

Notes:
1. Image created with OpenAI’s ChatGPT (GPT-5).