SOA bij de Kruispuntbank: het stond in de sterren geschreven

De Kruispuntbank van de Sociale Zekerheid (KSZ) zal in 2009 volledig steunen op een SOA-platform van IBM en gooit daarvoor het mainframe buiten. “Maar eigenlijk waren onze concepten en processen altijd al door een soort van service oriented architecture geïnspireerd”, vertelt Frank Robben, die aan het hoofd staat van de KSZ.

“Ik pleit al sinds de jaren negentig voor een ’toepassing-tot-toepassing-communicatie'”, wijst Robben op de SOA-minded aanpak van zijn dienst, “Alleen was het al te gek om zelf de techniek te blijven ontwikkelen als die vandaag gewoon voorhanden is.”

IT Professional: De KSZ vervangt haar mainframe door een open platform. Wat is er mis met mainframe?
Frank Robben: Niks. Het was ons niet te doen om de vervanging van een mainframe, wel om de mogelijkheden die SOA ons biedt. Als er vandaag een ander stuk technologie beter geschikt is voor wat doen, dan willen we die – op een moment dat ze rijp is – best gebruiken. In ons lastenboek hadden we trouwens niet vooropgesteld om het mainframe weg te halen.

Dat was dus een voorstel van IBM zelf?
Ja, maar voor alle duidelijkheid: we zijn tot op vandaag heel tevreden met de stabiliteit en continuïteit van het huidige systeem (de KSZ draait op een Sysplex-omgeving, red.). Die voordelen willen we behouden, maar tegelijkertijd willen we er ook voor zorgen dat een aantal zaken vlotter lopen dan in de klassieke architectuur.

Waarom zou de werking bij een SOA-oplossing beter lopen?
Sinds een tweetal jaar evolueren we van de ontwikkeling van gegevensstromen naar een dienstenconcept. Om dat verder te ontwikkelen is het noodzakelijk om zo’n architectuur te gebruiken. Ik ben er namelijk van overtuigd dat, als we een ‘e-government van de volgende generatie’ willen bereiken, er een duidelijke taakverdeling moet komen. Zo kan de centrale overheid een aantal basisdiensten aanbieden, terwijl instanties die dichter bij de mensen staan, zoals gemeenten of ziekenfondsen, de concrete integratie verzorgen.

Neem user management, bijvoorbeeld. Vandaag kunnen we met een eID iemand elektronisch identificeren, maar daarmee kennen we de karakteristieken van die persoon nog niet. Gaat het om een arts, notaris, gerechtsdeurwaarder of gemandateerd boekhouder van een bedrijf? Nu bestaan daar databanken voor, onder meer bij Justitie en Volksgezondheid. Maar het gevaar bestaat dat als we die databanken niet ter beschikking stellen als een dienst, we morgen riskeren dat andere instanties – die dezelfde karakteristieken moeten verifiëren – aparte systemen zullen bouwen.

BAAS IN EIGEN BUIK
Een SOA-oplossing zou ook kostenbesparend zijn. Dit project kost 5 miljoen euro. Hoe moeten we de besparing hier begrijpen?
Om risico’s te vermijden wil ik beide systemen een tijd parallel laten draaien. We zitten dus inderdaad met een investering. Maar de totale cost of ownership van het systeem, dat in 2009 volledig operationeel zal zijn, laat ons toe om de kosten te beheersen en – bij gelijkblijvende belasting – op hetzelfde niveau te behouden als vandaag. Waar we normaal een steeds stijgende kostencurve hebben, zullen we nu slechts een tijdelijke verhoging krijgen om nadien opnieuw op het niveau van vandaag terug te zakken – en dit ook aan te houden.

Ik ben er bovendien van overtuigd dat er, doordat wij onze diensten delen, op andere plaatsen minder uitgaven nodig zullen zijn. Neem opnieuw het voorbeeld van user management: we hebben dit systeem ook getransponeerd naar Be-Health (de elektronische samenwerking binnen de gezondheidszorg, red.). Dat bespaart niet alleen kosten, maar zorgt er ook voor dat het veel makkelijker samenwerken is. Als je de ziekenhuizen, artsen en ziekenfondsen vertrouwen wil laten hebben in Be-Health, dan is het goed om de basiscomponenten ook daar te plaatsen, zodat ze zelf baas blijven in eigen buik.

Is dat niet voor een deel het geheim van uw aanpak: dat u altijd dat principe van ‘iedereen-is-baas-in-eigen-buik’ hanteert?
Ik ben er niet om kritiek te geven op anderen, maar dit maakt deel uit van ons governancemodel. Veronderstel dat Vlaanderen voor haar beleid een aantal extra gegevens moet kunnen toevoegen aan de bestaande authentieke bronnen (de basisgegevensbanken waar andere overheidsdiensten gebruik van kunnen maken zodat burgers en bedrijven hun gegevens niet meermaals moeten doorgeven aan verschillende overheden, red.), maar niet de structurele garantie krijgt om dat te doen. Wat krijg je dan? Een Vlaamse overheid die uiteindelijk zelf een verijkte Kruispuntbank van Ondernemingen uitbouwt. Je kunt dat vermijden door opnieuw die governanceprincipes goed toe te passen.

Wanneer jouw klanten de authentieke bron zelf beheren dan kom je nooit in zo’n situatie terecht. Bij de Kruispuntbank zitten onze klanten dan ook niet toevallig mee in de raad van bestuur. Dit betekent dat je gedwongen bent om rekening te houden met wat zij willen. Services aanbieden is één zaak, maar je moet inderdaad baas blijven in eigen buik.

ONGELOVIGE THOMAS
Eén van de mogelijke pijnpunten bij een SOA-oplossingen zijn de antwoordtijden…
We hebben daarom een serieus volume uitgetest. Al ben ik daarin nogal een ongelovige Thomas: testen blijven testen. Vandaar dat we in een pilootfase een aantal processen van de KSZ willen omvormen naar deze nieuwe architectuur om vervolgens serieuze testen uit te voeren, waarna we conclusies trekken voor de daaropvolgende fase. Intern hanteren we de norm – al van in de jaren negentig – dat elke passage, die online via de KSZ verloopt, nooit meer dan een seconde vertraging mag oplopen. Dat staat ook in het lastenboek en we houden dat permanent in de gaten. Er bestaat hiervoor een boetesysteem en IBM moet zelfs gratis materiaal bijleveren als die norm niet wordt gehaald.

Waarom werd uiteindelijk voor Linux gekozen en niet voor AIX?
Wij hebben een open platform gevraagd. Maar of dat nu Linux was of AIX… Dat bleef ons om het even. Vergeet niet dat we hier in een systeem van overheidsopdrachten zitten. We hebben een aantal functionele eisen gesteld, maar het type van de achterliggende machines werd niet vastgelegd in het lastenboek. En zoals u weet, laat bij een overheidsopdracht de procedure niet veel onderhandelingsruimte toe.

Geen idee hoor, wij zaten nooit rond die tafel…
Wel, ik kan het u verzekeren: het wordt moeilijker en moeilijker om er enige flexibiliteit in te krijgen. We hebben een keuze moeten maken uit de oplossingen die ons werden aangeboden.

Wat was dan het verschil met het voorstel van Accenture, die als enige tegenkandidaat overbleef?
De architecturen van beide oplossingen waren nogal gelijklopend. Het is een kwestie van tests, het beantwoorden van een aantal functionele vragen en van de prijs. (De weging bij de beslissing was als volgt: 1) prijs: 35 %, 2) overeenstemming met het bestek op technisch vlak: 30 %, 3) overeenstemming met het bestek voor de dienstverlening : 30 % en 4) kwaliteit van de offerte: 5 %, red.)

Is het veiligheidsaspect niet belangrijker en technisch ingewikkelder geworden door SOA?
Wij evolueren steeds meer naar een situatie waarin niet de ‘periferiebeveiliging’, maar wel de intrinsieke beveiliging van een aantal zaken centraal staat. Ons dienstenaanbod wordt namelijk niet meer louter binnen onze beveiligde periferie gebruikt. We willen onze diensten ook buiten die beveiligde wal aanbieden aan gemeenten, OCMW’s of eventueel zelfs instanties die niks met sociale zekerheid te maken hebben. Doordat dit via het internet zal gebeuren, moeten we voor een intrinsieke beveiliging zorgen van de gegevens die uitgewisseld worden. Sommigen noemen dit ‘de evolutie van veiligheid naar immuniteit’: dit betekent dat men streeft naar ingebakken veiligheidsmechanismen en veiligheid niet meer als een aparte, losstaande zaak te zien.

OLD TIME HEROES
Hoeveel makkelijker zou het voor u geweest zijn mocht u die technologie al in de jaren negentig
hebben gehad?
Een groot stuk. Toen zaten we nog zelf een middleware te bouwen. In ’93 hebben we zelfs een online Edifact-vertaler gemaakt. (lacht) Mocht ik nu moeten herbeginnen, zou ik dit bijna gewoon off the shelf kunnen nemen. Dat is wel merkwaardig, want dat betekent ook dat de architectuur toen vrij goed was. Als je vandaag naar de middleware-oplossingen kijkt dan zie je dat dezelfde basisconcepten, die wij toen al gebruikten, terugkomen. We zaten begin jaren negentig – conceptueel – dus al vrij goed.

Niet voor honderd, maar toch zeker voor tachtig procent. Daardoor is het voor een aantal processen die toen goed geanalyseerd werden niet zo moeilijk om die in deze nieuwe omgeving om te zetten. Al zitten we nu wel met veel langere procesketens, doordat in de jaren negentig nog niet alle ondernemingen op een elektronische wijze met ons samenwerkten.

Nu heet dat met een modewoord ‘service oriented architecture’. Maar ik heb van in het begin gevochten – en daar nooit vanaf geweken – voor wat ik noemde een ’toepassing-tot-toepassing-communicatie’. In het begin waren er mensen die dat niet aannamen en toen zelfs met twee tot drie schermen op hun bureau zaten, maar we moeten nu eenmaal geïntegreerde diensten krijgen.