Key takeaways
- Detailed application guidance is found in the TOGAF Series Guides.
- Fundamental Content documents can be adopted selectively and incrementally.
- Most frameworks describe deliverables; TOGAF also provides a method.
- TOGAF’s generic deliverables can be replaced or extended by those of another framework.
- A style is integrated by adjusting models, viewpoints, and tools, not by rewriting the ADM.
Where to find application guidance
The TOGAF Standard consists of the Fundamental Content, six free-standing but linked documents, and a collection of TOGAF Series Guides. The “Applying the ADM” document of the Fundamental Content gives the general rules for adapting the method. Series Guides provide more detailed guidance for specific needs: strategy, Business Architecture, data, security, agility, digital enterprise, or combination with other Open Group standards.
These guides evolve faster than the core content, following market needs. Not all of them help in every context, but the architect preparing a deployment should know what exists. Fundamental Content documents can also be adopted selectively: an organization may start with the ADM and postpone the capability material.
Combining TOGAF with other frameworks
An architecture framework has two key elements: the definition of the deliverables to produce and the description of the method to produce them. Most frameworks emphasize deliverables and say little about method. TOGAF, being generic, offers an extensible content framework and a method.
It can therefore be used on its own, with its generic deliverables, or by replacing and extending those deliverables with the ones from another framework considered relevant. In every case, the architect builds a tailored method integrated with the enterprise’s processes and organization.
- Best practices cited: ITIL, CMMI, COBIT, PRINCE2, PMBOK, MSP
- TOGAF Library resources, such as the IT4IT Reference Architecture
- Vertical business domains, horizontal technical topics (security, manageability), or application areas
Serving an architecture style
Architecture styles (service-oriented, event-driven, risk- and security-focused…) differ in focus, form, and techniques. To serve one, first identify its distinctive features, then decide how to address them. This should not deeply change the framework: instead, the models, viewpoints, and tools are adjusted, often with metamodel extensions and suitable notation.
In Phases B, C, and D, the practitioner selects the relevant resources to describe each domain. If a style becomes dominant, the Preliminary Phase can be revisited to adapt the Architecture Capability. Style-specific reference and maturity models are common aids, and several guides illustrate these combinations (SOA, risk and security, SABSA, BIAN, DoDAF).
TERMS TO KNOW
The terms, in context.
- Fundamental Content
- The six core documents of the TOGAF Standard.
- TOGAF Series Guide
- Guide detailing how to apply the standard in a specific context.
- Tailoring
- Adapting TOGAF to the enterprise’s processes and organization.
- Architecture style
- A way of architecting defined by a set of distinctive features.
- Applying the ADM
- Fundamental Content document dedicated to adapting the ADM.