Having been lucky enough to be involved in a variety of technology transformation projects over the last 15 years ( makes me feel slightly old ) I have seen both successful and not-so-successful approaches to managing business change.
Technologists, by nature, often seem to be “fixers”. We look for the solution to the problem. That instinct can be incredibly valuable, but it can also create some familiar behaviours:
- Jumping to technology too quickly because it is familiar.
- Implementing solutions because the features are technically interesting.
- Fixing a problem quickly without fully reviewing the business impact.
- Designing around products rather than outcomes.
- Assuming that technical success automatically means business success.
This is where I found TOGAF useful.
Why I Looked at TOGAF
My background has been heavily focused on infrastructure, cloud, workplace, collaboration, Microsoft 365, VMware, architecture, migration, and transformation work. I have often worked in environments where change needed to happen quickly, but also needed structure, governance, and a clear link back to business value.
For me, TOGAF was not about learning a completely new way of thinking. It was more about giving structure, language, and method to things I had already seen in real projects. I have used Vendor based frameworks for many years, but a vendor agnostic framework that is used in many industries as a enterprise standard is extremely valuable professionally
It helped frame questions such as:
- What business outcome are we actually trying to achieve?
- Who are the stakeholders?
- What are the constraints?
- What is the current state?
- What is the target state?
- What gaps exist?
- What needs to be governed?
- What should be reused?
- What decisions need to be recorded?
- How do we move from architecture into delivery?
That is where TOGAF starts to become useful. It is not just theory. It gives a repeatable way to think about change.
My Initial Reaction
When I first looked at TOGAF, it felt quite large. There are a lot of terms, phases, concepts, artefacts, and definitions to review. At first glance, it can feel like a framework full of words rather than something practical.
However, once I started mapping it back to real examples from projects I have worked on in the past, it became much clearer.
(Click on image to download a PDF version)
The Architecture Development Method, or ADM, is essentially a structured lifecycle for architecture work. It helps move from understanding the business need through to designing architectures, planning migration, governing implementation, and managing change.
The key for me was not trying to memorise TOGAF as abstract theory. It was about connecting the terminology to real project experience.
For example:
- Business Architecture maps to understanding capabilities, processes, stakeholders, and outcomes.
- Data Architecture focuses on information, data flows, and how data supports the business.
- Application Architecture considers the systems and applications needed to support the business.
- Technology Architecture looks at the infrastructure, platforms, networks, cloud services, and technical building blocks.
That BDAT domains, Business, Data, Application, and Technology is a useful checklist of making sure technology does not dominate the conversation too early.
Foundation Exam Preparation
For the Foundation level, the biggest challenge was terminology. TOGAF has specific meanings for words that we may already use casually in technology roles. TOGAF is a standard and terminology understanding is extremely important.
Terms such as architecture principle, architecture decision, requirement, building block, deliverable, artefact, view, viewpoint, baseline architecture, target architecture, and gap analysis all need to be understood in the TOGAF context.
My advice for Foundation preparation would be:
- Learn the ADM phases.
- Understand the purpose of each phase.
- Learn the key terminology.
- Understand the difference between deliverables, artefacts, and building blocks.
- Do not just memorise map each concept to a real example, think Context, Conceptual, Logical, Physical
- Use the official test practice questions to famailize with how the TOGAF exam phrases things.
Foundation is very much about understanding the structure of the standard and recognising the correct terminology.
Practitioner Exam Preparation
The Practitioner level felt different. It was less about simply knowing the terms and more about applying the method.
This is where real-world experience becomes helpful and mapping back to previous projects help, but it can also be a trap. In real projects, we often have taken shortcuts, adapted approaches, or we have to make decisions based on organisational pressure. In the exam, you need to answer from the TOGAF perspective, not just from personal experience.
That means asking:
- What would TOGAF recommend?
- What is my role? What can I influence (Portfolio, Segment, Team?)
- What phase are we in?
- What is the context here?
- What is the correct next step?
- What governance or stakeholder concern needs to be considered?
- What artefact, deliverable, or repository item is relevant?
- Are we dealing with requirements, risks, constraints, gaps, or decisions?
Practitioner preparation is about applying the framework in the correct context.
The questions often test judgement, not just memory.
What Helped Me Most
The biggest thing that helped me was turning the framework into something visual.
I used mind maps, diagrams, simple examples, and comparisons to real projects. Once I could see how the ADM connected together, the content became easier to retain.
For example, I found it useful to think of TOGAF as a structured way of preventing poor change behaviours,
- Instead of jumping straight to technology, start with context, business drivers and stakeholders.
- Remember not to make design decisions in isolation & to manage requirements throughout the process.
- Instead of creating one-off designs, reuse architecture building blocks where appropriate.
- Use governance and architecture contracts to prevent delivery drift,
- Remember architecture is not just a design document, but a way of managing controlled approach to change.
That made the framework feel much more practical for work in the real world.
My Exam Experience
I took the combined version of the TOGAF certification, whereby I took both exams in one sitting, one after another.
The Foundation exam felt like a test of language, structure, and understanding. If you know the ADM, key definitions, and core concepts, it is very manageable.
The Practitioner exam required more thought. The questions felt more situational, and the challenge was selecting the answer that best aligned with TOGAF guidance. Some answers may look reasonable from a general technology perspective, but the best answer is the one that fits the method, phase, and scenario.
The most important exam technique for me was slowing down and identifying what the question was really asking. Often the clue is in the phase, context, stakeholder concern, or type of activity being described.
Reflections After Passing
After completing the preparation and exam, I can see why TOGAF is valuable, especially for people working across transformation, architecture, governance, or enterprise change.
It does not replace technical skill. It does not magically make projects successful. However, it does provide a structured way to think, communicate, govern, and align technology change to business outcomes.
For someone with a technical background, TOGAF can help shift the conversation from:
“What solution should we build?” to “What change does the business need, what architecture supports it, and how do we govern that change properly?”
That, for me, is the real value.
My biggest takeaway from TOGAF v10 is that architecture is not just about producing diagrams or choosing technology. It is about managing change in a controlled, structured, and business-aligned way.
Good technologists solve problems
Good architects make sure they are solving the right problems, for the right reasons, with the right level of governance and stakeholder alignment. That is the mindset TOGAF helped reinforce.