Saving enterprise-architecture from itself – 2: Personal background

Why do I worry about enterprise-architecture? And who the heck am I to worry about it? What kind of right have I got to criticise anything that anyone does in this space?

Okay, let’s forget the idea of ‘rights’ for a moment, but yeah, these are all valid questions, and they need honest answers if this exploration is to go anywhere meaningful.

Who the heck am I to talk?

Why do I worry about EA? Well, short answer is that I worry about it because I worry about it: that’s it, really. It’s a field that means something to me – means a lot to me, in fact. So yeah, I worry about it. Lots. Does anyone really need any more reason than that?

Who the heck am I to worry about EA? – by which most people would probably mean something like ‘what experience do you have?’ or ‘what official authority do you have?’ That one’s going to take rather more explaining, so I’ll split it up into smaller chunks:

• Am I qualified to do EA? – Given that at present there are almost no formal/academic qualifications in EA, I’ll guess that’d mean something closer to ‘what are my academic credentials, for anything?’ Quick answer is that I have a DipAD (BA or BSc – it’s convertible to either) in graphic-design, and an MA in ‘general studies’ from London’s Royal College of Art (yep, I’m one of the few people formally-qualified as a generalist). But those were both nigh on forty years ago now – so perhaps not especially relevant to what’s happening right now, other than that I’ve had a lot of practice since then with what I learnt there. Rather more recently, I did a Grad.Cert in Strategic Foresight: it was supposed to be a three-year MSc course, but I gave up after the first year after some fairly major disagreements with the professor there.
• Am I certified to do EA? Not really. (But is anyone, really?) For what it’s worth, I have a now-outdated TOGAF 8.1 certification, but which I’ve never really needed for any of the gigs I’ve done. (Instead, I found it more useful to rewrite the TOGAF ADM from scratch: you can see the result in my book Bridging the Silos.)
• Am I an academic specialist in EA? Nope: not in the usual sense, anyway. I ran away from that one a long time ago: academic-politics is even worse than business-politics… and having done some serious citation-trail tracking in one of my professional gigs a few years back, I’m now pretty cynical about the validity – or lack of it – of the whole ‘academic thing’, especially in the social-sciences.
• Have I worked for any of the big EA-consultancies? Nope. (I did once get an invite to join one: got as far as second-interview, after which they couldn’t even be bothered to tell me I hadn’t got the job. I wasn’t exactly amused, to be honest: but having seen what’s happened to various friends and colleagues who have joined them, I’m kinda glad I didn’t get the job, now.)
• Have I worked for any of the big IT-consultancies? Nope.
• Have I worked for any kind of big-consultancy?? Nope.
• Have I worked for any kind of consultancy at all??? Nope. (Other than in my own, as a sole-proprietor, of course.)
• How long have I worked as an employee in EA? I haven’t. (I’ve never yet been a ‘proper’ employee anywhere, and not exactly keen to be so, either.)
• How many large-scale EA projects have I directed, from start to finish? None. I don’t do that kind of work: I’m quite adamant that that needs to be done by internal staff with deep social-networks, not external consultants. (And EA should never be a ‘project’ anyway.)
• How many EA-capability setups have I directed, from start to finish? None. (Actually, that’s not quite true: the real answer is ‘One’, except that I pulled the plug on it myself when it became painfully clear the organisation was a long long way from ready for being able to use it.)
• How long have I worked in EA at all, then? Something like ten to fifteen years at least, but arguably more than forty.

In short, it all kinda depends how you define ‘EA’. Which is the whole point of this series in the first place.

What you should get from this is that, from the perspective of the usual kind of mandated, sanctioned, officially-recognised career-path and the rest, I’m so far out of the ballpark that at first glance it doesn’t make any sense. By most conventional standards, I’m barely ‘qualified’ at all.

And yet that’s the whole point here: I don’t fit. Yet that’s exactly why I’m good at what I do.

Fact is that, yeah, I’m probably not much good now at doing standard in-house EA – the kind that most people with ‘enterprise-architect’ on their business-card would do. But I don’t claim to be much good at it, either. (I can do it – I’ve actually done quite a lot of it – but I’m probably way too far out of date now on detail-level technologies and suchlike.)

What I do do is the other kind of enterprise-architecture: applying enterprise-architecture to enterprise-architecture itself. In other words, helping EA teams get started, and lift their game, to cope with ever-larger and more-complex business-problems. My value is precisely that I can, and do, look at a context from outside, in many, many different senses of ‘outside’. And I’ve had a lot of practice – professional practice – at doing just that, across many different domains, disciplines, industries, companies, countries and continents.

In short, I’ve seen ‘the trade’ from just about every angle – whereas many (most?) nominal ‘EAs’ barely see it from one… I’ve also researched and developed and written a heck of a lot about it over the years: maybe a couple of million words on it on this weblog alone, for example, plus a whole bunch of original frameworks such as Five Element, Enterprise Canvas, SEMPER and SCAN. And it’s for that reason that yes, I definitely am qualified to talk about enterprise-architecture – arguably a lot more so than most people who wear the ‘enterprise-architect’ job-title.

[Actually, everyone involved in an enterprise is, by definition, qualified to talk about its architecture – and that applies just as much to the architecture of the enterprise called ‘enterprise-architecture’. It just helps to know something about it, that’s all… 🙂 ]

Two EA gigs…

I first started getting into ‘EA proper’ back in Australia, around a dozen years ago. The real trigger would have been the nightmare problems that one of my clients was failing to address, around long-term knowledge management – relying on IT-based solutions that simply went obsolete over those time-scales, because there was no attention to any of the human element or whole-system awareness needed to keep it working as a whole.

(To give you some idea, for one of our projects there, we had to retrieve key data from the high-technology used at the original time: nine-channel mag-tape. Ever wondered how computer-museums keep going? – well that’s how. Oh, and no metadata on any of that: ever tried to make sense of a huge table of test-data, consisting of rows and rows and columns and columns of figures, with no headers of any kind at all? Fun…? Nope: and very expensive, too, in a lot of different senses of expensive. Yet another reason why whole-of-context EA matters, folks…)

Two gigs really stand out for me from this period.

The first was with Telstra, Australia’s part-nationalised telco. The project was labelled as ‘business-transformation’, though the primary focus was about getting some kind of rationalisation into the business side of Telstra’s IT-estate. The core framework we used was Telemanagement Forum’s eTOM/SID/NGOSS set, nowadays rebadged as Frameworx. Notice that the matrix-structure of the eTOM framework covers the whole of the business-space – not solely the IT:

(There’s also a really nice video of a 3D-style Frameworx toolset on Vimeo.)

I’m sorry to say I can’t remember the name of the project lead there – a cheerful Italian or Greek guy – but his right-hand man was Bob McDowell. Wonderfully wry and laconic, he had a deep, deep social-network throughout every part of Telstra, and, from many years of first-hand experience, knew how to navigate every nook and cranny of its often labyrinthine politics. It was from him that I learned just how important this was for any EA project – and also recognise that I myself would never be able to do it, since I just did not have (or would have) that kind of long-time depth-experience in just that one organisation.

My own work – which I gather is still in use there – was in data-architecture and information-architecture, for which we had three distinct layers: the usual logical-to-physical mapping, and an additional layer about the business use of information. And that was a key point there: it was not solely about information-technology, but about information in its broadest sense – including all of the human processes and skills that were needed to derive business-sense and business-meaning from the information. Again, a foundational point for my understanding of EA.

From there, I moved on to another business-transformation project, at Australia Post, under the brilliant leadership of Helen Mills. Like Bob McDowell, she and her immediate team had an encyclopaedic knowledge of the organisation, its systems, and the history of those systems. (Again, ‘systems’ in the broadest sense – not solely the IT.)

Our brief was to tackle business as whole, across the whole of the Mail & Networks division. (‘Network’ in this case meant the mail-network, not the IT-network – IT-systems did figure in there, quite a bit, but overall it was much more about trucks, depots, sorting-lines and suchlike.) And we needed an EA framework to guide our work. Some time before I got there, they’d already reviewed TOGAF (version 8, I think, or maybe 8.1), and rejected it as too narrow in scope: pretty much IT-only, they said. We also took a fair look at FEAF, in part because it did mention non-IT items such as ‘Human Capital’ and ‘Other Fixed Assets’, but in practice, for our purposes, it was no better than TOGAF – they merely mentioned those items, on one diagram (FEAF-PRM), but that was it, with no other detail at all. It soon became obvious that our only option was to ‘roll our own’.

Which we did. One of the core assertions was that, in principle, any process and its associated information could be implemented and managed via any appropriate combination of people, machines and IT – often shown as an explicit triangle of relationships, as indicated in the central view of this tetrahedral ‘pyramid’. (The other dimension on the tetrahedron is ‘Purpose’, which I added somewhat later.)

Probably the key EA-artefact was the ‘Functional Business Model’, a three-to-four-tier mapping of every aspect of the work of the division, usually shown in three-tier form on an A3-sized graphic (but still readable at A4-size) – in essence, ‘the organisation on a page’. It was hugely popular: without any prompting from us, pretty much every manager printed out their own copy, in pride of place on their office wall – it was used for their own training, business-planning, ‘who to call’ mapping and much else besides. We built up a whole suite of cross-maps on that base: business-information clusters, physical information-systems, process-flow relationships, project-impact maps, investment-maps, even activity-based costing. In other words, from just one diagram, our EA could trace directly, for example, between investment spend, potential change-project synergies, equipment-lifecycle impacts, and operational costs at run-time. Pretty impressive: which is one reason why, for much of the time, we worked directly at whole-of-executive level – not just with CIO or CTO, but with the whole of the C-suite, and more.

Oh, and at some point we took over the so-called ‘enterprise-architecture’ unit, which, yeah, was almost exclusively IT. (I should have taken a warning from that, but didn’t notice at the time…) We split their team and work into two parts: those who still thought EA was only about IT went back to form a new IT-architecture unit, explicitly named as such; but those who really did understand the concept of a literal ‘the architecture of the enterprise’, we kept with us, and gladly. They were pretty glad to escape from their previous IT-only world, too…

But good things come to an end, and for various personal and practical reasons it became clear, by late 2006, that it was time for me to head back to Britain. Where I expected that the EA practices and disciplines would be much more mature and advanced than what I’d experienced in what I – like so many others there – had presumed to be the business-backwaters of Australia.

That was the dream. The reality, though, turned out to be a really nasty shock.

…and an EA disaster

“Yes, it’s an enterprise-architecture role. What are your Java skills like? – that’s an essential for this one.” Yeah, I blinked: What the…? That was the first of some five hundred or so supposed ‘enterprise-architecture’ jobs I followed up during those first few months back in Britain: yet it turned out to be almost entirely typical. Over the whole of that time, there wasn’t a single listed ‘EA’ job, anywhere, that covered anything that in any way resembled the kind of scope or scale of the whole-of-enterprise architecture-work we’d been doing in Australia: it was all IT-only, and often ludicrously low-level IT at that.

When I did eventually get a gig, the main reason I got it was because, when they asked me to develop their EA “according to the Zachman methodology”, I told them that I couldn’t do it. “Why not?” My answer: “It’s because it doesn’t exist.” (It didn’t at the time; it does now, sort-of.) “Oh”, they said, “no-one ever told us that before…”. Although that gig did work out fairly well in the end, I remember clearly the ‘Yikes…!’ feeling I had at that moment: what the heck kind of mess have I gotten myself into here? Is it really that bad everywhere?

Yep: it was. (And as far as I know, it still is, though it’s a long time now since I bothered wasting much effort looking at the recruiters’ pages and pages of ‘EA’ disaster-areas online.) It was appalling. It was atrocious. So darn pathetic that I just wanted to cry. (Which I did, a few times, just out of sheer frustration…) This isn’t enterprise-architecture, it’s a joke – and a really bad joke, at that. How the heck did it get to be this bad?

It took a while, but in the end the real reason became: that age-old warning of “follow the money”. For the big IT-consultancies, all of the money at that time was doing big-IT for big organisations in banking, finance, insurance, and tax. (If anyone had been honest about it, much if not most of the ‘EA’ work was actually in tidying up the mess previously caused by those same big IT-consultancies – but that’s another story, of course.) Hence the whole darn discipline pretty much sleepwalked itself into a circular-definition, which in time became a full-on term-hijack that they didn’t even realise was a term-hijack: “enterprise-architecture is only about IT for banks, insurance, finance and tax, because, well, the work that we’re doing is in IT for banks, insurance, finance and tax, and that’s what we call enterprise-architecture, so that’s what enterprise-architecture is“. And these guys thought of themselves as the rational, logical, analytic end of business? Sheesh…

Yeah, it really was that bad. And for the most part, it still is: that’s the problem.

It got worse. For a while, anyway.

I went to few Open Group conferences, thinking that, from what it claimed, TOGAF should be about enterprise-architecture. And it was, sort-of: but only a tiny, tiny slice of enterprise-architecture – kind-of like looking out from the bottom of a deep, deep well, centred only on IT-infrastructure. TOGAF 8.1 had introduced the notion of ‘Business-Architecture’, but it wasn’t anything like the business-architecture, which in itself had only been an intermediate step or sub-domain within the overall whole-of-enterprise view. Nope: the real scope and limitations of this ‘so-called ‘business-architecture’ could be summed up in just one short, simple yet painfully-accurate phrase: “anything not-IT that might affect IT”. Yeah: pathetic – utterly inadequate for any real enterprise-architecture, that was for sure. And yet this claimed to be the major standard for enterprise-architecture – for all enterprise-architecture? What the heck…?

I presented a couple of times at those conferences, describing and expanding on the work we’d done in Australia, and that I’d done since: but it didn’t go down well. A few people pretty much laughed at me straight in my face: probably most wrote me off as some kind of nutcase, away with the fairies in some kind of sad utopian fantasy of the future – and somehow failed to notice that I’d said that this was what we’d already been doing, for years, back in Australia. Sigh…

There were a few other ‘crazies’ like me, who held a much larger view of the real scope and potential for EA. Len Fehskens, was one of them, for example; the redoubtable Dave van Gelder was another. It was noticeable, though, that almost all of us came from the ‘small countries’, not necessarily small in size but with a small technical pool who’d had to think like architects out of sheer necessity, just to get job done: people from countries like Australia, New Zealand, Canada, the Netherlands, Sweden and South Africa. I remember one side-meeting at at TOGAF, pushed out to a tiny back-room somewhere, where I think I was the only person there who didn’t speak fluent Dutch… yep, the ‘small-countries’ got it, all right, whereas for the most part the ‘big-countries’ just didn’t get it at all.

Slowly, very slowly, very slowly, the EA in the ‘big-countries’ is beginning to get it. Beginning to get it. Pretty much by force, often from business-execs utterly fed-up – and understandably so -with the sheer inadequacies of ‘conventional’ EAs obsessive IT-centrism. I remember an EA-toolset vendor’s client-conference a few years back where they proudly showed off their ‘new, cutting-edge’ EA technique called ‘capability maps’ – in essence, a somewhat cruder and less-complete version of what we’d been doing routinely back in Australia more than half a decade earlier. At that rate, the current EA ‘standards’ might – just might – start to catch up, in another five years or so,  with where we were in our EA in Australia when I left. In other words, only a full decade behind – yet absolutely certain that it’s right at the leading edge. And hence, aggressively, demandingly, insistently, holding all of us back, every inch of the way. Sigh indeed…

So where are we now?

— TOGAF 9 was a huge missed-opportunity – we know why it happened, but it’s held us back for at least another half-decade.

— FEAF and TEAF never really got started, other than as a generator of useless paperwork.

— DoDAF/MoDAF and the like still show some promise, but – perhaps by intent – they have no actual method: it’s just s description of some desired deliverables, and not much more than that.

— Zachman is still a magnificently-misleading taxonomy-or-is-it-ontology-or-something.

— Archimate started out well, but has now become pretty much trapped into being yet another IT-centric disaster-area. (Where do you model real-enterprise things like trucks and warehouses and buildings and power-supplies and people-only business-processes in Archimate? Short-answer: you can’t – it doesn’t even know they exist. Which means there’s no way to model any actual whole-enterprise with Archimate – which claims to be the notation for enterprise-architecture. Oh well.)

In short, it’s a mess. I’ve written about it extensively, here on this blog and elsewhere, and I won’t bother to go into old ground here: suffice it to say that, in my opinion, the only useful we can do now with all of this IT-centric so-called-‘EA’ junk is to strip it right back to the roots, and start again from scratch – it really is that bad. If we don’t do that, they will, increasingly, become far more of a hindrance than a help, for any form of EA – even more of a hindrance than they are already…

So what do we do about it?

For my own part, I just keep writing – researching and writing, creating new tools and techniques for real enterprise-scope architectures. It’s no way to earn a living (as I could show you straight off from the paucity of my pocketbook 🙁 ) – but someone has to do it, otherwise that future ain’t gonna happen at all. And yeah, a lot of people in ‘the trade’ would still write me off as a nutcase: yet it’s kinda odd how so many of the things that I told some of those same people five years and more ago are beginning to be embedded in mainstream ‘EA’ – themes such as the importance of a business-architecture that really is an architecture of ‘the business of the business’, rather than solely a simplistic summary of ‘anything not-IT that might affect IT’.

In short, if you want to see where EA has been, and where it’s quietly dying, follow the money – go talk the big IT-consultancies and their ilk, who still dominate most of the discussion on EA-certification and suchlike. But if you want to find out about where EA is headed – the future of EA – well, yeah, I’m probably one of the people with whom it might be worthwhile to talk.

So, where do we go from here? I don’t really know, to be honest – not for certain, anyway. But seems to me that one place we usefully could start is to pull apart and comment on a couple of comments on a previous post of mine, about EA certification.

The first of those comments we’ll look at is one by Sally Bean: see you there, perhaps?