And more on EA certification…

What is the profession of enterprise-architecture? And what should we do about certification, to define and protect that profession?

Yeah, it’s much the same questions as before – but perhaps becoming a bit more urgent as the thrust from Open Group and the like to determine the nature of the EA-profession gathers more momentum.

And yes, I’ll freely admit an ulterior motive here – because if the Open Group’s arbitrarily-narrow concept of ‘enterprise-architecture’ does take hold, I and anyone like me who does work at a whole-enterprise scope would effectively be banned from practice. Which would not be a good idea, not just for us but for the profession as a whole – though I’ll expand on that latter point in a moment.

First, though, here’s a good illustration of the current thrust, from a single-slide slidedeck by Jason Uppal:

It’s intended to illustrate a ‘typical’ career-path for an enterprise-architect, from undergraduate-degree to SVP or CxO. And it’s a fair bit broader than the kind of career-path assumed in so many conversations I’ve had at Open Group conferences and elsewhere: for example, although it’s still painfully IT-oriented, it does consider the possibility of other routes, such as via business-analysis (IIBA) or project-management (PMP).

Yet there are still an awful lot of hidden assumptions there: for example, that enterprise-architects are only ever employees, and pretty much only in large organisations. And, in the background, the inevitable assumption that it’s really mostly about IT. Which it is not: therein lies the real problem.

To explain that last point, let’s look at the history of TOGAF itself. It started out as a set of models and methods (i.e. a framework) to help manage the changing picture of IT-infrastructure in large organisations and consortia – initially in government, and then later in strongly IT-oriented industries such as banking, insurance, finance and tax. And it pretty much stayed that way until TOGAF 7, when – as one of the original members once told me – they suddenly realised people were actually using it, and therefore needed something a bit more systematic to hold it together.

Part of ‘systematic’ implied that they now needed to look at that IT-infrastructure in terms of its systemic-context – because in a system, everything ultimately depends on and connects with everything else. Which meant that the scope has gotten wider with each iteration of TOGAF itself:

• TOGAF 7: IT-infrastructure
• TOGAF 8: Application and data that reside on that IT-infrastructure
• TOGAF 8.1: Business-use of those applications and data that reside on that IT-infrastructure
• TOGAF 9: Business-context for that business-use of those applications and data that reside on that IT-infrastructure
• TOGAF 9.1: Motivations, drivers, and change-processes for and within the business-context for that business-use of those applications and data that reside on that IT-infrastructure

But notice a subtle yet crucial point that’s easily missed here: it’s still primarily about IT-infrastructure. In essence, the whole thing is an ‘inside-out’ view of the overall enterprise, from the perspective of IT-infrastructure – like looking upward from the bottom of a well. Hence, for example, ‘Business-Architecture’ in TOGAF is still essentially best described as ‘anything not-IT that might affect IT’ – it’s not ‘business-architecture’ in its literal sense of ‘the architecture of the-business-of-the-business’, focusing on things such as business-models, financial-architectures, value-stream translations and the like. And this reflex IT-centrism still permeates just about everything that comes out of the self-proclaimed major-players in enterprise-architecture – including Jason’s ‘career-path’ description above.

Yet this IT-centrism – in fact any kind of ‘anything-centrism’ – is exactly what not to do in an enterprise-architecture. This becomes immediately obvious if we turn round at, say, the business-architecture level, and look back ‘downwards’ – ‘outside-in’ or ‘inside-in’ – towards the implementation and operational layers of the organisation. From this perspective, we’re able to see IT in its proper proportion: rarely more than 10% of any organisation, and usually a whole lot less. Yes, IT permeates pretty much everything – but so does everything else. Facilities and machines and people and skills and relationships and much, much more are all exactly as important as the IT – because without those system-elements, the system can’t work as a system. The architecture of a business includes everything in that business, necessarily as exactly ‘equal-citizens’ – not where one domain such as IT-infrastructure is arbitrarily accorded priority over everything else, with every everything else all but ignored, such as we see in Archimate and TOGAF and so many other approaches to so-called ‘enterprise’-architecture.

So let’s hammer this point home yet again: In a viable architecture, everything depends on everything else – we cannot and must not allow any one domain to set itself up as ‘the centre’ of it all, because, in practice, especially at the operational level, everywhere and nowhere is ‘the centre’, all at the same time.

And that’s just when we look back from a business-architecture level. The business-itself is in the context of its market; and that market in turn is in context of a broader shared-enterprise that can encompass and intersect with many markets. In that sense, enterprise-architecture is the architecture of that entire shared-enterprise: as enterprise-architects, we develop awareness and understanding of that entire enterprise, for our organisations, to enable our organisations to understand their external options and choices and trade-offs in their relationship with their market and enterprise – and thence guide their internal options and choices and trade-offs for business-models, facilities, products, processes, staffing, IT and everything else. (There are also further layers ‘outward’ – ‘enterprise-of-enterprises’, in the same sense as ‘system-of-systems’ – but we can skip over those for the moment, because essentially the same principles apply, in recursive fashion.)

In short, what Open Group et al. describe as ‘enterprise-architecture’ is merely a tiny, tiny sliver of the real scope of enterprise-architecture, rooted somewhere in the minor depths of the blob marked ‘organisation’, that itself is only one small part of the total scope implied in this enterprise-model:

And the notion that ‘professionalisation’ and ‘certification’ for that entire scope of action should be driven by and controlled by that one tiny sliver of a subset of that scope is not merely absurd, but extremely dangerous.

To illustrate why, let’s use a healthcare analogy.

Healthcare is a huge shared-enterprise, revolving around a shared story of ‘health’ and ‘being healthy’, in its broadest possible sense. There are vast number of players, of whom some would focus more on ‘resolving illness’ – all the various subsets and sub-disciplines of medicine – whilst others are more about ‘maintaining wellness’ – which would include yoga-teachers to swimming-clubs to nutritionists and celebrity-chefs and many, many more. For the sake of this analogy, though, let’s focus just on the ‘medicine’ side of the story, and focus in again on just one discipline within medicine: radiology.

Electromagnetic or radiation-based diagnostic-imaging – X-rays, CAT-scanners, MRI-scanners and so on – is obviously important in medicine. But there are also real dangers there: if we get it wrong, people can get very ill, or die. Hence, working in parallel with other disciplines, a distinct profession has developed to manage radiology, particularly in hospitals and the like: radiologists.

So let’s go to a hospital. There, the radiologists have their own department, filled with large, impressive technology that they alone are allowed to operate. You’ll see their work in use throughout the hospital, on the wards, in the operating-theatres, in consulting-rooms. Yet they’re kind of sideways-on to everyone else: their work is used in the operating-theatre, but unlike nurses or anaesthetists or physicians, or even the janitors who keep everything clean before and after, they themselves would not be part of the active surgical-team. Odd.

We could note that there’s a kind of suite of intersecting-sets here: radiologists do medical-imaging, but other teams do so too, with different technologies – ultrasound, for example, or plain old photography and illustration. And the same kind of technologies that radiologists use – radiation-emitting devices or one type or another – are also used by others for other purposes entirely, such as radiotherapy.

Yet if we take the same line as Open Group and the others have done with regard to enterprise-architecture, the radiologists would claim that their form of medical-imaging is ‘the sole reason’ for everything – it’s the centre of the medical world! The surgeon and the nurses and all of the others are there only to act on what they’re shown by the diagnostic-imaging; the patient being operated on is viewed solely as an ‘diagnostics-user’, in context of ‘diagnostics-processes’, ‘diagnostics-services’ and the like. The other equipment-items in the hospital, the ward and the operating-theatre – and even the physical operating-theatre itself – are deemed not to exist, or at least can’t possibly matter, because they’re not associated directly with radiology-diagnostics itself.

Yeah – absurd, isn’t it?

You’d recognise straight away that to make any sense of the role of diagnostics in an operating-theatre, or even the operating-theatre itself, we need to understand the whole of what happens there – the system-as-system. We’d need to place that in turn in context of the hospital as a whole, as a larger system-as-system; even more, we’d need to place it in context of the patient – the experiences of that patient, a ‘customer-centric‘ approach. And we’d also need to interpret all of what happens in terms of the story of medicine, and, in turn, the broader story and shared-enterprise of health and healthcare – especially if we need to look at from a perspective such as health-of-the-nation, or epidemiology, or any other necessarily whole-of-enterprise view.

Everything is in context of everything else: there is no single ‘the centre’. The closest that we have to a ‘the centre’, in fact, is the whole-enterprise story. And the moment that any one domain forces upon everyone else that it alone is ‘the centre’ around which everything else must revolve, the system-as-system will start to break down, fail, implode, collapse into a fragmented mess of disjointed pieces.

Which is exactly what we see with the mess created by the still-endemic IT-centrism that permeates through far too much of so-called ‘enterprise’-architecture. Unless the EA covers the architecture of the whole enterprise, with equal attention paid to every aspect of that system-as-system, it cannot and should not be called ‘enterprise-architecture’.

There is, of course, no reason why subsidiary disciplines should not exist, covering specific domains of the overall architecture – exactly as radiologists cover a specific aspect of medicine. There is an undoubted need for professional standards, and professional certifications: radiologists, for example, do indeed have certifications – but specifically in radiology, which don’t claim to define the whole of medicine. And exactly as with radiologists, the work that the various types of domain-specific ‘enterprise’-architects do should be named appropriately: radiologists do not claim that they alone do medicine, and likewise TOGAF-style IT-architects should not describe themselves as enterprise-architects.

Why not? Well, take a careful look at one key current end-result of that mess: we have recruiters and others seemingly convinced that there is no difference whatsoever between detail-layer IT-architecture and, for example, highest-level business/market strategy and business-model development – because at present they’re all called ‘enterprise-architecture’. Which, clearly, they’re not: IT-architecture is in the scope of enterprise-architecture, yes, but in no way is it ‘the architecture of the enterprise’ – a very different beast, often requiring very different skillsets from those used in detail-layer IT-architecture.

We also have the utter absurdity that those of us who do work at the whole-of-enterprise level, on business-model design and suchlike, are turned down for such roles, because we don’t conform to the box-ticker’s assumption that TOGAF is the only certification in enterprise-architecture. In the meantime, someone who’s dithered their way through a five-day training-course can be offered a role that they do not have any skills or competence to handle, again on the assumption that TOGAF is the only enterprise-architecture certification that anyone would need. The result: competent people get blocked out of work, novices trigger off catastrophes that will blacken their record for their entire career, a lot of seriously annoyed clients, and serious damage to the EA profession as a whole. Everyone loses from this kind of inanity…

Hence whilst, yes, I’m impressed that certifications for TOGAF 9 currently stand at somewhat over 27,000, part of me just weeps, because that’s at least 27,000 people who’ve been systematically taught a fundamentally-wrong approach to enterprise-architecture, a fundamentally-wrong description of the scope and role and required-skillsets for enterprise-architecture, and who – if they’re not to cause damage to an organisation’s overall architectures – will at some stage have to unlearn all of that and then relearn the right approach to enterprise-architecture and the relatively-small place of IT-architecture within that overall scope. That process might start to happen with TOGAF X, the eventually-upcoming TOGAF version 10: but after the missed-opportunity of TOGAF 9, I’m not holding any high hopes of realistic change – and in the meantime there will be thousands and yet thousands more ‘enterprise’-architects going out there to cause further damage to the real profession of enterprise-architecture. Sigh indeed…

And career-path? – ah yes, career-path. (I haven’t forgotten. 🙂 )

Real enterprise-architects – those working at that true whole-of-enterprise scope – are a fairly rare breed. By necessity, all are experienced system-thinkers; by nature, they’re often a bit eccentric, because the work routinely requires an ability to look at things from a seriously-sidewise perspective – from every perspective, in fact. So whilst, yes, it’s probable that most of us will have a serious amount of IT somewhere in our CVs – as Jason Uppal’s ‘career-path’ suggests – a closer look would show that we’re more likely to have bumbled around at many or most of its edges, bouncing around between disciplines, rather than sitting solely in one domain for years on end.

And for a lot of us, even the concept of ‘career-path’ in the usual sense makes little sense. Take my own case: I’ve never yet been an employee – only ever either an independent, a contractor or consultant. I’ve not so much had a career, as that I’ve careered (careened), from place to place, industry to industry, role to role, discipline to discipline – hence why I find it so much easier than most people seem to do, to link across between disciplines and domains, so as to make sense of an architecture as a whole.

To give a bit more detail:

• my university-years were at art-college: my DipAD (convertible to either BA or BSc) in graphic design also included a short stint on placement studying at the Architectural Association, and my MA from Royal College of Art, where my research on design for skills-development was so interdisciplinary that they in effect gave me a department of my own;
• my first jobs included photography for medical-education, illustrator in child-development, and teaching typography at two design-colleges;
• wrote and illustrated my first book (the case-study from my MA research), published in my early twenties, still in print almost forty years later;
• in my late twenties, my first startup, a phototypesetting business – at a time when phototypesetting-machines were still a very new technology, and each cost about twice as much as my house;
• learnt to code (all in assembler) to link early microcomputers to our phototypesetting machines, then wrote the first true copyfitting apps for micros, as a predecessor to what later became desktop-publishing;
• quit when the company was bought-out by a competitor, then spent several years doing odd bits of tech-writing and consultancy – reverse-engineering the source-code of a misbehaving robot-truck in a toothpaste-factory in the US Mid-West is one example that comes to mind – and writing a few more books;
• moved to Australia, doing tech-writing, website and database development for e-commerce, emergency-dispatch systems and a whole bunch of other clients – including around a decade doing requirements-mapping, databases, workflow-design and such for an engineering research-lab;
• at clients’ request, moved sideways into architectures, particularly data-architecture and whole-enterprise architecture, in logistics, utilities, government and a bunch of others;
• moved back to Britain, in the mistaken belief that there would be a more mature enterprise-architecture market there – then discovered the hard-way that it was about decade behind where we’d been in Australia, and to a large extent still is;
• committed myself to researching, developing and disseminating tools and techniques for whole-enterprise-architecture – and I still am.

Oh, and yes, I did get round to doing a TOGAF 8.1 certification at some point – so yes, I can indeed claim to be a ‘real’ enterprise-architect! Wow… (Reality is that I’ve never been in any gig where I’ve needed it, it’s now long since lapsed, and I haven’t bothered to renew it, or ‘upgrade’ to later versions, because there’s just no value to me for doing so. But it keeps the recruiters happy, I guess. Sigh.)

So yeah, I’ve ‘careered’ all right – yet that amount of ‘careering’ is not untypical for most of the EAs that I know. I’ve met at least two enterprise-architects who’d previously worked as building-architects; another was a naval-architect, designing ships rather than IT-systems; another had been a mathematician specialising in quantum-physics and satellite-design – literally a rocket-scientist. A fair few arts-graduates, too. Sure, there’ve been a few who actually have followed Jason Uppal’s ‘standard’ career-path – but they’ve tended very much to be the exception rather than the rule. Overall, the only thing we all have in common is that we now work in some aspect of enterprise-architecture – and that’s it.

In which case, whence certification? The only thing that the proposed ‘professionalisation’ around these certifications from Open Group and elsewhere would do is that it would shut out most of the people who actually do do enterprise-architecture at the real whole-of-enterprise scope – because most of them aren’t ‘IT-people’, and in many cases don’t ever want to be described as such, either.

Most of those who work at the current leading-edge of enterprise-architecture – and I think I can reasonably claim to be one of those – would not fit the absurdly-IT-centric requirements of those certifications. And hence, in principle, and probably in practice too, those who contribute most to this profession would be forced out of the very profession that most needs their skills and services. Not clever…

Is that really the outcome we want? That this profession needs? Because that’s the way this supposed ‘professionalisation’ is going right now…

Time for a rethink, folks… a serious rethink, I’d suggest?