Hoe laat je een olifant dansen?
Grote organisaties met een it-omgeving die in tientallen jaren is uitgegroeid tot wat zij nu is kampen allemaal met een Grote Interne Vijand, die hun beperkt in hun mogelijkheden om op snel wisselende externe omstandigheden te reageren. Deze vijand heet Complexiteit. Hierdoor wordt alle IT – hoe hoogwaardig ook – op den duur een blok aan het been. Wat dan te doen? Het blok aanvullen met snelle apps? Het blok in zijn geheel – dan wel in stukjes – converteren tot een nieuw en beweeglijker blok? Of langzaam maar zeker en heel voorzichtig uithollen?
Kort geleden werd bekend dat de Raad van Bestuur van de SVB (Sociale VerzekeringsBank) de handdoek in de ring gooit. Een groot automatiseringsproject dat daar onder leiding van Capgemini werd uitgevoerd liep op de klippen. Schadepost: tientallen miljoenen, misschien wel meer dan 100 miljoen. Dit project loopt al sinds 2006 en er is in totaal al 121 miljoen euro in geïnvesteerd. Het schip strandde trouwens al eerder. Capgemini is vijf jaar geleden in huis gehaald om het weer vlot te trekken. Sinds die tijd is er 43,7 miljoen euro belastinggeld ingestopt. Het is onduidelijk wat er van al dit programmeer- en systeembouwwerk uiteindelijk hergebruikt kan worden in een oplossing die wel gaat werken.
Het ziet ernaar uit dat de SVB in 2006 gekozen heeft voor strategische Optie 2 (als geheel converteren naar iets nieuws). Dat is een riskante strategie, want als er iets mis gaat, dan gaat het ook faliekant mis. Aan de andere kant: gaat het goed, tel dan je zegeningen. Maar het risiconiveau van Optie 2 is wel zeer hoog. Dat is waarom onze overheid niet snel weer mega-projecten zal opstarten. Er is wat dit betreft veel leergeld betaald bij Defensie, bij BZK (P-Direct) en nu dan bij Sociale Zaken.
Optie 1, aanvullen met apps, biedt snel soelaas, maar ook hier loert een groot gevaar, al is dat in eerste instantie misschien nog niet zo herkenbaar. Snelle apps moeten ook beheerd en onderhouden worden en de techniek schrijdt almaar voort. Wat nu simpel is kan over een jaar al ingewikkeld zijn en over vier jaar gekmakend complex. Wie voor Optie 1 kiest bestrijdt complexiteit met nieuwe complexiteit. Want het blok blijft gewoon zitten en daarbovenop ontstaat een nieuw – moderner – blok. De risico’s van deze aanvulstrategie zijn op termijn misschien nog wel groter dan die van Optie 2. Ze worden alleen pas volledig zichtbaar in de toekomst. Altijd handig voor het carrièrepad van de CIO of CFO.
Fade-out en fade-in
Waar grote risico’s tot iedere prijs vermeden moeten worden, lijkt Optie 3 (uithollen) de meest verstandige strategie. Het oude blok blijft in stand, maar daarnaast ontstaat iets nieuws dat het langzaam maar zeker leegzuigt. Het is een soort fade-out- en fade-in-situatie, zoals in een videomontage.
Maar vergis je niet. Ook deze voorzichtige keuze brengt risico’s met zich mee. Voornamelijk tijdgerelateerde risico’s. Want wat nu als je concurrenten sneller vooruitgang boeken met Optie 1 of 2? Dan kun je systeemtechnisch wel heel veel winnen, en je risico’s voorbeeldig beheersen, maar economisch toch het nakijken krijgen.
Voor Optie 3 is tijd nodig. Veel tijd. Of – wat op hetzelfde neerkomt – een ijzersterke markt- of branchepositie waardoor je zo’n transformatieperiode veilig kunt overbruggen.
Diep ingrijpen
Een goed voorbeeld van een grote organisatie die aan strategische complexiteitsreductie doet met behulp van ‘Optie 3’ is de Rabobank. Hier wordt de complexiteit veroorzaakt door historisch gegroeide, langgerekte en parallel uitgevoerde informatieketens, die in sommige individuele gevallen wel achttien stappen kunnen omvatten. Bij veranderingen in de commerciële sturing en/of wet- en regelgeving moet de bank wijzigingen aanbrengen in alle verschillende schakels in vaak meerdere parallelle ketens. Een energie- en tijdverslindend proces.
“Twee jaar geleden hebben we agile ingevoerd als methodiek om zulke aanpassingen sneller te kunnen doorvoeren,” vertelt Fabian van Altena, business change manager bij de unit CRG (Control Rabobank Groep). “Met agile kun je achttien stappen sneller aanpassen, maar het blijven wel achttien stappen die allemaal aantoonbaar juist moeten zijn en blijven. Het heeft een veel groter effect als we er vijf stappen van kunnen maken en verschillende ketens kunnen samenvoegen tot één gemeenschappelijke. Daar gaan we ook naar toe, maar dat kan niet zonder diep in te grijpen op de structuur van onze informatiesystemen.”
Eén datawarehouse
Toen CRG zich – ongeveer twee jaar geleden – diepgaand bezon op de beste aanpak voor deze ingreep in haar legacy-omgeving kwam ze tot de pijnlijke conclusie dat het in de Rabobankwereld met SAP BW als datawarehouse-oplossing niet zou gaan lukken. Integratie van informatie in het heterogene Rabobank landschap, dat slechts enkele SAP bronsystemen kent, is met SAP BW een te grote uitdaging. De overtuiging is dat het met het opener SAP HANA wel lukt. SAP HANA wordt dan ook in fasen geïmplementeerd.
“Onze vernieuwde infrastructuur zal straks één data warehouse voor de Finance en Control functie hebben,” zo schildert Van Altena het perspectief. “Alle verschillende parallele ketens en informatielagen worden daarin waar mogelijk en wenselijk geconsolideerd. In dat ene data warehouse zullen afzonderlijke datamarts worden opgenomen die ondersteuning bieden aan de verschillende bedrijfsprocessen. Een belangrijke operatie waarin de business case zowel kwalitatief als kwantitatief is. Wij staan als CRG voor één versie van de waarheid en hebben de ambitie om daarbij een kostenreductie van 30 procent te bewerkstelligen. Meerdere afzonderlijke systeemomgevingen worden geconsolideerd tot één. Parallel daaraan maakt de rest van de Rabo-organisatie een vergelijkbare ontwikkeling door. De tientallen grote gegevensverzamelingen die de bank nu telt zullen zo uiteindelijk zijn teruggebracht tot een stuk of zes.”
Knop om
Dit is binnen CRG allesbehalve een louter technisch proces, onderstreept Van Altena. “Het gaat ook om afstemming tussen de verschillende bedrijfsonderdelen. En in die zin is het een omvangrijke organisatorische en culturele operatie.”
Zowel in de business zelf als bij de it’ers van de bank moet een knop om. “Veel van onze medewerkers hebben hier moeite mee. Ze verliezen de zekerheid van een denkkader en van kennis die ze jarenlang hebben opgebouwd. Want de nieuwe manier van werken met SAP HANA is fundamenteel anders. Het is de basis voor een geconsolideerde gegevensverzameling binnen een heterogeen it-landschap. Daarnaast gaan we bijvoorbeeld werken met de software van Informatica voor de data-integratie. Er komen zo verbindingen met allerlei bronsystemen die soms van SAP zijn, maar vaak ook niet. Daar moeten onze mensen naar toegroeien en dat kost tijd.”
Gimmicks
Hoeveel grote organisaties zullen – net de Rabobank – gekozen hebben voor een langetermijnoplossing in plaats van voor wat snelle succesjes? Het zijn er niet al teveel als we de uitkomsten van een recent internationaal onderzoek van Vanson Bourne in opdracht van it-leverancier Micro Focus mogen geloven. Daaruit komt naar voren dat it-managers over het algemeen een lage prioriteit toekennen aan het moderniseren van legacy-applicaties. Oorzaak? De business ziet dit niet als innovatie. In het kader van het onderzoek werden 590 it-managers bevraagd en bijna drie kwart van hen (72 procent) kwam met dit antwoord.
Wat ‘de business’ wel als innovatie aanmerkt? Nieuwe gimmicks, apps en widgets, aldus de onderzoekers. Flashy stuff waar je mee voor de dag kunt komen. Of, zoals hierboven betoogd: nieuwe complexiteit op termijn.
Portfolio in kaart
Uit de resultaten van het onderzoek in opdracht van Micro Focus blijkt verder dat vandaag de dag nog steeds iets meer dan de helft van alle bedrijfskritische applicaties van grote organisaties voornamelijk of volledig op een mainframe draait. Dat betekent dat het mainframe nog steeds van immens belang is. Vrijwel alle it-managers die aan dit onderzoek deelnamen (98 procent) erkennen dit ook. En ze bevestigen eveneens dat het toevoegen van nieuwe functionaliteiten aan mainframe-applicaties tot productiviteitsverhoging kan leiden.
Alleen lopen ze er in de praktijk toch niet erg warm voor. Deels komt dit omdat dit veel tijd kost, terwijl de business haast heeft. Maar er is vooral ook die Grote Interne Vijand: de enorme complexiteit van vaak decennia lang doorontwikkelde en uitgewaaierde portfolio’s van applicaties.
Door 57 procent van de it-managers in dit onderzoek worden deze portfolio’s als een onoverzichtelijke warboel ervaren. En daar ga je je vingers niet aan branden. Dat is riskant, tijdrovend en duur. Hoe duur is trouwens niet duidelijk, want daarvoor zou je overzicht moeten hebben. Overzicht is het eerste vereiste om de juiste strategie te kunnen bepalen. De olifant zal dus gedetailleerd in kaart gebracht moeten worden. Meet Your Own Elephant! Zo’n hernieuwde kennismaking moet vroeg of laat plaatsvinden. En dan wordt pas goed duidelijk of het Rewrite, Replace of Reuse gaat worden.
Een olifant laten dansen is een kunst die weinigen meester zijn. Het lijkt er op dat daar – net als in een circus – veel geduld bij komt kijken. En veel respect. En de moed om af en toe een kleine nieuwe act op te voeren, waarbij die olifant zich lekker voelt. Hij heeft immers een vetorecht. Als hij niet wil, gebeurt er niks. Maar aan de andere kant is hij ook de beroerdste niet.
Is complexiteit meetbaar?
Als complexiteit zo’n sterk belemmerende factor kan worden, dan is het interessant om dat verschijnsel zelf eens aan een nader onderzoek te onderwerpen. Wat is eigenlijk complexiteit? Kun je de mate van complexiteit meten? En wat kun je doen of nalaten om de groei van complexiteit tegen te gaan of af te remmen?
In de afstudeerscriptie van Roel Konieczny, getiteld ‘Architectuur als stuurmiddel?’ vinden we boeiende antwoorden op deze vragen (Katholieke Universiteit Nijmegen, richting informatica en informatiekunde, mei 2014, pdf is makkelijk online te vinden)
Eerst legt de auteur uit dat complexiteit afkomstig is van het Latijnse woord complexus dat samengevouwen betekent. “Iets is dus complex als het twee of meer delen heeft die zodanig met elkaar verstrengeld zijn dat ze moeilijk uit elkaar zijn te halen. Hieruit kan worden afgeleid dat complexiteit bestaat uit distincties (onderdelen) en connecties (verbindingen), die onderling een relatie hebben.”
Het vaststellen van de mate van complexiteit is een lastige opgave, aldus Konieczny, want alleen kijken naar de omvang van een systeem of verschijnsel is niet voldoende. Met de omvang als maatstaf zou een doos spijkers complexer zijn dan een microprocessor, wat overduidelijk onjuist is. Je zou ook een algoritme kunnen opstellen dat de mate van complexiteit meet, maar dat kan alleen als een systeem in wiskundige termen kan worden beschreven. Voor it-omgevingen gaat die vlieger helaas niet op, aldus de auteur. De wiskunde gaat ons niet helpen.
Konieczny kiest voor een bijna taalkundige meetinstrument, namelijk de lengte van de kortste omschrijving van een systeem of verschijnsel, ook wel de Kolmogorov-methode genoemd. Hoeveel woorden heb je minimaal nodig? Het idee hierachter is: hoe complexer het systeem is hoe lastiger en omvangrijker het is om in zijn geheel te beschrijven.
En nou komt het: om dat goed te kunnen doen is informatie nodig. Als zulke informatie ontbreekt spreken we van entropie. “Van een systeem met een hoge entropie kan weinig gezegd worden, dus ook niet of het wel of niet complex is.”
Konieczny formuleert uiteindelijk vier vragen die als hulpmiddel kunnen dienen om een eerste indruk te krijgen van de mate van complexiteit van een it-omgeving:
