Besides being what Fergie used to do in the nineties, TOGAF is a method for enterprise architecture, and a couple of weeks ago I went on a TOGAF 9.1 Foundation and Certified course. My interest was exploratory rather than targeted: I wanted to hear a view on how to do architecture properly without really expecting to execute it myself at any point soon. Here’s a summary of some things I learned from the course.
- Drawing lots of diagrams of the same thing for different audiences is an inescapable part of being an architect. This is a disappointment to me because I find drawing diagrams quite difficult, and maintaining multiple diagrams representing a changing system is even more difficult. There are two solutions to the problem of maintenance, and I don’t think either is possible to reach perfectly:
- Only start drawing multiple representations when the system isn’t going to change at the level at which you want to draw the diagrams. (Although you will still need to make many drafts of your master diagram: the one that represents your viewpoint.)
- Get an architecture repository which can auto-generate nice projections of systems for appropriate audiences.
- This isn’t part of TOGAF, but I first heard of spider diagrams, which are a way of comparing two or more different solutions, each of which is evaluated in various ways.
Definitely one for the business toolkit rather than the science one. If you can mentally translate them into a simple bar chart, like the one below, then fine.
If not then they can be a bit misleading. For one thing, if there are more than three aspects to compare, the area covered by each option is affected by the order of the spokes. Look at these two solutions:
|Solution 1||Solution 2|
Both solutions have an equivalent numerical score, but look very different on a spider graph: solution 2 covers more than a third of the hexagon whilst solution 1’s area is close to zero.
The other problem is them is that they don’t allow you to weight the importance of the various aspects very well. However, this weighting is something that tends to happen in each individual stakeholder’s mind, so providing the raw data (like this or in a bar chart form) is probably more politically advisable. And, as my father pointed out to me this evening, they do actually allow you to put different units on each spoke, which is much more difficult in a bar chart.
Arguably the point of a diagram is to be interesting and pretty enough for someone to actually look at it, so perhaps it doesn’t matter that spider diagrams can do misleading things with areas as long as they’re sufficiently novel to get a busy important person to look at them long enough to read the figures.
In the same vein, the instructor told us about ‘tube map’ diagrams, which don’t seem to have to mean anything in particular as long as they’ve got circular intersections and thick coloured lines, like the example below.
Besides being founded on the superlative clarity of the tube map, they doubtless draw their effectiveness from the fact that most of their audience are, or have at some point been, commuters or international travellers, and so have developed an unconscious attaction towards anything that might help them travel more efficiently. This fact is ruthlessly exploited by the advertisements on the London Underground, which use tube-map analogies to advertise everything from homeless charities to cold remedies. (Note to any advertisers who happen to be reading this techie blog: it’s best to obey the grammatical rules of tube maps. For example, all lines should be horizontal, vertical, or at 45 degrees and the corners should be arcs of small circles: if you can’t make it with a wooden BRIO train set, it ain’t right. If you break the rules you risk putting off your audience, unless you’re doing something clever by subverting the format, such as showing how a drunken night can go hideously off course by going all swirly towards the end of the line.)
- The exam is probably a bit too easy to be able to use it to draw any conclusions about the effectiveness of certified architects or TOGAF course instructors. (I haven’t actually taken the exam yet.) There are two stages to it: Foundation and Certified. Both are multiple choice.
Foundation is all about terminology, and requires a bit of rote learning (e.g. the Architecture process consists of ten phases, eight of which are drily called Phases A-H, and you have to remember which letter of the alphabet corresponds to which inputs, activities and outputs).
Certified involves reading various scenarios and choosing one of four options about what the action of a TOGAF enterprise architect would be. This could be a good test of understanding, but the mark scheme is such that if you can eliminate the two least likely answers from each question then you’re certain to pass, and in fact even if you’re only able to eliminate the least likely answer, your expected result is still the pass mark. And, from the fake test that my course provider gave me, it looks as though they always put howlers of answers in which are easy to spot if you’ve learnt your TOGAF terminology.
- The opinion that enterprise architecture is expensive and ineffective is not universally held. However it is sufficiently widespread that a significant part of the course was about learning to sell the benefits (higher-quality and cheaper IT) to management.
- An architecture respository is essential if you want to be able to work out what systems could be affected by changes you are considering making to your enterprise architecture. This makes sense to me, because the alternative system – asking people who were there when the system was first implemented – doesn’t seem to work very well.
- I learnt a process for doing architecture. I don’t think I’ll be executing it rigorously in my current workplace, as that would require cooperation with others and the consequent need to become a TOGAF bore, but I do plan to turn it into a checklist to see whether we’ve done everything that the process suggests should be done.