In the world of enterprise architecture (EA), TOGAF (The Open Group Architecture Framework) is one of the most widely adopted methodologies. At its heart lies the Architecture Development Method (ADM): a structured, iterative cycle that guides architects to conceive, build, govern, and evolve an architecture that aligns business and IT.

Although TOGAF’s full ADM contains more than just eight steps (there is a preliminary step, as well as a continuous Requirements Management activity), the core of the method is often described in eight phases (A through H). 

In this article, we walk through each of those eight phases: what they aim to do, how they interlock, and what deliverables or pitfalls to watch out for, with examples and metaphors to bring them to life.

The 8 Phases (A–H) of TOGAF ADM

Here is a quick list, before diving deeper:

Phase	Name	Objective in brief
A	Architecture Vision	Define scope, secure buy-in, sketch a high-level vision
B	Business Architecture	Model how the business must operate to deliver that vision
C	Information Systems Architecture	Define data + application architecture needed
D	Technology Architecture	Define infrastructure, platforms, and technical enablers
E	Opportunities & Solutions	Identify projects/solutions to realize the architectures
F	Migration Planning	Build a roadmap / plan to transition from baseline to target
G	Implementation Governance	Oversee implementation to stay aligned with architecture
H	Architecture Change Management	Manage evolution, respond to new requirements

Preliminary phase 

In the Preliminary Phase, the focus is on establishing the framework and capability needed to support enterprise architecture within the organization. This involves identifying required changes, defining how they will be implemented, and preparing the environment for the ADM cycle.

During this stage, TOGAF is tailored to the organization’s context, core principles are defined, existing capabilities are assessed, and integration with other frameworks or standards is considered. The goal is to ensure that the organization can adopt and sustain the architecture process effectively without being disrupted by future adjustments.

A key output of this phase is the Architecture Work Request, which clearly defines the scope, objectives, tools, and structures required to begin the architecture development process.

Phase A: Architecture Vision

In Phase A, you take the initial “Request for Architecture Work” and use it to clarify who cares, what matters, and why. The goal is to establish a high-level vision, define scope, and get stakeholder approval to move forward. You:

• Identify stakeholders, their concerns, and objectives
• Establish business drivers and constraints
• Propose an initial (sketch) of the target architecture, often a “light version”
• Define scope boundaries, assumptions, risks, and success metrics (KPIs)
• Prepare the Statement of Architecture Work (the go/no-go document)
• Secure formal approval to proceed

This phase is essential to avoid “big jumps in the dark.” It ensures alignment at the outset, so that subsequent phases do not stray into territory nobody asked for. 

Phase B: Business Architecture

The main objective of Phase B is to develop a target business architecture that defines the company’s structure and how the organization must function to realize the vision. Here you define the Baseline (where we are now) and Target (where we want to be) business architecture, and analyze the gaps between them. You cover:

• Business capabilities, organization structure, governance
• Business processes, value streams, roles
• Business rules, policies, and external constraints
• Stakeholder alignment, interfaces, and dependencies

Often you will rely on reference models or industry best practices to accelerate work. The output is a coherent business architecture specification and a gap analysis report. 

Phase C: Information Systems Architecture

Phase C focuses on designing the data and application architectures that work together to support business objectives. Whether you start with data or applications does not matter, the key is ensuring both are integrated and aligned with business goals.

Phase C is typically split or tackled in two parts:

1. Data Architecture: modeling how data is organized, flows, governance, metadata, logical/physical schemas.
2. Application Architecture: defining how software modules, services, APIs, and integrations must be structured to deliver business capabilities.

You again compare baseline to target, and perform gap analysis. You also specify application interfaces, data exchanges, and functional decomposition. The result is an architecture definition for data and applications that aligns with the business architecture. 

Note: The order of data vs application work can vary (you may start with data or application first).

Phase D: Technology Architecture

Technology Architecture defines the technology platforms, infrastructure, and enabling components. Now the architects translate the data + application needs into technology choices: servers, networks, middleware, runtime platforms, deployment, security, etc. You:

• Define baseline and target technology architecture
• Select reference models, toolsets, standards
• Consider performance, scalability, connectivity, availability, and constraints
• Do impact assessments (e.g. on latency, network, location)
• Finalize technical architecture aligned to prior phases

Essentially, this phase “grounds” the solution in realistic infrastructure and ensures the architecture is implementable in the existing or planned tech environment. 

Phase E: Opportunities & Solutions

Phase E focuses on identifying and assessing potential solutions that can meet business requirements. During this stage, architects develop a preliminary architecture roadmap, drawing on the gap analyses and outputs from Phases B, C, and D to outline how the target architecture can be realized. With the architectures defined, now you must find how to bring them to life. Phase E involves:

• Feasibility studies of alternative solution options
• Grouping of architecture building blocks into projects
• Performing value/cost/risk analysis
• Formulating high-level migration strategies
• Drafting an initial architecture roadmap
• Determining implementation constraints and sequencing

Essentially, this phase turns “what we want” into “what we could do next.” 

Phase F: Migration Planning

The goal here is to turn the roadmap into a detailed migration plan. Here you refine the roadmap from Phase E into a workable plan. That means:

• Defining transition architectures (intermediate states)
• Sequencing projects (which to do first, dependencies)
• Estimating cost, risk, and resource needs
• Aligning with change management and project governance
• Finalizing the migration plan and confirming readiness

You do rigorous prioritization and phasing to make deployment achievable.

Phase G: Implementation Governance

This phase oversees the implementation so that the delivered solutions conform to the architectural intent. During execution, the architectural oversight does not end; rather, you monitor, review, and guide:

• Ensure projects implement in accordance with architecture
• Conduct compliance assessments and audits
• Manage deviations, change requests, and remedial actions
• Interface with project management to resolve conflicts

This phase acts as a “guardian” of architecture quality, ensuring the vision is not lost. 

Phase H: Architecture Change Management

Finally, Phase H focuses on keeping the architecture relevant and responsive over time. In an evolving business environment, architecture cannot be static. Phase H ensures:

• Processes exist to identify and assess change requests
• Tools and metrics monitor architecture performance
• Impacts of changes are evaluated and fed back
• The architecture is updated (and new cycles of ADM may begin)

In effect, this phase institutionalizes continuous architectural evolution. 

The Continuous Phase: Requirements Management (Across All Phases)

Although not numbered among A–H, Requirements Management is a continuous activity that runs across all phases. Its role is to:

• Collect, document, prioritize, and manage requirements
• Ensure earlier assumptions remain valid
• Feed requirement changes into relevant phases
• Validate that architectural work remains aligned to them

This ensures the architecture evolves based on valid, traceable requirements rather than whims.

How the Phases Fit Together: Iteration, Feedback & the Architecture Cycle

The ADM is not strictly linear. The eight phases are often revisited, refined, or even “looped back” as new insights or changes arise. Each phase produces work-products, roadmaps, and governance checks that inform subsequent phases or earlier ones. 

Think of it like sculpting, you sketch broadly (A), refine structure (B, C, D), decide how to build (E, F), supervise the build (G), and adjust for reality (H), while always keeping an eye on the original requirements (Requirements Management).

Benefits & Key Pitfalls

Why use the eight-phase (A–H) ADM model?

• It enforces discipline: architects have clear roles, inputs, outputs, and checkpoints
• It aligns architecture work with business goals
• It enforces governance, quality, and consistency
• It enables incremental adoption, you can pilot a cycle rather than try a “big bang”

However, some pitfalls deserve attention:

• Over-engineering: trying to make all phases perfect before delivering anything
• Poor stakeholder engagement: skip buy-in in Phase A and you will pay later
• Rigid adherence without tailoring: ADM must be adapted to your context
• Ignoring change management: implementation will deviate unless governed

Conclusion & Next Steps

The 8 phases (A–H) of TOGAF’s ADM offer a powerful, modular roadmap for building enterprise architectures that deliver strategic value while managing complexity. But the real art comes in tailoring this roadmap to your organization’s maturity, scale, risk tolerance, and domain context.

Trends in the digital world today have shown that success is not just about having the latest tools. It is about designing systems that support business goals and governing them responsibly so they deliver value, stay secure, and remain compliant.

Two of the most respected global frameworks that help organizations achieve this balance are TOGAF and COBIT. While TOGAF focuses on how to design and structure enterprise architecture, COBIT ensures how to manage, control, and govern it effectively.

Together, they form a powerful combination that bridges strategy, technology, and governance.

What Is TOGAF?

TOGAF (The Open Group Architecture Framework) is a leading framework used for enterprise architecture (EA). It provides organizations with a structured approach to designing, planning, implementing, and managing their IT architecture so that technology aligns with business strategy.

At its core, TOGAF uses the Architecture Development Method (ADM), an eight-phase cycle that guides architects from vision to implementation and continuous improvement. The ADM ensures that every system, application, and data process supports the organization’s goals.

TOGAF helps organizations:

• Improve alignment between IT and business objectives.
• Reduce redundancy and duplication in systems.
• Increase interoperability across departments.
• Provide governance and structure to architecture development.

In short, TOGAF turns strategy into a clear architectural roadmap that ensures every IT decision serves a long-term purpose.

What Is COBIT?

COBIT (Control Objectives for Information and Related Technologies) is an IT governance and management framework created by ISACA. It provides organizations with a comprehensive system to manage and control IT processes, ensuring technology delivers measurable business value.

COBIT focuses on governance, risk management, compliance, and performance monitoring. It defines specific objectives, metrics, and maturity models that guide how IT operations should be designed, monitored, and improved.

As ISACA explains, COBIT helps enterprises:

• Align IT goals with business priorities.
• Manage risks and ensure regulatory compliance.
• Measure IT performance using key indicators.
• Strengthen cybersecurity and data protection.

In simple terms, COBIT ensures that IT systems are not only effective, but also controlled, secure, and auditable.

Key Differences Between TOGAF and COBIT

Although TOGAF and COBIT share a common goal, maximizing business value through IT, they focus on different aspects of enterprise management.

Aspect	TOGAF	COBIT
Purpose	Enterprise architecture design and transformation	IT governance, control, and compliance
Focus	Defines what to build and how to structure it	Defines how to manage and control IT
Orientation	Strategic and architectural	Operational and governance-oriented
Core Framework	ADM (Architecture Development Method)	Governance Objectives and Management Processes
Key Domains	Business, Application, Data, and Technology	Governance, Risk, Compliance, Performance
End Goal	Create a flexible and efficient architecture	Ensure IT delivers value and meets compliance

How TOGAF and COBIT Work Together

Instead of viewing TOGAF and COBIT as alternatives, leading organizations use them side by side. They complement each other in powerful ways:

Governance Meets Architecture

TOGAF defines how systems should be designed. COBIT ensures those designs follow proper governance, risk, and compliance policies. Together, they align IT execution with business oversight.

Strategy Meets Control

While TOGAF translates high-level business goals into architecture, COBIT ensures that architecture is implemented responsibly, with the right controls, metrics, and checks.

Continuous Improvement

TOGAF’s ADM encourages iteration and refinement. COBIT provides the tools to measure performance, assess maturity, and feed improvements back into the next architecture cycle.

Security and Risk Integration

In modern enterprises, security is a shared responsibility. TOGAF defines the security architecture, while COBIT ensures security policies are enforced and monitored for compliance.

Shared Value Creation

When applied together, TOGAF and COBIT enable organizations to build IT ecosystems that are efficient, secure, scalable, and accountable, the foundation of digital resilience.

When to Use TOGAF, COBIT, or Both

Scenario	Use TOGAF	Use COBIT	Use Both
You are redesigning enterprise architecture or migrating systems	✔		✔
You need better IT governance or risk control		✔	✔
You are aiming for compliance with audit or regulatory standards		✔	✔
You want to measure IT performance and accountability		✔	✔
You are pursuing end-to-end digital transformation	✔		✔

Many organizations adopt TOGAF first to structure their architecture, then integrate COBIT to govern, measure, and optimize it.

Benefits of Combining TOGAF and COBIT

• Stronger alignment between architecture and governance.
• Improved risk management and regulatory compliance.
• Better decision-making through clear accountability and metrics.
• Efficient resource utilization and cost savings.
• Enhanced cybersecurity posture through governance-backed architecture.

By blending TOGAF’s architectural strength with COBIT’s governance precision, businesses can build IT environments that are both visionary and dependable.

Conclusion

In the evolving landscape of enterprise IT, TOGAF and COBIT stand out as complementary frameworks that empower organizations to design smarter systems and govern them effectively.

• TOGAF helps define the “what” — a well-structured, business-aligned architecture.
• COBIT defines the “how” — the governance and controls needed to manage IT responsibly.

When combined, they create a robust foundation for digital transformation, security, and long-term business value. In short, TOGAF and COBIT are not rivals, they are partners in building resilient, well-governed enterprises ready for the future.

When companies grow bigger and more complex, they often struggle to keep their operations, data, and technology aligned with strategy. Enterprise Architecture (EA) is the discipline of planning how all the pieces, business processes, information, applications, and technology, fit together so the organization works efficiently and effectively.

One foundational way to understand EA is by breaking it into four types (or domains). Each domain captures a slice of an organization’s structure. Think of these as four lenses through which architects design how a company runs.

Let us walk through each domain, what it includes, why it matters, and how they all work together.

Business Architecture

1. This domain is concerned with how a company runs at the surface level: its mission, organizational structure, processes, rules, and services. It defines what the business does and how it does it.

It includes:

• Business goals and strategy
• Processes (for example, sales, customer service, order fulfillment)
• Organizational structure (teams, departments, roles)
• Business capabilities (what the company can reliably do)
• Rules, policies, and governance

If business architecture is off, then everything else (data, apps, tech) may support the wrong directions. It ensures the business side is clearly defined before investing heavily in systems.

Information / Data Architecture

1. This domain deals with how data flows through the organization: how information is collected, stored, managed, and used. It includes:

• Data models, schemas (how data is structured)
• Master data management (keeping data consistent)
• Data integration (moving data between systems)
• Metadata (data about data e.g. labels, descriptions)

Businesses that cannot access reliable data or that have “data silos” (data stuck in isolated systems) struggle with bad decisions. A good data architecture enables coherent, clean, and trustworthy data for analysis, reporting, and operations.

Application / Systems Architecture

1. This domain focuses on which applications or software systems exist, how they interact, and what functions they serve. What it includes:

• Application inventory (list of all software the organization uses)
• Integration and interfaces among applications
• Patterns like microservices, APIs, legacy vs modern systems
• Business logic (the rules encoded in software) 

If applications do not align or integrate well, work gets duplicated, handoffs fail, and efficiency suffers. Good application architecture ensures systems work together and support business needs without friction.

Technology / Infrastructure Architecture

1. This domain describes the technical foundation: hardware, networks, platforms, servers, cloud services, and other infrastructure components. It includes:

• Servers, data centers, cloud platforms, virtualization
• Network architecture (how devices are connected)
• Security layers, operating systems, middleware
• Infrastructure services (storage, messaging, backup)

Even if business, data, and applications are well-designed, without robust infrastructure, performance fails, downtime happens, or growth stalls. Technology architecture is about stability, scalability, and reliability.

How the Four Types Work Together

These four domains are not standalone, they are deeply interconnected. A change in one often ripples into the others. The value of this domain breakdown is that it helps architects reason clearly and manage complexity.

For example:

• If business strategy changes (Business Architecture), you may need new data types (Information Architecture), new software (Applications), and possibly upgraded infrastructure (Technology).
• If you adopt a new cloud service (Technology Architecture), it may require changes in software (Application Architecture), which in turn demands data migrations (Information Architecture).

Also, many EA frameworks use this four-domain model as their core structure. As enterprises mature, architecture teams use these domains to shape their work, communicate with stakeholders, and organize their deliverables.

Why These Domains Are Important (Even for Non-Tech Audiences)

Understanding these four types of architecture is useful if you are:

• A business leader or manager needing to oversee digital transformation
• A stakeholder in IT projects wanting clearer communication and less confusion
• A vendor or consultant proposing solutions, knowing which domain you are targeting helps explain impact
• A student or newcomer trying to get clear mental models of how large systems fit together

When everyone understands these four domains, it becomes easier to see where investment is needed (e.g. maybe the infrastructure is outdated, or perhaps application integration is broken).

Challenges and Real-World Considerations

While the four-domain model is powerful, a few cautions are worth noting:

• Overlapping concerns: Some systems or initiatives span multiple domains, security, for example, is relevant in all four.
• Organizational maturity: Companies with less mature digital practices may struggle to build strong architecture in all domains at once.
• Resource balancing: Investing equally in all domains may be unrealistic; prioritization is needed based on risk, ROI, and urgency.

Communication gaps: Domain-specific language can create silos; continuous alignment and translation between domains is key.

Conclusion

The four enterprise architecture systems, Business, Information, Application, and Technology, give a useful, structured way to think about how organizations plan, build, and evolve their operations. Each type focuses on a different slice of how everything fits together: how a business works, how data flows, how software operates, and how hardware supports it all.

Even if you are not a technologist, knowing these domains helps you see architecture as more than “IT stuff”, it is the blueprint for how a company works behind the scenes. When all four domains are aligned, digital transformation becomes clearer, more coherent, and less chaotic.

Enterprise Architecture (EA) is the discipline of aligning an organization’s business processes, technology, information, and governance in a coherent way so the business goals are supported by the IT strategy. But because organizations differ in size, industry, regulatory pressure, technical maturity, and other factors, many different EA frameworks have been developed. A good EA framework gives structure: helping you plan, document, execute, and govern architecture work. Below are some of the most commonly used frameworks, what makes them useful, and when they are most appropriate.

Classification of EA Frameworks

EA frameworks tend to fall into three main types:

• Comprehensive Frameworks: industry & domain-agnostic, covering the full spectrum of roles, stakeholders, domains, deliverables, governance, etc. 
• Industry Frameworks: tailored to a specific vertical (e.g. finance, government, telecom), with domain-specific reference models, regulatory compliance and stakeholder viewpoints already built in. 
• Domain Frameworks: focused on one aspect or domain (e.g. security architecture, cloud architecture, risk) providing deep methods & tools there. 

Organizations often customize (or combine) frameworks: using a comprehensive framework for overall structure, then industry or domain frameworks where deeper detail is needed. 

Key EA Frameworks in Use

Here are several frameworks widely used in practice, along with what they bring to the table.

Framework	Type/Primary Use	Strengths	Where It Fits Best	Considerations
TOGAF (The Open Group Architecture Framework)	Comprehensive	Strong in governance, well-defined method (ADM, or Architecture Development Method), covers business, data, application, technology domains. Widely adopted.	Organizations needing full lifecycle guidance, migration roadmaps, standardization. Good when you need a repeatable process and consistency.	Can be heavy/complex. Needs tailoring; full adoption takes time. Some parts may not be needed in smaller organizations.
Zachman Framework	Comprehensive	Very strong for visual taxonomy and stakeholder views (what, how, who, why, when, where). Helps ensure all viewpoints are considered.	Useful when clarity among many stakeholders is needed, or when documenting from many perspectives. For organizations emphasizing clarity and design consistency.	Not a process/methodology: it does not tell you how to build or implement architecture, only how to classify/model. May require pairing with another framework for implementation guidance.
FEAF (Federal Enterprise Architecture Framework)	Industry	Designed for government agencies; strong in compliance, performance, standardization, mandated views.	Governments or heavily regulated industries, or when working in the public sector with strict regulatory or policy constraints.	Less flexible; heavy on standardization. Might not adapt well to fast-moving or agile environments without flexibility.
DoDAF (Department of Defense Architecture Framework)	Industry	Rich in domains, views, and concern separation; supports complex, mission-critical systems integration.	Large organizations with distributed, complex systems (defense, aerospace, large government bodies) where integration and long lifecycles are common.	Complexity and overhead; might be overkill for simpler business settings. Documentation and work products can become heavy.
SABSA (Sherwood Applied Business Security Architecture)	Domain Framework (Security / Risk)	Gives detailed methods for risk, security architecture aligned to business strategy; strong for designing secure systems or governance.	When security/risk is a major domain (e.g. finance, healthcare, regulated industries), or when an organization needs a security framework integrated with its EA.	Focused heavily on one domain (security/risk):  might miss business or tech domains unless integrated with broader EA.
Integrated Architecture Framework (IAF)	Comprehensive	Broad inclusion of business, technology, information, infrastructure, security, with multiple abstraction levels. Useful in consulting/large enterprise contexts.	Enterprises needing alignment across many functions, or where consulting partners will guide adoption; situations requiring abstraction and detail layers.	May require customization; complexity. Requires organizational maturity to support many layers of abstraction.

What Makes a Framework “Good”

1. Governance & Stakeholder Engagement: how well it builds in oversight, roles, stakeholder communication, decision-making. Without this, architecture becomes documentation without impact.
2. Domains Covered: business, data/information, applications, technology, but also security, cloud, integration domains as needed.
3. Methodology/Process: the “how” of doing EA (e.g., TOGAF’s ADM) so that architecture is developed iteratively, validated, and delivered. 
4. Deliverables & Work Products: what artifacts, models, diagrams are produced, how much detail, and how useful for both technical and non-technical stakeholders. 
5. Fit & Adaptability: ability to be tailored to industry, domain, company scale, culture. A lightweight framework may be better for some, more rigorous for others.

Visualization & Clarity: ability of framework to help visualize complexity: relationships, dependencies, flows etc., in ways understandable across departments.

Choosing the Right EA Framework

When selecting or adopting an EA framework, these steps help:

• Clarify organizational goals and maturity: what is the problem you are solving? Regulatory compliance? Integration? Speed? Innovation?
• Start small: tailor the framework: you do not need to use every part of a large framework. Pick what fits.
• Ensure stakeholder buy-in: the leadership, business, and IT must see value. Without it, EA could wither.
• Measure outcomes & iterate: deliver value early (quick wins), monitor performance, adjust process.

Conclusion

Enterprise Architecture frameworks are tools to bring order, clarity, alignment, and governance to how technology, information, and business integrate in an organization. Popular frameworks like TOGAF, Zachman, FEAF, DoDAF, SABSA, and others serve different needs; some across whole organizations, some for specific domains like security or defense. The key is not choosing the “best” framework universally, but selecting one (or compositing a few) that fits your company’s scale, industry, goals, and maturity, and then using it adaptively.