A good Twitter exchange with John Polgreen (thanks John!) set me thinking yet again about the future of TOGAF (The Open Group Architecture Framework).
At present, TOGAF is just about the standard for the enterprise-architecture (EA) field, and the recent Version 9 release has further cemented that position. The catch is that the Open Group is an IT-standards body; and as EA at last starts to expand outward to a true ‘architecture of the enterprise’, that history is beginning to be a problem. Possibly a serious problem. Quite possibly serious enough, in fact, to kill the future usefulness of TOGAF for enterprise architecture. Not good… Hence, right now, TOGAF is facing a crossroads.
Up until the latest version, it prided itself on its detail: it provided detailed reference-models, a detailed methodology, and so on. In Version 8.1, the ‘Technology Architecture’ section provided 50 distinct steps to assess the architecture of an IT infrastructure. It was all too evident, though, that everything was grounded in that low-level technology: business, applications and data were all glossed over (8-9 steps each, compared to ‘Technology Architecture’s 50 steps), because they were relevant only inasmuch as they impacted on the technology infrastructure. Which was fair enough, given the Open Group’s history as a standards-body for IT.
But although many, if not most, people with an ‘enterprise architect’ job-title still believe that enterprise-architecture is an IT-specific discipline, there’s an increasingly urgent need for something that really is ‘an architecture of the enterprise’, rather than solely of the enterprise IT. That shift in awareness has been growing fast over the past couple of years, as I’ve commented about recent EA conferences such as TOGAF London and EAC2009. So there are two fundamentally different perspectives about EA:
- an IT-centric view, ‘bottom-up’, focussed on detail-level technology, applications and services, and in which ‘business architecture’ is a summary of ‘anything not-IT that might impact on IT’
- a global or ‘holistic’ view of the enterprise, initially ‘top-down’, in which IT is merely one amongst many potential domains of interest, and in which ‘business architecture’ is partitioned into distinct domains such as strategy, value-chain, process and capability-infrastructure, and in which whole-of-enterprise integration and agility are the real overall goals
TOGAF Version 9 tried to reconcile those two views, by bringing its descriptions of its ‘four architectures’ (technology, data, applications and business) into better balance, and adding new tools such as its Capability-Based Planning section. The result, unfortunately, is a classic compromise: in trying to satisfy all needs, it ends up satisfying none. It’s now doubled in size, to just under 800 pages - way too big to be usable - and even so it’s lost too much of the applicable detail, especially in ‘Technology Architecture’, which achieves a balance with the other ‘architectures’ by rounding down to the same eight steps. The same applies almost everywhere else: the sections on iterations, on security, on services, all present skimpy overviews that summarise the issues but fail to provide enough detail to be actionable, yet also give little or no indication as to how to derive that detail for any given context. In ISO-9000 terms, each section is stuck somewhere between an actionable work-instruction and an abstract procedure to derive work-instructions, satisfying neither need. And whilst TOGAF’s inherent IT-centrism still made some degree of sense in information-centric industries such as insurance, banking and finance, in other industries it constrains the ‘enterprise’ architecture in a dangerously blinkered way, often trying to enforce IT-based assumptions in areas where they make no sense at all. Hence, unsurprisingly, a lot of frustration…So it seems to me that TOGAF is now caught on a double-dilemma:
- should it go for the detail (’work-instruction’); or for the abstract (’procedure’)?
- should it stay with bottom-up IT-architecture (and preferably stop calling it ‘enterprise architecture’…); or should it expand to a true ‘architecture of the enterprise’?
It can’t do all of these: that much is certain.
If it goes for the detail, it will need continual update: a new release every year as a minimum, and probably more frequent than that. Practical realities will mean that going for the detail will also force a narrowing of scope, probably right back down to low-level technology-infrastructure again.
If it goes for the abstract, the scope can be broader; but it will need detailed examples of how to derive actionable practices from the procedures, otherwise - as is close to the case already - the material will be unusable in practice.
If it stays with the IT-centric view, it’s a more comfortable fit with the Open Group’s history; but it risks being left behind - other than as a tool for a narrow niche market - as the EA industry, of necessity, moves outward to cover the true whole-of-enterprise scope. Trying to promote an IT-centric architecture as ‘enterprise architecture’ will guarantee that business-folk will reject it, worsening the already notorious ‘IT/business divide’; to resolve that, EA practitioners will be forced to use alternatives to TOGAF, leading to a wasteful ‘reinventing the wheel’ for the entire industry.
If it aligns with the industry trend, there’s a real risk that too many of the Open Group architecture-forum members could be forced too far out of their comfort-zone: as John Polgreen put it in one of his ‘tweets’, the Open Group members collectively tend to be very strong on IT-architecture issues, but “[perhaps] not enough good minds with real business architecture experience”. This in turn risks causing a split in TOGAF, or even within the Open Group itself - neither of which would be a good outcome.
What it can’t do is all of these. TOGAF is at the crossroads: it has to find an appropriate balance in this double-dilemma.
The ‘obvious’ solution is for TOGAF to retreat back to its roots: concentrate on IT only, and attempt to clean up and control the detail. At first glance, that would seem to be the best fit with the Open Group’s legacy and charter, and it would fit well with the fact that most of the big players in this not-so-open group are focussed on selling IT systems, software and services. And it would work, for a while, but in reality it would be the start of a spiral into angry irrelevance as the industry itself moves on - something I’ve seen happen several times with overly IT-centric ‘enterprise architecture’ teams out in real-world EA practice.
A far better solution would be to apply lessons-learned from other frameworks such as ISO-9000 and ITIL.
The early versions of the ISO-9000 quality-systems standard were a disaster-area: at best useless, at worst a bureaucratic nightmare, drowning in the detail of a pointless paper-trail. But someone, somewhere made the essential observation that, unlike IT-boxes, people don’t follow the rules, because the real world doesn’t follow the rules either: to make things work, people must adapt ‘the rules’ to the specific details of the specific context. So in ISO-9000:2000, everything changed: instead of an obsessive emphasis on compliance to predefined work-instructions, there was an explicit layering from work-instruction (live practice) to procedure (how to define new work-instructions) to policy (how to define new procedures) to vision (to guide new policies). The predefined work-instructions thus became worked examples of how to use procedures to define contextual ‘work-instructions’ for live practice; and so on up the audit-trail all the way back to vision, which (in principle, at least), would always remain the same. The standard itself doesn’t properly explain how this works in practice; but the guidance-notes do explain it, and so do all the better training-courses. Applied wrongly, as a means of ‘control’, ISO-9000 still creates a pointless paper-trail; but applied right, as a context-aware framework, it enhances every aspect of quality-management throughout the enterprise.
So to ITIL (IT Infrastructure Library), the IT service-management standard. Up until Version 2, ITIL was much like TOGAF today: literally with IT on one side, business on the other, and IT service-management uncomfortably straddling the gaping void between the two. But in Version 3, everything changes: instead of being focussed almost exclusively on IT issues - again, much like TOGAF today - the standard presents a generic service-management model, using IT as its worked-example of how that generic model is used in practice. Anecdotal evidence suggests that for many IT service-management folks there isn’t enough detail in that worked-example: too much was lost from the previous version, they say - much like the detail lost from ‘Phase D: Technology Architecture’ between TOGAF’s Versions 8 and 9. But again, the guidance-notes do explain it, and so do all the better training-courses. Applied right, as a context-aware framework, ITIL can be used for any service-management need.
If we look at how TOGAF needs to develop, several themes become clear:
- it needs to continue to provide full, ongoing, evolving support for IT-architecture - because that’s the Open Group’s main consituency at present
- like ITIL, it also needs to become generic enough to manage any type of domain-architecture, because that’s where the EA industry is headed - ‘the architecture of the enterprise’
- it can’t carry all the detail within the standard - there’s too much of it already, and will go out of date too soon anyway
- like both ITIL and ISO-9000, it needs to describe how to adapt generic principles to real-world practice, by showing how these devolve through architecture’s equivalents of ISO-9000’s ‘policy’, ‘procedure’ and ‘work-instruction’
- it needs to align with the Open Group’s vision of ‘boundaryless information flow’ and mission of ‘making standards work’ - otherwise there would be no reason for it to belong to the Open Group
We can resolve all of these as follows:
- like ITIL, a new TOGAF should be generic, but should use IT-architecture as its worked-example
- like ISO9000’s ‘guidance notes’, it should emphasise how each worked-example practice devolves from procedure, from policy, and from overlighting principle
- within the standard itself, it should carry only enough detail to illustrate a useful and actionable worked-example; all other detail should be maintained by the overall EA community on an open public resource ‘knowledge-base’ of best-practice, ‘worst-practice’ and, again, explanations of how contextual practices are derived from overall principles. (As Allen Brown pointed out at the TOGAF London conference, the TOGAF TRM and IIIRM reference-models are now years out of date: he suggested that they should be scrapped, but a better option would be put effort into maintaining them as live worked examples of the principles of ‘reference-model’ creation and use.)
- a true ‘architecture of the enterprise’ must, necessarily, extend beyond the Open Group’s traditional IT-centric emphasis; yet that extension does still directly align with the Open Group’s vision and mission, because EA is a body of knowledge about enterprise structure and purpose, and hence itself requires ‘boundaryless information flow’ and a clear need to ‘make standards work’. (There is an urgent need, for example, for an information-exchange format for architecture-information above solely that for software-development - as per the existing XMI standard - to enable interoperability between different enterprise-architecture toolsets.)
The real core of TOGAF is the ADM (Architecture Development Method); and as I’ve explained elsewhere - such as in my books Bridging the Silos and Doing Enterprise Architecture - the amendments needed to make the ADM usable for any architecture scope are almost trivial, and still remain compatible with existing TOGAF architecture and practice. It’s all doable, and we could do it today if need be: all that’s needed now is the courage to change, and the will to do so.
I won’t be able to go to the next TOGAF conference, in Toronto next month, but I hope others will be able to champion these suggestions there. Because if we don’t, we risk losing TOGAF itself over the next few years - which would not be a good outcome for the EA industry…
Let’s be blunt about this: TOGAF Version 9 was a lost opportunity, the wrong kind of compromise, and we dare not let that happen again. TOGAF at the crossroads: it’s up to us to make it work.
