Haussmannisation

This may come as a surprise from a Chief Technology Officer, but in my family I am not exactly seen as a handyman. When it comes to construction skills, I am more like the laugh of the town. My brother effortlessly builds entire kitchens and just for the fun takes care of the plumbing and electrical wiring too. Personally, I already get nervous when I watch a Billy bookcase kit getting unpacked.

On the other hand, I have undisputed demolition skills. Give me a sledgehammer and within a few hours even the worst junk yard looks like an empty Zen garden. An underestimated, yet quite useful skill that is becoming more and more relevant in the IT landscape as well.

Because let’s face it, our systems developers are still mainly educated as constructors. This is done from the downright naïve perspective that software is developed in a green field situation. Almost all of the innovations in our profession aim to build better, faster and smarter. Starting from nothing. For that, we fill our toolboxes with accelerators such as Model Driven Architecture, frameworks, components, services, Domain Specific Languages and code generators.

And then we are genuinely disappointed that these toolboxes are being used less and less.

The reason? All the junk that the constructors before us – or maybe even ourselves – have left behind. The bulk of the budget of the average IT department is spent on keeping existing systems operational. Sometimes, these systems have been written in programming languages that are only known from old myths. I recently heard about a certain crucial Scandinavian government system that is only understood by one single, 74-year old programmer. He is being kept alive with iron pills, massages and daily blood transfusions.

The butter mountain of immovable, inflexible and rusty software continues to grow year after year. And with it, the frustration that there is not enough room to build new, differentiating applications. You can envision the most beautiful kitchen, but if the collapsed roof and walls prevent you from even putting a ladder there, all your intentions and handy skills won’t get you far.

I would therefore like to make a passionate plea for bringing back the good old craft of demolition in systems development. Just to be able to have a sharp, scrupulous look at the existing portfolio of applications would be a big step forward. Which parts of the system deliver real value to the business and which don’t? What proportion has the value to the amount of time that is dedicated to it? And to what extent is the underlying technology still relevant and extendable?

This will all give inspiration to putting together a demolition strategy. Migrate the data, throw all existing applications away and replace by non-customised packaged solutions, for example. Or isolate the most unstable elements and rebuild them piece by piece on a new platform. Or extract business process logic and business rules from the old code and house them in separate business process management or business rules systems. Or use automated tools to disentangle the structure of the existing software and simplify it. Or – if everything else fails – stabilise the old system as much as possible and build new interfaces and façades around it.

Much like "cutting through an old town of dense and irregular medieval alleyways into a rational city with wide avenues and open spaces which extend outwards far beyond the old city limits". The difficult part of urban planning like that is not constructing the new roads, squares and buildings. It’s getting rid of the old ones and dealing with all types of resistance that inevitably comes with it.

True Haussmannisation indeed. We should watch and learn some of these old crafts again.

Published earlier on Capgemini's CTO blog and AOGEA's Architectural Existentialism blog