From time to time, Forrester publishes what we call accelerate content: material intended not to explain why something matters, but to help organizations actually do it. Our newly updated enterprise architecture policy falls squarely into this category.

We usually don’t blog about this kind of material. Policies are not aspirational. They are not trend‑driven. And they don’t lend themselves to neat two‑by‑two matrices. But in this case, the policy provides a useful opportunity to make two points that are worth stating explicitly.

First, Forrester is — and has always been — a full‑service analyst firm. We can discuss enterprise architecture (EA) as a strategic, executive concern, but we can also go all the way down to the mechanics of implementation: operating models, control points, metrics, and, yes, policy language precise enough to withstand audit scrutiny.

Second, and more interestingly, enterprise architecture remains one of the clearest examples in modern technology organizations of a staff function — and the way that role has evolved tells us a great deal about how EA itself has matured.

A Brief Detour: Why “LIne/Staff” Matters

The distinction between line and staff functions has fallen somewhat out of fashion, but it is hardly obsolete. Originating in military and early industrial organizational theory, the idea was straightforward: line functions execute the organization’s primary mission, while staff functions provide expertise, coordination, and oversight across those lines.

In IT terms, delivery teams — product teams, platform teams, operations — are line functions. They build, run, and change systems. Staff functions, by contrast, are accountable for coherence across those activities: finance, risk, security, compliance, and architecture.

This distinction matters because it explains a persistent tension around EA that has existed for decades. Architects are frequently asked to “own” outcomes they do not directly control, or conversely accused of being disconnected from delivery when they are deliberately structured not to be embedded in the line.

Enterprise Architecture As A Second‑Order Capability

The EA policy we’ve just published makes an important — and sometimes controversial — assertion: enterprise architecture is not primarily about designing systems. It is about creating and maintaining a holistic, systems‑level understanding of how digital and IT capabilities support the organization’s objectives, and using that understanding to influence decisions.

That framing places EA firmly in the category of staff functions whose value is second‑order but indispensable. Like finance or risk, EA does not “ship” functionality. What it produces instead is:

  • A shared vocabulary for digital and business capabilities.
  • A consistent view of portfolios, dependencies, and technical debt.
  • Guardrails that shape investment and design decisions before irreversible cost is incurred.

Seen through this lens, many long‑standing debates about whether EA “slows delivery” or should “just build things” start to look misplaced. Staff functions exist precisely to introduce friction where unconstrained action would be more expensive in the long run. They function as enabling constraints.

Why Policy Is Architecture’s Natural Artifact

One reason EA has sometimes struggled to assert itself as a staff function is that it has been overly identified with diagrams and models — valuable, but easy to ignore. Policy, by contrast, is one of the canonical instruments of staff authority.

A well‑designed EA policy does several things at once:

  • It defines scope unambiguously — what architecture does and does not govern.
  • It separates “what” from “how,” allowing practices to evolve without constantly reopening fundamental commitments.
  • It makes architecture auditable, which is increasingly non‑optional in regulated industries.
  • It anchors EA in the organization’s formal control framework, alongside risk management and financial oversight.

Notably, the policy also avoids a common trap: equating architecture with centralization. It explicitly allows for federated models, multiple architecture roles, and embedding architects with delivery teams — while still insisting on alignment mechanisms that preserve coherence.

That balance is very much a product of EA’s evolution over the past twenty years.

From Blueprinting To Governance — Without Becoming The “Architecture Police”

Modern EA operates in an environment of agile delivery, product orientation, and platform engineering. The staff role has become more subtle. Influence increasingly comes through:

  • Lifecycle policies (such as technology lifecycle management).
  • Automated controls embedded in platform architectures and delivery pipelines.
  • Portfolio‑level visibility into risk, debt, and redundancy.
  • Clear escalation and consequence models that are used sparingly but credibly.

Historically, EA emerged as a response to fragmentation: too many systems, too many technologies, and too little coordination. Early attempts often leaned heavily toward centralized design authority. That led to the unaccountable “department of no” and many EA failures. The more durable vision: EA’s job is to make sure the right people are in the right conversations at the right time, when the organization is faced with an “expensive to change” decision. And in these calls, to be the voice of institutional memory, to recall and advocate for principles: “our agreement has been X.”

One of the more nuanced aspects of the policy is its treatment of enforcement. It explicitly situates EA as a staff function— informing, challenging, and escalating where necessary — rather than attempting to directly command delivery teams. That positioning is not accidental; it reflects both regulatory realities and hard‑earned lessons from organizations where architecture overreached.

Why This Matters Now

We have argued elsewhere that enterprise architecture has never been stronger. This policy is, in some ways, an artifact of that maturity. When EA is working well as a staff function, it does not need to constantly justify its existence. Its presence is felt in:

  • Fewer “surprise” risks.
  • More deliberate technology choices.
  • Clearer accountability for technical debt.
  • Faster, not slower, decision‑making at scale.

Publishing this policy is not about suggesting that every organization should adopt it wholesale. Policies, by definition, must reflect context. Our templates are for tailoring. But we do believe it illustrates something important: EA has moved beyond evangelism. It is now part of the institutional machinery by which enterprises govern digital capability.

That may not be a viral message. But it is, in our view, a durable one.