Monday 28 May 2012

I got the gift of TOGAF

I passed my TOGAF certification at the beginning of last week.Whilst studying for it in my spare time over the past few months and trying to apply it to my everyday role, I came across a large number of statement which validate my stance that enterprise architecture methods such as TOGAF and agile methods can live very happily together. TOGAF is regarded (by misguided developers in the agile sphere) as 'a bureaucratic nightmare' because it is "up front design" using "documentation and models" which delivers everything in a "big bang" - All of which is entirely false.

Some snippets from the TOGAF 9 specification and related literature (there are many many more):

"A capability will take an extended time to deliver (specifics will be a function of the organization and industry vertical) and will normally involve many projects delivering numerous increments. In addition, the capability needs to provide real business value to stakeholders as soon as possible and maintain momentum to achieve the Target Architecture as well as the associated executive support and corporate funding. Therefore, it is useful to break the capability into capability increments that deliver discrete, visible, and quantifiable outcomes as well as providing the focus for Transition Architectures and the deliverables from numerous inter-dependent projects. These outcomes are the Critical Success Factors (CSFs) for continued capability support."

Now map:

Critical Success Factors -> Acceptance Criteria
Capability increments -> Story cards in a feature or features in an epic

Indeed, you can do the same with:

"Just Enough EA" -> "Just Enough Up-front Design"

Where 'Just enough EA' is usually characterised by just enough detail (and volume) to allow directed initiative (the Gartner research group goes one step further and states "Just enough Enterprise Architecture, Just In Time", the latter half of that statement should resonate with Agilists.

NB, TOGAF is a very abstract EA framework. It can be applied in a variety of ways tailored to the organisation and can leverage other frameworks and methodologies to actually deliver the capability of which IT would be one part. It works across the four domains of architecture of Business, Data, Application and Technology. So not only does IT have to bring itself to the party, but the business has to do their bit first, with information systems and then technology following on from there. So it is much more than delivering IT, but it currently has that focus, given a lot of solution architects find this a requirement for their jobs.

What I would recommend for those agilists who want to see more light and scale agile methods to the enterprise, is to view Dennis Stevens' presentation on "Scaling Agile to the Enterprise" where he outlines methods to deliver an agile enterprise (not just agile development). For those with good TOGAF knowledge, the mapping to TOGAF ADM, artefacts and deliverables is too striking to be able to ignore, especially when addressing the whole system in transformation, not just the individual elements.