IT Executive column: Proof of Concept

Ik reis graag met de trein van en naar ons hoofdkantoor in Parijs. In de Thalys zit je comfortabel en je kunt op je gemak documenten doorlezen of je laptop openklappen. En het heeft iets melancholisch, dat ontspannen wachten op de trein onder de historische koepel van Den Haag Holland Spoor (elk moment lijkt Carice van Houten op te kunnen duiken, gehuld in een grijs vilten mantelpakje met bijpassende hoed). Een stuk beter dan aanschuiven in de lange rij van de veiligheidscontrole op Schiphol of uren jakkeren op de snelweg.

In elke idylle rammelt echter wel wat. Zo ook in de Thalys, waar luidruchtig mobiel telefoneren tot de alom geaccepteerde mores hoort. Ik luister regelmatig belangstellend mee – veel keus heb ik trouwens niet – temeer daar de voornamelijk Nederlandse en Britse schreeuwlelijkerds hier geen enkel bezwaar tegen lijken te hebben. De meest vertrouwelijke zakelijke transacties worden zonder enige gêne met de rest van de coupé gedeeld. En verdomd als het niet waar is, het gaat bijna altijd over IT. De proof-of-concepts, pilots, roadmaps, workstreams en sourcing-vraagstukken vliegen je om de oren. “Dat zit écht niet in de SLA” roept er een triomfantelijk. “Maak jij je nou maar geen zorgen over dat testplan,” bezweert een ander vaderlijk. “Het is half 9 in de avond, ga jij eerst maar eens lekker naar moeder de vrouw”.

Toch heeft het ook zijn charmante kanten, zo’n trein volgepakt met it’ers. Er wordt in ieder geval heel wat minder CO2 geproduceerd en deze beroepsgroep lijkt een natuurlijke aanleg te hebben om het werk onverstoorbaar en monter te blijven doen, op welke plek en vanuit welke positie dan ook. Met technologie kunnen we het mobiliteitsprobleem te lijf, dat verkondigen we aan iedereen die maar wil luisteren. Misschien moeten we alleen zelf nog wat meer het voorbeeld geven, wat meer ons eigen hondenvoer eten.

We hebben alles in huis om van het gros van de it’ers uit de auto te krijgen: collaborative development tools, virtuele projectruimtes, sociale netwerken en software uit de cloud. Via unified communications kunnen we intensiever contact met elkaar en met onze klanten houden dan op kantoor, als het moet vanuit de trein, maar ook vanaf thuis of een flexibele werkplek, ergens dicht bij waar we wonen. En misschien kan iemand eens wat mooie mashups in elkaar draaien? Je zou dan met behulp van Google maps en de agenda’s van het projectteam precies moeten kunnen vaststellen op welke plaatsen het werk kan worden gedaan met minimalisering van de reistijd.

Over proof of concept gesproken. Stel je voor als we met behulp van technologie alle it’ers met hun leasebakken van de weg weten te krijgen. Gooi die spitsstroken maar weer dicht, zou ik zeggen.

Gepubliceerd in IT Executive magazine, 22 september 2009

IT Executive column: Romeinse Cloud

Ooit bracht ik een zomer door met Isaac Asimov’s The Foundation, volgens ingewijden de beste boekenreeks uit het sciencefictiongenre. Veel is me van het verhaal niet bijgebleven maar de rode draad zit in het principe van psychohistory: de toekomst kan beter worden voorspeld naarmate er meer personen bij zijn betrokken. Met het collectieve denkvermogen van een compleet heelal kom je bijvoorbeeld al een heel eind.

Stel je voor: alle individuen uit het heelal met elkaar verbonden, iedereen met zijn eigen pagina op Facebook en voortdurend aan het tweeten. Dat is nog eens een sociaal netwerk.
En wij maar moeilijk doen over Enterprise 2.0.

Maar ik dwaal af. Een ander thema dat ik me van de serie herinner is dat van de inzakkende beschaving. Er is sprake van een planeet waar gebruik wordt gemaakt van uiterst complexe machines. Met één klein, lastig probleempje: de makers ervan zijn lang geleden vertrokken. Die zitten waarschijnlijk in een ander universum of zijn gewoon op tijdreis tussen twee zwarte gaten (gaat u me nu vooral niet e-mailen over de details, ik probeer een punt te illustreren). Hoe dan ook, niemand weet meer hoe de machines werken en terwijl de een na de ander het krakend begeeft, vraagt de bevolking van de planeet zich suffig af hoe het nu verder moet.

Een verhaal met dezelfde allure als de ondergang van het Romeinse rijk. Ik moet er deze week onwillekeurig aan denken. Vers teruggekomen van een zonnige rondreis door Spanje beland ik in een workshop met financiële directeuren. Het onderwerp: hoe nieuwe technologie de rol van de cfo gaat veranderen.

Inderdaad: na de vakantie kun je maar beter zonder aanloop weer aan het werk gaan. Gelukkig blijkt de discussie interessant. Ik leg de principes van de cloud nog eens uit: zowel rauw rekenvermogen als complete applicaties haal je straks van elders, ergens op internet. Dat is simpeler, goedkoper en groener. En je houdt nog eens tijd over voor andere zaken, zoals beter zijn dan de concurrentie. Klinkt plausibel. Toch wordt een aantal financieel directeuren nerveus van dit toekomstperspectief. Informatie en systemen vormen de kern van de financiële administratie. Ze zijn de sleutel tot in control zijn. Sommigen zien spookbeelden voor zich van een organisatie die alles heeft uitbesteed en van de weeromstuit is vergeten hoe processen horen te werken en hoe systemen in elkaar zitten: suffig wordt naar die cloud gestaard, waarin onbegrijpelijke dingen gebeuren.

“Dan moet je vanaf nu eigenlijk ook geen rekenmachine meer gebruiken,” merkt er een op. Goed punt. Misschien dat sommigen iets van de cloud beginnen te begrijpen. Maar elders klinkt het nog als sciencefiction. Letterlijk.

Eerder gepubliceerd in IT Executive magazine

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