TOGAF - The Open Group Architecture Framework (1995)

Theory Publication Information

Citation Information

Why Was the Model Created?

During the 1990s, enterprise architecture discipline was emerging as organizations faced increasingly complex technology environments and business transformation challenges. The enterprise architecture field lacked standardized methods, terminology, and frameworks for architecture practice. Individual organizations developed unique architectural approaches without common standards. This created challenges: architects from different organizations could not easily share knowledge, methods varied widely, and organizations struggled to implement consistent architecture discipline.

The Open Group, a vendor-neutral industry consortium, recognized that standardized enterprise architecture framework would benefit industry globally. A common framework would enable knowledge sharing across organizations, establish terminology standards, define repeatable methods for architecture development, and enable certification and professional development in enterprise architecture discipline. The Open Group created TOGAF to establish open standard for enterprise architecture that organizations worldwide could adopt.

TOGAF was initially derived from the US Department of Defense TAFIM (Technical Architecture Framework for Information Management) framework, adapted for commercial sector use. TOGAF has evolved through multiple versions since 1995, expanding to incorporate lessons learned, additional architectural domains, and industry best practices. TOGAF became the dominant enterprise architecture framework, with over 100,000 TOGAF professionals reported as holding certifications globally (figure reported by The Open Group, as of roughly 2022).

Core Concepts and Definitions

TOGAF centers on several core concepts:

• Enterprise Architecture:A comprehensive view of organization’s structure supported through four architecture domains: Business, Data, Application, and Technology. Architecture provides a strategic blueprint aligning business and technology decisions.
• Architecture Development Method (ADM):Iterative, cyclic process for developing enterprise architecture. ADM comprises a Preliminary Phase plus eight lettered phases (A - Architecture Vision, B - Business Architecture, C - Information Systems Architectures, D - Technology Architecture, E - Opportunities & Solutions, F - Migration Planning, G - Implementation Governance, H - Architecture Change Management), with Requirements Management operating as a cross-cutting activity throughout the cycle.
• Architecture Content Framework (ACF): Structured model describing architecture work products, artifacts, and deliverables. ACF provides comprehensive catalog of architecture elements and their relationships.
• Enterprise Continuum: Framework categorizing all artifacts in organization, ranging from foundational assets through solutions. Enterprise Continuum enables reuse of architecture components across organization.
• Reference Models: Pre-built architecture models providing foundation for common architecture domains. Reference models enable faster architecture development.
• Architecture Repository: Centralized repository storing all architecture artifacts, models, and documentation. Repository enables knowledge management and artifact reuse.
• Stakeholder Management: Systematic approach to identifying, analyzing, and engaging stakeholders throughout architecture development. Stakeholder engagement ensures architecture addresses organizational needs.

What Does the Model Measure?

TOGAF is a prescriptive enterprise architecture framework and method specification rather than a psychometric measurement model. It does not define latent constructs or validated scales. Instead, it structures how organizations describe, develop, and govern their architectures.

Evaluation activities commonly organized through TOGAF include:

• Architecture maturity:Maturity-model style assessments (often TOGAF-aligned, using frameworks such as ACMM or the Architecture Capability Framework) characterize how developed an organization’s architecture practice is.
• ADM phase completeness: Whether each Architecture Development Method phase has produced its prescribed deliverables and artifacts.
• Stakeholder concern coverage: Whether identified stakeholder concerns are addressed by architecture viewpoints and views.
• Architecture compliance: Whether proposed solutions conform to published architecture principles and standards.

Source note: Content in this article reflects widely documented descriptions of TOGAF Standard Version 10.0 (2022) and prior versions as published by The Open Group, together with commonly cited secondary treatments. Direct page-level verification against the Standard document set has not been performed for every claim.

Preceding Models or Theories

TOGAF built upon and extended several prior architectural approaches:

• TAFIM (Technical Architecture Framework for Information Management, DoD 1994): TOGAF was directly derived from TAFIM, adapting military architecture framework for commercial sector use. TOGAF maintained TAFIM’s core principles while extending for broader applicability.
• Zachman Framework (Zachman, 1987): Early enterprise architecture framework emphasizing multiple stakeholder perspectives. TOGAF incorporated Zachman’s perspective-based architecture approach.
• Systems Engineering Practices (IEEE, 1980s-1990s):Systems engineering discipline provided foundation for TOGAF’s systematic architectural approach.
• Quality Frameworks (ISO 9000, CMM, 1990s):Quality and capability maturity approaches informed TOGAF’s emphasis on repeatable architectural processes.
• Business Process Reengineering (Hammer & Champy, 1993): Business process improvement discipline informed TOGAF’s business architecture domain.
• Information Technology Library (ITIL, 1989 onwards): IT service management framework provided context for technology architecture and operations disciplines.

Describe The Model

TOGAF provides comprehensive enterprise architecture framework enabling organizations to design, develop, and implement business and technology architecture through iterative Architecture Development Method combined with content framework, reference models, and repository infrastructure.

Architecture Development Method (ADM)

TOGAF’s core method is the Architecture Development Method, organized as an iterative cycle comprising a Preliminary Phase and eight lettered phases (A through H), plus Requirements Management as a cross-cutting activity that operates throughout the ADM:

• Preliminary Phase: Establish architecture capability, define scope and constraints, secure sponsorship and resources for architecture work.
• Phase A - Architecture Vision: Develop high-level vision of architecture change, define business drivers, identify stakeholders, establish architecture principles and governance framework.
• Phase B - Business Architecture: Develop detailed business architecture describing organizational structure, value chain, business capabilities, and business requirements.
• Phase C - Information Systems Architectures: Develop Information Systems Architectures (comprising Data Architecture and Application Architecture) to support the agreed Architecture Vision.
• Phase D - Technology Architecture: Develop technology architecture describing technology infrastructure, standards, and platforms required to support applications and data.
• Phase E - Opportunities & Solutions: Identify transition opportunities, consolidate project list, identify dependent projects, and prioritize implementation.
• Phase F - Migration Planning: Develop implementation and migration plan showing sequencing and dependencies for transition from current to target architecture.
• Phase G - Implementation Governance: Define governance structures, establish monitoring mechanisms, and manage architecture realization during implementation.
• Phase H - Architecture Change Management: Establish continuous monitoring and architecture change management processes ensuring architecture remains relevant and effective.
• Requirements Management: A cross-cutting activity operating throughout the ADM that manages architecture requirements throughout the cycle. Per the TOGAF Standard, Requirements Management is not a numbered phase but a continuous activity at the center of the ADM cycle.

Architecture Content Framework (ACF)

TOGAF ACF describes comprehensive set of architecture work products, catalogs, matrices, and diagrams produced during ADM phases. ACF includes:

• Catalogs: Structured lists of architecture elements (organizations, actors, applications, technology components, data entities). Catalogs enable systematic inventory of architecture components.
• Matrices: Tabular representations showing relationships between architecture elements (application-business capability matrix, business function-organization matrix, technology-infrastructure matrix). Matrices enable traceability and gap analysis.
• Diagrams: Visual representations of architecture including organizational charts, business process diagrams, application architecture diagrams, system context diagrams, technology architecture diagrams. Diagrams provide visual understanding of architecture.
• Documents: Narrative descriptions of architecture vision, principles, business requirements, architecture specifications, migration plans, governance frameworks. Documents provide detailed guidance and decision rationale.

Enterprise Continuum

TOGAF Enterprise Continuum provides framework for categorizing all organizational assets from foundational through specific:

• Foundation Assets: Generic, reusable components and patterns applicable across organizations. Includes TOGAF reference models, architecture patterns, and best practices.
• Common Systems and Services: Assets applicable across specific industry sector or industry domain. Includes industry-specific reference architectures and standards.
• Organization-Specific Assets: Assets specific to particular organization. Includes organization architecture standards, governance frameworks, and approved solutions.
• Solution Implementations: Specific projects and implementations tailored to particular business situation. Includes system implementations and custom solutions.

Key Architectural Domains

The TOGAF Standard identifies four architecture domains that are commonly accepted as subsets of an overall Enterprise Architecture:

• Business Architecture: Defines the business strategy, governance, organization, and key business processes. Establishes business context for the other architecture domains.
• Data Architecture:Describes the structure of an organization’s logical and physical data assets and data management resources.
• Application Architecture: Provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
• Technology Architecture: Describes the logical software and hardware infrastructure capabilities and standards required to support the deployment of business, data, and application services, including IT infrastructure, middleware, networks, communications, processing, and standards.

Within the ADM, Phase C (Information Systems Architectures) develops the Data Architecture and Application Architecture domains together, while Architecture Governance and stakeholder management are supporting capabilities exercised across all domains rather than domains in their own right.

Main Strengths

• Comprehensive framework: TOGAF provides complete framework covering architecture development method, content framework, reference models, and governance. Framework addresses all aspects of enterprise architecture.
• Iterative, cyclic method: ADM iterative approach enables continuous refinement and learning. Cyclic method adapts to changing business requirements.
• Industry standardization: TOGAF became industry standard enabling knowledge sharing and professional development. Over 100,000 TOGAF certified professionals as of 2022.
• Vendor-neutral approach: TOGAF independent of specific vendors or technologies. Framework applicability across diverse technology landscapes.
• Extensive supporting materials: Numerous case studies, implementation guides, and supplementary materials support TOGAF adoption and implementation.
• Broad reported adoption: TOGAF is reported as adopted by thousands of organizations across industries. Published success stories are largely practitioner- or vendor-authored; systematic independent evaluation of framework effectiveness is limited.

Main Weaknesses

• Complexity and learning curve: TOGAF framework is comprehensive and detailed requiring significant effort to master. New practitioners require extensive training.
• Documentation burden: TOGAF-compliant architecture development requires extensive documentation and artifact creation. Documentation burden increases time and cost.
• Rigid structure: While iterative, TOGAF ADM provides structured phases that some organizations find constraining. Organizations with different culture may struggle with structure.
• Certification focus: Heavy emphasis on TOGAF certification creates perception that framework is primarily for certification rather than practical architecture work.
• Technology evolution pacing: Technology changes faster than TOGAF standards can be updated. Framework reference models may become dated.
• Implementation variation: TOGAF adoption and implementation varies widely across organizations. Inconsistent implementation limits standardization benefits.
• Agile tension: TOGAF structured approach can conflict with agile development practices. Integration with agile methods requires careful design.

Key Contributions

• Advanced enterprise architecture as discipline: TOGAF helped legitimize enterprise architecture as a structured professional discipline and created a large-scale certification program. Prior frameworks (notably Zachman 1987 and TAFIM) had established earlier groundwork.
• Standardized architecture methods: TOGAF ADM provided repeatable method for architecture development. Method standardization enabled knowledge sharing and best practice dissemination.
• Created architecture content framework: TOGAF ACF established comprehensive catalog of architecture work products and artifacts. Content framework provides detailed guidance for architecture development.
• Enabled architecture reuse: TOGAF Enterprise Continuum enabled systematic reuse of architecture components. Framework enabled organizations to build on prior work rather than starting from scratch.
• Fostered global community: TOGAF certification program created global community of enterprise architects. Community enables knowledge sharing and professional networking.
• Influenced government and industry policy: TOGAF principles influenced Federal government, major corporations, and industries. Framework adoption shaped IT architecture policy globally.
• Enabled vendor-neutral discussion: TOGAF provided common language for discussing enterprise architecture across vendors and organizations. Common terminology enabled better communication.
• Continuous evolution: TOGAF has evolved through ten major versions since 1995, incorporating lessons learned and responding to industry changes. Evolution demonstrates framework viability and commitment to improvement.

Internal Validity

TOGAF is a prescriptive framework and method specification rather than an empirical theory, so it is not subject to construct-validity testing in a psychometric sense. Considerations typically raised about its internal consistency include:

• Logical coherence: The argument that systematic architecture discipline improves organizational IT outcomes is logically sound. Method discipline should improve consistency and decision quality.
• Comprehensive coverage: Framework comprehensively addresses architecture from business through technology domains. Comprehensive approach addresses multiple interconnected concerns.
• Iterative design: ADM iterative approach enables continuous learning and refinement. Iteration supports organizational adaptation.
• Stakeholder engagement: Framework emphasis on stakeholder identification and engagement reflects established best practice. Stakeholder involvement improves architecture acceptance.
• Governance foundation: Framework emphasizes governance infrastructure ensuring architectural decisions are made systematically. Governance improves decision traceability and accountability.
• Widespread adoption as circumstantial support:Widespread organizational adoption and the size of the TOGAF certification community are sometimes cited as circumstantial evidence of the framework’s usefulness, though adoption can also reflect vendor and certification dynamics rather than demonstrated effectiveness.

External Validity

External validity considerations concern generalizability of TOGAF across diverse organizational contexts:

• Global adoption: TOGAF adopted across industries, sectors, and geographies. Global adoption demonstrates framework applicability across diverse contexts.
• Scalability: TOGAF successfully applied in organizations ranging from small enterprises to global corporations. Framework scalability accommodates diverse organizational sizes.
• Industry applicability: TOGAF applied in financial services, healthcare, government, manufacturing, and other industries. Framework proves applicable across sectors.
• Cultural variation: TOGAF adopted in organizations across different national cultures and business cultures. Framework adapts to cultural variation.
• Technology diversity: TOGAF applied in organizations with diverse technology environments from legacy to cloud-native. Framework accommodates technology diversity.
• Agile integration challenges: Organizations adopting agile methods report challenges integrating TOGAF structured approach. Framework adaptation required for agile environments.
• Implementation variation: TOGAF implementation maturity varies significantly across organizations. Some organizations achieve framework benefits while others struggle with implementation.
• Business model dependence: Framework effectiveness depends on organizational commitment to architecture discipline. Organizations lacking commitment struggle with TOGAF implementation.

Relevance to Technology Adoption

TOGAF addresses technology adoption by establishing that technology decisions should align with enterprise architecture and organizational strategy rather than being made independently. TOGAF requires organizations to develop technology architecture based on business requirements, assess technologies against architecture standards, and acquire only technologies supporting architecture vision. This enables managed technology adoption with clear business alignment.

Barriers to Architecture-Aligned Technology Adoption Identified

• Lack of architecture discipline: Organizations without mature architecture practice make technology decisions independently without strategic alignment. Absence of architecture discipline leads to fragmented technology landscape.
• Business-technology disconnect: Technology decisions may not align with business strategy or business requirements. Disconnect leads to technology investments not supporting business needs.
• Governance gaps: Technology acquisitions may bypass governance processes. Governance gaps allow non-compliant technology acquisitions.
• Legacy system constraints: Existing systems may constrain technology adoption choices. Legacy system dependencies limit architecture options.
• Insufficient stakeholder engagement: Technology decisions made without adequate stakeholder input may lack organizational support. Stakeholder resistance slows adoption.
• Inadequate change management: Technology adoption without change management support fails to achieve adoption. Change management gaps reduce adoption success.
• Cost and resource constraints: Architecture-aligned technology adoption requires investment in architecture work. Resource constraints may limit architecture practice investment.

Leadership Actions the Framework Prescribes

• Develop enterprise architecture capability: Establish architecture function with trained architects and documented processes. Architecture capability provides discipline for technology decisions.
• Define technology architecture: Develop technology architecture aligned with business strategy defining target technology platforms and standards. Technology architecture provides baseline for technology decisions.
• Establish architecture governance: Create governance structures and decision processes ensuring technology acquisitions conform to architecture. Governance ensures architectural compliance.
• Engage stakeholders systematically: Identify and engage stakeholders throughout architecture and technology adoption process. Stakeholder engagement improves adoption outcomes.
• Develop migration planning: Create realistic plans for transitioning from current to target architecture. Migration planning enables orderly technology adoption.
• Manage business-technology alignment: Establish structures connecting business strategy to technology decisions. Alignment ensures technology supports business objectives.
• Plan change management: Develop comprehensive change management strategy supporting technology adoption. Change management increases adoption success and organizational readiness.
• Monitor and refine: Continuously monitor technology adoption outcomes and architecture alignment. Monitoring enables refinement of architecture and adoption strategies.

Following Models or Theories

TOGAF has evolved through multiple versions and is commonly discussed alongside the following related frameworks and research areas:

• TOGAF Evolution (1995-present): TOGAF has evolved through 10 major versions. Evolution demonstrates framework viability and ongoing refinement.
• Federal Enterprise Architecture Framework (FEAF, 1999): US Federal government developed FEAF based partly on TOGAF principles. FEAF applied TOGAF-style discipline to Federal agencies.
• Department of Defense Architecture Framework (DoDAF, 2003): DoD architecture framework emphasizing capability-based architecture. DoDAF applied architecture principles to military domain.
• Agile Architecture Movement (2010s): Architects recognized need to integrate TOGAF with agile development methods. Agile architecture research addresses TOGAF-agile integration.
• Digital Transformation Frameworks (2010s-2020s): Digital transformation frameworks adapted TOGAF principles for cloud-native and digital contexts. Frameworks apply architecture discipline to digital transformation.
• Enterprise Architecture Research (1990s-present): Enterprise architecture research has multiple intellectual roots (Zachman, TAFIM, TOGAF, and commercial frameworks). TOGAF is commonly cited within this body of work rather than being its sole source.
• Specialized EA Frameworks: Numerous specialized frameworks emerged for specific domains (healthcare, finance, manufacturing) building on TOGAF principles.

References

1. Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 276-292. https://doi.org/10.1147/sj.263.0276
2. The Open Group. (2022). TOGAF standard, version 10.0. The Open Group Publications.

Further Reading

1. The Open Group. (2011). TOGAF version 9.1 (The Open Group Architecture Framework). The Open Group Publications.
2. U.S. Department of Defense. (1994). Technical architecture framework for information management (TAFIM), version 2.0. U.S. Government Publishing Office.
3. Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard Business School Press.
4. Kappelman, L. A. (Ed.). (2010). The SIM guide to enterprise architecture. CRC Press.
5. Weill, P., & Ross, J. W. (2009). IT governance: How top performers manage IT decision rights for superior results. Harvard Business School Press.
6. US General Services Administration. (1999). The Federal Enterprise Architecture framework. U.S. General Services Administration.
7. U.S. Department of Defense. (2003). DoD architecture framework version 1.0. U.S. Department of Defense.
8. Schekkerman, J. (2003). How to survive in the jungle of enterprise architecture frameworks. Trafford Publishing.
9. Group, T. O. (1995). The Open Group Architecture Framework (TOGAF).

Series Navigation