When Architecture Requirements Meet Organizational Politics

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. Just be sure they’re specific and evaluable.

But now, because we’re talking about requirements, this is where enterprise architecture starts to get complicated—from both an organizational and a political standpoint.

Why Architecture Requirements Trigger Organizational Resistance

We’ve covered asset management and how to use assets structurally to align enterprise architecture with the entire organization—ownership, responsibility, and all. We also brought these ideas together in Unstoppable Enterprise Architecture, showing how to put them into practice.

But requirements are an assertion of control and oversight.

So, while maybe all of this sounds great, it could still feel like too much for your organization. And in reality, many enterprise architecture efforts can only lead by influence.

Sometimes that’s because the approach lacks the enabling structures we’ve been establishing (like asset management). But often—perhaps more often—leading by influence is all the organization as a whole will tolerate.

We’re about to find out.

Moving from Influence to Authority in Enterprise Architecture

It’s one thing to champion someone else’s policies; it’s another to be the mechanism for how—and possibly if—those policies get implemented across the enterprise.

This dynamic matters because our peer organizations will inevitably become dependent on enterprise architecture for the execution of their own policies—or at least a subset of them—which means they’re now dependent on, and, depending on the function, subject to enterprise architecture oversight.

So expect a range of reactions—not all favorable.

Also, as we filter through policies, many aspects will never translate into architecture requirements. While we may contribute to some of those (especially people- and process-related ones), they’re not explicitly the purview of enterprise architecture—which, in some cases, is just a polite way of saying they’re somebody else’s problem.

So, while it’s important to be collaborative when establishing and maintaining architecture requirements, it’s also important to be firm.

It’s also extremely important to establish these requirements in a rigorously objective way so that there are no misunderstandings. We’ll cover how to approach that in the measurements article.

Policy Collision, Domain Boundaries, and Organizational Power

As discussed in the article How Policies Shape Enterprise Architecture, policies rarely fit neatly within a single domain. They spill over—creating redundancies, crossovers, inconsistencies, and the occasional cross-domain conflict.

Those domains also tend to map to organizational structures and their leaders, which means we must navigate the people, power, and politics of the enterprise—which we examined in the article Structure and Substrate.

In other words, policy overlap isn’t just technical; it’s anthropologic as well.

Establishing Control Through Architecture Requirements

When we distill policies into architecture requirements, we’re deciding what makes the cut: what matters (i.e., what’s in and what’s out), what it means, and how that translates into action. We’re also doing this work operationally, which, in part, means we’re prioritizing our efforts. We, just like everyone else, do not have unlimited time.

Also, while this work is necessarily collaborative, establishing architecture requirements is fundamentally an enterprise architecture function. We’re basing them first on policies, then on principles, and asking for input and feedback along the way—but not for approval.

Ownership, Accountability, and the Enforcement of Requirements

As discussed in Maximizing Value in Technology and Architecture Assets, every asset must have an assigned owner. Now, not only are we putting requirements in place, we’re pairing those requirements with ownership and accountability, rooted primarily in policies.

In Effective Asset Classification for Enterprise Architecture Governance, we covered the tiered model for asset reviews. Those tiers are the structure within which architecture requirements (i.e., substrate) are applied and assessed.

So, while in the past, it might have been entertaining for some in technology to just complain about how ineffective enterprise architecture is, that’s about to become harder; detractors lose when requirements are grounded in policy and we have processes and methods in place that are woven into our regulatory and compliance posture.

With all of this, enterprise architecture is no longer a theoretical construct. Control has shifted.

We’re now firmly in our lane, equipped with the structure and substrate to function from a position of leadership.

The Inevitable Friction: Agile, Autonomy, and Resistance

That shift, as we’ve been discussing and building to, manifests, again, through defined, often policy-based architecture requirements.

But soon, we’ll add layers—processes and methods like architecture reviews and diagramming standards, which means we’re also on a collision course with some of the third-rail influences in many organizations, like Agile.

As the control elements of this approach tighten, many parts of the organization—perhaps most—will see the value, contribute to, and embrace enterprise architecture.

Others may follow the program but just not be overly excited about it.

Some, though, may be outright detractors. But, structurally, that detraction will increasingly become a challenging place to be, given the non-negotiability of the policy-driven approach.

So, everything is going to be fine. But don’t expect universal applause. 

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