Tom Graves / Tetradian

At Dave Snowden’s request, I’ve re-edited my new book Everyday Enterprise Architecture: sensemaking, strategy, structures and solutions to clarify the differences between the Cynefin framework and my own work as described here. That update is now complete, and the amended master-files went off to Lightning Source early this afternoon, so that printed copies should be available via Amazon and the like by somewhen next week (around May 12, I think).

Apologies all round for this unfortunate glitch in the book-launch, but I hope you’ll be pleased with the end-result.

You can download the updated PDF from:

• http://tetradianbooks.com/2010/05/everydayea-ebook/

At the moment the link on that page points to the full e-book, not the sample version. I’ll replace it with the sample when I deliver the commercial master-copy to the retailers, but the full version will probably be up there for the next week or so – nominally until 22 May 2010 – so  grab the full version while you can!

And the updated version is also available, with the others in the series, in the private ‘Review’ section at:

• http://tetradianbooks.com/2008/12/review-books (email me for the page-access password if you don’t already have it)

For more on the book itself:

Main theme of this book is the actual details of what we do in enterprise-architecture work, particularly the thinking-processes, the review and reflection, and the practicalities of dealing with clients and other stakeholders in live real-time real-world practice. I’ve structured the book around a realistic ten-day architecture-project, based on real assignments over the past few years.

(Note for various folks at TOGAF Rome: the working-title of this book was Enterprise-architecture in real-time, so that’s what you’ll see in the notes for the conference, and in the sample PDF file if you took a copy.)

Comments and reviews would be much appreciated!

And another book off to press: Everyday Enterprise Architecture: sensemaking, strategy, structures and solutions. The master-files went off to Lightning Source on Friday, but I didn’t have time to update the Tetradian Books website until this morning.

(Note for various folks at TOGAF Rome: the working-title of this book was Enterprise-architecture in real-time, so that’s what you’ll see in the notes for the conference, and in the sample PDF file if you took a copy. Just before release to press I realised that the ‘real-time’ term was potentially confusing, hence switched over to the ‘everyday’ term to emphasise that the text goes through the process day-by-day as well as step-by-step.)

Main theme of this book is the actual details of what we do in enterprise-architecture work, particularly the thinking-processes, the review and reflection, and the practicalities of dealing with clients and other stakeholders in live real-time real-world practice. I’ve structured the book around a realistic ten-day architecture-project, based on real assignments over the past few years.

The sample-version PDF is at:

• http://tetradianbooks.com/2010/05/everydayea-ebook/

At the moment the link on that page points to the full e-book, not the sample version. I’ll replace it with the sample when I deliver the commercial master-copy to the retailers, but the full version will probably be up there for the next week or so –  grab the full version while you can!

The complete e-book is now available with the others in the series, in the private ‘Review’ section at:

• http://tetradianbooks.com/2008/12/review-books (email me for the page-access password if you don’t already have it)

Physical copies should be available via Amazon, Borders and other online retailers – and your local friendly independent bookstore – from about May 8.

Comments and reviews would be much appreciated!

Update (3 May 2010): As can be seen in the ‘comments’ section to this post, Dave Snowden, the originator of the Cynefin framework, has made a number of objections, necessitating an urgent re-edit. Production for the book has been postponed until an updated master-file can be created, which should be ready later today. Will add a further update on that here, anyway.

Update (also 3 May 2010): Checking through the text, it looks like there will need to be approximately 40 changes to the text, and 26 diagrams to redraw. Most of the text-changes will be trivial, fortunately, so that shouldn’t take long, but redoing all those drawings will definitely take a while – I’d hoped to get it all done today, but it may overrun into tomorrow. My apologies on that, and also apologies for the problem anyway. More later.

Several people have asked me for more information about the book I’m writing at present, ‘The Business Anarchist‘, so here’s a quick summary of the themes and structure.

Who or what is a ‘business-anarchist‘? Anyone who works with inherent uncertainty in business in an intentional, disciplined way – working with the uncertainty rather than trying to ‘control’ it. Often it’s not so much a person as part of a business-role – a necessary part of that business-role. (Most of the examples in the book will come from my own field of whole-of- enterprise architecture, but the same principles apply in just about every other type of business-role.)

Why ‘anarchist’? Anarchy is about working without rules, working ‘outside the box’. When ‘business as usual’ breaks down, a disciplined form of anarchy is probably the only way through to something new that works well in the new business context.

‘Kiddies-anarchy’ and real anarchy: Anarchy has had a very bad press in the past, mainly because of what I describe as ‘kiddies-anarchy’ – an overdose of presumed ‘rights’ without responsibilities, especially in terms of causing disruption and destruction without any awareness or respect of the consequences for anyone else. Real anarchy is very different – arguably the most difficult of all political forms, because there are no easy rules to fall back on or to blame. Some entire organisations have been run on anarchic lines – the Quakers have done so for centuries – and even some businesses – such as Ricardo Semler’s Semco Group – but here we’re mainly focussing on an often-unnoticed yet everyday set of roles and responsibilities within an ordinary, everyday type of business.

What kind of business? Any business, and any type of business – for-profit, not-for-profit, government or social – from a huge global conglomerate right down to the local bridge-club or the school parent/teacher association.

Business-analyst and business-anarchist: Business-analysts deal with certainty and predictability: they refine the figures, crunch the numbers, track the trends. When your business world is reasonably stable, you need your analysts to help you optimise efficiency and maximise returns. But when your business world is not certain, not predictable, that’s when you’ll need your anarchists. And you’ll need your anarchists then, too. Your analysts can only tell you how to do more of the same, better – which is good, of course, in its own context, but it doesn’t help when what you really need to do is something different.

What’s different about how business-anarchists work? The quickest one-line answer is that analysts rely on rules and algorithms; anarchists rely on guidelines and principles.

What principles should business-anarchists rely on? Obviously this varies from one context to another, but from my work in whole-of-enterprise architecture the three most important design-principles seem to be these:

• There are no rules;
• There are no rights; and
• Money doesn’t matter.

These three principles, and a fourth follow-on principle, Always enhance adaptability, provide the overall structure for the book.

There are no rules: Rules provide a spurious sense of certainty that can let us down badly when our business-world changes around us. The real world is much messier and more complex than any system of rules that we could devise. Hence at times it’s necessary to start off from the assumption and expectation that there are no rules: instead, we have to rewrite the rule-book, by working back to the core-principles from which the rules originally arose. A simple everyday business-example of this is embedded in the ISO-9000 standard on quality-systems:  work-instructions provide ‘the rules’ that we need for real-time practice and process, but when the world changes, we need to rewrite the work-instructions by working upward to procedure, policy and, if necessary, overall vision.

There are no rights: ‘Rights’ are an important social fiction, but as with rules, they don’t actually exist in the real world, and in themselves they tell us almost nothing about how to create the conditions that such ‘rights’ would require. In practice, apparent ‘rights’ arise from mutual, interlocking responsibilities – so it’s those responsibilities, and not the purported ‘rights’, that are where we need to start. This has important implications for business-architecture and enterprise-architecture that will be explored in some depth in the book – for example, we need to ask serious questions about “What do shareholders own?” if they possess all the ‘rights’ for the business but without any real responsibilities.

Money doesn’t matter: Money is important for every business, of course, especially in a commercial context – but as with rules or ‘rights’, it’s not the place where we need to start. Money is also only one small part of the overall economy in which the business operates: reputation, trust, attention and respect all need to exist before any money will be placed on the table. And if we state – or show – that we’re only interested in ‘making money’ from our customers and community, why would anyone want to engage with us? As with other ‘rights’, money is solely a social fiction, and profit is an outcome of being ‘on purpose’ to values: to achieve the profits that we may desire, we first need to start from values, with a values-architecture that describes how we engage with everyone within the extended-enterprise of the business.

Always enhance adaptability: Change is the only certainty: we therefore need to design for that fact. Mistaken notions about rules, rights and money often serve only to slow us down, placing the business at risk as the world changes around us. This sections of the book explores how to embed the ‘business-anarchist’ principles into everyday business-practice, especially in business-architecture and enterprise-architecture.

—

More details to follow over the next few days, including book-cover, cover-blurb, ISBN numbers and so on. Publication-date is fixed as late-April, so I need to keep moving!

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.

(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.

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!

Delighted to say that I’ve now completed the next book in my ‘Tetradian Enterprise Architecture’ series, Doing Enterprise Architecture: process and practice in the real enterprise, with the master-files now delivered to Lightning Source for printing.

The sample-version PDF is at:

• http://tetradianbooks.com/2009/03/doing-ea-ebook/

The complete e-book is now available with the others in the series, in the private ‘Review’ section at:

• http://tetradianbooks.com/2008/12/review-books (email me for the page-access password if you don’t already have it)

Physical copies should be available via Amazon, Borders and other online retailers – and your local friendly independent bookstore – from about April 21.

Comments and reviews much appreciated!

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.

Back at the TOGAF conference, something that really seemed to be missing was any real description of doing enterprise architecture – in particular, what changes and needs to change in EA practice at each stage of architecture maturity, and how each layer builds upon the next.

It’s barely mentioned in the TOGAF 9 specification, either: Chapter 51 ‘Architecture Maturity Models’ describes the overall notion of architecture-maturity, but doesn’t explain how that affects EA practice. I’ve seen a few references elsewhere, such as in Dana Bredemeyer’s work, and in this article from the CIO Magazine website, but that’s been about it. Most of those focus on how to identify the maturity-level – not what you have to do to get there. And, of course, almost every description is only about IT-architecture – not the full scope of real whole-of-enterprise architecture.

So yes, another topic for yet another book. Which, perhaps unsurprisingly, will be titled Doing Enterprise Architecture: process and practice in the real enterprise. Aim is to get it ready in time for the next TOGAF conference in London, in late April, but in the meantime I’ve put up the cover-picture and blurb on the Tetradian Books website. A first-cut preview should be up on the site within a couple of weeks, I’d hope – more later on that as the work progresses.

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?