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

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?

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

  1. Tom,
    Thanks for the testimonial! This is quite a timely blog as I have been taking an in-depth look at soft skills recently. A few thoughts and observations follow.

    While I obviously believe that soft skills are crucial, as are the ‘meta-thinking’ skills you mention, I think it’s overstating the point to say that technical skills are trivial. In most of the organisations I’ve worked with, there’s a need to appreciate the factors involved in integrating IT systems, as well as appreciating the implications of new technologies and the quirks of old ones. However, it’s hard to make definitive statements about EA skills, because EA means different things to different people.

    As well as the Stakeholder Management material you refer to, TOGAF provides a list of generic skills mapped to roles (section 52.5.1), but I’ve not been able to find any detailed descriptons of these. I have developed my own taxonomy of skills which I’m currently refreshing.

    Training does not have to be carried out by courses alone. When I’ve worked with clients, we’ve developed competency models with enough information in them to enable architects to develop their own blended learning programmes, with a mix of training, work-based learning tasks and community activities. In fact Continuous Learning is a capability that is missing from the TOGAF list.

    I agree with your comment that’eccentricity’ in some form is desirable to stimulate change, in terms of thinking differently.

    I have myself done the TOGAF and Zachman certifications and found the discipline of doing them useful. But I agree with you that anyone using them as a filter for recruitment may be missing out on some good people.

    Finally, I think the Margaret Mead quote is spot-on – in practice, effective EA is achieved by people working successfully in small groups, and then building a movement for change.

    Finally, I think the Margaret Mead quote is spot-on – in practice, effective EA is achieved by people working successfully in small groups, and then building a movement for change.

  2. Thanks, Sally. I think there’s only one point to which I need to respond:

    @Sally: “I think it’s overstating the point to say that technical skills are trivial”

    Yep, okay, I do need to clarify that one a bit.

    Yes, there’s no doubt that technical factors are hugely important in enterprise-architecture, as in any other form of architecture. Yet at the scope that we’re talking about for enterprise-architecture – and again, I’d emphasise the point about ‘at the scope and scale’ – there are so many technical factors that at too much knowledge of a technology can easily become more of a hindrance than a help.

    The architect does need to know ‘just enough’ about every technology in context, such as to be able to frame meaningful questions about how each might come into play in the overall architecture story, and how they might all usefully weave together in that story.

    And it should, I hope, be obvious that the architect will need extensive experience in more than one form of domain-architecture before they move on the enterprise-architecture – so in that sense, the understanding and experience of the nature and demands of ‘non-trivial’ technical-knowledge should already be there.

    In practice, it’s actually quite important that the enterprise-architect should not attempt to keep up to date with every technology in scope – it was hard enough in the Middle Ages, it’s certainly not doable now. In-depth technical-knowledge is the role of domain-architects and solution-architects: the enterprise-architect’s job is to keep all of those different disciplines together, into some form of unified whole. (Again, we’d perhaps need to emphasise the phrase ‘some form of’ – at this scope it’d be very unusual to have simple ‘alignment’, there’s emergence and suchlike almost always at play here.)

    No doubt at all that the technical skills and knowledge required for this are non-trivial: yet they actually come most into play in a different part of the overall story, via other actors than the enterprise-architect. Hence why, at this scope and level, specifically for enterprise-architects themselves, the soft-skills and metaframework / metamethodology skills are far more critical and necessary than technical-skill alone.

    Or, to put it the other way round, the soft-skills and metaframework / metamethodology skills are the technical skills that the enterprise-architect most needs to learn for this role. Given those skills, all other required skills and knowledge should be accessible, via the application of those ‘meta’-level skills.

  3. Great post @Tom. As always you are spot on.

    It appears by your comments in this article that it’s not only EA thinking that need to be shaken up but the whole recruitment industry and processes as well! This is a subject close to my heart at the minute after three months of CV’s being rejected probably because they are missing one or two crucial words, or as you say certain words are weighted way too heavily. Let’s not even mention the attempt to create my CV using Archimate… 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *