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.

4 Comments on “Summary from the TOGAF conference

  1. Tom,

    I agree with the fact that TOGAF doesn’t do much about business architecture.
    As a practitian and consultant I felt the fact that the current EA frameworks fail to convey a picture of how the business works. In fact the outcome EA has a very small audience because the islands of IT described cannot convey an overall picture of the structure and operation of any Enterprise.
    That being said, I published a book where all layers of an Enterprise Architecture are treated. I provide business reference maps (starting from Value Chains), process maps, alignment to the Enterprise business and operating model, IT applications and technology architecture templates. It’s not that I want to promote the book. But I feel the Business Architecture model and the overall framework work and would help push the EA forward.
    The 3rd edition of the book is available on Amazon and other sites.
    http://www.amazon.com/Enterprise-Architecture-Development-Framework-Practices/dp/1412086655/

    Adrian

  2. Tom,

    Good article. As you know, because we have talked about it at length, that I agree with you on much of this. In fact it is the reason why I went off in 2006 and started work on the http://process.AgileEA.com.

    We are however at risk as an EA industry of spawning too many small break-away “we’ll do it better” sects. We need to all get together and form a central place, with a few common principles and objectives to work towards and release something that is better overall.

    I also think we should be careful of not throwing the baby out with the bathwater. Even if EA is currently too IT centric, and we get it more Business centric, there will always be elements of IT within EA and we need to not lose sight of these elements.

    Charles

  3. Charles

    Agree entirely.

    The practical problem is that the Open Group holds the ‘enterprise architecture’ space at the moment, and despite the shift in mindset described in my post, clearly wants their part of it to remain centred on IT, because that’s always been their main focus. Which is fair enough, but it does mean that there’s a kind of vacuum – hence, as you say, the real danger of proliferating ‘”we’ll do it better” sects’, each purporting o be ‘the new standard’.

    Some of this fragmentation is natural and even necessary – see, for example, the context-specific variants of Linux for enhanced-security or use in embedded systems. But yes, we do need a common ground where all the extended-EA variants do at least share a common foundation. No idea where that will be, but I’m suspecting that the Open Group route has all but run its course.

    Do also agree that EA will usually include some aspects of IT: the scope of enterprise architecture covers the entire enterprise, and IT is definitely (usually!) part of the enterprise in some form or other (if only as pencil and paper 🙂 ). I’m not saying that IT isn’t part of EA, just that’s it’s not necessarily the centre of EA. (To be precise, everywhere and nowhere is ‘the centre’ of EA – the centre is whatever needs to be the focus of our attention in this moment, here, now.)

    There are a lot of us ‘doing our own thing’, just as there were/are with the Open Source movement: any ideas as to what could be our EA equivalent for SourceForge, perhaps?

  4. The company I work at is starting / formalizing its EA practice. We use TOGAF as the roadmap and Zachman as the framework. Another analogy would be that Zachman is our bingo card and TOGAF is the bingo caller.

Leave a Reply

Your email address will not be published. Required fields are marked *

*