Leveraging the TOGAF ADM

If there’s a single image that has become iconic for TOGAF, it’s the TOGAF ADM – the Architecture Development Method. The image of the 8 steps of the ADM (plus the preliminary phase and requirements management) is so recognizable that it’s almost at the status of a logo for TOGAF – and that’s not surprising. While I can find things to dislike in the ADM (you can find things to dislike in anything if you try hard enough), I still find the basic simplicity of the underlying idea attractive. Figure out where you are and where you want to be for each of business, data, application and technology, identify the gaps, group the gaps into coherent packages of work, and then execute them. Some might argue that it is outdated because of the use of BDAT layers (i.e. business, data, application and technology), but I’m going to argue later on that this is not true, regardless of what you think about the traditional layers.

While the standard presentation of the Architecture Development Method in Part 2 of TOGAF implicitly focuses on enterprise transformation with a focus on transforming the information technology systems, this doesn’t mean that the ADM is only of use for performing a root-and-branch transformation for an enterprise. First of all, the concept of an enterprise is nebulous. Depending on how autonomous different departments are, it's possible to treat a single department as an organization for the purposes of the ADM. The TOGAF spec acknowledges this in the executive overview: “an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership”. So, depending on the level of integration, you could successfully apply the ADM to a single department.

In fact, TOGAF practices what it preaches in this regard, by considering how you can use the Architecture Development Method in establishing an architecture capability in Chapter 46. By way of example, Chapter 46 considers in some detail how this would apply for the first two stages of the ADM, the preliminary phase and the business architecture.

But the ADM is also applicable for any transformation – just as there is no universal law mandating what an enterprise is, the layers of Business, Data, Application and Technology are arbitrary. They've been used so long that it's easy to forget that they're just a classification scheme, and like all classification schemes, they're merely there to allow you to break a problem up into more digestible pieces.

For example, you could just as easily use the ADM with the ‘layers’ of security, governance and cloud systems, and then follow the ADM by the sequence of: Identify gaps->group into work packages->plan migration->execute.

Or you could do this with the ‘layers’ of physical, digital, process, contract. The Architecture Development Method is really just a way of planning a migration – it’s just that it’s presented with the classification scheme that’s become familiar, namely business/data/application/technology.

Because TOGAF is so dominant, and provides so much detail, it's easy to forget that it was never intended to be taken as a (rather large) set of stone tablets of commandments. I always try to remind people that TOGAF is there to be stolen from. Early on in Chapter 2, TOGAF states that it “is a generic framework and intended to be used in a wide variety of environments”, and that “it is expected that the architect will adapt and build on the TOGAF framework”. Or, to use one of the late Steve Job's favorite quotes, “good artists copy, great artists steal”. And in this short discussion I've provided an example of how you can productively steal from TOGAF.

After all, it's what it's there for.