Effective Enterprise Architecture Principles: From Policy Gaps to Actionable Direction

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.

But in describing that approach, I left out something important: not everything is policy driven.

Some things—perhaps many—are simply driven by what we want to do, ideally from strategy or at least formal objectives, but not always.

So we need to accommodate that missing piece in the creation of architecture requirements, which brings us to principles—or architecture principles, if you prefer.

In my view, principles need to be anchored in getting things done, which is to say they need to be actionable. But this is a challenge, given the abstract nature of most architecture principles you’ve probably encountered.

Why Enterprise Architecture Principles Matter

But before we dig into this part of enterprise architecture, let’s consider two reasons—though there are likely others—why it’s important to have Architecture Principles:

1. There are ways to create principles, in a structural and directional manner that frame architecturally significant interests that are not fully addressed by policies.
2. There’s that colleague we all work with who will say, “Your principles are just common sense, things that we already know,” who is also the same asshole who will say, “We need to go back to First Principles,” when things are on fire.

Let’s address both.

What Are Architecture Principles?

To get us going, I’d like to start by hearing from some actual experts on the definition of Architecture Principles:

TOGAF

Architecture Principles are the general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.

Gartner

Architecture Principles are a set of tenets and rules that constrain and guide how an organization’s technology architecture is designed and implemented.

Zachman

Architecture is a taxonomy of perspectives through which principles are implicit guidelines that emerge as constraints or rules that shape each perspective’s models. 

Conceptual vs. Practical Architecture Principles

A lot of times—perhaps most—architecture principles are essentially aphorisms like Buy vs. Build, Standards before Preferences, or Simplicity Is Better Than Complexity. I once made up one, Build to Run, that I still think was terrific even though it was useless.

I suppose that some architecture principles, stated in this manner, might be clever and helpful (e.g., Build to Run), depending on the organization. But if you take a conceptually driven approach to architecture principles—and enterprise architecture generally—don’t expect a warm reception from people who are actually responsible for getting shit done.

Principles vs. Policies in Enterprise Architecture

In order to align on what’s architecturally significant—what we want to create architecture requirements for—some, perhaps much, of that direction will come from policies, as we’ve discussed. But, as mentioned at the beginning, not all of it. 

Which brings us to an important thing about policies, which, simply put, is that they are just one construct we have to work with.

However, in an architecture purist’s sense, policies should be derived from principles. This is actually so common in enterprise architecture approaches that it’s almost universal. 

But it’s simply a trap, one that will encourage—even necessitate—overly conceptual principles. It also runs counter to policy integration, as we have defined it, where those policies come from across the enterprise, not just Enterprise Architecture.

Where Architecture Principles Actually Add Value

Do I really need a principle like Design for Security, as a catchall for policies that eventually distill into architecture requirements that specify things that for example, address input sanitization? I’ll go with no, but maybe that’s just me.

But when you define architecture requirements that are not based on policies, it’s a good idea to know what they are based upon, which is a good place to look for the need for principles. It’s also an interesting inflection point where architecture domains often intersect in interesting and peculiar ways.

Cross-Domain Architecture Principles

So let’s explore an example…

A Practical Example: Aligning Trust and Failure Domains

A principle that says, Align Trust Boundaries with Failure Domains, connects the security, infrastructure, and system domains in a context that probably isn’t expressly addressed by policies that come from multiple departments, as well as related controls. 

Here, we’re addressing trust boundaries that do not align with how systems can fail, where a compromise in one component (e.g., a privileged service account, an exposed API) could have a ripple effect across systems and production environments. 

Many security policies (and controls) handle slices of what this principle touches on. But they don’t collectively tie it all together architecturally.

Why Policies and Controls Fall Short

Digging a little deeper…

A policy might say Sensitive Data Must Be Encrypted in Transit or Network Segmentation Must Be Applied to Production and Non-Production Environments.

But these are point solutions, narrow and prescriptive. They address encryption, or segmentation, or access, but they don’t force the issue of thinking about how trust and failure interact.

Similarly, and contextually, most controls are typically scoped to technology implementations, addressing, for instance, firewall configurations, IAM rules, endpoint protection settings, or logging pipelines. They address protection but not uptime or availability. 

But why does this matter? 

Using Principles to Address Systemic Risk

Well, attackers often exploit resilience gaps (e.g., like taking down monitoring, which propagates into gaps in log aggregation, or worse). So why not use principles to directionally define things that are nonobvious and important instead of making statements that are obvious and not all that important—except in a conceptual sense?

Pragmatic Architecture Principles

If used in a sophisticated architectural manner, principles can organize and provide directionality for making a computer do something when that “something” is strategic—or just something we want to do—and is not already or sufficiently encapsulated in policies.

But, there are definitely other ways to approach principles.

An Alternative (and Less Useful) View of Principles

Let’s go back to Zachman—building on one of the definitions at the beginning—to summarize and more deeply explore another option:

So there are these models. They’re shaped by rules. Except the rules aren’t rules; they’re constraints. And the constraints just kind of emerge as implicit guidelines. But they come from principles, which live in perspectives which may lead to an architecture, or maybe just a process for turning an abstract idea into concrete realities, known as reification. 

Which leads me to the legendary and insightful words of Homer J Simpson: “Who’s doing what now?”

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