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 (EA) 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 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’s hardly obsolete. Originating in military and early industrial organizational theory, the idea was straightforward: Line functions execute the organization’s primary mission; 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 don’t directly control or are conversely accused of being disconnected from delivery when they’re deliberately structured not to be embedded in the line.
EA As A Second‑Order Capability
The EA policy we’ve just published makes an important — and sometimes controversial — assertion: EA isn’t primarily about designing systems. It’s 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 doesn’t “ship” functionality. But it does create value and business outcomes. 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 or risk are 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’s 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 doesn’t govern.
It separates “what” from “how,” allowing practices to evolve without constantly reopening fundamental commitments.
It makes architecture auditable, which is increasingly mandatory 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 20 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 and 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 isn’t accidental — it reflects both regulatory realities and hard‑earned lessons from organizations where architecture overreached.
Why This Matters Now
We have argued elsewhere that EA 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 doesn’t need to constantly justify its existence. Its presence is felt in:
Fewer “surprise” risks.
More deliberate technology choices.
Clearer accountability for technical debt.
Faster decision‑making at scale.
Publishing this policy isn’t 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’s 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.
====P.S. To those who dismiss “ensuring the right conversations happen at the right time” as “soft benefits” or merely a “glue function”: I’d recommend revisiting Atul Gawande’s The Checklist Manifesto. One key finding of his was that a powerful form of checklist in construction is the submittal schedule, which exists for one purpose: ensuring the right people have the right conversations at the right time. Buildings stay up, not just because individual engineers did their jobs but also because a staff function forced the necessary interactions — including interactions that weren’t foreseen in initial planning. The construction industry cut build times by a third while increasing complexity, in part by getting the coordination right.
