Tom Graves / Tetradian

Better write up some of my notes and memories from the TOGAF Hong Kong conference before I forget them!

Like every TOGAF conference there were some of the same ‘usual suspects’ (including me, of course! ) with their current version of the same developing themes for enterprise-architecture – such cloud-computing, security, TOGAF itself, and (in my case) expanding out beyond IT. But what made this conference special for me was the unique Chinese perspective on what has historically been a somewhat Anglo and technology-driven construct.

This difference in perspective was highlighted especially in presentations that came from three contrasting aspects of Chinese business: a large software-development and training house, a major university, and the Chinese arm of a large US-based multinational.

(Another long post, so continues after the ‘More’ link…)

Read more…

Another month, another enterprise-architecture conference, in the hope that it won’t be just another more-of-the-same ‘IT-architecture pretending to be enterprise architecture’. This time, at the IRM-UK Enterprise Architecture Conference 2009 (EAC2009) in London earlier this week, that hope actually showed some real signs of fruition.

Sure, there were plenty of signs of the usual IT-centrism. Roger Sessions is one of those still fighting the rearguard for that cause, mainly because he (correctly) points out that there is a very real need for organisations to clean up their IT act, and always will be. (To illustrate his point, there was an excellent presentation from Johan Krebbers, showing how Shell is using a classic TOGAF-style EA in managing the huge complexity of their IT space.) My concern, and that of what is now a rapidly-growing number of enterprise architects at the conference, such as Sally Bean, Richard Veryard, Chris Potts, Anders Ostergaard (Jensen), John Gotze, Kristof Dierckxsens and Nigel Green, is that starting from IT as the primary (or only) focus is the wrong way round for doing EA: we must start from the whole-of-enterprise scope, and only then explore the information needs, in parallel with all of the other needs of the enterprise. It’s startling how few still of the IT-folks manage to grasp this central point, but the wave is growing.

John Gotze and his co-authors may help in that shift with their upcoming book Coherency Management. They describe three distinct tiers of enterprise architecture:

• Foundation – conventional TOGAF-style ‘enterprise architecture’, centred around IT, and with business-architecture (if any) aimed solely at improving ‘business/IT alignment’
• Extended – what I’ve been promoting as ‘enterprise architecture’, covering the whole-of-enterprise scope, but maintained primarily by an explicit (and, in the earlier stages, often quite large) team of full-time enterprise architects
• Embedded – what I’ve described as ‘hands-off’ architecture, in which the ‘ownership’ and responsibility for the architecture is distributed throughout the enterprise and becomes an embedded part of business-as-usual practices, much like security or health-and-safety

As they say somewhat ruefully in their chapter-summary, the ‘Foundation’ level is “the predominant form of EA practiced today”, but we need to be aware of and build towards ‘Extended’ and ‘Embedded’, rather than leaving us stranded in the limited and limiting IT-centric space. I’m definitely looking forward to reading that book when it comes out in a few weeks’ time.

In the meantime, one of the industry’s living legends was also presenting at the conference: John Zachman. It’s amusing that he still hasn’t made it into the Powerpoint age, let alone anything more current: he did his presentation on a museum-piece of an overhead-projector, reading every word off the transparency with a little hand-shaped pointer, like the worst of school rote-learning from half a century ago. And I do still disagree with his core metaphor of ‘engineering the enterprise’, which is fatally flawed by its failure to make any allowance for the fact that, by definition, an enterprise is a social system, not a machine – and that failure inevitably leads to serious problems in the architecture and in management practice. But the real surprise was at the human level: for someone so famous in ‘the trade’, he is such a nice guy! Engaging, warm, personable, genuinely friendly, genuinely inclusive, genuinely comfortable with critique: a real pleasure, and a real example to us all, I suspect!

A very different conference from the TOGAF ones, in many subtle ways: a much stronger emphasis on practice over theory, for example, and on real-world practitioners rather than primarily the large consultancies. The big-consultancy hype was better held at bay, too – much more realism around cloud-computing, for example.

And I had a lot of good conversations with a range of different folks, again most of them in the live practice space. Much appreciated, and most enlightening in most cases. So yes, I’ll be going to EAC when it comes round again next year. Pricey (of course), but recommended.

Yikes! Talk about misinterpreted in a sound-bite…

(Before I go any further, a note to all in the TOGAF training/education community: from what you’ve read elsewhere, you may at present believe that I’ve been attacking you personally. As you’ll see below, this is not the case – so please accept my apologies for others’ interpretations of what I wrote. Do read on – and thank you.)

There are a few Tweets going round that suggests I’m attacking TOGAF (again), this time by suggesting that TOGAF training is worse than useless:

harsh deduction by @tetradian: TOGAF certification almost an indication that one is NOT capable of doing #EA

“… close to … a TOGAF certification is an indication that someone is not capable of doing enterprise architecture.” http://bit.ly/uZDZd

I’ll admit my original post summarising the London TOGAF conference last month does indeed include that latter quoted text. But it’s quoted way out of context: so please, do read the whole post before you jump to that conclusion! – because it isn’t what I’m saying at all.

First, it’s not my own ‘deduction’: it’s a near-verbatim report from a broader discussion at the TOGAF conference. From the certification perspective, four key themes came up from the conference, all from leading members of the TOGAF community:

• the reference-architectures (Part VI of the TOGAF spec: ‘Technical Reference Model’ and ‘Integrated Information Infrastructure Reference Model’) are way out of date, and at the least need a complete overhaul, if not dumped altogether [that was from the Open Group's lead Allen Brown, in one of the plenary sessions]
• “almost no-one” uses the ADM in the form described in the TOGAF specification [in my last post I said I thought that was one of the guys from Deloitte, but my notes indicate it was Mike Lambert from Architecting the Enterprise, one of the lead TOGAF training groups]
• enterprise architecture is much broader than IT, and must now encompass the whole of the enterprise [that theme came up at least a dozen times, in plenary sessions and elsewhere]
• enterprise architecture needs to be understood as a professional discipline, comparable to other professional disciplines such as medicine and building-architecture [again, many people, but particularly Len Fehskens, Open Group VP on Skills and Capabilities]

These are all points that, yes, I have personally pushed hard over the past few years: but you can see from the above that it’s not just me that’s saying it – it’s being echoed now right from the centre of the TOGAF community itself. (Just this once, I’m not ‘the Outsider’ here! <wrygrin>)

So, to the problem of certification. The key point is that certification alone is not an indication of professional competence. Back in my aero-engineering days, it was common knowledge that newly-graduated engineers were a potentially lethal danger to everyone in the place: they knew just enough to think that they knew what they were doing, with that arrogant certainty of the newly-qualified, but had no idea of how to work with the subtle complexities and constraints of the real world of engineering. For example, they would specify components that couldn’t actually be made, or assemblies that could be made but couldn’t physically be assembled. Even for the best, it usually took a year or two at least “to learn how to make my mathematics sufficiently imprecise to be usable”, as one of them put it. Crucially, there were a few who never learnt that lesson, and instead clung on to their certification as ‘proof’ that they were competent – which in practice more proved that they were not competent to be let loose on a real aircraft. Or, in this context, a real enterprise.

On its own – and again I’ll emphasise, on its own – an enterprise architecture certification does not and cannot indicate competence: it needs to be balanced by real-world practice. For which, again, crucially, this profession at present has no means to monitor or measure.

Next, look at what’s actually covered in the existing TOGAF certification: it’s primarily about the ‘standard’ ADM and the reference-models – which are no longer used in that form in practice. And – as also indicated in those themes from the conference – real enterprise architecture is much, much broader than IT: yet everything in the existing certification is centred on IT. So anyone who does slavishly follow the ‘standard’ will be almost guaranteed to create an architecture that might at first seem ‘efficient’, but will be so outdated, so IT-centric and so far off the real mark that it will at best be useless, and possibly much worse than that.

What the old TOGAF 8 certification exam did not cover was how to adapt the ADM to the enterprise, or how to create reference models and use them for compliance-monitoring and risk-management – which is what is actually most needed in those stages of architecture that the TOGAF spec aims to cover. And there’s no way that any of that kind of context-dependent knowledge could be assessed in a simplistic multiple-choice exam such as is still used for TOGAF certification. As I mentioned in the previous post, I nearly failed my TOGAF exam because in many parts of the test, none of the options shown on the screen actually matched what I knew from experience works in practice, and the nearest available guess turned out to be ‘wrong’ according to the specification in the book. Conversations at the conference made it clear that I was far from alone in that experience: in effect, anyone who presents a high score in their TOGAF certification may have the book-knowledge but know nothing about the practice, whereas many will score low because they are competent in practice. So as it stands, the TOGAF certification not only tells us nothing about professional competence, but can be actively misleading: a high score may well indicate that someone is not competent to do the work, whereas a low score indicates either high competence or complete failure, with no apparent means to distinguish between those two extremes.

All of which adds up to a serious problem.

It does not, however, mean that TOGAF training is wrong. Quite the opposite: many of the trainers I talked with at the conference made it clear that their training-courses emphasise the importance of adaptation of the ADM, development and use of reference-models, and all the other skills needed to assess and adapt to the enterprise context, and how to extend EA beyond the IT domain itself. To develop those professional skills, we’re likely to need more training, not less; and much of that training needs to be context-specific, too. The catch is that almost none of this material is in the current TOGAF specification, and none at all is assessed in the current TOGAF certification. So yes, whilst to my mind the TOGAF specification is still annoyingly limited and limiting, that’s not the real problem in this case. The point here is that, as it stands, the TOGAF certification is not only meaningless but actively misleading: and right now that is a real, genuine, active, in-your-face, fundamental problem for the profession.

This is a problem that’s being addressed: as I said in the previous post, Len Fehskens is specifically tasked with this on behalf of the Open Group, and others are tackling it in other ways with other groups. But we must first acknowledge that it is a real problem, and one that won’t go away simply by ignoring it, which is all that had been happening to date. So, yes, whilst it’s an uncomfortable fact to face, one of the key signs that the EA profession is maturing as a profession is that it is now willing to face up to such uncomfortable facts.

‘Bad’ news that’s good news all round, in fact.

Delighted to say that Lightning Source have done it again with my new book Doing Enterprise Architecture: a one-week turn-round from sending in the PDF source-files to delivery of the first fifty copies on my doorstep. Very impressive.

And the print-version is now available on both Amazon.com and Amazon.co.uk – those two links point direct to the respective Amazon detail-page. For other online retailers, or your local friendly independent bookstore – like the ever-helpful Red Lion Books in Colchester – use the ISBN book-number: 978-1-906681-18-0

I’ll also have copies to hand out at the TOGAF conference in central London next week – see you there, perhaps?

Please pass the word on for me, if you would? Many thanks!

Just had confirmation from the Open Group that they’ve accepted my proposed presentation for the TOGAF London enterprise architecture conference at the end of April. Working title is Stepping-Stones of Enterprise Architecture, with the following abstract:

TOGAF 9 includes a well-described architecture capability-maturity model. This session, illustrated with practical examples from a wide range of industries, explores how to use the maturity ‘stepping stones’ to guide the choice and sequence of architecture activities, in a way that expands outward to engage the whole enterprise.

The ‘takeaways’ would be as follows:

• how to use TOGAF 9 at a whole-of-enterprise scope
• how to use the TOGAF 9 maturity-model as architecture ‘stepping-stones’
• how to use enterprise values to bridge across the IT/business divide

In other words, the same overall themes that I’ve been pushing hard for a couple of years now, about how to adapt TOGAF and the like to work with the real enterprise, rather than solely the tiny subset that is its IT.

Variation this time is that I’m using the TOGAF maturity-model (adapted from COBIT or CMMI, I believe?) to show why we need to do things in what is actually a very different order from what TOGAF itself suggests, and why we have to bend the TOGAF-ADM quite radically in order to make it work for the real enterprise.

The detail for all of this will be in my upcoming book Doing Enterprise Architecture: process and practice in the real enterprise – which I now definitely have to finish and get published in time for the conference! (I’m still just about on schedule, but the timing will be tight – wish me luck, perhaps?)

And if you’re going to TOGAF London, I look forward to seeing you there.

Okay, back ‘home’ in England after the TOGAF conference in San Diego. Time to reflect a bit.

First: a real sense that I’m not as on my own in my approach to enterprise-architecture as I thought and felt I’d been: there are a lot more folks out there now who recognise the inadequacies of standard IT-centric TOGAF, it’s just that in many cases it was still at the level of a feeling of discomfort rather than explicit articulation.

(In that, I owe an apology to Len Fehskens and Walter Stahlecker, who did indeed articulate that discomfort at the TOGAF Munich conference last October. After I first saw their presentations at Munich on ‘the future of EA’, it did feel that a fair bit of had been all but lifted from the conversations I’d had with them at previous conferences; but I now acknowledge I’d done an Isaac Newton, claiming exclusive ‘possession’ of ideas that were more out there in the general aether. The simple fact is that they’d arrived at much the same conclusions as I’d done, but each from an entirely different direction: I should have celebrated that fact rather than being annoyed about it! :wrygrin: )

Anyway, for me, a lot of very good conversations: the mood seemed far more receptive than before to ideas about the need to get out of the IT-centric rut and move to a more explicit whole-of-enterprise perspective. Having the books definitely helped in that: in street-value terms, I must have given away something like $3,000-worth of books, plus probably much the same in e-books, but it meant that I had something concrete and (literally) tangible to back up my thesis about the need for a broader EA scope, and it certainly helped in terms of establishing credibility. It was really noticeable, though, that the people who picked up on the ideas quickest were almost all outside of ‘mainstream’ EA – either in non-information-centric industries and contexts (such as one of the US federal government departments, or again a large logistics operation), or from countries outside of the US/British ‘axis of IT-centrism’ (such as Norway, Malaysia, Japan, China, Switzerland, and, of course, the Netherlands).

Some parts of the conference were excellent – particularly the business architecture sessions led by Bob Weisman – but some were appalling, bluntly. The lead keynote speaker said almost nothing useful beyond sales-pitch, and even somewhat sarcastically that EA was irrelevant to his own work – which was not a good start…  And at least two of the plenary sessions on cloud-computing were blatant sales-hype, with nothing of substance behind them at all: a bit disappointing, to say the least (which to my mind was true of the entire cloud-computing hype, to be honest – I’m seeing all too many memories of the ‘Business Process Re-engineering’ farrago a few years back, such that it’s clear that no lessons have been learned from that debacle at all). But there were some definite highlights, too, such as Bob Weisman‘s presentation on “Enterprise architecture: the strategic tool for innovation in tough times”, and Chris Armstrong‘s presentation on “Agile enterprise architecture”: in that sense, it was worth going there, regardless of the TOGAF 9 launch.

And TOGAF 9 itself? Well, I’ve had more of a chance to look at it in depth (i.e. something to do in the long long waits at airports, and on the flights themselves…), but I’m still disappointed at the lost opportunity that it represents. To be fair, The Open Group is focussed on “boundaryless information flow”, so the over-emphasis on IT should hardly be a surprise; and the history of TOGAF itself, certainly from version 7 onwards, represents a slow climb up from the IT-centric depths. But although the Open Group may need to emphasise information above everything else, that isn’t true of the enterprise-architecture discipline as a whole: and since TOGAF is the leading framework here, that imposes some really frustrating and unnecessarily arbitrary limitations on where and how we can use it. Hence the disappointment.

There’s no doubt, though, that from an IT-architecture perspective, TOGAF 9 is a huge improvement on the previous version. There’s been a lot of clean-up, it’s far better structured, the Content Framework (adapted from CapGemini’s IAF, apparently) and Capability Framework (from Bob Weisman) look like a good basis for future standards for interoperability and architecture governance. And there’s some explicit guidance on how to link across to SOA and security-architecture – though, like me, some of those practitioners are a bit disappointed that the links don’t go far enough into their respective spaces.

Yet despite all that good effort, it still doesn’t work properly for iterative architecture, or for anything outside of an IT-centric scope. And the reason is exactly the same as before: the absurd assertion that all enterprise architecture can be crammed into a fixed scope of ‘anything not-IT that impacts on IT’ (the proper meaning of what they term ‘business architecture’), ‘information systems architecture’ (IT-only) and ‘technology architecture’ (again, IT-only). It does sort-of work for low- to mid-level EA maturity; but it acts as a rigid block against moving any further in maturity-levels – and that move is what business is demanding now.

The good part, I suppose, is that the critiques and solutions I developed in Bridging the Silos and Service-Oriented Enterprise apply to and work just as well with the new version as they did with the old. I’ve now set myself the target of doing a new ‘TOGAF 9 edition’ of Silos in time for the next Open Group conference in London, in April: on that, Watch This Space, as usual?

In transit to San Diego, for the Open Group conference and the launch of TOGAF 9. Weighed down with what feels like a ton of books (though it’s probably only about 30kg – I’d hate to have to carry a literal ton of books…) to hand out there, as an ideas-and-marketing exercise: if you’re going to be there, give me a yell somewhen.

Otherwise, yes, probably expect even more erratic service than usual for the next few days – especially today and Thursday/Friday, which will be eaten up with travel.

Best wishes to all.

I hadn’t intended to go to TOGAF Munich this week, but a chance email from Jos van Oosten (the lead for the SqEME process framework, over in the Netherlands) got me glancing at the conference agenda – and what I saw there sent me scurrying to search the web for suitable flights. It was previously advertised as being solely about system security – which isn’t my bag at all – but the Tuesday sessions suggest that they’re at last breaking out of the IT-centric rut and getting to grips with whole-of-enterprise architecture – which would be very good news if so… So yup, I’s headin’ there kinda quick to find out, and see which way that wind is blowing.

One side-effect is that I’ve rather hurriedly ‘staked my claim’ to the rework I’ve done on adapting the TOGAF Architectural Design Method (ADM) for use at the whole-of-enterprise scope, with a two-page / single-sheet reference-sheet now posted up on the Tetradian Books website. (Doing this before their conference presentations should verify that I did indeed get there first. ) More on that in the next post. Some time in the near future I’ll also post an equivalent ‘cheat-sheet’ for the revised Zachman framework for whole-of-enterprise architecture.

And although I’m still some weeks away from completing Bridging the Silos, I’ll also post an updated draft on the publishing website, to include the material I’ve slowly been adding over the past few months. Apologies that it’s taken so long, but I’s been kinda distracted…