5 Reasons why TOGAF Certification could be a waste of your time

Okay, first of all: TOGAF is an acronym and I have strong feelings about acronyms. See my previous post on this Dogma of Acronyms.

With that out of the way, I also want to make clear that I am a great proponent of architecture and I think that understanding, that is Understanding, of the principles behind TOGAF and how to apply TOGAF within an enterprise environment is very useful.

It's just that certification is a waste of time. And in this post I will provide 5 reasons in an arbitrary order, why it's a waste of time. And because the order is arbitrary, I won't number the reasons so you'll have to count them yourself.

• Enterprise Architecture is an activity and todo it right, to master this activity, takes practice. As the proverb goes; Practice Makes Perfect. Certification is a hoax from this perspective, since it doesn't require you to be an experienced architect that knows the specifics of TOGAF. It requires you only to know the specifics of TOGAF. Since the role of the architect is the most senior role in IT, in my humble opinion and many HR managers agree with me, being certified should take this into account.
• TOGAF covers to broad an area to be applied within an enterprise. TOGAF covers the complete enterprise and although I completely agree with this coverage, leading from business aspects all the way down to IT through Organization etc, this is hardly applicable in an enterprise. Typically TOGAF is done by IT people. Huh? Yes, by IT people, and this is due to the fact that the role of architect is typically an IT role. And on top of that, it was invented because there were too many senior IT people that sucked as managers. So in order to get them higher pay grades they became architects. And yes, there's the irony, architect are supposed to manage projects and programs on a technology level. Uhm, uh... what's happening here?
• TOGAF is based on best practices, models and notations. So it means absolutely nothing unless you fully understand your enterprise, its current state, where it wants to go and so on. Just like ITIL, being certified has no value to the company you're working at, what has value is you understanding what's good for the enterprise and what's not. Which means that you need to be engaged not certified. 
• Being an architect means you need to be able to communicate, and more importantly, you need to be a sales person. Being a successful architect means that you can sell an idea and in contrast to many sales people, also need to ensure delivery once you've sold it. As the architect is the most pro-active techie in the enterprise, having a long term view and a solid idea as to how to get there with steps that need to be taken immediately, you have to get that mindset. No TOGAF course teaches you how to become a great sales person, so don't think you'll be a certified sales person either.
• Everybody who wants to be an architect and has some time available gets TOGAF certified these days. Darn, I was thinking about it myself when it seemed as if my contract wouldn't be extended. Very similar to the Java certifications in 2003/2004 when the IT job-market was down in Europe. Unlike that time, I see that at interviews CV's of those that are TOGAF certified are scrutinized for experience that matches the claim of being knowledgeable because certified. I think that having done the training but not getting certified is better than being certified as it shows that you got the theorie, but don't claim the experience.

Unfortunately not many HR managers understand this and allow IT managers to send their staff en-masse to TOGAF training. Staff being certified are returning to enterprises that are not ready for enterprise architecture. Hard cash spend on training but no cash spend on following this through. I think for any company it is better to decide on a strategy and follow up on it from the various manager levels and support it by sending the right people to the right training.

In  my humble opinion, Enterprise Architecture and consequently all methodologies related to it is too mutch of the good stuff for many enterprises. For most of the enterprises I encountered. It's a maturity thing and as with us mere humans having to go through infancy, childhood, puberty before becoming adults, if at all. The same goes for organizations.

So dear HR manager, think first if your organization is actually mature enough and needs Enterprise Architects before you send your best resources to training and certification.

It is my experience that you should send your staff to training to improve your enterprise, and to certification to improve your staff. And at all times, you send them to training and certification if you choose so, that is relevant... in the short, mid and long term.

As always, thanks for reading this post and please comment when you see it differently. Diverse opinions make for clearer perspectives.

Iwan

The dogma of acronyms

Hi,

I think that when you know me, you know I don't like acronyms, especially those acronyms I encounter at work. I really don't like the ESB, SOA, ITIL, TOGAF, TRM, BPMN, BPO, etc in this world. I get really nervous around people that use them.
What even makes me more nervous are those acronyms that refer to 'Best Practices', 'Adaptable', 'Frameworks' and 'Models'.

The reason for my dislike of acronyms is that they tend to be very dogmatic. And I really dislike dogma. The worst of them are those that are brand new. Acronyms I mean. The new acronyms are the worst because they're typically an existing acronym's reincarnation or they're so new that nobody has experience in them.

Even worse acronyms are those that provide certifications, multiple levels of certification with accredited training.

Well, actually I don't really dislike acronyms, but I do get nervous around people that use them. Most of the time anyway. Because these people are usually very dogmatic about what the acronym stands for.
They've lost every sense of pragmatism and reality for that matter. When they reason that an acronym is great because it represents the best practices, they tend to forget that you really need to be very pragmatic when applying the acronym. Tailor it for your specific situation. Explicitly not being dogmatic at all.

My experience is that architects that use frameworks and methodologies that are summarized by an acronym, knowingly use them. That purposefully use them, have no to little clue what they mean, what benefit you can get from them or why to use them in the first place.
When this is a result of inexperience, it is not so bad. But an experienced architect that falls into this category is probably not that talented.
Those esteemed architects I've come across that were actively applying an acronym told me later that they found out by accident that they were doing the acronym. And now were leveraging the work of others to document their way of working.

As a starting architect the acronym is there to give you guidance, a head start, as an experienced architect you have the acronym to help you guide the starting architects in your team.

Iwan