Ride a Snail

An organization wants rebuild its critical software infrastructure on new data and software platforms, with rearchitected data structures. The system is large, complex, and critically important to internal and external users. The rebuild will take a year or more but there cannot be a day of downtime. It's what people call a problem of changing horses in midstream. 

Instead of horses, consider riding a snail.

My admiration of gastropods dates back to a pet slug I once had. "Doug" was fascinating to watch: using his delicate palps and eye stalks to explore and navigate; climbing over obstacles; quickly condensing his body into a small, hard form when disturbed. Left alone, he would leave a light trail of slime to show where he'd been and what he'd done. Once, he escaped from his terrarium and made it surprisingly far down the hallway before he was apprehended. Particularly impressive was Doug's ability to get from one surface to another, across gaps seemingly far too wide for a non-jumping animal.

A snail (or a slug, but Youtube only has snails) begins solidly planted on one side of the gap. Its head and slender front end are free to stretch, reach, and explore. The front end settles on a destination, and then a gradual and almost imperceptible change begins. If you watch the video you'll see the shell cross over. But that's only part of what moves: the snail is actually shifting its insides forward within its body. At the end, when it lifts its back end away from the starting place, the "tail" has become light and easy to lift, with the center of gravity now securely on the far side.

It's a compelling vision for how to transition a software system: establish a small base of functionality on the new platform, with a live connection to the old architecture. Incrementally shift functions from the old platform to the new one, until all functions have migrated and the old platform can be disconnected completely. A beautiful trick if you can pull it off; but the details are key. Is there a simple and reliable "live link" that will allow components to interoperate across the gulf? In what sequence can modules migrate? Are some modules too tightly interconnected to migrate separately? In the case of one organization that collects, curates and delivers market intelligence data, it was possible to connect old to new via a one-way data transformation converting the old data structure to the new. With delivery functions migrating first, content management functions next, and content creation last, we have been able to minimize the need for data to flow backward from the new architecture to the old.

Is the work of a continuous transition worth the trouble? Easily! In our case, there was an urgent need to deploy an updated presentation system as soon as possible. But even without that pressure, an incremental transition is best. Imagine the opposite strategy: build the new system from scratch, with all new functions implemented, until the big day comes when everyone can switch to the new system. The "big day" is likely to be the first of many very stressful days, as users struggle to adapt and glitches and problems are exposed. Incremental live deployment ensures that each new system component gets the vetting and tweaking that it needs. It's technical and organizational change at a manageable pace—a snail's pace.

Rebuilding critical infrastructure while the organization continues to function.