Much of the prevailing narrative of Enterprise Architecture does not converge on its purpose, remaining largely abstract. And theory has a habit of dissolving when it encounters practice unless it is firmly grounded.
The Three Responsibilities That Define Enterprise Architecture
In 2025, the work documented here converged on three essential responsibilities of Enterprise Architecture, first articulated in Defining Enterprise Architecture: A Practical Approach:
- Translate Strategy into Technology Execution
- Integrate Policies Across the Organization
- Design Solutions
That convergence provides the structure for what follows.
The Foundation: Asset Management, Policy Integration, and Architecture Requirements
The second responsibility, Integrate Policies Across the Organization, breaks into three parts, which together form the foundation of Enterprise Architecture:
- Asset Management
- Policy Integration
- Architecture Requirements
The sections that follow revisit articles published over the year, grounding these elements in practice.
Asset Management as the Structural Backbone
The Role of Asset Management in Enterprise Architecture explains how a robust asset management model serves as the structural backbone for Enterprise Architecture. Maximizing Value in Technology and Architecture Assets then ties asset ownership and lifecycle rigor to improved organizational outcomes.
Asset management moves from structure to execution in Effective Asset Classification for Enterprise Architecture Governance, where asset ownership is made explicit and operational. This classification method puts the asset management model into motion, enabling governance and lifecycle management over time.
With that structural foundation in place, we move to developing architecture requirements based on enterprise-wide policies.
From Policy Integration to Measurable Architecture Requirements
How Policies Shape Enterprise Architecture explains that an organization’s policies should be the basis for architecture requirements. But those policies must be integrated, and the resulting requirements must be expressed in an implementable and measurable form.
To do this, we start with enterprise-wide policies, add principles where warranted, and turn them into rules and measures that collectively form architecture requirements.
How Rules Translate Architectural Intent into Action explains how domain-spanning policies can be reconciled into actionable architecture rules, offering concrete examples. The piece frames rules as the mechanism for turning architectural intent into specifications for measurable implementation.
A No-Nonsense Approach to Measurement in Enterprise Architecture Programs then examines how measures complement rules in operationalizing architecture requirements, showing both simple and nuanced ways to evaluate assets objectively.
Once architecture requirements become explicit and measurable, they also become visible. And visibility in large organizations typically has consequences.
The Organizational and Political Reality of Enterprise Architecture
The internet offers no shortage of material explaining the political complexities of Enterprise Architecture. It is inherently cross-functional, and putting measurable architecture requirements in place, aligned with asset management oversight, will likely create friction in large organizations, potentially even igniting turf wars.
In When Architecture Requirements Meet Organizational Politics, we explore how establishing architecture requirements inevitably involves navigating the political and power dynamics within organizations. The article underscores the importance of clear, objective requirements formed through collaboration.
Lastly, Calm Down and See the Bigger Picture—It’s Just Architecture reflects on real organizational scenarios to emphasize that architecture should be collaborative and pragmatic rather than rigid or mystical. It underscores the importance of clarity and consistency in architectural practice while insisting on the nonnegotiability of policy-based architecture requirements.
Navigating these organizational dynamics is not incidental to architecture work; it determines whether an architecture effort survives long enough to matter.
Making Enterprise Architecture Work in Practice
We wrap up Asset Management, Policy Integration, and Architecture Requirements with Unstoppable Enterprise Architecture. The article addresses common misunderstandings about Enterprise Architecture’s scope and value and argues for a more grounded, actionable definition of its role.
With the policy groundwork established, it makes sense to turn to the topic that dominates much of the Enterprise Architecture conversation: frameworks.
Frameworks, Methods, and Methodologies in Context
We begin the discussion on Enterprise Architecture approaches by establishing simple definitions for frameworks, methods, and methodologies in The Structure Behind the Practice: Enterprise Architecture Frameworks and Methods. Each is different, but in mainstream Enterprise Architecture dialogue they are typically grouped together and called frameworks.
From there, the discussion steps back. The article A Brief History of Architecture Frameworks, Methods, and Methodologies offers a measured historical survey showing how structured approaches for software development and systems engineering have evolved and influenced modern Enterprise Architecture.
The discussion then turns to the two most prominent Enterprise Architecture frameworks, which receive significant attention in mainstream Enterprise Architecture circles:
- How to Use TOGAF Without Becoming the Archetype of Its Adherents provides a critical analysis of TOGAF’s conceptual breadth and the risk it poses to practical Enterprise Architecture when applied dogmatically. It advocates a grounded, outcome-oriented use of TOGAF as a canonical set of architectural concepts.
- In The Latin of Enterprise Architecture: The Zachman Framework Is Historically Significant but Rarely Used, the enduring influence of the framework is examined, highlighting its intellectual underpinnings and limited practical adoption. It argues that conceptual completeness does not necessarily translate into everyday value for practitioners.
The section concludes with Agile and Enterprise Architecture Discourse, in Practice, which explores how Enterprise Architecture, often presumed to be at odds with agile, is actually central to making it work at scale.
Reconnecting Architecture to Execution and Design
A great deal of mainstream Enterprise Architecture orthodoxy incorporates an imaginary, unwise line between Enterprise Architecture and Solution Architecture. But this notional separation is counterproductive if your goal is, like mine, to make a computer do something.
What Comes Next for Enterprise Architecture in 2026
So, as we move into 2026, we will explore a range of topics in digital systems, systems engineering, and technology strategy. Through these topics we will demonstrate how to apply strategic thinking and architectural methods within those settings.
This approach allows us to ground the other two essential responsibilities of Enterprise Architecture, Translate Strategy into Technology Execution and Design Solutions, in a reality-based setting. It also provides a practical way to address architecture topics such as patterns, specific architectures, diagramming methods, and Architecture Review Boards.
From there, we will build toward a point where it makes sense to start from the top and work down, meeting in the middle between strategy and execution. We will also begin to layer in many strategic aspects of running technology organizations.
Over time, this body of work will cover enough topics across the architectural domains, including system, application, data, infrastructure, and security, to organize it into a formal methodology.
Closing Thoughts
This site, The Computer Is Going to Do SomethingTM, exists to explore architecture and systems engineering in a way that takes the work seriously without insisting on solemnity.
I aim to be clear, rigorous, and occasionally amused by the subject matter. So, if it entertains you, know that that’s intentional; if it entertains only me, that’s probably inevitable.
If you’re reading, thank you. It’s a privilege to write for you. And if you’d like to connect, I’d be glad to.
— Ed
The Computer Is Going to Do Something – Join an ongoing, practical examination of technology strategy, enterprise architecture, systems engineering, and technology operations.
Notes:
1. Image generated with Google Gemini (2025), adapted for editorial use.
Leave a Reply