Enterprise ArchitectureTOGAF

Why TOGAF Is More Important Than You Think

TT
TopicTrick
Why TOGAF Is More Important Than You Think

Introduction to TOGAF

To understand why TOGAF® is more important than you think, it helps to understand The Open Group and the multiple components that make up the TOGAF framework.

The Open Group is a global consortium that enables the achievement of business objectives through IT standards. They have hundreds of member organizations which contribute to the consortium and their standards, specifically TOGAF.

Their primary vision is Boundaryless Information Flow.

Boundaryless Information Flow

Boundaryless Information Flow means having the ability to deliver required information in an understandable way to the correct people over integrated systems in a timely and secure manner.

    A Brief History of TOGAF

    TOGAF itself was first developed back in 1995 and was initially based on research done by the Department of Defense and the US government. After spending millions of dollars and years of research, the Department of Defense gave explicit permission to The Open Group to use the Technical Architecture Framework for Information Management (TAFIM) as a starting point for TOGAF.

    Since then, The Open Group has been incredibly successful in furthering TOGAF, establishing The Open Group Architecture Forum as the place where changes to the standard are discussed and collaboratively revised by industry experts.


    Core Components of TOGAF

    Aside from introductory components, TOGAF is largely made up of the Architecture Development Method (ADM), alongside guidelines and techniques for using it.

    Developing Architecture

    The ADM describes how to actually produce the various architectural components required to build a functioning enterprise architecture. It is a true method in that there is a specific order to follow: architectural components should be developed iteratively in a specific sequence for the best results.

    Guidelines and Techniques

    The guidelines and techniques provide further information around the practical application of the ADM. These represent the refinements and suggestions from Architecture Forum members over decades of real-world enterprise architecture experience.

    Architectural Content Framework

    In addition, there is an Architectural Content Framework. This describes a standard structure for storing all architectural documents and other outputs from the ADM. Perhaps the most important outputs are the reusable architectural components (Building Blocks).

    Enterprise Continuum and Tools

    The Enterprise Continuum section describes the categorization and storage of architectural outputs, acting as a virtual repository from generic to highly specific architectures.

    TOGAF Reference Models

    TOGAF includes reference models such as the Foundation Architecture and the Integrated Information Infrastructure Reference Model (III-RM). Even if a specific organization doesn't use these exact models, reference models inevitably form part of the foundation for creating any mature enterprise architecture practice.

    Architectural Capability Framework

    Finally, there is the Architectural Capability Framework, which centers around building up and maintaining an enterprise architecture practice within a business. This includes information around the relevant skill sets, roles, and business processes required to operate effectively.

    Apply TOGAF Holistically

    TOGAF is a large framework. While it is possible to successfully use pieces of TOGAF separately, the full magic and value of TOGAF are only realized when the framework is applied holistically.


      The 10 Phases of the Architecture Development Method (ADM)

      The ADM is the beating heart of TOGAF. All phases are performed iteratively in a cycle as enterprise architectures are defined and implemented. As the business continually changes, the architecture will need to change with it.

      If a business strategy or vision statement changes, this should be a signal to re-evaluate the architecture. Even when the business strategy remains static, Application and Technology Architectures must be reviewed periodically to keep pace with new hardware/software releases and changing market conditions.

      Here are the phases of the TOGAF ADM:

      Preliminary Phase

      The preliminary phase revolves around setting up the enterprise architecture practice and capability. You define the overarching principles (try to keep them under ten) and agree upon the scope. As the business changes over time, this foundational capability may need to be reviewed and altered.

      Phase A: Architecture Vision

      For each new architecture developed, it is treated like launching a project. A project management office (PMO) might be involved, stakeholders are identified, and scope is agreed upon. Similar to a project charter, an Architecture Vision is created and approved before proceeding with deep architectural work.

      Phase B: Business Architecture

      This is where the Business Architecture is developed based on the approved Architecture Vision.

      Phase C: Information Systems Architectures

      Here, the Information Systems Architecture is developed based on the vision and the completed Business Architecture. (Note: Phase C includes both the Data and Application architecture domains).

      Phase D: Technology Architecture

      The Technology Architecture is developed based on the vision and all previous architectures (Business, Data, and Application). This covers the hardware, networks, and infrastructure.

      Phase E: Opportunities and Solutions

      In this phase, opportunities and solutions are examined. This is essentially initial implementation planning, figuring out how to build what has been designed.

      Phase F: Migration Planning

      Here, the migration plan is developed. This is the detailed plan for how to safely move from the Current State Architecture to the Target State Architecture. It may involve intermediate architectures (Transition Architectures).

      Phase G: Implementation Governance

      This critical phase allows the architects to oversee the implementation projects, ensuring that the transition to the target architecture is actually proceeding according to what was designed and planned.

      Phase H: Architecture Change Management

      Change management for the new architecture is established here. This ensures the architecture lifecycle continues efficiently when new changes are inevitably required.

      Requirements Management

      Requirements Management is placed at the center of the ADM graphic because it's not a sequential phase—it is a continuous process performed alongside all other phases. As an architecture is developed, various requirements will present themselves and must be managed continuously to ensure the final result truly meets the business need.