TOGAF for Feds

This one starts with a blog-post by John Polgreen, of training-group Architecting the Enterprise, called “TOGAF for Feds – Isn’t TOGAF too IT-centric for Fed EA?”. The key issue that of scope:

TOGAF is often associated with IT architecture, as opposed to the business-driven, holistic enterprise architecture espoused by the US Federal government.

John argues that whilst there’s still room for improvement, TOGAF 9 is much more business-focussed than the previous versions:

The present TOGAF definition of enterprise architecture – although holistic – doesn’t seem very business-driven: “…the description of an enterprise as a system in terms of its components, their inter-relationships, and the principles and guidelines governing the design and its evolution.” Contrast this to a definition suggested by Paul van der Merwe to be included in the next release of TOGAF: “The continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change.”

He then points to the TOGAF ADM (Architecture Development Method) as the solution. But to me the current structure of the ADM is a key part of the problem, not the solution. Since John asked “What are your thoughts? Is TOGAF too IT-centric for your agency? I’d very much like to hear your opinion”, I appended the following comments to his post:

The short answer to “Is TOGAF 9 too IT-centric for your agency?” depends on two factors:

• whether you think enterprise architecture is primarily about the relationship between business and IT, versus whether it’s about the enterprise as a whole, of which IT is only one small part;
• whether the work of the agency is centred around information (eg. IRS), versus some other domain(s) (eg. Parks & Environment)

If your concern is more with the first side of both of those two spectra – the business/IT relationship, in an information-oriented agency – then TOGAF 9 will be a very good fit, with TOGAF 9 a valued improvement over the previous version. For those contexts, the short answer would be ‘No’: TOGAF is not too IT-centric for the agency.

But the fit becomes progressively worse as you move to the other side of either of those spectra. Unlike FEAF, TOGAF has almost no concept of people (FEAF’s ‘Human Capital’), or of physical things other than IT-infrastructure (FEAF’s ‘Other Fixed Assets’). If your need is to build a whole-of-enterprise view for an agency that deals primarily with people or with physical things, TOGAF 9 provides little real gain over TOGAF 8. It’s true there are a few real improvements – such as the section on Capability-Based Planning – but in some ways it anchors the architecture even more rigidly into the IT domain. For those contexts, the short answer would be ‘Yes’: as it stands, TOGAF would definitely be too IT-centric – and in some cases even dangerously so.

The key problem-area is one of scope. The TOGAF 9 ADM retains from the previous version exactly the same fixed IT-centric scope, with a linear progression from ‘Business Architecture’ – in essence, “everything not-IT” – through ‘Information Systems’ to ‘Technology Infrastructure’. The end-point is always to clarify the design and structure of the IT-systems: everything else is peripheral to that purpose. If the architecture has any other purpose – as it will do in most agencies, especially as architecture maturity develops – the current design of the TOGAF ADM may become an active hindrance almost every step of the way.

(In principle the new section on Iterations should relieve this to some extent, but the iterations concept is not well-enough described to be useful in practice: in essence the ‘new’ ADM is still a Waterfall model with a few half-hearted attempts at Agile vaguely tacked on, with a governance model that fits neither approach well enough to be reliable – especially at an enterprise-wide scale.)

The ADM principle is sound, and provides a much-needed methodology that FEAF lacks. But for anything other than IT-oriented ‘enterprise’-architecture in information-centred agencies, TOGAF 9 is usable only if we can break free from the existing ADM’s fixed IT-centric scope. To do this, we need to rethink the detailed structure and sequence of the ADM, whilst retaining the overall principles of the methodology.

Key requirements for such a revision include:

• stronger support and governance for Agile-style iterations
• support for consistent management of iterations of any duration and any level of nesting
• support for any architecture scope, dependent on the needs of each iteration
• explicit removal of any assumptions about the centrality of IT

The latter requirement also supports architectural assessment of contexts where IT may not be involved or even available, such as in process-design and planning for some disaster-recovery/business-continuity scenarios.

For one example of one such modified version of the TOGAF ADM, see http://tetradianbooks.com/2008/10/silos-method-ref/. A matching framework to identify scope for architecture iterations is at http://tetradianbooks.com/2008/12/silos-frame-ref/.