Wining & dining

Van tijd tot tijd laait het debat op over de superioriteit van legacy software. Recentelijk heeft Wouter Keller deze discussie weer eens aangesneden op Via Nova Architectura. In zijn bijdrage stelt hij “politiekcorrecte technologie” tegenover “bestaande oplossingen die zich bewezen hebben in de praktijk”. En, het laat zich raden, hij stelt dat techniek “een van de belangrijkste faalfactoren is bij ICT-trajecten”. Mijn bijdrage aan dit debat beoogt dit beeld enigszins te nuanceren.

De Kwestie

De discussie over de zin en onzin van het gebruik van nieuwe technologie is zo oud als de IT-sector zelf. Er zijn vast nog schrijvers te vinden die de voorkeur geven aan het gebruik van een typemachine boven een PC. Toch is het een hele poos geleden dat ik voor het laatst over een typekamer liep. Het moet ongeveer in dezelfde tijd geweest zijn dat er een hevige discussie werd gevoerd over het gebruik van compilers voor tijdkritische processen. Er ging tenslotte niets boven ambachtelijke assemblercode.

Sindsdien heb ik opmerkelijk soortgelijke argumenten pro en contra nog diverse malen horen langskomen. Bijvoorbeeld bij de overgang van tekstgeoriënteerde schermen naar GUI's, de migratie naar relationele databases, bij de invoering van Client/Server technologie, bij de adoptie van webgebaseerde user interfaces en – last but not least – bij het gebruik van CBD en SOA. Telkens als het tegenzit, zoals bij organisaties die momenteel worstelen met opschaling van SOA, dan zijn de doodgewaande dino's er als de kippen bij om te betogen dat al die moderniteit in de praktijk alleen maar problemen oplevert en dat het vroeger allemaal beter was. Legacy is voor de één een haast onuitroeibaar onkruid, terwijl de ander trots is op het stoere, robuuste karakter ervan. Herkenbaar?

Er is een keur aan wijnen op de markt. Van jong tot oud, van soepel tot geraffineerd. Belegen wijn is jarenlang vertroeteld, de besten op nieuw eikenhout, voor een smaakvol en complex resultaat. Wie van zulke wijnen houdt, en dat zijn er velen, hecht aan oude tradities en is bereid om een stevige prijs te betalen. De pleitbezorgers van legacy software kunnen hier zeker moed uit putten.

Iedere levensgenieter weet dat wijn de kroon is op een goede maaltijd. Echter, niet iedere wijn past bij elk gerecht. Het echte succes zit in de combinatie. Zoals een witlofschotel baat heeft bij een Chileense Carmenère, een Australische Syrah heel goed past bij een Hongaarse goulash en een Kaapse Riesling een betoverend oesterwatertje is. En omgekeerd moet ik niet denken aan een mooie Sancerre met Hollandse Nieuwe, of een onvolprezen Barolo met erwtensoep. Yeck.

Een goede wijn kan een goede maaltijd tot een belevenis maken – mits goed gecombineerd. Een slechte wijn, of een slecht gecombineerde wijn kan een prima maaltijd behoorlijk bederven. En, jammer maar helaas, een goede wijn kan een slecht maal niet redden – tenzij je er misschien heel veel van drinkt (maar ook daar krijg je later spijt van).

Iets soortgelijks geldt voor archITectuurkeuzes. Er zijn boeken volgeschreven over succesvolle combinaties, patterns, maar hoed u voor het toepassen van goede technologie die niet past bij het probleem dat opgelost moet worden. Verwacht ook niet dat goede architectuur een slecht project kan redden. Dat levert hoogstens een kater op.

Weerwoord

ArchITecten worden verantwoordelijk gehouden voor architectuurkeuzes. Dat is een complexere en verantwoordelijkere taak dan sommigen zich lijken te realiseren. Zij hebben de neiging om slaafs de voorgeschreven referentiearchitectuur te volgen, of om juist vast te houden aan de vertrouwde keuzes uit het verleden. Beide vormen van jumping to solutions miskennen de echte waarde van (werken onder) archITectuur. Goede archITectuurkeuzes zijn geen sinecure! Het is een vak, dat veel studie vereist – al is het maar om de ontwikkelingen in de technologie en de ervaringen ermee nauwgezet te volgen. Een sommelier moet tenslotte ook blijven bijleren over de nieuwe jaargangen en de opkomende wijngebieden om bij te blijven in zijn vak.

Als projecten niet lukken, dan is de gebruikte technologie een dankbare zondebok. Het projectteam treft dan tenminste geen blaam, want de leverancier heeft de feiten anders voorgespiegeld, zo redeneert men. In de realiteit mislukken er maar weinig projecten door slechte technologie. Als je achteraf eerlijk analyseert wat er is misgegaan, dan blijkt het veel vaker te liggen aan verkeerde technologiekeuzes (erwtensoep met Barolo). En daarbij is het zeker niet zo dat het altijd ligt aan het kiezen van eigentijdse architectuur voor ouderwetse problemen; het kiezen van bewezen architectuur voor moderne problemen is een minstens even grote valkuil.

Een minder vaak belicht aspect is de neiging tot het schromelijk onderschatten van de consequenties van modernisering. Het is één ding om een – laten we zeggen – Progress ontwikkelaar naar een .Net cursus te sturen om te leren om webapplicaties te bouwen. Maar daarmee heb je nog niet de competentie in huis om self-service applicaties te kunnen ontwerpen of om websites professioneel te hosten. Net zo min levert het ontwikkelen van herbruikbare services een bijdrage aan het oplossen van het governance probleem. Gert Florijn heeft daarover laatst een behartenswaardig interview gegeven in het blad “service oriented architecture” [1]. Het zou archITecten naar mijn mening sieren als zij de verantwoordelijkheid zouden nemen om dit soort zaken vroegtijdig te signaleren

En ja, ook ik kom in mijn adviespraktijk projecten tegen die gewoon gefaald zijn door een slechte besturing. Eigenlijk is het onderschatten van de consequenties van veranderingen daar ook een vorm van. Want die consequenties hadden doorgaans best vooraf voorspeld kunnen worden. Het is en blijft kennelijk verschrikkelijk moeilijk om te leren van fouten van anderen. Jammer is dat.

Er moet mij nog één ding van het hart. Er wordt soms met wat dedain geschreven over het gebruik van moderne technologie als uit de hand gelopen hobby van de nerds uit de pizzakelder. Ik vind het volkomen legitiem om het ontwikkelen van nieuwe competenties als prominent nevendoel voor een project op te voeren, zo lang die nieuwe competenties maar stevig zijn ingebed in de strategie van de organisatie. Daarom is het juist zo belangrijk dat archITecten zijn aangehaakt bij de strategische dialoog.

Om nog één keer terug te grijpen op de metafoor van de wijn: ook hier geldt dat een wijn, hoe goed hij ook is opgevoed, na verloop van jaren over zijn hoogtepunt heen is. Dan gaat hij onverbiddelijk alleen nog maar achteruit. Zo is het ook met technologie. Eerst groeit het gebruik minder hard dan de markt, dan groeit het helemaal niet meer en daarna krimpt het marktaandeel alleen nog maar. Voor leveranciers is dat het signaal om de investeringen anders in te gaan zetten. Medewerkers die nog een carrière voor zich hebben, raken ook minder bereid om hun tijd en energie te investeren in oude technologie. En tegen de tijd dat zoiets zich aan het voltrekken is, dan kun je maar beter een alternatief achter de hand hebben.

Als je als organisatie het lef niet hebt om te investeren in de toekomst, dan moet je ook niet gek opkijken als het slecht met je afloopt. Daar kunnen de vele geoutsourcede IT-afdelingen inmiddels over meepraten.

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 17de in een reeks die op dit weblog gepubliceerd zal worden.

[1] Dré de Man: “Struikelend hardlopen”. Service oriented architecture, mei 2009, p. 6.