De lengte van de polsstok

In opdracht van detacheerder Yacht is het boek ‘De Belofte’ uitgegeven met daarin visies op de business value van service oriented architecture, geschreven door Nederlandse professionals op hoog bestuurlijk niveau. Frans Haverkamp is CIO bij Eneco. Het gebruik van gezond verstand – en de menselijke maat – bij beslissingen in de IT heeft hij hoog in het vaandel staan. Met zijn lange ervaring in de IT is hij niet onverdeeld enthousiast over SOA. ‘Er is een wetmatigheid van nieuwigheden in de wereld van de IT, en daar moet kritisch naar gekeken worden. SOA biedt nuttige hulp, maar je moet het niet tot een doel promoveren.'

‘Achtendertig jaar werk ik in de IT, vanaf mijn twintigste, dus ik heb al heel wat trends en hypes voorbij zien komen. Wat ik in de loop van de jaren heb meegemaakt, is dat zich in de ICT-wereld met wetmatige regelmaat ultieme oplossingen aandienen. Dat varieert van een systeemontwikkelingmethodiek tot aan ‘agile development' wat nu op ieders lippen bestorven ligt. Je kunt min of meer vaststellen dat het vakgebied, na zo'n veertig jaar voortgang, nog steeds niet echt volwassen is. Er is een enorme verspilling. IT-projecten vliegen nog steeds uit de bocht wat betreft kwaliteit, geld en specificaties. Slechts dertig procent van de initiatieven komt in de buurt van de initiële vereisten wat betreft de requirements van tijd, geld en kwaliteit. Ik vind het bedroevend dat we in ons vakgebied na zo vele jaren nog steeds een dergelijk zwakke prestatiespiegel hebben, ondanks het gebruik en de invloed van ITIL, Prince II en dergelijke.
Hoewel ik Service Oriented Architecture nog steeds aanmerk als een hype, onderken ik wel dat deze architectuur praktische hulpmiddelen aanreikt voor de ontwikkeling, de implementatie en het beheer van systemen. Toch prevaleren voor mij de ‘basics' van het gezonde verstand. Gezond verstand houdt in dat je projecten in hapklare brokken verdeelt, dat je ze overzichtelijk houdt. Een belangrijk aspect bij ontwikkelingen is dat je gelijke tred houdt met de leercurve van de mensen mét wie je ontwikkelt, maar ook rekening houdt met het adaptatievermogen en de leercurve van de mensen vóór wie je ontwikkelt. En daar zie je dikwijls enorme spanningsvelden. Het gebeurt nog steeds vaak dat er een euforie ontstaat bij de definiëring van requirements wanneer een IT-initiatief wordt ontplooid. Er wordt een overvloed aan specificaties gedefinieerd, terwijl niet wordt nagedacht over de vraag of er wel aan kan worden voldaan binnen de gestelde tijd en binnen het budget. En er wordt al helemaal niet bekeken of het beoogde systeem de business ondersteunt. Het is veel verstandiger om delen van systemen gefaseerd te ontwikkelen en in gebruik te nemen, zodat ook lering kan worden getrokken uit het voortschrijdend inzicht tijdens dit continue ontwikkelingstraject.
Bovendien wordt dan ook de menselijke maat veel meer in acht genomen. Ik gebruik graag de vraag: ‘wat is de lengte van jouw polsstok?' Die kun je langs een financiële as of langs een intellectuele as leggen. Wat kan een organisatie zich financieel veroorloven, welke resources zijn er, wat kan de IT-afdeling aan werk aan, en wat kan het aan specificaties aan? Ook is vanuit de business vaak sprake van een iets te enthousiaste vraag naar wat in een rapport moet staan. De business wenst gaandeweg steeds meer ondernemings-, verkoop- en marktgegevens gerapporteerd zien, maar de vraag is of al die cijfers en gegevens nog wel begrijpelijke informatie opleveren. Door al die cijfers kan het gebeuren dat zakelijke beslissers de markt niet meer helder zien; het wordt intellectueel onmogelijk om al die rapportgegevens te verwerken en daarop gebaseerd een intelligent besluit te nemen. Opnieuw, ik pleit daarom voor gezond verstand.
Het gebruik van gezond verstand geeft dikwijls meer handvatten dan SOA. SOA biedt onmiskenbaar nuttige hulp, bijvoorbeeld om hergebruik te faciliteren en efficiëntie te verbeteren, maar het brengt je niet als bij toverslag in een veilige haven. Je ziet echter maar al te vaak dat hulpmiddelen worden gepromoveerd tot een doel, en dat brengt je in veel gevallen niet wat je oorspronkelijk voor ogen stond. Neem het voorbeeld van de aanloop naar het millennium. Eind jaren negentig hadden we de dolle dwaze IT-jaren waarbij een paar stuwmeren ontstonden die elkaar versterkten; het stuwmeer van het jaar 2000, de introductie van de euro en de internethype. Deze kwamen als een tsunami over ons heen en deden de boel ontploffen in het jaar 2001. Iedereen moest overal in investeren, maar nadat alles een beetje tot rust was gekomen, ontstond een negatieve tegenwerking. Toch waren er ook positieve ontwikkelingen; neem het internetbankieren. In die tijd waren de mogelijkheden daarvan marginaal, maar inmiddels is via een evolutionair ontwikkelingsproces veel mogelijk. De ontplooiing van functionaliteit gaat gewoon door – maar wel in delen, met een gefaseerde ingebruikname.
Banken benutten de bruikbare elementen van SOA in hun bedrijfsprocessen. Bij Eneco, vooral in de zakelijke markt, vindt de ontwikkeling van producten in een redelijk hoog tempo plaats. IT moet de businessontwikkelingen dan ook dicht op de hielen zitten. Dit betekent dat je de ontwikkeling en dienstverlening gestructureerd opzet om de time-to-market zo kort mogelijk te houden. En net als in de financiële wereld is een nieuw product bij ons ook vaak een nieuwe combinatie van bestaande componenten. Je bent min of meer met composers bezig, en zo zou je ook in de software met composers bezig kunnen zijn. Moderne softwareontwikkeling bestaat vandaag de dag deels uit het combineren van nieuwe functionaliteit met bestaande componenten. Ook leveranciers zijn bezig om stukje bij beetje verbeteringen aan te brengen in hun softwareproposities, ook zij combineren nieuwe componenten met bestaande elementen en doen er dan een fraaie strik omheen met een etiket als SOA of objectgeoriënteerd ontwikkelen. Maar de vraag is: hoe ontstijg je het ‘me too'- niveau?
Ik zou graag het dogmatische of het gepropageerde wetmatige van de ultieme oplossing die om de zo veel tijd opduikt – of dat nu SOA of OO of client/server heet – eraf willen halen. Service Oriented Architecture heeft zo zijn voordelen, laat me dat benadrukken. Bij Eneco willen we bijvoorbeeld alle klantinteracties zo veel mogelijk web-enabled laten verlopen. Deze omvatten het opgeven van meterstanden en verhuizingen, switchen van energieleverancier en nog meer. Dat kan allemaal via internet. Maar daar hebben we geen SOA voor nodig. Bedenk dat in de eerste drie, vier jaar van internetbankieren de term SOA nog niet eens bestond, maar de manier waarop toen vele zaken plaatsvonden, zouden we nu bestempelen als kenmerkend voor een SOA look-alike omgeving. Het lijkt alsof je achterloopt of niet goed met je vak bezig bent als je SOA nu niet omarmt, maar dat is onzin.
De cruciale vraag voor mij is of cijfermatig en kwalitatief kan worden aangetoond welke businessvoordelen SOA heeft gebracht, vergeleken met wanneer SOA nog niet in een organisatie zou zijn geïmplementeerd. Ik heb daar nog nooit een helder antwoord op gekregen, van niemand. Dat wil niet zeggen dat een Service Oriented Architecture daarmee wordt gediskwalificeerd, maar het lijkt alsof niemand antwoord kan geven op wat SOA nu echt is, en wat de bruikbare elementen zijn. Bovendien zijn ook organisaties voortdurend in ontwikkeling. Mogelijk bruikbare IT-componenten hoeven niet per se bruikbare elementen te zijn voor een organisatie. Eneco bijvoorbeeld heeft een behoorlijk complex applicatielandschap dat nog veel meer gerationaliseerd kan worden. Dat is een doorgaande ontwikkeling, werk in uitvoering, maar het wil niet zeggen dat ik het hele applicatielandschap van onze onderneming moet ver-SOA-en. Ik ben gematigd sceptisch, of gematigd enthousiast, maar ik ben zeker geen SOA-profeet.'