Welcome to the foundational post in our deep-dive series on TOGAF (The Open Group Architecture Framework). Whether you’re an aspiring Enterprise Architect, a project manager, or an executive trying to understand the “why” behind your organization’s IT strategy, this guide is your essential starting point.
TOGAF is the world’s leading Enterprise Architecture (EA) framework, providing a structured approach to creating and managing an organization’s architecture. But before we explore its powerful methodology, we need to speak its language. This article will serve as your comprehensive dictionary, decoding the core TOGAF concepts and terminology that are crucial for passing the TOGAF certification and, more importantly, for successfully applying the framework in the real world.
Decoding the Core TOGAF Concepts
At its heart, TOGAF provides a standardized way of thinking about an enterprise. Here are the most fundamental terms you must master.
1. Architecture
In the TOGAF context, architecture is not just about buildings. It refers to the formal structure of a system, a blueprint that defines its components, their relationships, and the principles guiding its design and evolution. Think of it as the master plan for an organization’s structure, processes, and technology, ensuring all parts work together harmoniously to achieve a common goal.
2. Enterprise Architecture (EA)
Enterprise Architecture is the practice of applying a comprehensive and rigorous method to the business and IT landscape of an organization. It’s the strategic discipline that connects an organization’s business strategy, its operational model, and its technology landscape. An effective EA ensures that technology investments support business objectives, not just for today but for the long term.
3. Architecture Framework
An Architecture Framework provides a structured set of best practices, tools, and a common vocabulary. TOGAF is an example of an architecture framework. It defines what to do, how to do it, and provides a clear methodology—the Architecture Development Method (ADM)—to guide the process from start to finish. Without a framework, an EA effort can quickly become unstructured, inconsistent, and ultimately ineffective.
The Three Key Building Blocks of Your Architecture
This is where many new practitioners get confused. Understanding the distinction between these three terms is vital for any successful TOGAF implementation.
| Term | Definition | Analogy |
| Deliverable | A work product that is contractually specified and formally reviewed, approved, and signed off. A Deliverable is tangible. | The final, signed-off architectural blueprint handed to the construction company. |
| Artifact | A detailed work product that describes an aspect of the architecture. An Artifact is a smaller component that contributes to a Deliverable. | A specific floor plan, a list of electrical components, or a plumbing diagram within the blueprint. |
| Building Block | A reusable component of capability that can be combined with others to create an architecture. A Building Block can be a requirement, a specification, or a product/solution. | A pre-fabricated wall section, a standardized door frame, or a specific type of plumbing fixture. It’s a reusable part of the final building. |
In short, you use Building Blocks to create Artifacts, which are then organized and consolidated into a formal Deliverable.
The Four Pillars of Enterprise Architecture: The Domains
TOGAF organizes the entire EA landscape into four distinct, yet interconnected, domains. Understanding these domains is essential as the entire ADM is structured around them.
1. Business Architecture
The Business Architecture domain defines the business strategy, governance, organization, and key business processes. It answers the fundamental questions of what the business does and why. It’s the starting point for any architecture effort because it ensures that technology decisions are driven by genuine business needs.
2. Data Architecture
The Data Architecture domain describes the structure of an organization’s logical and physical data assets and the data management resources. It’s concerned with what data an organization needs, where it is located, and how it is managed. This domain ensures that data is a consistent, reliable, and accessible asset across the enterprise.
3. Application Architecture
The Application Architecture domain provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes. It focuses on how the organization’s applications work together to meet business needs, including integration and interoperability.
4. Technology Architecture
The Technology Architecture domain describes the hardware, software, and network infrastructure needed to support the deployment of business, data, and application services. It answers the question of with what technology the organization’s systems will be built and run. This includes everything from servers and operating systems to databases and communication networks.
