One of the best known parts of TOGAF, The Open Group Architecture Framework, is the Architecture Development Method or ADM. I'm comfortable in stating that the ADM's set of 8+2 steps is the best known image of TOGAF. But the key point of TOGAF is that it is suggestive, not prescriptive – if you choose to implement some parts of it and not others, or if you choose to tailor the parts that you do implement, you won't get raided in the middle of the night by the TOGAF police, kicking your door down. TOGAF is meant to be borrowed from and adapted – in fact, since the fifth step of the Architecture Development Method's preliminary phase is to “determine what tailoring of TOGAF is required”, you could argue that an organization that performs a wholesale adoption of TOGAF without adaption... is not really following TOGAF.
So the contents of TOGAF exist to be borrowed from, adapted and used as needed. Previously, I've talked about how the Architecture Development Method has value outside of just using it to plan transformations of enterprise architectures for organizations. I've talked about how you can adapt it to categories other than the traditional, and sometimes maligned, layers of business, data, application and technology.
There's another technique that is particular to TOGAF, and it's also one that you can adapt to uses beyond those that it's described as being used for in the TOGAF pages. I'm thinking of the Enterprise Continuum.
To refresh our memories, the Enterprise Continuum is an approach to classifying architectures and solutions. The basic idea is that there are four categories, running from more general to more specific, with the standard progression given being Foundation Architectures-> Common System Architectures-> Industry Architectures-> Organization-specific Architectures. And similarly for solutions. But note that I say the standard progression. Chapter 39, the chapter of TOGAF states that the progression also represents some other transitions;
- Logical to physical
- Horizontal (IT-focused) to vertical (business-focused)
- Generalization to specialization
- Taxonomy to complete and specific architecture specification
So the key idea is not so much the precise classifications as the idea of an evolution from one end of a spectrum to another, which then forms the basis for classification of a catalog. Now, all classification schemes are by their nature arbitrary, but they are most effective when they represent a natural way of thinking about the things that they are classifying. This idea of a progression can be usefully applied to a few other, related areas.
For example, some architectural principles might apply globally while some would only be applicable at the country or departmental level – depending on the level of independence of countries or departments within the organization. Adopting an enterprise continuum-like approach would be a valuable way to enable staff to understand the distinction between the different types of processes in this case.
Likewise, an organization operating in a federal environment, such as Australia, Canada or the USA might have process that apply globally, country-wide and then at the state or province level. This is particularly appropriate to processes, as some or even many processes in the organization may be defined by the need to comply with regulations for the region in which the process operates– while other processes could be left to be more generic.
The size of TOGAF nowadays makes it tempting to see it as a bible, but it’s important that it’s explicitly intended to be borrowed from and adapted. This goes just as much for borrowing and adapting the range of ideas in TOGAF as it is to applying TOGAF to architectural transformation.