Iedereen praat erover, maar niet iedereen doet het

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. Denis Hageman is Head of IT Strategy & Architecture bij ABN AMRO Group Functions. Zijn werkgebied heeft zich de afgelopen twintig jaar uitgestrekt van geldautomaat, internetbankieren en hypotheekoffertes tot bankfusies in Brazilië: ‘Als je services weet te implementeren over een hele waardeketen heen, waarbij je interne processen kunt combineren en koppelen met die van externe partijen, dan ben je pas echt servicegeoriënteerd bezig.'

‘Er zijn binnen ABN AMRO nooit specifieke business cases gemaakt om onderzoek te doen naar Service Oriented Architecture of deze om technische redenen te implementeren. Er is wel het nodige te vertellen over waarom wij aan een SOA de voorkeur geven boven een ander soort architectuur. We zijn de SOA-kant opgegaan, en met ons vele andere banken, omdat we in de jaren negentig veel meer communicatie- en verkoopkanalen naar de klant op onze systemen zijn gaan aansluiten. Het begon al een decennium eerder. In de jaren tachtig zijn de banken de automatisering tot aan het kantorennet gaan uitbreiden. Een baliemedewerker in een lokale vestiging kon toen bijvoorbeeld op zijn terminal zien welke rekeningen een bezoekende klant had, wat in de jaren zeventig nog met papieren lijsten ging. Daarna kwamen de geldautomaten. Eind jaren tachtig kwam er technologie beschikbaar om ook telefonisch bankieren mogelijk te maken. Daarna ontstond wat wij Home Banking noemden, de mogelijkheid om via een telefoonlijn allerlei bestanden en informatie uit te wisselen met behulp van een personal computer. Uit dit Home Banking is het huidige internetbankieren gegroeid. Later kwamen ook nog de mobiele telefoons die dienst kunnen doen als communicatiemiddel. Via al deze klantkanalen wilden we dezelfde bancaire functionaliteit aanbieden die voorheen alleen op een kantoor mogelijk was. Dit is het moment geweest, in ieder geval in Nederland en in de Verenigde Staten, dat we zijn begonnen na te denken over hoe we dat nu op een handige manier in het vat zouden kunnen gieten.
Een van de ideeën was te kijken naar de bedrijfsprocessen, bijvoorbeeld de betalingsprocessen of het opstellen van een hypotheekofferte, en dan te onderzoeken welke IT-services benodigd zijn om die processen te ondersteunen. Als je die dan op het juiste granulatieniveau weet te definiëren, wat in dit geval wil zeggen dat je op de juiste manier de brokken functionaliteit met elkaar weet te verbinden, dan kun je bestaande services hergebruiken; of het proces nu in het callcenter of in het kantorennet loopt. Mocht blijken dat nieuwe of andere IT-services nodig zijn voor bepaalde processen, dan kun je die eenvoudig ontwerpen en bouwen, zonder opnieuw het wiel uit te vinden. Het voordeel spreekt voor zich. We hoeven functionaliteit niet steeds opnieuw te bouwen als we een nieuwe toepassing in gebruik nemen. Nu is hiervoor niet per se een SOA nodig, maar het hergebruik van functionaliteit is wel een fundamenteel onderdeel van het servicegeoriënteerde denken. Het heeft wel iets weg van het gebruik van de utilities op het mainframe, utilities waarvan we in de jaren tachtig gebruikmaakten en die we voor verschillende toepassingen konden gebruiken. Ook kun je denken aan objectoriëntatie die eveneens in de jaren tachtig zijn opwachting maakte, en die je kunt zien als een datageoriënteerde manier om herbruikbare componenten in te zetten. Het nadeel van objectoriëntatie was dat we zelfs voor een eenvoudige kasapplicatie van zo'n tweeduizend componenten gebruik zouden moeten maken. Het was in veel gevallen eenvoudiger om een geheel nieuwe applicatie te bouwen. Objectoriëntatie heeft het om deze reden niet gered, maar wat hieruit duidelijk blijkt, is dat herbruikbaarheid altijd al een belangrijke rol heeft gespeeld in de financiële dienstverleningsector.
In de loop van de jaren negentig zijn we gaan nadenken over hoe we op een hoger niveau dan dat van de objectoriëntatie wel grotere herbruikbare componenten zouden kunnen definiëren. Zoals ik al eerder zei, zijn we toen op het idee gekomen om basisservices te definiëren die de bedrijfsprocessen zouden ondersteunen. In het kader van de multi-channelstrategie zijn banken vanaf die tijd druk bezig om deze services zo veel mogelijk in te zetten. De cruciale vraag is hoe we dit serviceconcept kunnen implementeren en het antwoord op deze vraag is niet zo eenvoudig. We hebben van oudsher te maken met grote mainframeomgevingen met onder meer IMS-transactiemonitoren. Hoe kun je die nu ontsluiten voor een servicegeoriënteerde omgeving? Hier in Nederland is rond IMS een schil gebouwd in Java die voor de ontsluiting van de gegevens zorgt. Het grote nadeel is dat er een enorme en intensieve communicatiestroom ontstaat tussen de voorkant die in de Java-omgeving is gebouwd en de IMS back-end. In Brazilië hadden we een andere situatie, zowel technisch als functioneel, dan in Nederland en hebben we serviceoriëntatie om drie redenen ingevoerd. Ook in Brazilië hebben we gekeken hoe we de multichannel-strategie efficiënter konden inrichten. En ook hebben we gekeken hoe we legacy-migratie konden doen, ofwel op een handigere manier de legacy-systemen zouden kunnen hergebruiken en op termijn gefaseerd zouden kunnen vervangen. De derde reden was dat we applicaties zoals PeopleSoft op een nette manier in de bestaande toepassingen kunnen integreren opdat medewerkers deze gemakkelijk konden gebruiken. Dus ook hier was servicegerichtheid, zowel voor de klanten als voor de bankmedewerkers, de voornaamste reden, met op de achtergrond een aantal technische voordelen.
Het voordeel van een servicegeoriënteerde architectuur, mits goed geïmplementeerd, is dat je als organisatie flexibeler bent. Je kunt processen veranderen, maar nog steeds dezelfde services gebruiken. Bovendien kun je zaken eenvoudiger vervangen, want je kunt ze service voor service aanpakken, zonder dat je aan de front-office iets hoeft te veranderen. Het belangrijkste argument is echter het hergebruik, waarmee je de kosten laag kunt houden zonder de stabiliteit en de kwaliteit van de dienstverlening aan te tasten. We hebben dit in de praktijk ervaren toen we een bank acquireerden in Brazilië. Deze moest om organisatorische en commerciële redenen nog enige tijd haar eigen processen blijven hanteren, maar ook onze applicaties gaan gebruiken, waaronder een leningentoepassing. Op basis van een servicegeoriëntieerde architectuur konden we betrekkelijk eenvoudig de nieuwe processen in de leningenomgevingen incorporeren met gebruikmaking van bestaande services. Een project dat anders maanden zou hebben geduurd, hebben we nu in enkele weken kunnen afronden. En dat spreekt natuurlijk aan. Er zit wel één maar aan vast. De herdefiniëring en de migratie van een legacy-omgeving op een mainframe met COBOL- en PL1-code en ADABAS zijn niet eenvoudig.
In de nabije toekomst zal voor ABN AMRO de focus gericht zijn op de splitsing en integratie van IT-systemen. We zijn nu bezig om de SOA-aanpak te professionaliseren en tooling te implementeren waarin processen, applicaties en services worden vastgelegd. Op basis van processen kunnen we gestructureerd services definiëren die we vervolgens met behulp van domeinindelingen bereikbaar in repository's kunnen vastleggen; want daaraan ontbreekt het vaak nog. Je mag niet vergeten dat serviceoriëntatie nog steeds een concept is dat volop in ontwikkeling is. Iedereen spreekt erover, maar niet iedereen doet het. Bovendien is er mijns inziens ook nog geen eenduidig begrip van wat serviceoriëntatie nu eigenlijk is. Iedereen heeft er verschillende ideeën over. Sommigen benaderen het vanuit een strikt technische invalshoek, anderen bekijken het vanuit de businesskant, en volgens mij is dat de juiste benadering. Als je services weet te implementeren over een hele waardeketen heen, waarbij je interne processen kunt combineren en koppelen met die van externe partijen, dan ben je pas echt servicegeoriënteerd bezig.'