Can TOGAF and Agile really go together?
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.
The governance problem
Although we want agile teams to be autonomous and self-managing, they are still part of a wider organisation. Agile teams in large organisations can never be fully autonomous as they need to work within a boundary of data, conventions, technologies and strategies that are set by the wider organisation. What TOGAF attempts to do is define a structures process for developing this boundary in a way that is transparent and inclusive.
In this sense, there's no conflict between architectural frameworks and agile as they are trying to solve very different problems. Enterprise architecture is concerned with defining the infrastructure and standards within which teams operate. Agile methodologies are more concerned with the most efficient way of organising a software development team.
Despite this separation, there does come a point at two approaches can collide, mainly when it comes to enforcement and governance.
TOGAF can be very opinionated about which aspects of development should be left to teams. It uses compliance reviews to ensure that best practice is applied, standards are adhered to and shared infrastructure is used. This can be a very detailed process - a full compliance review involves a checklist of more than a hundred items including from hardware, information management, security and engineering approach.
Although you are expected to tailor the standard list to focus on high risk areas, the intent is for an external body of architects to hold development teams to a very detailed account. This can be as much about power and control as anything else. Architectural governance is fine when it concerns itself with the wider context that teams do not have visibility of. It is less appropriate when it concerns itself with aspects of development where the teams themselves should be the recognized experts.
How do agile frameworks try and reconcile governance?
TOGAF captures work that happens in a large organisation regardless of whether it is executed as part of a framework. You should have some kind of architectural vision that is aligned to a business strategy. You need to broker some common agreement over how things are done and ensure that decisions are fair and transparent. You also need to track your portfolio of applications and reduce any unnecessary repetition.
Most agile frameworks that attempt to inflate Scrum for large organisations have a placeholder for architecture. The main difference is that they tend to emphasise collaboration, simplicity and decentralised governance.
Large-Scale Scrum (LeSS) focuses on the importance of “emergent design” where teams can respond to immediate user needs that only appear when a system is being built. There is no room for enterprise considerations in this team-orientated approach, where “architecture astronauts” are dismissed as out of touch with reality if they are not directly engaged with the evolving source code.
The Scaled Agile Framework (SAFe) takes a more balanced approach by recognising the need for what it calls “intentional architecture”, i.e. those planned, long-term initiatives that enhance solutions. This needs to be balanced by the more incremental emergent design.
For SAFe, both incremental and emergent design contribute towards what it calls the “architectural runway”. This is the foundation of components, infrastructure and conventions that need to be in place for teams to meet their immediate objectives. This is where architects focus much of their attention, though they need to adopt a much more collaborative and hands-on approach than that implied by TOGAF.
TOGAF can be whatever you need it to be
TOGAF merely provides a bunch of tools for how you would define and build and enterprise architecture. The numerous building blocks that make up TOGAF may seem exhausting, but this is because they are trying to grapple with something very large and very complex.
This complexity doesn't go away just because the organisation has embraced agile. It does mean that architects need to take a more collaborate and iterative approach to defining the architecture. They need to adapt their processes to minimise bureaucratic overhead and delegate as much as possible to individual teams.
Agile and TOGAF can happily co-exist, mainly because they operate in very different spheres. Where agile is principally concerned with the most efficient way of organising a team, TOGAF is concerned with the challenges faced by the wider enterprise.
The trouble comes when the governance structures of TOGAF start to impinge on the autonomy of agile development teams. It's up to the governance regime to trust their teams and provide them a wide remit and plenty of latitude. Above all, architects need to understand the difference between governance and control.