6 years, 10 months ago

Saving enterprise-architecture from itself – 3: Skills and certification

Link: http://weblog.tetradian.com/2013/11/11/saving-ea-from-itself-3-skills/

What skills do we need for enterprise-architecture – for a literal ‘architecture of the enterprise’? And why? And how do we certify those skills?

Or should we even try to certify those skills? If so, why? If not, why not?

The focus in this part of the series is on a comment by Sally Bean, on a previous post about EA and certification.

A bit of background first. Sally is probably one of the most experienced EAs in Britain, having been involved with it in various forms such as ‘operations research’ over many years, particularly at British Airways. Until recently, she organised the annual IRM-EAC enterprise-architecture conference in London; she was also one of the prime movers to link together that conference and the parallel BPM conference (with Roger Burlton) into a unified whole. In short, she’s someone of whom I have huge respect, and, to me at least, whose opinions about EA will greatly matter.

These were her comments about certification:

Certification has pluses and minuses. Employers like it because they think it makes it easier to recruit qualified people. It does create a structure for a common body of knowledge.

Yes, both of those are true. However, there’s a huge problem here, that perhaps only becomes visible when we look at the employer / recruitment nexus as an enterprise in its own right.

As so many of us know to our cost, recruiting too often tends to be done by people who have little to no actual in-depth knowledge of the respective field. Without knowledge of that field, recruitment-criteria tend to default to a tick-the-box exercise.

Hence if a prospective employer is foolish enough to mention Zachman or whatever – because they don’t know what they want, either, so they’re just stuck with playing buzzword-bingo – then that item just gets added to a list of tick-boxes, all of them with equal weight.

Much of recruitment operates by exclusion: so if some candidate doesn’t have a ‘Zachman certification’, they won’t even make it to the shortlist. The result is that largely-peripheral but easily-identifiable short-course subjects can and do end up being assigned higher importance than years of real-world practice that’s harder to place into a single box.

Which is ludicrous – to say the least.

Certifications are purported to be ‘the solution’ to the recruitment challenge. In practice, though – and especially in this context, for experienced enterprise-architects – the obsession with certifications is proving instead to be a key cause of the recruitment-problem in the first place.

However, doing a certification course early in the learning process may not be beneficial, because the need to get through the exam tends to limit it to a rote learning experience, rather than getting a practical grasp of the concepts. Learning to pass an exam is not the same as learning to actually do something.

Yep: and that initial ‘However’ is really important there…

The rote-learning problem is a huge one: we have the ridiculous – and potentially-dangerous – situation that someone with rote-learning and no practical understanding is deemed a ‘better’ candidate than one with solid practical understanding but without a small amount of technical information that they could pick up in a couple of days.

“Learning to pass an exam is not the same as learning to actually do something” – that’s exactly the point here. We can usefully illustrate this with a SCAN crossmap:

Rote-learning, by definition, is way over on the left-hand side of the frame. But the whole point of the skills of an architect is to bridge across disparate and disjoint domains – in other words, most of the work is on the far side of the the red transition-line, and often way over towards the far right side of the frame. In most cases, certifications are meaningful only at the Trainee and Apprentice level. (One important exception is the Open Group’s ‘Open-CA’ certifications, which in principle would mainly apply at the Journeyman level.) So if recruitment focusses primarily on base-level certifications such as ITIL Foundation – because they’re easier to describe – then what we’re really saying is that Trainee-level experience is more important than Journeyman or Master level. Which is daft…

And we then see job-adverts for ‘business-architect, minimum 10 years experience, must be Zachman / TOGAF / Archimate certified’. All of which should tell you that the recruiter doesn’t have a clue – but unfortunately they’re the gatekeeper between you and a worthwhile job. Now what do you do? That’s why I’m asking these questions now…

In addition to the IT-centricity problem that you mention, one issue that I see with certification of enterprise architects is that about 50% of the qualities they need are ‘soft skills’. These include communication, conceptualisation, problem-structuring, collaboration, facilitation and relationship-building, which are highly contextual and don’t really lend themselves to meaningful certification.

Yes: this is hugely important. TOGAF is one of the few frameworks that does acknowledge this at all, and even there its only significant mention is in chapter 24, ‘Stakeholder management‘.

To my mind, we have the entire structure of enterprise-architecture training completely the wrong way round: the ‘soft-skills’ are actually the most important part of the job, whilst the technical-skills are almost trivial. (Not for solution-architecture, of course, or even for domain-architecture: but the whole point of EA is that its core focus is to link between all of those different technical domains, and hence needs to focus on the skills that apply between the boxes rather than within them.) Hence the soft-skills should be front-and-centre of even early training in EA; and whilst yes, technical-skills are important, in most cases they should have been picked up in real-world practice (typically years or decades of practice) before any explicit training in EA as such.

The technical-skills specific to EA itself are not ‘technical’ in the usual sense – not at the ‘you need Java for this EA role’ level that we see so often in recruitment-ads, at any rate. Instead, rather than frameworks and predefined reference-models, we need metaframeworks that show us how to create new context-specific frameworks; rather than methods and methodologies, we need metamethodologies that show us, for example, how to adapt supposed ‘best practices’ to a completely different to that for which they were originally designed and developed. Other than the work of John Gotze and the ‘Copenhagen crew’, I don’t know of any purported ‘EA training’ that covers much if any of this at all – certainly, none of the supposed ‘standard’ EA-certification schemes. Individual trainers may do it, some of them very well indeed – John Polgreen is one who comes immediately to mind, showing people how link TOGAF to FEAF and DoDAF – but it’s not in the ‘EA’-frameworks themselves, nor their associated certification-schemes.

To reiterate: in effect, most current so-called ‘EA-training’ has it completely ass-backwards – the least-important things (such as rote-learning of predefined frameworks) get almost the highest priority, and the most-important things (such as those crucial soft-skills) get the lowest. This must change if we are to have any chance of building a viable EA profession.

Finally, a comment from Sally that’s perhaps directed at me in a more personal / professional sense:

I wouldn’t want to be described as ‘eccentric’ when working as an EA inside an organisation. You have to be seen as trustworthy and credible by people at all levels, and you can’t afford to be too unconventional. It might be desirable to bring in an ‘eccentric’ consultant, if you want to shake things up. :)

Again, yes, agreed and understood, and likewise very important – especially for an EA working inside an organisation. (We can be eccentric, in who we are, of course, but managing our apparent level of eccentricity is itself one of those much-needed soft-skills! :-) )

Don’t forget, though, that ‘eccentricity’ of some form is often essential: in mechanics, the ‘eccentric’ or the ‘crank’ is what provides the leverage to enable movement, or change of any kind. The anthropologist Margaret Mead perhaps expressed it best of all:

Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.

My belief – or hope? is that we would need only “a small group of thoughtful, committed citizens’ to change EA for the better, too. That’s what this series of posts is really all about.

The next post in the series, centred around a comment from Len Fehskens, addresses a challenge we all need to face if we’re to get anywhere with a viable EA: our own responsibilities in making it happen, and making it work well for everyone involved. See you there?