TOGAF, which stands for “The Open Group Architecture Framework”, is the most important Enterprise Architecture Framework nowadays. It has first published in 1995 by The Open Group and has regularly been updated since then. Today, The TOGAF Standard is the most cited and used knowledge book with detailed methods and tools for developing enterprise architecture in a company, and many, if not most, large global corporations base their enterprise architecture activities on TOGAF or a modification of it.
When and Who Developed TOGAF?
As mentioned, TOGAF has been first released in 1995. The latest main release, version 9, was released in 2011 and the latest minor release, version 9.2, was released in 2018. TOGAF is regularly developed further and worked on by more than 300 TOGAF forum members, many of them from large corporations, such as IBM, Oracle, or Philips. It, therefore, provides a good overview of common and generic EA practices across many different organizations. However, you should not expect to find fancy best practices to master the digital transformation in TOGAF.
What is TOGAF Used For?
Enterprise Architecture covers the whole IT landscape of an organization, including business processes and capabilities, applications, information systems, and technologies. To handle that complexity, TOGAF provides methods, frameworks, and principles to approach and structure daily Enterprise Architecture challenges. Further, TOGAF helps organizations align business and IT in terms of strategy and operations, managing cross-domain or cross-departmental IT efforts, supporting projects from an architectural point of view, and governing and enhancing Enterprise Architecture activities.
What is the Content of TOGAF?
TOGAF covers a wide variety of helpful content for enterprise architects. The heart of TOGAF is the Architecture Development Method, which can be used as a project approach for architecture projects and that provides detailed insights on goals, inputs, activities, and outputs of every stage. It is also where TOGAF introduces its architecture layers (Business, Application, Information Systems, and Technology) that are widely reused by many companies in very different contexts. Further content includes the architecture content framework and metamodel and a framework to structure all kinds of architecture work, called the Enterprise Continuum. Further, TOGAF provides some specific reference models that can be used as a rough reference for a company´s architecture. Finally, TOGAF provides a detailed view of which capabilities an enterprise architecture department should have in a company and also provides a glossary with definitions of the most important terms. Let´s take a deeper look into those areas.
1. Architecture Development Method
If I had to pick one concept to be the most important in TOGAF, it would be the Architecture Development Method (ADM). It is a stepwise approach to assess all landscape layers of an enterprise including their current and target state, to develop a roadmap towards the goal, support the transformation, and guide its governance and future development of it. The steps of the ADM include:
- Preliminary Phase: Establishing the basics, such as defining who are the architects, defining the broad scope of enterprise architecture
- A. Architecture Vision: High level view of what the architecture should look like
- B. Business Architecture: Development of a detailed as-is and to-be view on the business (especially processes) of an organization
- C. Information Systems Architecture: Development of a detailed as-is and to-be view on the information systems / applications / data of an organization
- D. Technology Architecture: Development of a detailed as-is and to-be view on the technology architecture / infrastructure of an organization
- E. Opportunities and Solutions: Development of components that deliver the defined target architectures in a tangible way
- F. Migration Planning: Development of the corresponding roadmap
- G. Implementation Governance: Governing the roadmap implementation
- H. Architecture Change Management: Long-term supervision of the enterprise architecture, such as starting a new development cycle to refine the target states
- Requirements Management: Central management of demands and requirements during all phases
Each step is described with detailed activities, deliverables, prerequisites, goals, etc., where steps A to D have the same structure but target different architecture layers. Together, the steps build a detailed foundation for an enterprise architecture development or transformation project. If you are interested in more details on this topic and how TOGAF should improve it, take a look at this article.
2. Architecture Content Framework and Metamodel
The Architecture Content Metamodel defines which different types of content enterprise architecture can develop as outputs (especially during the different phases of the ADM). The major three output types are the following:
- A Deliverable: A contractually specified project/work output that is formally reviewed and signed off
- An Artifact: An architectural work product that describes a part of architecture (e.g. a matrix or a diagram)
- A Building Block: A more general piece of architecture that is potentially re-usable and might be used as a reference within the organization
The Architecture Content Framework provides a structure to consistently relate them to each other. This structure is also aligned to the phases of the ADM. On a high level, the Content Framework looks like the following:
3. Enterprise Continuum
The Enterprise Continuum is the most abstract concept of TOGAF. However, it is easily explained: The Enterprise Continuum offers a solution for structuring the architecture documentation of a company. The idea is to imagine a slider that has on the left end documents that are very generic and that can be broadly applied (e.g. a document explaining what enterprise architecture is) and on the right end documents that talk about very specific problems or situations (e.g. a document that describes how a particular mining company succeeded in establishing an enterprise architecture governance across its subsidiaries). The TOGAF library itself is structured along the Enterprise Continuum and offers the following four areas: First Foundation Documents, Second Generic Guidance and Techniques, Third Industry-Specific Guidance and Techniques, and fourth Organization-Specific Guidance and Techniques.
4. Reference Models
TOGAF reference models provide a basic understanding of different concepts of the IT landscape. For instance, the Technical Reference Model describes a high-level architecture of a platform with infrastructure, a layer of applications that provide foundational services on that platform, and a layer of applications that provide services to the user. It also describes components, such as platform principles, how the interfaces should look, etc.
Another model is the Information Infrastructure Reference Model, which focuses on the boundaryless information flow between applications. Both models help to gain a basic understanding of such models but do not deliver detailed solutions for an enterprise.
5. Architecture Capability Framework
This part of TOGAF describes what an organization needs to establish, operate, and govern an enterprise architecture successfully. While a business capability would describe what an organization does, an architecture capability describes what an enterprise architecture does. Similar to the concept of a business capability, an architecture capability describes components, such as organizational structures, processes, roles, responsibilities, and skills needed to successfully run an Enterprise Architecture Department. The core of such a capability would be for instance a certified enterprise architect (people/ skill component), a defined and lived demand process (process component), knowledge about the architecture components of the company (data/ information component), and an established Architecture Management Board to take decisions (organizational component). I personally think that the TOGAF framework is too generic to be helpful. If you are interested in a more elaborated view on what capabilities an enterprise architecture needs, take a look at this post.
6. TOGAF Glossary
Finally, the fact that TOGAF talks about so many different areas and concepts of enterprise architecture and that it is widely accepted in the industry has led to the situation that organizations often desire to use the definitions and standards as they are defined by TOGAF. The glossary of the TOGAF Standard contains roughly 100 different definitions which often form the basis for all further discussions within and across organizations.
The number of people that become TOGAF certified has been strongly increasing over the past few years and reached over 100,000 certifications worldwide. Many Enterprise Architects become certified because they want to lever the best practices and industry standards that TOGAF offers, some become certified because it helps them a lot to align with other Enterprise Architects in terms of terms and definitions, and others become certified because the certification provides a strong signal to potential employers that you have a profound knowledge in the area of Enterprise Architecture.
If you want to become certified, you need to pass level 1 and level 2 of the TOGAF exams. While level 1 is about studying the theory to become TOGAF level 1 certified, the TOGAF level 2 focuses more on an architectural understanding. In order to easily pass both levels, consider these 10 simple tips to pass TOGAF that I summarized for test takers.