Bimodal IT: Let the backlash begin

Gartner defines Bimodal IT as: “the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed”.

I find myself more than a little bemused by the concept. First of all, why would I want to manage two separate modes of activity? That means that either I have to employ different people with specialisms in different approaches (expensive) or I have to take on people who are skilled in both areas (which by definition means they're not going to be best-of-breed in either).

Second, I have a strange liking for the concepts that Gartner mentions in Mode 1: safety and accuracy. I find it useful that my IT systems don't kill people; here in Jersey, for example, it's frowned upon if too many employees die in tragic business systems accidents. And in my experience, the CFO tends to be quite irritable if the month-end numbers don't add up. I also find security and integrity fairly useful too, along with availability – all things that can suffer in Gartner's so-called Mode 2 at the expense of agility and speed.

Back to the future

Although the term “bimodal IT” is relatively new, the concept isn't. Back in the 1990s I worked in an environment with two distinct approaches to IT: one slow, steady and methodical, and the other fast-moving and bleeding edge. Did the latter break more than the former? No, actually it didn't – but only because it was done by a small number of very technical people who could respond quickly to issues. Did it bring advantages? Yes: it was doing IP-based wide area stuff long before the other part of the IT world.

Would I go back to that setup tomorrow? Not on your nelly – it put a group of techies out on a limb, largely unsupportable by the other team and hence permanently lumbered with supporting bleeding-edge technology whenever it threw a tantrum and interfacing it tenuously into the core systems in the face of reluctant sighs from the core support group.

I had another of these “parallel” examples more recently, when a new senior techie decided that he would spin up cloud-based servers seemingly at random alongside the company's well-managed, well-documented and extremely stable infrastructure. He took exception, for some reason, when someone called him a “f**king cowboy”.

Gartner also mentions “sequential” in its concept of Mode 1, but I disagree in part. I can see what they're getting at: they mean following processes, introducing new versions in turn, and such like. But actually, controlled system development doesn't have to be entirely sequential: the infrastructure guys can, for example, be building their part of a project while the software developers are building their part in the existing development environment. This said, though, the only way that IT can support an organisation adequately is to have proper policies, processes and controls governing it – which means doing things in a sensible order and with checks and balances at every step.

So what's so bad about “exploratory” and “non-linear” IT operation? Errr … nothing, actually. Research and experimentation are fine disciplines, and the old adage is true: it takes at least two or three iterations and much tearing up of early designs before you get to the most workable solution. Had a great idea that you think could benefit the business? Take a week and have a lash at it, to see if it stands a chance of being any good: but do it on the dev platform or the lab bench, there's a good chap.

One company I worked with stands out in my mind in the latter sense. The boss would come down and say: “Can you do XXX?”; we'd put on a pained look and say: “Errr … very possibly not, but give us a few days to play”, before locking ourselves away with a whiteboard and a couple of developers for a few days. We always found a way to do it – sometimes through cunning design, sometimes through writing a cheque for new kit because the current equipment didn't deliver all the functionality we needed.

And here's the thing with this Gartner idea of two “modes”. What happened in the above cases, where our experimental, nimble approach came up with something worthy of putting into production? Well, once we'd proven the idea and had something that was sensibly performant we then put down the design and iterated the new concepts into the next release of our system.

We had, then, a world with the ability to set aside a small team (in that case on a part-time basis) to innovate and experiment but which had a traditional model of design, review development, testing and release. And you know what? Many of the companies I worked with before and since had exactly the same concept.

In fact, the only place where it didn't work was in the earlier example of two parallel IT approaches; that may have been because that setup was accidental rather than deliberate, and/or because it certainly wasn't properly managed, but I somehow suspect it was just that the two approaches are naturally awkward bedfellows.

But a setup that has a flexible, agile innovation team whose outputs feed into the production cycle via proper analysis, security consideration and change control? Yes, bring it on, that's an excellent setup.

But that's not “bimodal”. It doesn't need a new word, because it's not a new idea. It's just IT. ®