Een paar jaar geleden moest de SVB op zijn schreden terugkeren. Een grootscheepse systeemvernieuwing werd afgebroken. Nu bloeit de aloude ICT-omgeving weer op en kiest de SVB voor evolutie in plaats van voor revolutie van systemen. Zo slecht waren die in Cobol geschreven applicaties helemaal niet, blijkt de conclusie op een kennissessie van het Bureau ICT Toetsing.
Foto: www.computerhistory.org
Als CIO van de SVB is Rikky van Osch medeverantwoordelijk voor het netjes uitkeren van 42 miljard euro per jaar, aan in totaal 5,5 miljoen mensen. Het gaat om een groot systeem; er is sprake van veel informatiedeling met andere partijen zoals, pensioeninstellingen en ketenpartners. Voor de sociale verzekeringen verwerkt de instantie zo’ 3700 telefoontjes er dag, voor het PGB ruim 2000. Voor die laatste wordt inmiddels 98 procent van de betalingen binnen 10 dagen afgehandeld.
En dat is niet vanzelfsprekend. Begin jaren 2000 is de SVB begonnen met het zogeheten Multiregelingensysteem (MRS), ‘data- en business rules-gedreven’, dat de bestaande systemen moest vervangen met een ambitieus en alomvattende aanpak. Maar het programma SVB Tien, waarin dat systeem vorm moest krijgen, is maar deels realiteit geworden en eind 2014 gestaakt – te ambitieus en complex. De zo benodigde systeemflexibiliteit bleek niet te realiseren met een alles-moet-anders-mentaliteit. Van Osch: “Er is een geolied proces nodig, met flexibele IT-systemen.”
In de kern van de SVB-systemen herleeft nu de oude glorie van de Cobol-systemen (AA en AKW). Het 7 á 9 miljoen euro kostende project vAKWerk behelst een nieuwe stap naar één gezamenlijk systeem dat is gebaseerd op de oudere Cobol-onderdelen die nu eenmaal hun nut en robuustheid ruimschoots hebben bewezen. “Vanuit IT was de overtuiging aanwezig dat die systemen goed onderhouden waren.” Een rationalisering/modernisering – van twee overlappende systemen naar één en van tien databases naar één – is de slag waarvoor vervolgens is gekozen. Daarbij moesten ook de gebruikersschermen gemoderniseerd worden.
Maar in de kern ging het om een solide en bewezen ‘backend’. De in het verleden vaak teruggekeerde vraag ‘moeten we niet af van die oude Cobol-code?’ werd na onderzoek alsnog met ‘nee’ beantwoord. De keuze daarvoor kreeg ook een positief advies van het Bureau ICT Toetsing. Doorontwikkeling van het systeem vindt immers aan de ‘buitenkant’ plaats; de veel veranderlijker online interactie met de gebruiker kan via een flexibele gegevensschil gebeuren. Dus, zo vat Van Osch het samen: geen grootscheepse vervangingsstrategie, steeds actuele business cases en kleine iteraties en projecten aan de buitenkant.
Veertig producten
Waarom lukte het oorspronkelijke Multiregelingensysteem in het SVB-Tien-project eigenlijk niet; was het misschien kansrijker geweest als het stapje voor stapje was gedaan?, suggereert een toehoorder. BIT-manager Cokky Hilhorst ziet in ieder geval dat het lastig was in het gewraakte multiregelingensysteem een veertigtal Oracle-producten aan elkaar te knopen. Een aantal van deze producten had zich nooit bewezen voor massale verwerking.
Maar hoe weet je of die oude code wel een beetje up-to-date is en opgewassen is tegen zijn taak? Door met een forensische blik naar die code te kijken, legt professor Chris Verhoef uit. Hij onderzocht voor de SVB de opties, toen de vraag over de levensvatbaarheid van de oude software nog niet was beantwoord. Hij zocht naar typische tekenen van wankelheid, veroudering en gebrekkig ouderhoud. “Voor dat soort onderzoek heb je heel veel data nodig, bijvoorbeeld over hoe de toekomstvastheid er in de afgelopen jaren heeft uitgezien.”
Verhoef keek bijvoorbeeld naar reparatiescripts, logbestanden, de historie rond wie er wát doet met de programmabestanden, hoeveel nieuwe bestanden er in de afgelopen 15 jaar zijn bijgekomen en wat de ‘volatiliteit’ is van bepaalde soorten bestanden. “De mediane volatiliteit bleek vooral bij het datamodel hoog”, aldus Verhoef. Dat kán betekenen dat er weloverwogen onderhoud is gepleegd.
Maar Verhoef kijkt verder. “Als je bijvoorbeeld wilt weten hoe onderhoudbaar de code is, zoek je uit hoe lang het duurt om wijzigingen door te voeren.” Dat blijkt erg mee te vallen. Veranderingen in de code zijn er wel, maar beperkt in omvang en met een zeer beperkte impact op broncodebestanden. Resets – terug naar de oude situatie – zijn ook zeldzaam.
En zo speurde Verhoef verder, bijvoorbeeld naar hoe het verloop van de engineers eruit ziet. Deskundigheid blijkt overwegend goed op peil gehouden te zijn en ‘kenniseilanden’ zijn afwezig. Hij zag ook dat tussen 2010 en 2015 het aantal systeemveranderingen steeg van circa 20 naar 40 per maand, maar zonder dat het aantal incidenten toenam – best knap eigenlijk.
Geen probleem
Samenvattend: “In die 15 jaar zie je groei én snoei; oude code wordt keurig weggegooid.” Zo’n 18 procent is weggegooid en vervangen door ongeveer even veel nieuwe code. De consolidatie van het ICT-landschap – ook van 10 databases naar één – moet technisch geen probleem zijn, stelt Verhoef, die in de SVB-aanpak een weerspiegeling ziet van hoe de banken het doen: ‘exploit the old, explore the new’.
Waar de SVB wel extra aandacht aan moet besteden is de toekomstvastheid van de ‘front-end’ van de SVB-systemen. “Die front-end wordt gegenereerd vanuit de back-end. Die generator is goed en volkomen stabiel, waardoor de kennis erover schaars is geworden: hoe hou je mensen vast die niets te doen hebben? Nu de look-and-feel van de schermen aangepakt wordt, zal ook een nieuwe generator gemaakt moeten worden, en dan moet die kennis op de een of andere manier geborgd worden, wie weet via een derde partij die meerdere van dit soort bedrijfsspecifieke software infra beheert.”
Het is net meubelmaken. Vakmanschap herken je aan het product, niet aan het gebruikte gereedschap.