Another month, another enterprise-architecture conference? This time it was Open Group London, billed as “Business Transformation in Finance, Government and Healthcare”.
Of which it did cover some – according to the programme and the Twitterstream, anyway. (See the Open Group’s ‘highlights’ blogposts for Day 1 and Day 2 for more on that.) Yet the real focus, it seemed to me – as far as I could tell on the admittedly only one day that I was there – was less on the practical application of EA for real business problems, and more on the ‘sideshows’: in particular, the future potential of upcoming technologies, and, increasingly, on certification and ‘professionalisation’ of EA itself.
To me there is real value in looking at the upcoming technologies. The problem, it seems to me, is that there’s still way too much focus on technology-for-technology’s-sake, and nothing like enough attention on (or even awareness of?) the socio-technical aspects – the interaction between people and technology, within a social context that itself is impacted by environment and many other ‘big-picture’ factors that are way beyond the scope or ‘control’ of any technology itself.
Although I was mostly tied up elsewhere, I did grab a chance to drop in on the part of the ‘Future technologies’ stream, a panel-session with Andy Mulholland, Graham McLeod and Stuart Boardman. I was really delighted to see that – unlike some previous years and sessions – this was a panel that really did understand the broader scope, beyond just the technology: yet it’s still not something of which I saw much elsewhere… and to me at least, that’s a real problem, for the EA profession as a whole.
There was one slide in Stuart’s brief presentation that really caught my eye – and in fact he said later that he could have spent his entire session and more talking about just that one slide. It was was an overview-map – what DoDAF folks would call an OV-1 diagram – that encapsulated the key concerns, drivers and and technologies for the ‘smart-energy grid’. The crucial point was that whilst, yes, IT and information-flows did pervade the whole thing, it was not about IT as such – it was about how all of the different themes had to work together as a unified whole if it was to work at all.
Yes, the IT was important, and it wouldn’t work without it: but the same was true of everything else – the politics and economics, the physical buildings and structures, the interplay between centralisation and decentralisation, the issues around regulation and governance, the social incentives, the materials-science, the relationships and interdependencies between all the different forms of energy-capture and distribution, the sub-microsecond technologies to shield the overall system from lightning-strikes, and everything else that made it feasible as a sociotechnical system. Hence the moment we place any one of those themes as ‘the centre’ – as IT-centric ‘EA’ still seems to do with the IT-aspects at every possible moment – then the view of the system-as-system will collapse. Stuart and the others on the panel definitely did understand this point: yet how many others in the EA field do? Nothing like enough as yet, it seems: I really worry about this a lot, I really do…
On the flip-side of this, there’s a huge role here for standards-bodies such as Open Group. We have no idea where these future-technologies will actually lead us: consider text-messaging on cell-phones, for example, which was not part of the original design-intent at all. In reality, the actual usages for these technologies – the ones that stick, that we later see as ‘the technology’ – will arise from the affordances that people discover from using them and putting things together, in an emergent, unpredictable way. To make this work, though, we need clear technical and other standards, to provide the base-platform on which people can put things together: agility needs a backbone. The hard part is not in creating a single standard, but in the horse-trading and politics of linking all of the disparate standards together, to create an overall platform of potential-capability that people can use. And it’s in that kind of politics – creating ‘standards of standards’ – that I do know Open Group excels.
Training, certification and professionalisation
On other fields, maybe not… The other area where I do really worry for EA as a whole is in the current near-obsession – or so it seems to me – with ‘certification’ and ‘professionalisation’. To me, Open Group is – like so many other actual and would-be ‘standards-bodies’ – busily pushing hard in entirely the wrong direction, with a fundamentally-wrong approach to professionalisation and, hence, in turn, to certification. That wrong-headed-approach was very much in evidence at this conference – and whilst I certainly wasn’t the only one who noticed it, I admit I just don’t know what to do about it, because the pressures to promote and preserve that wrong approach are absolutely huge. Sigh…
There are three key parts to the problem here. The first is around the content of that certification – the ‘language’ and suchlike.
TOGAF and Archimate would purport to be the lingua franca of enterprise-architecture, but right now they’re more like its Newspeak – a stripped-down language in which many key concepts become impossible to express:
“The purpose of Newspeak [in George Orwell’s novel 1984] was not only to provide a medium of expression for the world-view and mental habits proper to the devotees of IngSoc, but to make all other modes of thought impossible. Its vocabulary was so constructed as to give exact and often very subtle expression to every meaning that a Party member could properly wish to express, while excluding all other meaning and also the possibility of arriving at them by indirect methods. This was done partly by the invention of new words, but chiefly by eliminating undesirable words and stripping such words as remained of unorthodox meanings, and so far as possible of all secondary meaning whatever.”
If, in that quote from Orwell above, you were to substitute “IT-centric ‘enterprise’-architecture” for “IngSoc”, and “TOGAF-certified” for “Party”, you’ll find that the parallels are scarily exact…
It is easy to use the TOGAF-metamodel and the Archimate notation to describe just about anything in the enterprise that revolves solely around some form of IT (though information itself is somewhat of a ‘second-class citizen’, as my table-neighbour wryly observed at the conference). Yet it is all but impossible to describe anything else:
- We can describe the computers in a data-centre, but not its power-supply or cooling-system or physical racking, or even the building that houses those computers and everything else.
- For a chemical plant, we can describe the information-flows from the plant, but not the sensors from which that information is derived – let alone any of the physical equipment or chemical-processes.
- We can describe people-based processes in the Business layer, information-processes in the Application layer, and physical-processes in the Infrastructure layer, but there’s no way to describe them all in the same layer, as we need to do in planning for whole-system trade-offs or disaster-recovery – the concepts simply aren’t there in the language.
Which is a problem – a huge problem – that at present is deeply embedded in all TOGAF and Archimate certification. In essence it renders those certifications invalid for anything other than a very narrow subset of enterprise-architectures – yet, Newspeak-style, purport to cover the whole space. Worse than that, it actively dissuades anyone from being able to see anything outside of that specific subset, because there’s no way to describe it within the language. That’s a problem that’s going cause enormous challenges and enormous pain over the next few years: but right now most people in ‘the trade’ don’t even seem to be able to see the problem, precisely because the language itself renders that problem ‘invisible’ and inexpressible. Newspeak indeed…
The next part is to more to do the nature of the work of enterprise-architecture.
To be blunt, I’d have to say that the current approaches to certification and professionalisation have completely misunderstood and misdescribed the nature of the work that needs to be done in EA, and hence misframed what needs to be assessed and managed in certification and professionalisation. It’s quite easy to see how this has happened, and even why this has happened – but not so easy as yet to see what we can usefully do to get out of the mess. Hence, yes, another huge problem here…
The simpler the work, and the more the work relates to things that are physical and repeatable – the more it’s over to the left side of the SCAN frame – then the more suitable it is for some kind of predefinable certification. Hence knowledge of vocabulary can be tested in some form of certification, such as in TOGAF Foundation or Archimate Foundation; and knowledge of how to do repeatable tasks can be tested in some form of certification, such as in the wide variety of technical-level IT-certifications.
And yes, those are no doubt useful to recruiters and large organisations; and yes, it’s probably fair to say that something useful for this could be taught and tested for in a five-day training course or a small amount of self-study. But the catch is that that isn’t where enterprise-architecture sits. Solution-architectures, yes; domain-architectures, probably yes, for some parts at least; but for enterprise-architectures, no. There is a rather important difference there…
The reality is that by the time someone is doing real enterprise-architecture, or just about any type of architecture at a whole-of-enterprise scope, most of their work will be way over on the right-hand side of the SCAN frame – ambiguous at best, often highly uncertain or even not-known, and almost invariably highly-‘political’ at that. And we can’t teach that, or test that, in a pre-scripted five-day training-course: more like five years or more – 10,000 hours and up – of often-intense in-depth experience ‘at the coal-face’. That’s what professionals do; in essence, supporting that kind of experience and competent, contextual, on-the-spot judgement, decision-making and action is what professions are all about.
Peer-review is the only known way to test for that kind of competence. But with EA we’ll hit a real problem even there, because the work is often inherently-unique – and, for certain business-purposes, often unique by intent, such as for ‘competitive advantage’ and the like. I don’t think I know any two enterprise-architects who do do exactly the same work as each other. And unlike surgery, for example, it may take years – if ever – to demonstrate direct outcomes from what we did or didn’t do: so we may not have any means to assess quality just in terms of results. In which case, who are our peers, who could exactly validate our competences in terms of their own experiences? Do they exist? Could they exist? The answer seems to be ‘No’…
Which, if we’re honest about it, leaves us a bit stuck.
Worse than stuck, in fact. Right now we have the ridiculous situation that the only certifications available, and the only ones that recruiters and suchlike seem to take into account, are for lower-level skills and competencies than the ones we actually need to be using in EA. Which means that those who do know what they’re doing will get turned down for work, in favour of those who don’t, on the basis of largely-meaningless certifications. And the scope of those certifications is completely wrong, too: in my own case, I’d normally expect to work at CEO or whole-executive level, exploring the architecture of their enterprise as a whole, but whenever I mention the words ‘enterprise-architecture’, the inane recruiter will immediately send me to talk with some mere minor erk, maybe five or more levels below even the CIO, to look at some tiny fragment of work divorced of context or connection with anything else – which isn’t architecture. Which is a complete waste of everyone‘s time.
And for me – and for many other highly-experienced EAs that I know – the last time I worked in-depth with detail-level IT was many years ago: so I probably wouldn’t pass the damn ‘certification-test’ anyway, because my skills in that area are too far out of date. Which the recruiters would take as ‘proof’ that I don’t know EA… – kind of an insult, to say the least, given that in my case I literally ‘wrote the book’ on several key aspects of the entire EA profession.
[An aside: some years back I went to an interview for an EA consulting-gig with a mid-sized financial-services company somewhere in mid-England. It started off badly, because the first thing they asked about was whether I knew SQL (which I do) and Siebel (which, thankfully, I don’t). A moment later, one of the interviewers sneered, “Look at all those different types of work you’ve done, in all those different industries! It’s not just IT, is it? Proves you can’t be any good at enterprise-architecture, doesn’t it, hey?” Which, as far as I was concerned, was the end of the interview: if that they’d got it that far wrong, there wasn’t much point in my being there… Sigh.]
Separate from the conference, there’s also been an excellent post recently by Voytek Janisz, titled ‘Certifiably Influential?‘, which again casts serious doubt on relevance of the current crop of certifications to the kind of work that enterprise-architects really do:
Can you certify one’s ability to influence? How about one’s ability to compromise? I don’t believe you can. Those are traits usually acquired through experience involving number of successes and mistakes in previous endeavors… actually mostly through mistakes.
Hence, again, the key point is this: in essence, the existing ‘enterprise-architecture’ certifications test mainly for what enterprise-architects don’t do. Which kinda misses the whole point of it, really…
The other part of my concerns about the current approaches to certification and professionalisation revolves around the lumbering elephant-in-the-room that no-one seems to be able to shift: the naming problem. To put it at its shortest, how the heck are we ever going to be able to build an enterprise-architecture profession until we can get agreement on what it is that we actually do?
I’m going to be really blunt about this: what the Open Group calls ‘enterprise-architecture’ is not enterprise-architecture. Or, more accurately, is merely a subset of the literal ‘architecture of the enterprise’, but commits the cardinal sin of pretending that it’s the whole – and then compounds that sin by creating promoting ‘certifications’ that cover an even smaller subset of it, yet which likewise pretend to be the whole. And Open Group (and, I hasten to add, many others) have been doing this for nigh on a couple of decades now – whilst knowing, right from the start, that it was and is a very misleading thing to do. This must stop – for Open Group’s sake as well as everyone else’s, because as TOGAF and suchlike do expand out into more of the full EA space (as in fact they’ve been steadily doing ever since around TOGAF 7), they’ll be held back every step of the way by their own mistakenly-myopic legacy. So it isn’t just that it hurts those of us who are doing enterprise-architecture at a whole-of-enterprise scope: it’s starting to hurt Open Group too – and that fact was very clear in some of the ‘professionalisation’ sessions at the conference, particularly that by the indomitable Len Fehskens.
One way out is to use James Lapalme’s ‘Three Schools of Enterprise Architecture‘ model:
- Enterprise-wide IT – an ‘inside-out view’ of the business-enterprise, centred around and from the perspective of ‘the IT unit’ (e.g. TOGAF 8.1 and earlier)
- Enterprise – an ‘inside-out’ view of the business in context of its enterprise, though still primarily centred around IT (e.g. TOGAF 9.1)
- Enterprise-in-Environment – intersection between ‘inside-out’ and ‘outside-in’ views from the broader enterprise-context, not centred solely around IT (not yet described in TOGAF)
The three ‘schools’ have different emphases – respectively IT-centric, business-centric and whole-of-enterprise. They also have different reporting-relationships – typically to CIO/CTO, CMO/CFO, and whole-executive. In effect, the second ‘school’ is a superset of the first, and the third ‘school’ a superset of the second – which means that only the third school should be properly described as ‘enterprise-architecture’. The others must be acknowledged merely as convenient identifiable-subsets of that broader scope – and should not, under any circumstances, purport to be the whole. The blunt reality is that we will get no further towards the true professionalisation until this point is fully accepted by all players in this space.
Perhaps equally to the point, the longer we allow these fundamentally-flawed and mis-scoped ‘enterprise-architecture’ certifications to continue, the more we risk permanent damage to any chance of creating a viable profession. And the window of opportunity is shrinking all the time: at a guess, I’d say that we have no more than two or three years before it closes forever. You Have Been Warned, perhaps?
A question of uniqueness
Finally, a quick note about my own presentation at the conference: ‘Same and different: architectures for mass-uniqueness‘.
Given that one of the core themes for the conference was healthcare, I wanted to focus on the architectural challenges of mass-uniqueness:- contexts where some form of uniqueness occurs not just as ‘outliers’ or ‘exceptions’, but as a central fact of that business-context – uniqueness at scale, exactly comparable to the ‘sameness at scale’ that we see in most IT, and in Taylorism and the like. This mass-uniqueness occurs not just in healthcare – where we see it, for example as the bewildering array of patients’ differences and unique needs – but in many other industries: retail, education, recruitment, customer-service, farming and city-planning, to name just a few.
Here’s my slidedeck, anyway:
It seemed to go down pretty well: comments or suggestions, anyone?