Updates

A few quick updates for keen readers: I know I haven’t been posting as regularly as I would like. There are a few things in the pipeline, but nothing brought to fruition as yet.

For those worried about whether or not my business case for multiple monitors was successful or not: it was indeed successful. My PC was swapped out and a second monitor installed on Thursday morning. So far, they are everything I hoped for and more.

I’m sure there is also great interest in how things are progressing with Phoenix, the idea of managing IT systems from cradle to cradle, rather than cradle to grave. Unfortunately, there has not been a great deal of activity on this front, but let me leave you with a qualification, a question, and the promise of more to come.

The qualification: Despite the reference to Cradle to Cradle, Phoenix isn’t about green IT systems – although they are very important. Instead, Phoenix is about how the information imbedded in one system survives the death of that system, and rebirth in another.

The question: if you’re developing new functionality with a system today, the odds are pretty good that XML is involved. Are we at the point where we have standardised building blocks for XML schemas? For example, physical mailing addresses: is there the one true XML schema for address information? Or are there a half a dozen competing standards, plus hundreds of unique implementations imbedded within larger frameworks?

The promise of more to come: there will be more to come.

Pheonix

Almost everything we come in to contact with is designed to be thrown away. Toasters, couches, computers, buildings, public transport systems – almost everything we use will eventually end up in land fill. When we design things, we normally don’t think about what will happen once it’s served its purpose. If we do, it’s only to plan how we can manage getting rid of it. Often we don’t even do that. Most of us are guilty of hoarding some useless thing or other, simply because we never thought about what we’d do with it once we were done with it.

IT systems are no exception.

A few years ago I read a fascinating book called Cradle to Cradle: Remaking the Way We Make Things by McDonough and Braungart. The normal approach to design – the one we experience every day – is cradle to grave design. We design a product or service to be created, used, maintained, and then thrown away. McDonough and Braungart opened my eyes to a different type of design. Designing things in a way that allows them to be reborn when they’ve reached the end of their current life.

For physical objects, this means designing things to be either recyclable or biodegradable. There are countless examples of what can be done. Phones that simply pop-apart when heated above a certain temperature, making it economical to recycle their component parts. Square carpet ’tiles’, instead of rolls of carpet, that can be replaced individually when they wear, and again be recycled in to new carpet (your office, if it’s been fitted out recently, probably has these.) The ‘renting out’ and re-capture, rather than sale, of industrial chemicals.

Why do these things? Because we’re running out of land fill and resources, and so ultimately we have no choice. But perhaps more relevantly, because it’s often cheaper. In the long term, it’s cheaper to design products and services that create more resources than they use. To design products and services that will be the foundations that tomorrows products are built upon, and the fertile soil that tomorrows services grow within.

Does this have any lessons for IT management? We habitually manage our systems and services on a cradle to grave basis. Indeed, IT management frameworks such as ITIL build in the assumption that systems will be decommissioned-thrown in the bin. We make decisions on the basis that, at some point, the system is going to be replaced. We take shortcuts when developing new processes or capabilities, because we know we won’t have to support them forever. Often, we avoid making necessary changes because a new system is perpetually just around the corner.

Would we make different decisions if we were managing IT cradle to cradle? What would this mean in practice? Stay tuned.