A Brief History of Architecture Frameworks, Methods, and Methodologies

The approaches that have shaped Enterprise Architecture tell the story of a discipline adapting over time to a changing enterprise.
By Ed Bednar

Enterprise Architecture, like any maturing discipline, is the product of evolving ideas—each a step toward translating strategy into technology execution. Since it is still an evolving discipline, it’s a good idea to know how we got to where we are. 

So before defining frameworks, methods, and methodologies in the next article, let’s look at their origins. We’ll explore the problems they addressed, how they evolved, and how they shape modern Enterprise Architecture.

But before diving into that history, it’s worth remembering that our instinct to bring order to complexity is as old as civilization itself.

Organize then Evolve: A Historical Disciplinary Lineage 

The Library of Alexandria,² founded around 283 BCE, sought to collect all of human knowledge. More than just a collection of scrolls, it was an infrastructure for scholarship, a classical antecedent to modern systems for classification, indexing, and collaboration.

It gathered Greek philosophy, Egyptian science, Persian mathematics, and Indian medicine—and, although lost to history, is still a lasting reminder of why we organize knowledge.

After we’ve built something physical, like a library, Stewart Brand’s How Buildings Learn illustrates what happens over time. Architecture isn’t frozen at design. It evolves, as in a building, as people inhabit it—sometimes for the better, sometimes not.

That same pattern—organize, then evolve—reappears in computing, where systems evolve through use, modification, and scale.

From Physical to Digital Systems and Software Complexity

Large enterprises and engineered systems evolve too. But because much of what we build is software, it feels malleable—easily changed, not cast in concrete.

A lawyer once asked me why a simple-sounding change was so costly since it was “just software.” In answering, I compared the program to a legal brief: change the frame late stage, restructure the logic, and you’ll have to rework the whole thing—even though it’s “just a Word document.” We ended up having a great conversation.

The increasing scale of software development drove the need for and rise of methodologies. But the effort to manage or avoid change played an even larger role.

The Engineering Roots of Enterprise Architecture

Computing systems based on the von Neumann architecture³ emerged in the mid-20th century. Over time, as computing shifted from hardware-centric to software-driven systems, complexity multiplied—as did the need for structured approaches.

To address these challenges, researchers and engineers at places like Bell Labs, NASA, the U.S. Department of Defense, and IBM began developing structured approaches to manage that complexity.

Each early attempt at structure, method, or process offers a glimpse of how we arrived at modern systems engineering. These disciplines evolved in parallel and overlapped, together also forming the foundations of modern Enterprise Architecture.

Systems Engineering as the Foundational Discipline

Systems Engineering,⁴ one of the first formal engineering disciplines, began as an approach for designing and managing complex physical systems. As these systems became dependent on software, the discipline expanded to address these developments.

It introduced structured phases (e.g., requirements, design) and artifacts to software development. It also framed the enterprise as a “system of systems” governed by structure and control.

As the foundation of modern software methodologies, it remains the root disciplinary substrate of architecture. But as software began to dominate these engineered systems, it required its own structure—what became the Software Development Life Cycle.

Structured Methods and the Rise of the SDLC

As software systems grew in scope and complexity, practitioners began formalizing the Software Development Life Cycle (SDLC)—a structured process defining phases from requirements to maintenance. 

Within that lifecycle, Structured Analysis & Design (SA/SD)⁵ emerged as a systematic method, emphasizing decomposition and the representation of systems through data flows.

SA/SD reinforced the divide between structure (frameworks) and process (methods)—a distinction that still underpins Enterprise Architecture and shaped my early fascination with these frameworks and methodologies.

Where Systems Engineering emphasized control and structure, SA/SD brought those principles into the realm of software design. Once structure and process were formalized, the next challenge was connecting those systems back to the enterprise itself.

Linking Business and Technology Through Information Engineering

Information Engineering⁶ linked organizational functions to data structures and system design. It viewed information as an enterprise’s core asset and incorporated techniques for data and process modeling. 

It was among the first methods to align business strategy with technology. Importantly, for architecture, it introduced the concept of domain modeling.

While Information Engineering linked data and systems, Business Process Reengineering shifted the lens to the processes those systems supported. Together, they expanded the architect’s view from systems and data to the enterprise as a strategic whole.

Process Transformation and Enterprise Integration

Around the same time, Business Process Reengineering⁷ emerged. It focused on redesigning business processes to more deeply achieve improvements enabled by technology.

It aligned with the rise of ERP systems and enterprise integration technologies, which led to dramatic shifts in enterprise systems. It also evolved amid a rapid shift toward offshore delivery models.

We gained the integration of value-chain analysis, process modeling, and enterprise capability mapping with information technology design, which still aligns closely with some conceptual modeling by architects (e.g., Business Architectures). 

These process-oriented views set the stage for a new kind of modeling—one that more closely simulates the real world.

Modeling the Enterprise with Object-Oriented Design

As technology caught up, modeling became both practical and powerful.

Object-Oriented Analysis & Design⁸ is a modeling approach that structures systems around objects—encapsulated entities representing real-world concepts and their relationships—which was formalized with the Unified Modeling Language (UML) and the Rational Unified Process (RUP).

One of the most powerful architecture tools is UML-based component modeling where components represent modular, replaceable units with provided and required interfaces. This modeling construct came from Object-Oriented Analysis & Design and is especially useful for architecture if approached in a simplified form.

As the concepts evolved, object-oriented programming languages like Smalltalk and C++ enabled the development of systems using this approach.

Model-driven design—often visual—enabled iterative refinement beyond what Rapid Application Development (RAD) approaches had done previously.

As modeling and engineering practices were developing, attention had also begun to shift toward the enterprises themselves—the structures, stakeholders, and abstractions behind the systems.

But someone had already tried to capture that complexity in a single schema.

The First Attempt at Enterprise Architecture: The Zachman Framework

That schema became the Zachman Framework,⁹ the first formal attempt to define Enterprise Architecture. It treated architecture as structured knowledge, a concept that later frameworks, like TOGAF, expanded upon.

The Zachman Framework is puzzling, though. It is essentially just a classification schema that organizes architecture representations by abstraction and stakeholder perspectives. But it also disguises its ideas within nearly impenetrable academic language.

It’s hard to argue Zachman is even an Enterprise Architecture framework—certainly not a method or methodology—yet it’s still cited, almost synonymously, with them, despite being barely usable.

Its importance, in my view, is only its ancestry and because of that, which we cover in the article, The Latin of Enterprise Architecture: The Zachman Framework Is Historically Significant but Rarely Used.

Still, Zachman’s attempt to impose order on architectural knowledge reflected the same instinct that later governance frameworks would apply to control and assurance.

Governance, Control, and the Operational Substrate

Control frameworks brought structure and accountability to enterprise technology management—focusing on control, service quality, and risk. Collectively, they supply much of the control and assurance mechanisms needed to integrate Enterprise Architecture with operational concerns.

We’ve already referenced a few of these frameworks in previous articles showing how they codify approaches for audit, control, and performance measurement. Notable examples include COBIT (control objectives), ITIL (service management), and ISO/IEC and NIST (risk and oversight).

From these governance frameworks, Enterprise Architecture gains much of its structure and substrate for asset management, policy integration, and architecture requirements.

TOGAF and the Attempt to Unify the Discipline

Out of all of these examples, and other, parallel efforts to structure, model, and govern technology came one attempt to unify them all: TOGAF.¹⁰

TOGAF, The Open Group Architecture Framework, is advertised as a process for defining and governing architectures. It’s a comprehensive enterprise architecture methodology that combines frameworks, methods, and governance into an iterative lifecycle for designing and managing enterprise systems.

In many ways, TOGAF unites all these threads—the formalization of structure, process, and control into one enterprise practice. It integrates frameworks (i.e., structure), methods (i.e., process), and governance (i.e., control) into a unified methodology. It has also led to a lot of the formalization of Enterprise Architecture in many large enterprises, especially in Europe. 

Its comprehensiveness, however, makes it difficult to define and terribly impractical to implement. It’s also intractable to use if you’re really trying to focus on making a computer do something.

Still, parts of it can be carved out and used effectively, which we explore in the article, How to Use TOGAF Without Becoming the Archetype of Its Adherents.

The Enduring Role of Structure in Enterprise Architecture

So that’s our brief tour through the history leading to where we are now. I hope this look at computing history, as it pertains to system engineering and Enterprise Architecture, has provided useful context.

The same instinct that organized ancient libraries now guides Enterprise Architecture as we continue to confront growing system complexity and scale. That enduring instinct—to impose structure on complexity—is what keeps Enterprise Architecture evolving.

In the next article, The Structure Behind the Practice: Enterprise Architecture Frameworks and Methods, we’ll define frameworks, methods, and methodologies—and begin our discussion on putting them into practice.

Notes:
1. Featured Image AI generated using OpenAI’s ChatGPT (GPT-5) with help from Google Gemini Flash 2.5.
2. Library of Alexandria (Wikipedia), accessed November 5, 2025.
3. Von Neumann (Wikipedia), accessed November 5, 2025.
4. Systems Engineering (Wikipedia), accessed November 5, 2025.
5. Structured Analysis (Wikipedia), accessed November 5, 2025.
6. Information Engineering (Wikipedia), accessed November 5, 2025.
7. Business Process Reengineering (Wikipedia), accessed November 5, 2025.
8. Object-Oriented Analysis & Design (Wikipedia), accessed November 5, 2025.
9. Zachman Framework (Wikipedia), accessed November 5, 2025.
10. TOGAF (Wikipedia), accessed November 5, 2025.