WBISCT Pty Ltd – Enterprise Architecture Consulting and Training

Can TOGAF and Agile really go together?

by Ben Morris

On the fact of it, everything about TOGAF seems to be in direct opposition to the agile and lean worldview. It is extremely detailed with numerous frameworks, techniques and templates described in a rather sterile manual that runs to nearly 700 pages. This does not sit well with the agile focus on favouring working software over documentation.

There is a cultural difference here as much as anything else. Agile champions unfettered teams and encourages direct collaboration where the world of TOGAF is one of architecture boards and carefully indexed document repositories.

Mapping TOGAF to agile processes

It’s important to understand that TOGAF is not a rigid framework that has to be followed to the letter. It actively encourages practitioners to adapt and modify the application model to suit the circumstances. This does at least mean that in theory the various parts of TOGAF can be adapted to fit in with agile development.

It’s also important to note that TOGAF captures work that happens in a large organisation regardless of whether it is executed as part of a framework. You need to track your portfolio of applications, capture architectural decisions, reduce unnecessary repetition, facilitate some common agreement over how things are done and ensure that decisions are fair and transparent.

Some attempts have been made to map TOGAF directly to agile processes. This is difficult to do cleanly, but the earliest TOGAF phases such as the architectural vision can be placed within backlog management, business architecture is part of iterative sprint planning while change management is taken care of during the sprint review and retrospective process.

Whether or not this mapping can be made to work depends very much on the behaviour and approach of the architects themselves. They need to recognise the culture shift that agile brings and take a more collaborative and iterative approach to defining the architecture. Above all, they have to view their work as a means of enabling teams and be prepared to delegate as many decisions to them as possible.