Navigating the Tension between Agile and Enterprise Architecture

Back in the early 2000s, I’m with my team in Texas when my phone rings. It’s my boss, and he’s not happy.

An all-day planning session for a new, major program in one of our largest organizations is supposed to be starting. But, instead, they’re waiting for me.

I wrap up quickly and head to the meeting. As I walk in, it’s clear my boss isn’t the only one upset. Everyone is.

One group is just frustrated because they believe I’ve wasted their time, even though I hadn’t known about the meeting. Another is infuriated, but for a very different reason: now that I’m there, their attempt to exclude Enterprise Architecture hasn’t worked.

As I take a seat, I notice the slide on the screen. It’s titled The Agile Manifesto. I don’t know what that means.

The Agile Manifesto: Values, Intent, and Real-World Limits

A few years prior, The Manifesto for Agile Software Development,² known as the Agile Manifesto, was written as a statement of values for a light-weight approach to building software.

Agile favors adaptability and speed over formalism, prioritizing human interaction and working software over rigid processes and extensive documented artifacts. Ongoing collaboration and a preference for responding to change over following fixed plans is central to the approach.

It works exceptionally well in certain contexts. But it becomes challenging when expanded beyond a few small, tightly coupled teams working in bounded settings.

Scaling Agile: When Autonomy Meets Organizational Complexity

Over time, a range of agile approaches has emerged, most sharing a common structure: small, cross-functional teams with significant autonomy.

Work is organized into short, time-boxed iterations, or sprints, often guided by frameworks such as Scrum that support planning and coordination.

Each team is expected to be fully equipped and accountable, owning outcomes from inception through delivery, demonstrating progress through incremental delivery of working software.

In the right circumstances, this model is highly effective. In large organizations, however, autonomy collides with scale and directionality, often placing Enterprise Architecture in a state of persistent tension with agile delivery teams.

What often gets missed is that these conflicts are not only structural, but also cultural, reinforced here by language that oversimplifies the matter.

Agile as a Manifesto: How Language Shapes Collaboration and Conflict

Linguistically, a manifesto declares rather than invites. It draws a line in the sand and dares others to cross it. Manifestos speak at the world, not with it, in a posture rarely well suited to large organizations focused on solving complex problems.

This language of proclamation competes with discursive collaboration, which, rhetorically, is both a manifesto’s great strength and also its central limitation.

Although I didn’t know what the Agile Manifesto was when I entered the meeting, I did, of course, know what manifestos are. So with that, plus reading the room, I knew where things were heading:

Agile was being used as a pretext to justify directionality that would not involve the rest of the organization, resulting in tension, to say the least.

But discourse allows ambiguity, revision, and the slow work of mutual understanding. It can be inefficient and frustrating, but it is the language of inquiry and collaboration required in complex domains like large-scale software development.

Enterprise Architecture depends on this form of discourse. It requires context, stakeholder alignment, negotiation, resolution, and sustained collaboration.

But understanding why the Agile Manifesto resonated in the first place requires examining more than just its language. We also have to look at the conditions that made that language compelling.

From SDLC to Agile: How Software Development Methods Evolved

Extreme reactions are often less innovations than responses to other extremes. One excess creates the conditions for its opposite, which may feel restorative but often carries the same absolutism it claims to reject.

In A Brief History of Architecture Frameworks, Methods, and Methodologies, we traced how early software development coalesced into Software Development Life Cycle (SDLC) approaches. These plan-based methods emphasized requirements, analysis, and documentation as a form of rigor meant to avoid costly downstream change.

These approaches served a real purpose, enabling achievements such as the software that guided the Apollo missions. But as languages, libraries, tools, and platforms evolved, the assumptions underlying those methods began to erode.

Also, as digital systems became more interactive and user-driven, rapid feedback became central to successful development. Teams could increasingly gather and respond to feedback in previously infeasible ways.

In that context, exhaustive specification began to look less prudent and more obstructive, even oppressive. Building first and adjusting later appeared to be the way forward.

But what emerged as a corrective to rigidity often encounters real limitations when applied to large, interdependent systems.

Agile at Scale: When Team Autonomy Meets Enterprise Complexity

In large organizations, agile struggles primarily with scale and complexity, which, like it or not, impose structural constraints across systems, projects, and teams.

Agile teams are expected to make decisions independently, yet many large organizations, especially in highly regulated industries, are structured to constrain decision-making. These are environments where critical systems, including those responsible for moving and safeguarding money, must be handled with particular care.

At scale, autonomy cannot function merely as a team preference. It becomes an organization-wide concern. Small, autonomous teams remain appealing, but specialized skills resist replication, especially in settings shaped by long-lived legacy systems.

Even in large organizations, deep knowledge of critical subsystems often resides with only a few individuals. In theory, expanding those teams would increase speed and resilience. In practice, doing so is often unrealistic and sometimes particularly unwise.

Paradoxically, it is actually where autonomy collides with scale that Enterprise Architecture becomes essential to successful agile delivery, although not a universally popular opinion.

Integrating Enterprise Architecture into Agile Delivery

In the post Defining Enterprise Architecture: A Practical Approach, we defined three focus areas for Enterprise Architecture:

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

We’ve also focused extensively on policy integration, which we treat as three closely related activities forming the core structure and substrate of Enterprise Architecture:

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

In practice, this work appears not as abstract governance but as a small set of persistent operational concerns.

Enterprise Architecture and Asset Management in Agile Sprints

Agile teams always work on assets. Those assets have structure and persistence, whether or not they are emphasized in the day-to-day rhythm of agile delivery.

New assets emerge continually, often aligned with sprints. Making asset creation and registration easy, ideally through self-service, helps Enterprise Architecture support the pace of agile delivery.

In practice, systems consist of multiple assets, including applications, data, infrastructure, security, and technology. (Technology assets include software, hardware, and services.) This rigorous structure provides the map for work done across agile development teams.

Asset management remains an architectural concern, but it must align with how teams operate rather than impose a separate cadence. Once assets are visible, the question shifts from what exists to under what conditions they must operate.

Enterprise Architecture in Agile Delivery

While asset management makes the enterprise legible, architecture requirements give it meaning by expressing policy as conditions and constraints. Because these requirements derive from organizational policy, this work is shaped more by planning than iteration.

But those requirements must still be implemented and verified. For agile teams, this work is not separate from delivery. It becomes part of sprint planning and execution, reflected directly in the backlog.

Those conditions and constraints ultimately surface in design decisions, where policy, assets, requirements, and delivery intersect.

Aligning Architecture Requirements with the Product Backlog

Solution design works best when it stays close to implementation and is shaped by delivery realities rather than abstract specification. It should occur in delivery programs and projects, where assets and architecture requirements meet operational realities.

Unfortunately for many Enterprise Architecture approaches, architectural designs developed in isolation from what teams build rarely prove useful. This is where my approach breaks from conventional ones like TOGAF, which insist on having an imaginary line between enterprise architecture and solution architecture.

While there are certainly times when design work needs to happen in a broader setting (e.g., to complement strategic planning), operating on a different time scale than the immediacy of project work to design solutions will likely be ineffective, and Enterprise Architecture is still responsible for making a computer do something.

Strategy vs Agile Execution: Aligning Long-Term Direction with Delivery

Strategy operates on a longer horizon than programs, projects, or sprints, setting direction rather than governing daily execution. It informs roadmaps and investment decisions that are chartered as programs. Those programs may be executed through agile or plan-based methods.

Strategy sets direction; agile governs execution. What strategy stabilizes, delivery continuously challenges, creating a persistent tension Enterprise Architecture must navigate, which requires close alignment and ownership of work that’s tied to delivery programs, including those following an agile approach.

Enterprise Architecture and Agile: Managing the Ongoing Tension

Many Enterprise Architecture approaches assume uncertainty can be designed away at a conceptual level, or, worse, ignored. However, it is difficult to believe that any architecture produced in isolation will simply endure unchanged over time.

In contrast, many agile perspectives instead treat constraints as temporary inconveniences or as things that should not exist at all. That view conflicts with policy integration and architecture requirements. It also conflicts with asset-management obligations such as periodic reviews and, dare I say, documented artifacts.

The way forward lies in working through the tension continually rather than resolving it. Not as a win–lose exercise, but through collaborative discourse.

This tension helps explain the importance of asset management, policy integration, and architecture requirements, which together make Enterprise Architecture practices nonnegotiable. That point is examined more fully in Unstoppable Enterprise Architecture.

I see value in both agile and plan-based approaches to software development. I hope you do as well.

Particularly in agile contexts, Enterprise Architecture occupies an enduring point of friction that does not disappear with better tools or stronger convictions. It must be mediated over time through discourse, not declaration in the form of manifestos.

Notes:
1. Featured Image AI generated using OpenAI’s ChatGPT (GPT-5) with help from Google Gemini Flash 2.5.
2. https://agilemanifesto.org/