Things you can learn about IdM projects from watching The Imitation Game

I just saw The Imitation Game and, while mostly I was absorbed in the story and particularly Benedict Cumerbatch’s convincing performance, I did recognise some themes from Identity Management projects I’ve worked on.

Note there may well be spoilers in this post – I think the Turing/Enigma story is pretty well known anyway, and the film has opened in Australia later than other countries so a lot of people will have seen it already – but if you’d rather see the movie without reading anything about it, you have been warned.

Talk to the front line

The scene where they finally figure out the common words in all the messages comes from a random conversation with one of the women who intercepts German messages. Turing, and the other cryptologists, had been working directly from the data without talking to the people who were most “hands-on” with that data.

In the type of projects I work on it is so important to talk to Service Desk. In fact someone from Service Desk, preferably one with good, long experience of all the real procedures (not just the documented ones), and what sort of issues and requests are common…. a person like this should be assigned to the IdM project as an advisor, reviewer and tester. And yet somehow in most of the projects I’ve worked on Service Desk have been only incidentally involved, or left out altogether, and we always end up overlooking crucial factors that cannot be read directly from the raw data, and that no one actually assigned to the project knew anything about. I really must remember to insist in future…

Test with real data in real time

In the film, when they finally turn Turning’s machine on, they expect it to work straight away. The Commander (in a completely fictionalised scene designed for dramatic effect, but we’re talking about the film here after all) tries to sack him on the spot.

While not building a Bombe when I develop a FIM solution, I did relate to this scene. My solutions have a lot of “moving parts”, however much I try to keep it simple, and the whole thing doesn’t just “work” in it’s totality the first time I start running data through it. It has to be tested and bug-fixed and tested and improved – and the worst thing is when you’re simultaneously trying to deal with someone who thinks you’re clearly incompetent because it didn’t “just work”.

Something else I always insist on is testing with real data, preferably all of it. In the film they didn’t have dev and test machines, so the only data to test with was real data – and so they found out “in production” that it was just too slow. Too often in FIM projects there is an expectation that testing with a small set of perfect data will somehow translate to the same performance when run against real data in prod. Test your data load, test your bulk operations, and use real data. If operations take days and days to complete in test then that’s pretty important information!

Costing cannot be exact

I was pretty impressed with Turing-the-film-character’s confident quote of £100,000 to build the machine – though of course this was a film and in reality I can’t believe he was that precise. Even then the cost was presumably for the parts and not the labour – and that’s where it gets really tricky.

In a FIM project it is easy enough to quote for the “parts” – ie the software licenses and servers needed. Not so the labour however. While some aspects of the project may be boilerplate stuff that we’ve done before so can estimate accurately, every project contains elements that are specific to that environment. We are, in effect, inventing those parts of the solution for the first time – so how can we know in advance how long it will take?

When designing the Bombe Turing et. al. only had one protocol to deal with: the Enigma machine stayed the same but the settings changed at midnight. In a FIM project we may well be dealing with hundreds of different procedures and rules – some of which get changed part-way through development with no notice. You just can’t fix-price against that!

Get buy-in from the top

While not quite as portrayed in the film, my understanding is that Turing and co did have to appeal directly to Churchill for funding to continue their work. Automation is expensive to implement, and the benefits may be slow in the realisation – how ever there will be long-term cost savings and improved efficiencies from having a machine complete repetitive tasks the same way each time, and a lot more quickly than a human can. But people do lose their nerve, particularly when testing is drawn out and uncovering a lot of issues or forgotten “requirements”. Having the backing of the CEO and, just as importantly, an understanding of what s/he is expecting to get out of this project, is absolutely critical to getting over this hump.

So my suggested New Year’s resolutions, inspired by The Imitation Game, are:

• Always involve Service Desk (or similar frontline personnel) in developing and testing the solution,
• Insist on a full data set for testing,
• Time & Materials is the only way to do a FIM project – fixed-price is not realistic, and
• Get Winston on side!