High-Level Overview of TOGAF 9.2 for Certification Preparation

I have been working in the ICT industry for a while and, before starting client engagements in my new role, I decided to use the free time to study for the TOGAF 9 certification without attending a formal course, sharing my notes to help others.

Previously, the highly theoretical nature of the TOGAF standard meant my managers did not see the need for certification, but now enterprise architecture is a core part of my job, and obtaining the credential will be beneficial.

High‑Level View of TOGAF 9.2

The complete standard consists of five parts; reviewing all of them can take up to two months if done alone, but I aim to progress faster by breaking the material into digestible chunks.

Similar to agile, TOGAF begins with a declaration that promotes reusing common solutions at both enterprise and solution levels. It defines deliverables, artifacts, and building blocks (ABB) and operates across four architecture domains—Business, Data, Application, and Technology—described in the Architecture Content Framework and the Architecture Capability Framework.

The core design framework, the Architecture Development Method (ADM), works across the four domains and comprises eight phases (A‑H) plus a Preliminary Phase and Requirements Management. Each phase requires a clear description of objectives, steps, and deliverables, and the standard details the associated tools and documentation practices.

Requirements Management

All ADM phases revolve around Requirements Management, making it an ideal entry point for understanding the method. Although introduced last in the standard, it represents a continuous service model where architects often start with existing inputs—current solutions and recorded requirements stored in the architecture repository, along with the architecture vision, deliverables, and artifacts.

As a new enterprise architect you will prioritize baseline requirements, assess the impact of new or changed requirements, and update the repository. The output is an impact assessment with conflicts and priorities, considering cost, schedule, and business metrics. The approach is dynamic and depends on surrounding ADM phases, taking into account assumptions, constraints, principles, policies, standards, guidelines, and specifications.

Note: I have highlighted the key variables you need to know for each phase (inputs, steps, outputs, methods).

Preliminary Phase

If the organization lacks an existing architecture practice, the Preliminary Phase provides a framework to establish an architecture governance process and tailor it to company needs. While most junior architects may not be assigned this work, understanding it helps ask the right questions when familiarizing yourself with existing practices.

The Preliminary Phase appears as an additional element outside the main ADM cycle. Inputs include TOGAF itself and any other frameworks you wish to use, along with business context and existing documentation. Outputs should be an organized model and a customized architecture framework, ultimately giving you your first architecture repository.

Key steps: define the scope of who is affected by the design, confirm governance, assign critical roles, and establish guiding principles. Then customize the methodology (terminology, processes, context classification). The challenging part is devising strategies and tools that make the framework effective, achieving the desired architecture capability maturity.

Summary

This concludes the first day of learning TOGAF. We have reviewed the high‑level structure of the standard and how the ADM starts and ends. Future articles will dive deeper into each architecture domain and examine every ADM phase. After reading the entire series and supplementing with additional study, you should have a solid understanding of enterprise architecture and be prepared to pass the foundation exam.