What’s New in TOGAF 10? Key Changes and Improvements

The TOGAF Standard, 10th Edition—often called TOGAF 10—modernizes the way organizations adopt and apply Enterprise Architecture. Its most important change is not a complete replacement of the Architecture Development Method (ADM), but a restructuring of the standard into a more flexible, modular, and practical body of guidance.

TOGAF 10 separates stable framework concepts from specialized implementation advice. This makes it easier for organizations to select the guidance they need for a particular architecture initiative rather than working through one large, comprehensive document.

TOGAF 10 was first released in April 2022 and continues the TOGAF tradition of providing a vendor-neutral approach for developing, maintaining, governing, and using Enterprise Architecture.

1. A new modular structure

The most significant change in TOGAF 10 is its modular documentation structure.

Earlier editions, particularly TOGAF 9.2, presented much of the framework in a large, relatively unified document. TOGAF 10 divides the material into several layers, allowing the standard to evolve and be applied more selectively.

The main components are:

Component	Purpose
TOGAF Fundamental Content	Defines the stable concepts, terminology, core principles, and fundamental framework elements
TOGAF Series Guides	Provides practical, specialized guidance for applying TOGAF in particular situations
TOGAF Library	Contains additional material, emerging practices, white papers, and supporting resources

This structure distinguishes between what is broadly applicable across organizations and what must be adapted for a specific industry, architecture style, business problem, or delivery context.

TOGAF Fundamental Content

The Fundamental Content acts as the framework’s stable foundation. It includes concepts such as:

The purpose and scope of Enterprise Architecture
Fundamental terminology
The Architecture Development Method
Architecture Governance
Architecture Content and viewpoints
Architecture Capability
Enterprise Architecture principles
Stakeholder management
Architecture compliance and change management

This material is intended to remain relatively stable over time.

TOGAF Series Guides

The Series Guides explain how to apply the framework in specific situations. Examples include guidance related to:

Business Architecture
Security Architecture
Risk management
Digital transformation
Agile Enterprise Architecture
Information and Data Architecture
Value Streams
Architecture project management
Enterprise Architecture capability development
Technology reference models
Business scenarios

The Series Guides are expected to evolve more quickly than the Fundamental Content because organizations’ needs, technologies, and delivery methods change over time.

The TOGAF Library

The TOGAF Library provides a place for additional and emerging material. It can contain guidance that is useful but is not yet part of the stable core of the standard.

This creates a progression:

Fundamental concepts provide the stable framework.
Series Guides provide established, specialized practices.
Library material provides additional or emerging ideas.

This layered approach helps TOGAF remain durable without preventing it from adapting to new architectural practices.

2. Greater flexibility and easier customization

TOGAF 10 is designed around the idea that organizations should configure the framework rather than adopt it unchanged.

A government department, global bank, software company, university, and manufacturing business may all use TOGAF, but they will not need the same architecture processes, governance structures, deliverables, or review cycles.

TOGAF 10 therefore emphasizes:

Selecting only relevant guidance
Tailoring the ADM to the organization’s needs
Adjusting deliverables to the size and complexity of the initiative
Integrating TOGAF with other methods and standards
Using different levels of rigor for different types of projects
Combining strategic, operational, solution, and domain architecture practices

For example, a small product team may need a lightweight architecture vision, key principles, major risks, and a decision log. A regulated enterprise transformation may need formal architecture boards, detailed compliance reviews, capability maps, transition architectures, and extensive traceability.

Both approaches can be consistent with TOGAF if the organization deliberately configures the method to suit its context.

3. More practical and scenario-specific guidance

TOGAF 10 places greater emphasis on practical application. The Series Guides are intended to answer questions such as:

How should an organization establish an Enterprise Architecture function?
How can architects work effectively in an agile environment?
How should security concerns be integrated into architecture development?
How can architecture support digital transformation?
How should business capabilities and value streams be analyzed?
How can architecture projects be planned and governed?
How should information and data architecture be addressed?

This represents an important shift from explaining only what Enterprise Architecture is to providing more guidance on how architects can perform the work.

The TOGAF ADM remains the central development method, while the Series Guides help practitioners apply it to particular situations.

4. The ADM remains central—but is easier to adapt

TOGAF 10 does not discard the Architecture Development Method. The ADM continues to provide the main lifecycle for developing and managing Enterprise Architecture.

Its familiar components include:

Preliminary Phase
Phase A: Architecture Vision
Phase B: Business Architecture
Phase C: Information Systems Architectures
Phase D: Technology Architecture
Phase E: Opportunities and Solutions
Phase F: Migration Planning
Phase G: Implementation Governance
Phase H: Architecture Change Management
Requirements Management, which operates continuously throughout the cycle

The ADM is still useful for creating a logical connection between:

Business goals
Stakeholder concerns
Baseline and target architectures
Gaps and opportunities
Transition plans
Implementation governance
Ongoing architectural change

However, TOGAF 10 presents the ADM as a flexible and iterative method rather than a rigid waterfall sequence.

Architects may:

Begin with the phase most relevant to the problem
Revisit earlier decisions
Iterate between phases
Perform several phases in parallel
Use only a subset of phases
Apply the ADM at different levels of the enterprise
Repeat the cycle for a domain, portfolio, program, product, or solution

This flexibility is particularly important in environments where requirements, technology, and business priorities change frequently.

5. Improved support for Agile Enterprise Architecture

One of the most important practical improvements in TOGAF 10 is its stronger treatment of agile delivery.

Traditional architecture programs are sometimes criticized for producing large volumes of documentation before delivery begins. TOGAF 10 provides guidance for using architecture in shorter, incremental delivery cycles.

Agile-oriented application of TOGAF may involve:

Time-boxed architecture work
Lightweight deliverables
Incremental elaboration of the target architecture
Frequent stakeholder feedback
Architecture runway planning
Continuous backlog management
Just-enough governance
Architecture decisions linked to delivery increments
Collaboration between architects, product owners, engineers, and business stakeholders

Instead of attempting to define every detail of the future state upfront, the organization can define the strategic direction and key constraints, then refine the architecture as delivery progresses.

For example, an architecture team supporting a customer portal modernization might:

Define the business outcomes and architecture principles.
Establish a high-level target architecture.
Identify the first valuable delivery increment.
Define the minimum architecture needed for that increment.
Review technical and business risks.
Refine the architecture during subsequent iterations.

TOGAF 10 includes guidance on applying the ADM through agile increments and sprints.

6. Stronger alignment with digital transformation

Digital transformation often crosses traditional business and technology boundaries. It may involve:

New digital products
Platform-based business models
Cloud adoption
Data-driven decision-making
Automation and artificial intelligence
Customer experience redesign
Ecosystem partnerships
Continuous product delivery
Organizational and cultural change

TOGAF 10 provides more explicit guidance for using Enterprise Architecture in digital enterprises.

This helps architects connect:

Business model change
Customer and stakeholder value
Digital capabilities
Information and data
Technology platforms
Product delivery
Organizational change
Governance and risk

The emphasis is not simply on designing IT systems. It is on understanding how architecture can help an organization change its operating model and achieve measurable business outcomes.

A digital transformation architecture should therefore address more than applications and infrastructure. It may also need to describe:

Customer journeys
Value streams
Business capabilities
Product platforms
Data ownership
Digital operating models
Integration ecosystems
Security and trust
Organizational responsibilities

7. Better coverage of specialized architecture concerns

TOGAF 9.2 already supported many specialized architecture domains, but TOGAF 10 makes specialized guidance more visible and easier to access.

This is important because modern architecture work frequently requires expertise beyond the traditional Business, Data, Application, and Technology Architecture domains.

Examples include:

Security Architecture
Risk and compliance
Information Architecture
Digital Architecture
Business Architecture
Cloud Architecture
Solution Architecture
Integration Architecture
Data and analytics architecture
Architecture project management
Technology adoption
Enterprise agility

The modular structure allows this material to be developed independently without destabilizing the core framework.

It also allows an organization to assemble a tailored architecture practice. A company undertaking a cloud transformation may prioritize technology adoption, security, migration planning, and agile delivery guidance. A financial institution may place greater emphasis on risk, compliance, information architecture, and governance.

8. A clearer separation between the framework and its application

TOGAF 10 distinguishes more clearly between:

The framework, which provides common concepts and structures
The method, which provides a process for developing architecture
The guidance, which explains how to use the framework in specific circumstances
The content, which consists of the deliverables, building blocks, models, and artifacts created during architecture work

This separation improves clarity because it prevents every piece of specialized advice from appearing to be a mandatory part of the core framework.

It also reinforces an important principle: TOGAF is not intended to prescribe one identical architecture process for every organization.

9. Improved support for different organizational sizes

TOGAF 10 is intended to be usable by organizations with different levels of maturity.

Small organizations

A small organization might use TOGAF to establish:

A few architecture principles
A simple architecture vision
A lightweight baseline and target view
A prioritized roadmap
A basic review process
A small set of reusable templates

Large enterprises

A large enterprise may need:

Multiple architecture domains
Formal architecture governance
Architecture repositories
Reference architectures
Standards catalogs
Architecture review boards
Portfolio and program integration
Compliance controls
Transition architectures
Architecture contracts
Metrics and maturity assessments

TOGAF 10 supports both situations by separating essential concepts from optional or specialized guidance.

The result is not “less architecture” for smaller organizations. It is architecture scaled to the decision being made.

10. More emphasis on establishing an Architecture Capability

TOGAF is not only a method for creating architecture documents. It also addresses the creation and operation of an Enterprise Architecture capability.

An Architecture Capability includes the people, processes, governance, information, tools, and organizational arrangements required to perform architecture work effectively.

Important capability questions include:

Who owns Enterprise Architecture?
Which decisions require architecture review?
What authority does the architecture board have?
Which roles are needed?
How are architects assigned to initiatives?
How are principles established and maintained?
Where are architecture artifacts stored?
How are exceptions handled?
How is compliance measured?
How is the value of architecture demonstrated?

TOGAF 10 includes guidance for leaders and practitioners who are establishing or evolving an EA capability. This helps organizations treat architecture as an ongoing management capability rather than a one-time project.

11. Continued emphasis on governance

Architecture governance remains an essential part of TOGAF 10.

Architecture governance helps ensure that implementation decisions remain consistent with approved principles, standards, and target architectures.

It may include:

Architecture review boards
Compliance assessments
Architecture contracts
Standards and reference models
Exception management
Decision rights
Design authority
Risk escalation
Traceability from business objectives to implementation
Periodic architecture reviews

TOGAF 10’s flexible structure allows governance to be scaled. A small initiative may require only a design review and documented decisions. A major transformation may require formal approval gates and ongoing compliance monitoring.

The goal is not to create bureaucracy. The goal is to ensure that important architecture decisions are visible, intentional, and aligned with business outcomes.

12. More emphasis on outcomes and value

TOGAF 10 supports a more outcome-oriented view of Enterprise Architecture.

Architecture work should answer questions such as:

What business problem are we solving?
Which stakeholder outcomes matter?
How will success be measured?
What capabilities must change?
Which risks are being reduced?
Which investments are being enabled?
What constraints must delivery teams respect?
How quickly must value be realized?

This encourages architecture teams to connect their work to:

Revenue growth
Cost reduction
Operational efficiency
Regulatory compliance
Customer experience
Risk reduction
Organizational agility
Faster delivery
Improved information quality
Technology simplification

Architecture artifacts remain important, but they are means to support decisions and change—not ends in themselves.

13. How TOGAF 10 compares with TOGAF 9.2

Area	TOGAF 9.2	TOGAF 10
Documentation	More centralized and document-heavy	More modular and layered
Core framework	Combined with much of the supporting guidance	Separated into Fundamental Content and Series Guides
Customization	Supported, but practitioners often had to interpret and tailor a broad body of material	More explicitly designed for selective adoption and configuration
Practical guidance	Available across the standard and supporting publications	More visibly organized into focused Series Guides
Agile support	Available but less prominent	More explicit guidance for agile increments and sprints
Digital transformation	Addressed, but less central to the structure	More directly supported through specialized guidance
Evolution of content	Large-scale revisions could affect the main document	Series Guides and Library materials can evolve more independently
User experience	Could feel extensive and difficult to navigate	Easier to locate relevant guidance
ADM	Central lifecycle method	Still central, but explicitly positioned for iterative and context-sensitive use
Architecture Capability	Addressed as part of the framework	Supported through dedicated capability-focused guidance

The key point is that TOGAF 10 is evolutionary rather than a complete reinvention. Organizations familiar with TOGAF 9.2 will recognize many foundational concepts, including the ADM, architecture domains, governance, principles, viewpoints, and architecture content.

14. What has not fundamentally changed

TOGAF 10 does not mean that the ADM has been replaced or that previous architecture knowledge is obsolete.

The following ideas remain important:

Enterprise Architecture should support business change.
Architecture must address stakeholder concerns.
Architecture development is iterative.
Business, information systems, and technology concerns must be connected.
Architecture principles guide decisions.
Baseline and target architectures help expose gaps.
Migration planning converts architecture into an actionable roadmap.
Governance is needed to maintain alignment during implementation.
Requirements Management continues throughout the architecture lifecycle.
The framework should be adapted to the organization’s circumstances.

Organizations using TOGAF 9.2 do not necessarily need to abandon existing methods, templates, repositories, or governance structures. In many cases, they can map existing practices to the TOGAF 10 structure and selectively adopt new guidance.

15. Benefits of upgrading to TOGAF 10

Easier adoption

Organizations can begin with the core concepts and adopt specialized guidance when it becomes relevant.

Better usability

Practitioners can find guidance by topic instead of searching through one large body of material.

Greater relevance

The Series Guides address current architecture challenges, including agility, digital transformation, security, information, and business capabilities.

More scalable architecture

The framework can be applied with different levels of rigor depending on the initiative’s size, risk, complexity, and regulatory environment.

Faster response to change

New guidance can be added or updated without requiring a complete rewrite of the stable framework.

Better connection to delivery

Agile and incremental guidance helps architecture teams work more effectively with product, engineering, and transformation teams.

Stronger executive relevance

By emphasizing capability, governance, value, and implementation, TOGAF 10 helps connect architecture decisions with investment and business outcomes.

16. Potential challenges and limitations

TOGAF 10’s flexibility is a strength, but it also creates responsibilities for the adopting organization.

It does not provide a single turnkey implementation

Organizations must decide:

Which parts to use
Which deliverables to create
Which governance mechanisms to establish
How much documentation is appropriate
Which complementary methods and standards to integrate

More choice can create inconsistency

If every project tailors TOGAF independently, architecture practices may become inconsistent. Organizations should define a common minimum method and then allow controlled variation.

The Series Guides require judgment

A guide may provide useful advice without being directly applicable to every organization. Architects still need to evaluate the organization’s maturity, culture, risk profile, and delivery model.

It does not replace delivery methods

TOGAF can complement Agile, Scrum, project management, product management, IT service management, security standards, modeling languages, and regulatory frameworks. It is not a substitute for all of them.

It does not guarantee business value

A framework cannot compensate for unclear objectives, weak sponsorship, poor governance, insufficient skills, or ineffective execution.

17. How to adopt TOGAF 10 in practice

A practical adoption approach is to start small and build an architecture capability incrementally.

Step 1: Define the purpose

Identify why the organization needs Enterprise Architecture. Common objectives include:

Supporting a transformation program
Reducing technology complexity
Improving investment decisions
Establishing architecture governance
Enabling cloud or digital adoption
Managing regulatory risk
Improving interoperability
Creating a future-state operating model

Step 2: Identify the scope

Define whether the architecture effort applies to:

The entire enterprise
A business unit
A product line
A transformation program
A geographic region
A capability
A platform
A specific solution or domain

Step 3: Establish sponsorship and governance

Identify the decision-makers, sponsors, architecture authorities, and stakeholders who will approve or challenge architectural decisions.

Step 4: Define principles

Create a manageable set of principles covering topics such as:

Business alignment
Data ownership
Security
Reuse
Interoperability
Technology standardization
Cloud adoption
Privacy and regulatory requirements
Resilience
User experience

Step 5: Configure the ADM

Decide:

Which phases are needed
Which phases can be combined
Which deliverables are mandatory
How reviews will be conducted
How the method fits with Agile or existing project processes
How requirements will be captured and managed

Step 6: Select relevant Series Guides

Choose guidance based on the problem at hand. For example:

Use agile guidance for iterative product delivery.
Use security guidance for regulated or high-risk systems.
Use business capability and value-stream guidance for operating-model transformation.
Use digital guidance for platform and customer-experience initiatives.
Use architecture capability guidance when creating an EA function.

Step 7: Create a minimum set of deliverables

A useful initial set may include:

Architecture charter
Stakeholder map
Architecture principles
Architecture vision
Baseline architecture summary
Target architecture summary
Gap analysis
Architecture decisions
Risk and issue log
Roadmap
Governance and compliance plan

Step 8: Integrate with delivery

Ensure that architecture outputs influence real decisions, including:

Product backlogs
Program increments
Investment cases
Procurement
Solution designs
Technology standards
Implementation plans
Risk reviews

Step 9: Measure and improve

Review whether architecture is helping the organization achieve its goals. Useful measures may include:

Decision cycle time
Reuse of architecture building blocks
Reduction in technical debt
Compliance with principles
Delivery risk reduction
Time to approve designs
Number of architecture exceptions
Business outcomes achieved
Stakeholder satisfaction

18. A simple example

Suppose an organization wants to modernize its order-management platform.

A TOGAF 10-based approach could look like this:

Architecture Vision: Define the business goals, such as faster order processing, improved customer visibility, and lower operating cost.
Principles: Establish principles for API reuse, data quality, security, resilience, and cloud portability.
Baseline Architecture: Document the current applications, integrations, data stores, processes, and major constraints.
Target Architecture: Define the desired business capabilities, application services, information flows, and technology platform.
Gap Analysis: Identify obsolete systems, duplicated capabilities, data-quality issues, and integration limitations.
Opportunities and Solutions: Evaluate modernization options, including replacement, re-platforming, refactoring, and incremental migration.
Migration Planning: Create a roadmap with transition architectures and delivery increments.
Agile Delivery: Deliver the most valuable capabilities in time-boxed iterations.
Implementation Governance: Review solutions and manage exceptions against the target architecture.
Change Management: Revisit the architecture as business priorities, technology, and customer needs evolve.

The organization does not need to produce every possible TOGAF artifact. It needs enough architecture to make better decisions and guide implementation.

19. Guidance for organizations moving from TOGAF 9.2

A migration does not need to be treated as a complete restart.

Organizations can:

Inventory their existing TOGAF 9.2 processes and deliverables.
Map them to the TOGAF 10 Fundamental Content.
Identify which existing guidance belongs in a Series Guide category.
Review the organization’s agile, digital, security, and capability needs.
Replace outdated or overly generic material with more relevant guidance.
Define a tailored architecture method.
Keep existing templates that remain useful.
Update governance and role descriptions where necessary.
Train practitioners on the new modular structure.
Pilot the updated approach on a real initiative.

The goal should be improvement rather than compliance with a new document structure.

20. Frequently asked questions

Is TOGAF 10 a completely new framework?

No. It is a major restructuring and modernization of the TOGAF Standard, but many core concepts remain familiar, especially the ADM, architecture governance, principles, content, and iterative architecture development.

Has the ADM been removed?

No. The ADM remains the central method for developing Enterprise Architecture.

Must an organization use every Series Guide?

No. Organizations should select the guidance relevant to their needs and configure the framework accordingly.

Is TOGAF 10 only for large enterprises?

No. Its scalable and modular structure makes it suitable for small, medium-sized, and large organizations, as well as government and nonprofit environments.

Does TOGAF 10 replace Agile or Scrum?

No. TOGAF 10 can be adapted to work with Agile delivery methods. It addresses architecture concerns; it does not replace product or software delivery methods.

Does TOGAF 10 require ArchiMate?

No. ArchiMate can complement TOGAF by providing a modeling language, but TOGAF and ArchiMate serve different purposes.

Does TOGAF 10 prescribe specific software tools?

No. It is vendor-neutral. Organizations can use architecture repositories, modeling tools, collaboration platforms, and document systems that fit their needs.

Is TOGAF 10 primarily about producing documents?

No. Its purpose is to help organizations make better decisions, guide change, establish governance, and align business and technology. Documentation supports those goals but should be proportionate to the situation.

Conclusion

TOGAF 10’s defining improvement is its move toward a modular, extensible, and practical standard.

Its stable Fundamental Content provides the core framework. Its Series Guides provide focused advice for applying that framework to areas such as Agile, digital transformation, security, business architecture, information, and architecture capability. The TOGAF Library provides space for additional and emerging practices.

Compared with earlier editions, TOGAF 10 is easier to tailor, more supportive of iterative delivery, more relevant to modern transformation programs, and better organized for practitioners. Its central lesson is that Enterprise Architecture should not be adopted as a rigid checklist. It should be configured deliberately to support the organization’s goals, decisions, risks, and change agenda.