Van spaghetti naar lasagne

Iemand belt de helpdesk en wordt vervolgens drie keer doorverbonden. Met zulk gedrag jaag je als bedrijf klanten weg. Om het probleem op te lossen moet je alle achterliggende afdelingen samenvoegen en daarmee ook de onderliggende crm-applicaties integreren. Een lastige klus. Het lukte KPN via een soa – een service oriented architecture.

Stel je voor, je bent it-manager bij een groot telecombedrijf. Binnen de organisatie werkt men binnen allerlei verschillende afdelingen met in totaal meer dan duizend verschillende applicaties – erfenissen van jarenlang, zich opeenstapelend it-beheer. De applicaties werken slechts gedeeltelijk samen en zijn moeilijk aan te passen aan de steeds sneller veranderende markteisen.

Dat kan zo niet langer, dat is duidelijk. De directie vraagt je om schoon schip te maken. Een deel van de applicaties moet uitgefaseerd worden. Van de rest moet nuttig gebruik worden gemaakt door het bouwen van een nieuwe softwarelaag. Die moet de communicatie verzorgen met bestaande applicaties. De nieuwe softwarelaag bestaat uit een verzameling services die de ‘legacy systemen’ ondervragen. Ze geven de antwoorden door aan eindgebruikers of andere applicaties. Deze services vormen de basisblokken waarmee nieuwe diensten kunnen worden gebouwd. De bestaande applicaties hoeven dus niet te worden aangepast voor het leveren van nieuwe diensten. En als legacy systemen vervangen worden, blijven deze services toch gewoon beschikbaar. Het lijkt het ei van Columbus. En het is helemaal van deze tijd. De directie vraagt je namelijk om een soa te implementeren. Binnen de hele organisatie. Leuk bedacht. Maar hoe pak je dat aan binnen een groot en complex bedrijf?

Eerst zien, dan geloven

KPN’er Peter Hermans zag zich in 2004 voor precies deze opdracht gesteld. Hij had echter een duidelijk idee over hoe hij zijn doelstellingen kon bereiken: “Het moest geen it-feestje worden.” Want, zoals Hermans het zegt: “Het implementeren van een soa bestaat voor slechts 30% uit aanpassingen van de technologie. De overige 70% is een kwestie van organisatorische aspecten, met daarin als belangrijkste uitdaging een focus op serviceoriëntatie te bewerkstelligen in plaats van op applicaties.” Daarom besloot Hermans aan te schuiven bij nieuwe businessprojecten. Daarin zit meestal ook een it-component. Voor deze nieuwe businessprojecten konden nieuwe softwarediensten worden gebouwd, gebaseerd op bestaande applicaties.

Aan Hermans de schone taak om zijn softwarearchitecten zoveel mogelijke nieuwe projecten binnen te kletsen. Met als enige worst een kleine bijdrage aan het budget van de nieuwe business. Voor het overige moest de gave van het woord het werk doen. Hermans: “Het was een uitdaging om alle neuzen dezelfde kant op te krijgen. Ik heb in die periode erg veel op de zeepkist gestaan. Men raakte op zich wel enthousiast door mijn verhaal, maar toch heerste er in het begin een stemming van ‘eerst zien dan geloven’.

Daarom werd een stoutmoedig plan ontwikkeld: “Als eerste project hebben we een van de belangrijkste pijnpunten binnen het bedrijf aangepakt. In 2004 speelde het grote probleem dat de zakelijke markt was opgesplitst in zo’n dertig productgroepen, elk met hun eigen helpdesk. Als klanten belden, werden ze daardoor heel vaak doorverbonden. Daar word je als klant dus helemaal gek van.” Om dit probleem op te lossen moest er een centrale helpdesk komen waar zakelijke klanten met al hun vragen terechtkonden zonder ook maar een keer doorverbonden te worden naar een andere afdeling. Hermans: “Alle onderliggende crm-applicaties moesten allemaal aan dezelfde bus worden gehangen.” Met ‘bus’ bedoelt Hermans in dit geval de softwarelaag die de communicatie verzorgt met de onderliggende applicaties.

Projecten van twaalf weken

Het geuzenplan slaagde. Met resultaat. De aanvragen voor deelname aan businessprojecten druppelden daarna stuk voor stuk binnen, totdat Hermans uiteindelijk bij bijna vijftig nieuwe projecten betrokken was, zowel binnen de divisie ‘Mobiel’ als ‘Vast’.

Daarbij werd als vuistregel gehanteerd dat de soa-bemoeienis aan elk nieuw businessproject niet meer dan twaalf weken in beslag mocht nemen. Hermans: “Veel it-projecten mislukken omdat er te grote stappen worden genomen.” Elk projectteam werd gevraagd een eisenpakket op te stellen. Daaruit ontsproten nieuwe services die de basis vormden voor de soa van KPN. Hoe meer services er ontstonden, hoe sneller Hermans zich in volgende businessprojecten van nut konden maken. Hermans: “Steeds vaker kwam het voor dat een aangevraagde service zich al in onze bibliotheek bevond, of dat we hem konden creëren door de upgrade van een bestaande service. Als een service nog niet bestond, probeerden we een zo generiek mogelijke dienst te bouwen die door zoveel mogelijk andere businessprojecten zou kunnen worden hergebruikt.”

Het huidige resultaat is een ‘Enterprise Service Backbone’ die bestaat uit meer dan driehonderd services, waarmee tot nu toe in totaal 44 nieuwe applicaties zijn gebouwd. De driehonderd services, de basisbouwblokken van elke soa, wisselen samen maandelijks zo’n twintig miljoen berichten uit met de onderliggende legacy-systemen. Dat zijn applicaties op het gebied van onder andere klantcontacten, facturering, netwerkonderhoud, enterprise management en logistiek.

Value added services

Een aardig resultaat, maar Hermans is nog niet tevreden. Boven op de soa-architectuur hoopt hij in de toekomst een ‘event driven technology’-laag te kunnen bouwen. Die moet het mogelijk maken ‘de werking van een soa te orchestreren op basis van gebeurtenissen.’ Zo’n gebeurtenis kan een klant zijn die de helpdesk belt, maar ook een graafmachine die een kabel lostrekt en zo een storing in het netwerk veroorzaakt. Al dit soort gebeurtenissen zouden in de toekomst moeten leiden tot het automatische genereren van processen die precies zijn toegesneden op die klantspecifieke situatie. Hermans geeft een voorbeeld van het belang van zo’n klantspecifiek proces: “Vorige week sprak ik op een soa-bijeenkomst van Gartner in Nice. Een analist vertelde daar over het aanbod van StarBucks. Die Amerikaanse koffieketen biedt zoveel keuze, dat een klant in totaal 52000 verschillende koffievarianten kan bestellen. Als je al die processen moet ontwerpen voor al die productcombinaties, dat wordt ondoenlijk. Met een ‘event driven technology’-laag kun je echter ‘on-the-fly’ dat ene benodigde proces en het gebruik van de daarin benodigde services genereren.”

Een andere optie die KPN onderzoekt, is het bieden van ‘value added services’ aan ketens van bedrijven, bijvoorbeeld in de zorg. Waarom zou je de legacy-systemen van huisartsen, apothekers en verzekeraars niet via een soa met elkaar verbinden en vervolgens allerlei diensten aanbieden waaraan al deze partijen iets hebben? Hermans benadrukt dat deze vorm van dienstverlening zich nog in een verkennend stadium bevindt: “Het is niet zo dat KPN morgen al daadwerkelijk op soa gebaseerde ‘value added services’ gaat leveren.”

Soa en eai

KPN maakte voor de implementatie van haar soa-architectuur gebruik van de diensten van TIBCO, een adviseur op het gebied van software-integratie. Volgens Hans Delleman, Country Manager Software Benelux van TIBCO, maakt soa volop gebruik van de technieken die al zijn ontwikkeld op het gebied van enterprise application integration, een filosofie die al langer bestaat. Er zijn dus zeker raakvlakken tussen soa en eai, maar verschillen zijn er ook. Delleman: “Als je het hebt over soa kijk je meer met een organisatorische blik, bij eai met een feitelijke.” Hermans: “Binnen eai ligt het accent op het integreren van applicaties, bij soa op het bieden van services.”

Het grote voordeel van soa is volgens Delleman dat deze vorm van softwarearchitectuur een ontkoppeling tot stand brengt tussen legacy-systemen en processen. Delleman: “Bij een ‘point to point-architectuur’ zijn alle systemen rechtstreeks met elkaar verbonden. Als je dan ergens wat verandert, moet je alle verbindingen tussen applicaties ook aanpassen. Dat aantal aanpassingen kan aardig oplopen. Bij negen systemen heb je al te maken met 80 (9×9-1) verbindingen. In een soa-architectuur hoef je niet alle interconnecties aan te passen, want die zijn er niet. Applicaties zijn binnen een soa namelijk onderling ontkoppeld, en services ook. In plaats daarvan wijzig je alleen maar de verbinding met de services-laag.” Hermans: “Ik zeg altijd maar: je gaat van spaghetti naar lasagne.” Hermans gebruikt hier lasagne als metafoor voor een soa-architectuur, omdat die bestaat uit een aantal lagen (zie de afbeelding op deze pagina).

Om een soa-architectuur te bouwen moet je adapters aanbrengen tussen de services-laag en de onderliggende it-assets laag. Delleman: “Voor de meeste platformen en talen bestaan adapters. Zo bestaat er bijvoorbeeld een SAP-adapter, al moet je die wel bij elke klant opnieuw aanpassen aan de specifieke situatie. Per adapter vergt dat een arbeidsinvestering van enkele dagen tot enkele weken. Je moet daarbij proberen om de benodigde tijd zoveel mogelijk terug te dringen door van tevoren de klanteisen goed in kaart te brengen en alleen services te bouwen die ook echt noodzakelijk zijn.”

Een nobel streven, zo’n soa-architectuur. Maar volgens Hermans in de praktijk niet altijd consequent vol te houden: “KPN is een groot bedrijf. Als je even niet oplet bestaat de kans dat er ergens in een hoekje iemand weer stiekem een point to point-verbinding aan het spannen is.”