TOGAF (which stands for The Open Group Architecture Framework) includes a set of concepts, frameworks, and methods that help architects to fulfill their enterprise architecture tasks in a proven and standardized manner. According to its Website, more than 625 organizations are member of the organization and many of them belong to the biggest companies on the globe.
The heart of TOGAF is the “TOGAF Standard”, which is a detailed document with more than 600 pages. The Standard is updated every few years with the latest update in 2018 to TOGAF 9.2. Besides the TOGAF Standard, there is the TOGAF Library accessible for its members with a vast amount of documents, research papers, whitepapers, and qualified opinion papers about all kinds of enterprise architecture topics. The third area of TOGAF is its trainings and certifications area. According to TOGAF, there are more than 70,000 architects that have studied the TOGAF concepts and passed the certification exams. Roughly 40% of globally certified people come from the UK, US, or India. Other top 10 certified countries are: 4th Netherlands, 5th Australia, 6th France, 7th Canada, 8th South Africa, 9th China, 10th Germany.
To pass the TOGAF exams (there are two levels), one needs detailed knowledge about the content of the TOGAF Standard. The following topics build the core of the TOGAF Standard and are most crucial to understand what TOGAF is:
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 their target state, to develop a roadmap towards the goal, to support the transformation, and to guide the 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 Architectures: 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 the 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.
2. Architecture Content Framework and Metamodel
The Architecture Content Framework defines which different types of content enterprise architecture can develop as outputs (especially during the different phases of the ADM) and provides a structure to consistently relate them to each other. This structure is also aligned to the 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 describe a part of an 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
3. Enterprise Continuum
The Enterprise Continuum is the most abstract concept that TOGAF offers. However, it is easily explained: The Enterprise Continuum offers a solution for structuring architecture documentations 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: 1st Foundation Documents, 2nd Generic Guidance and Techniques, 3rd Industry-Specific Guidance and Techniques, 4th 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 an 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 like 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 in order 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. Similarly 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).
6. TOGAF Glossary and Term Definitions
Last but not least, 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.