You’ve just spent several hours working your way through the TOGAF training. Now you are prepared and ready to take the TOGAF exams and gain your certification.
That is all well and good – I’m sure you spent the time training because you thought that it was going to be useful, either to have the certification in order to further your career, or to learn more about the discipline, process or deliverables in enterprise architecture.
At the end of each training course I run, I like to ask attendees: “what do you think?” It’s really a question about first impressions. I’m curious to know – especially from anyone who doesn’t know much about TOGAF before they attended the course –what’s your overall impression after a few intensive hours or days of instruction? I’m keen to improve the training materials, but I also want to know how TOGAF could be improved.
There are some comments that I nearly always get from this question, and I’d like to write about some of these impressions in this blog.
What do you Think?
The most common feedback is that TOGAF seems abstract and theoretical. These students usually want to get busy with TOGAF, but they were looking for something more prescriptive, down-to-earth or concrete. When I explore this criticism, students usually admit that the Architecture Development Method (ADM), in particular, has a lot of step-by-step detail – and that the real issues are that it is a lot to take in and that it needs to be integrated with other processes and methods that are already established.
This leads into another frequent point: that there are not enough examples in the TOGAF documentation. Now this is a good point – and a difficult one to resolve. Some of the best examples of EA work are hidden from public view, either through non-disclosure clauses that prevent participants from talking in detail, or because EA addresses large-scale, longer-term concerns that are difficult to condense into a simple case study. The Open Group do provide example scenarios as part of the Level 2 Examination, but it isn’t always easy to relate these to particular sections in the documentation. The best solution would probably be to have comprehensive best practice case studies, in the same way that building architects study particular buildings as examples of architectural style.
Students sometimes feel that the sections and concepts of TOGAF aren’t as well integrated as they could be. This is partly what The Open Group address in the minor releases of TOGAF. For example, TOGAF 9.1 contains a set of corrections to address comments raised following introduction of TOGAF 9 in 2009. The main focus was to ensure consistent use of terminology. However, given the way that TOGAF evolves – through contributions from people with diverse backgrounds and experience – improving the integration between TOGAF components is likely to be an ongoing task.
Another point is that there is a lot of material in TOGAF 9.1! Some would say that it’s too wordy or that there is too much that isn’t essential. It would be difficult to provide certification in a subject without it being covered in a thorough manner. For anyone approaching TOGAF for the first time it can be daunting – and even when you are familiar and experienced with the content there are still areas that that you may not understand in detail. A good training course will emphasize the essentials and make it easier to get a good overview before plunging into detail. The series of posters that we’ve produced at Good e-Learning are aimed at addressing this issue by highlighting the key points in a particular topic, such as the TOGAF metamodel or the objectives for each phase of the ADM.
Related to the volume of material is the fact that some parts of TOGAF don’t seem to be as well thought through. For example, some of the constructs in the metamodel are difficult to understand. Again, a good course will point out these weak areas, provide explanations and suggest workarounds.
Take TOGAF With a Pinch of Salt
Finally – there is often a question about the practicalities of introducing TOGAF into an enterprise. It can be difficult to get executive buy-in or business support for enterprise architecture, and there is a danger that slavish adherence to TOGAF can be too bureaucratic or intrusive. As with all methods and techniques – they are there to be adapted and applied in ways that make sense and are useful.
So take TOGAF with a pinch of salt. Don’t take everything as is – TOGAF always needs to be adapted and tailored to meet your needs. Take what is offered in TOGAF and mix it with your needs, plus experience, examples, and ideas from other architectural frameworks until you get something that works for you. And next time I’ll take a look at the positive comments I get from TOGAF students.
