Summary from the TOGAF conference

(This is an edited version of some notes I’ve already posted to the Enterprise Architecture Network list of LinkedIn.)

Two points particularly stick in my mind about what transpired at the TOGAF Enterprise Architecture conference in London this past week.

One is that there was a huge shift in the community, where almost everyone there openly and overtly stated (or at least overtly acknowledged) that enterprise-architecture is only peripherally about IT. IT is important, yes, but it’s not the reason for EA’s existence. The enterprise is. After two years of struggle, trying to get that point over to attendees, I can’t tell you how much of relief that is: a real sense of ‘mission accomplished’ for me there.

The other was a throwaway remark by one panel-speaker (William Sheleg from Deloitte, I think, but I may be wrong there), on the lines that “no-one uses TOGAF as per the specification anyway”. Amazingly, almost everyone there agreed: I certainly saw a lot of nodding of heads, and no-one questioned it – it seemed to be general knowledge, but no-one had actually been honest enough to say it before that point. Which brings us to an interesting question from Roger Sessions, namely that if no-one is using the TOGAF standard in accordance with the standard, how come we still call it a standard?

The real standard, it seems, is not the reference-models (which are acknowledged even by the Open Group to be years out of date), nor the current version of the ADM (which is too IT-centric to be usable for whole-of-enterprise architecture, and again quite a few of the Open Group crew will admit that now, if only in private), nor the new Content Metamodel (ditto re too IT-centric to be usable for enterprise architecture), but the guidelines to adapt the ADM to the enterprise context.

Which means that a good EA will also need to be a good metamodeller (to design frameworks that are usable in context), a good process-designer (to adapt the ADM or equivalent to the context), and must be able to work at the level of the whole enterprise, and not just its IT.

(Some other comments came up on the LinkedIn list: first this from Kevin Smith, and my reply: )

I have worked for various companies that “use TOGAF” but when you dig into the detail you find they are either not at all or only 10%.

I actually do use TOGAF. I use it very intensively indeed. But I don’t use it as the ‘standard’ spec: I use it as per the specific part of the spec (now called ‘Part III ADM Techniques and Guidelines’) which describes how to adapt TOGAF and the ADM to a specific EA context. (Much of that was actually better described in TOGAF 8.1, but that’s another story.) Now that the Open Group members are being more open about IT not being the sole centre of EA, we have much more freedom – ‘official sanction’, if you like – to strip out the redundant IT-centrism in the existing ADM spec and treat the hoary old ‘four architectures’ (business / data / application / tech-infrastructure) as just one of many, many possible scope-sets. Rather than going to TOGAF 9, we’re almost better going back to TOGAF 7, but allowing for any scope, rather than the assumption of that time that tech-infrastructure was the ‘only’ scope relevant to EA.

To me the TOGAF ADM is a well-designed (if still not well-described) model for governance of architecture development, describing how architecture-governance intersects with change-governance. If we simplify it right down to a generic process for development of any business-oriented architecture – and then, perhaps, using IT as the worked-example, much like ITIL has done with its Version 3 – we would have an architecture framework that we could use as a true industry standard. The only thing in the way right now is the residual IT-centrism in-built into TOGAF 9 – and we do have a good chance to clean that up over the coming year or two.

As [another participant on LinkedIn, Kirk Rheinland] says, perhaps “The big breakthrough may be getting the EA function to be more related to a business partner / customer relationship manager role, across not only I/T delivery areas, but across all aspects of the business.” Like Kirk and many others, I’m fed up of being sent down to the depths of the IT department, rather than up to the board-level strategists, as soon as I say that I do enterprise-architecture: with luck and a bit of careful PR work, the changes in attitude that I saw evidenced at the TOGAF conference could at last lead to the end of that kind of absurdity.

The tricky part around this change of attitude about TOGAF – the acceptance that it’s not just about IT, and the ‘standard’ ADM is a ‘best-practice’ for a context that rarely exists in the real enterprise – is around certification.

The existing TOGAF 8.1 certification exam focuses on three key areas:

• the general terminology and principles
• the ‘four architectures’ (business, data, apps, tech)
• the reference-models

But there’s general agreement that the ‘four architectures’ are a special case which is almost a distraction, and even overt admission that the reference-models are out of date. Which leaves only the principles and terminology, which themselves are still mostly too IT-centric to be usable for enterprise-scope architecture.

Which means means that the certification is a long way out of line with the actual practice of the industry and the profession. Which is kind of embarrassing, particularly for training-companies who have to train for a ‘standard’ that they know doesn’t work. Several of the trainers I spoke to said that they now include an ‘unofficial’ section in their courses, which explicitly covers the difference between the TOGAF theory and the real-world practice, and how to pass the exam-requirements for the former whilst gaining enough understanding to be able to do the latter. And of course the training is itself still only for IT-architecture, not true enterprise-scope architecture.

The complication is that it’s relatively easy to create a certification for the terminology, the standard ADM and the reference-frameworks, because they’re all things that are relatively easy to define in a form that fits within the constraints of a multiple-choice exam. But that isn’t what people actually use from TOGAF: what they do use is the material on adaptation, and the deeper, more subtle principles of architecture. And it’s not easy – probably not possible, in fact – to define a simple multiple-choice exam for those latter parts of the material, because the skills to use them come only from experience rather than from rote-learning in a classroom.

Which means in effect that, for anything other than the simplest of IT-centric architecture, the current approach to certification is not only meaningless, it’s actively misleading. We’re actually quite close to the point where a TOGAF certification is an indication that someone is not capable of doing enterprise architecture. The implications of that realisation were beginning to sink in during this conference, and again people were starting to be more overt about their concerns on this. If nothing else, it’s now clear we can’t keep going by pretending the problem doesn’t exist and and trying to run away from it by stuffing it into the ‘too-hard’ basket.

My colleague Len Fehskens – the Open Group’s VP for professionalisation and skills-development – has the unenviable task of trying to find a way through this mess: and if we’re to establish EA as a true profession, he needs all the help we can give him. We need to acknowledge that all of us are responsible for finding a workable solution to the ‘certification problem’ – and act on that acknowledgement in whatever constructive way we can, too.

(Cliff Berg, another regular on the LinkedIn list, asked: )

Were there any business people at the TOGAF conference? Or was it EAs talking to EAs?

A few business-folks, I’d say, but certainly not many: courtesy of the previous near-obsessive IT-centrism, they’re still staying away in droves. So yes, it was still mostly “EAs talking to EAs”. But there were a lot of people who weren’t solely from IT: perhaps even as many as half, which is a very big shift from even a couple years ago. And at least in the sessions that I attended, there was also a very much stronger perception that EA needs to become a business-discipline rather than an IT-discipline, and that we need to engage business-folks in any ways we can; Nigel Green‘s work on VPEC-T (values, process, event, content, trust) was just one example of a much more business-oriented approach to architecture and enterprise change.

The ArchiMate language/notation will help, too. Version 1.0 was formally launched at the conference, but they’re already talking about a number of more business-oriented extensions for Version 2.0, which would include alignment with the BRG/OMG Business Motivation Model, for example. That’s likely to be available within the year, but there are already some well-described work-arounds to use it up into the strategic space, and I’ve been talking with some of the ArchiMate crew about ways to extend sideways into the people-space and (non-IT) machine-space as well.

So yes, still mostly “EAs talking to EAs”, but it’s a much more business-oriented EA that’s starting to happen now.