Iterations, iterations, iterations. Every time you look at project methodologies they talk about “iterative approaches” or “short development cycles” as if they were a panacea for all the ills of modern IT. In some ways they are; keeping things short and concrete, with tangible results, does do wonders for keeping development projects on tract. What about things in IT other than development though? Don’t the rest of us count?
I’ve been told that iterations in “infrastructure” projects (software deployments, network upgrades, server OS upgrades, and operations) do not work. The whole idea, some of my managers tell me, simply cannot apply. Our work involves large, discrete changes which we can build up to but cannot do piecemeal.
From one perspective this point of view is absolutely true. When we change over server hardware or change out a switch, for example, we do not have the luxury of “iterating” the change over. Either we are on the new hardware or we are not. We may, if we have physical space, leave the old hardware in place as a fall-back position. If not, though, once the change is over it’s done with. The new hardware falls into the regular operational process and we move on with our lives.
We could regard each move or change as an iteration in a larger project, though this is a very simplistic approach. Changing out one rack of servers might be the first “iteration”; changing another the second, another the third, and so on. With each iteration we would, hopefully, learn something useful to making the next effort go more smoothly. By the time we get to the sixth or tenth rack, we should know all the tricks required to make it go well.
If we look at it, though, this “project” might actually be an activity within an operational process. Let’s face it – we’ve all migrated hundreds of servers. It’s not exactly like we didn’t know we would have to migrate another one, or that we haven’t been though the process enough times to make it almost rote. File and print servers are easy to move; application servers become somewhat more difficult when the application consultant’s hacked the software together, but we already knew all of that.
A more interesting project to look at might be the thing which goes almost unnoticed when you shift over hardware – the opportunity to install new operational monitoring software. Every iteration of these software products contains new features we can exploit if we feel up to it. Heck, we could even spend part of the migration time working on our monitoring process, so that we transform some of the chaotic mass of data we gather into actionable information.
So, we have two simple models for iterating infrastructure projects:
Iteration based on logistical constraints. We may do project work in sections when it is not practically possible to perform all of the work within a specific time-window (e.g. migrating a rack of servers at a time, rather than the entire data-center).
Iteration based on process functions. We may install software knowing we cannot use it now, but with a plan to slowly build up to using the software’s functions one at a time until we get full value from the system.
What other ways could we consider iterating an infrastructure project?