haarlemmerolie van de IT? Tobias Kuipers en Per John

service-oriented architecture

t

Naar een dienstbare service-oriented architecture

Complexiteit onder controle, kosten inzichtelijk?

Gezien de populariteit van service-oriented architecture is het goed eens terug te gaan naar de basis en te kijken naar wat SOA eigenlijk is, wat de redenen zijn om het in te voeren, hoe je dat dan doet en wat de vervolgstappen zijn. Is SOA de haarlemmerolie van de IT?

Tobias Kuipers en Per John

informatie / april 2008

Dataprocessing, corporate informatie systemen en waar we nu staan

18

Om te begrijpen waarom service-oriented architecture (SOA) een interessant gespreksonderwerp is, is het een goed idee even stil te staan bij de geschiedenis van de corporate informatiesystemen. Die heeft namelijk geleid tot de situatie die wij voor het gemak maar even ‘system-oriented architecture’ noemen. Het is een bekend, maar relevant verhaal. We nemen als voorbeeld de banksector en beginnen met een bank in de jaren zestig. Die begint met het automatiseren van één activiteit: rekening-courant. In plaats van in boeken bij te houden hoeveel iedereen op zijn rekening heeft staan, doet men dat met de computer. Dat is efficiënter en minder foutgevoelig. Als dat blijkt te werken, doet men hetzelfde met de effectenrekeningen. En de spaarrekeningen. En de hypotheken. Al deze systemen zijn zogenaamde stovepipes: ze staan los van elkaar en doen alles (zie figuur 1a). Dit werkt allemaal flitsend, totdat iemand zich realiseert dat je bij een verhuizing iemands nieuwe adres vier keer moet invullen. En dan komt er iemand van de marketing en die wil graag weten wie van de rekeninghouders met een saldo van meer dan 1000 gulden een spaarrekening heeft (zie figuur 1b).

Dan worden er weer nieuwe systemen geïntroduceerd: een systeem dat klantgegevens bijhoudt, en die gegevens worden elke nacht gerepliceerd in de oorspronkelijke systemen. Er komt een systeem dat gegevens uit het spaarrekeningsysteem kan halen, en uit het effectenrekeningsysteem (zie figuur 1c). Iemand wil internetbankieren invoeren, enzovoort (zie figuur 1d). Zo ontstond de situatie dat een moderne bank honderden systemen heeft en dat er op een heleboel plaatsen dezelfde data worden opgeslagen. Uiteindelijk heeft niemand meer overzicht van wat al die aan elkaar geknoopte systemen nu eigenlijk doen.

Wat is het probleem en hoe lost SOA dat op? Het aan elkaar knopen van systemen zoals geschetst in het bovenstaande scenario heet enterprise application integration (EAI). Er zijn allerlei manieren verzonnen om systemen te integreren, bijvoorbeeld door alle data in één database te stoppen (data-integratie), de applicaties elkaar te laten aanroepen (applicatie-integratie), data via schermen te gebruiken (screenscraping) of applicaties via messages te koppelen (message queueing, message broker). SOA is de nieuwste trend in EAI en hierin worden applicaties geïntegreerd door middel van services.

Samenvatting Service-oriented architecture (SOA) is een vorm van enterprise application integration (EAI) waarin applicaties worden geïntegreerd door middel van services. Een service is een ‘activiteit uitgevoerd voor een klant, anders dan fabricage’. Het aantal services dat via SOA wordt aangeboden moet klein zijn. SOA gaat niet over technologie maar is een manier van nadenken over informatiesystemen.

a) Het verschil met de oude EAI-strategieën is dat men bij SOA hergebruik nastreeft, terwijl de oude EAImethoden puur bezig waren met het aan elkaar knopen van applicaties.

Wat is een service? Een service is een ‘activiteit uitgevoerd voor een klant, anders dan fabricage’. Het succes van het invoeren van SOA in een organisatie valt of staat met in hoeverre deze definitie wordt gevolgd. Met andere woorden: hoe ‘groot’ definieer je je services? Zoals blijkt uit de reguliere definitie van het woord ‘service’ is het woord ‘klant’ hierin van groot belang. In het licht van SOA kan een

b)

d)

Figuur 1. De ontwikkeling van corporate informatiesystemen


c)

19


t

klant zowel een echte (externe) klant zijn als een interne klant, maar zeker niet de IT-afdeling. In het voorbeeld van de bank met de legacysystemen zouden ‘Wat is mijn huidige saldo?’ en ‘Hoeveel kan ik lenen?’ een service zijn, maar niet ‘Wat is de statuscode van de replicatie van database 2?’. Het idee van serviceoriëntatie is om een abstractielaag over de bestaande informatiesystemen heen te leggen en zo de interne complexiteit te verbergen. Dat betekent dat een organisatie de services in de SOA-zin moet aanbieden die ze ook in werkelijkheid aanbiedt, en niets meer. Het aantal services dat via SOA wordt aangeboden moet dus klein zijn. In onze adviespraktijk komen we eigenlijk nooit (legacy)systemen van klanten tegen die meer dan zeven services aanbieden, en de meeste niet meer dan vier. Minder services is beter te begrijpen. Bovendien hoef je minder te integreren als je minder services hebt. We kennen één organisatie die overwoog haar legacysystemen uit te faseren door tweeduizend services te introduceren, namelijk alle interfaces die de legacysystemen nu ook al aan elkaar boden. Het is evident dat je daarmee niet het probleem oplost en zelfs een nieuw probleem introduceert.

komen wij maandelijks zeer creatieve interfaces met legacysystemen tegen die de doorsnee ESB niet ondersteunt, van screenscraping tot aan het schrijven van assembly-interfaceprogramma’s. Het tweede probleem is dat wat deze interfaces bieden geen service is. Ze bieden een (klein deel van een) technisch aspect van de totale service die het systeem levert. Een interface kan bijvoorbeeld een record in een specifiek formaat wegschrijven naar een tabel in een database, vervolgens een Cobolprogramma aanroepen en tot slot een record in een tabel uit een andere database uitlezen, om zo de eerste stap van het proces dat leidt naar het klantnummer uitgevoerd te hebben. Als dit soort interactie met legacysystemen nodig is (en dat is zo, daarom heten ze immers legacy systemen), dan is het vrijwel onmogelijk, en in ieder geval onwenselijk, om deze integratie in de fraaie grafische XML-omgeving van de ESB tot stand te brengen. De XML is er simpelweg niet expressief genoeg voor en vereist integratieprogrammatuur die dan weer onderdeel wordt van de XML-integratielaag. Hierdoor wordt het probleem niet kleiner, om nog maar te zwijgen van de testinspanning om dit überhaupt aan de praat te krijgen.

»Een SOA op zich levert geen financiële winst voor de organisatie op«


Het gaat niet over technologie

20

SOA is een manier van nadenken over informatiesystemen. Er is zeker technologie die SOA kan ondersteunen, maar als je alleen maar die technologie introduceert, dan is er nog geen SOA. En andersom kun je SOA invoeren zonder enige technologie aan te schaffen. Zo zijn webservices een veelgebruikt middel om SOA in te voeren. Als je echter de oorspronkelijke interfaces repliceert met behulp van services, heb je nog geen SOA, maar is er slechts een extra laag geïntroduceerd boven op het legacysysteem. Omgekeerd suggereren veel aanbieders dat door het inpluggen van hun SOA-technologie, bijvoorbeeld een enterprise service bus (ESB), eenvoudig een SOA kan worden gerealiseerd. Elk legacysysteem krijgt dan direct een of meer interfaces naar de ESB. Het eerste probleem is dat dit lang niet altijd kan. In onze adviespraktijk

Hoe voer je SOA in? Het invoeren van SOA in een bestaande organisatie is geen eenvoudige operatie. Het is ook geen project. Het invoeren van SOA levert in eerste instantie geen enkele waarde voor de organisatie op. Pas op termijn zal de IT kosteneffectiever worden door het gebruik van services. Het invoeren van services kan het beste stap voor stap gebeuren, tegelijk met IT-projecten die toch al worden uitgevoerd. Dan brengt het geen onoverkomelijke kosten met zich mee en worden er ook geen services bedacht die uiteindelijk toch niet gebruikt gaan worden. Een onverstandige aanpak is om een commissie in te stellen die langdurig gaat vergaderen over wat nu eigenlijk de services zijn die de organisatie levert en/of nodig heeft. Als je een commissie nodig hebt om te bedenken wat je bedrijf eigenlijk doet, dan is IT niet het belangrijkste probleem van het bedrijf. Een beter idee is om in één à twee weken vast te stellen wat globaal de services zijn en waar die zich ongeveer in het applicatielandschap bevinden. Als

er dan een nieuw systeem gebouwd of vervangen gaat worden, is het de moeite waard om te kijken of de benodigde services uit de oude systemen kunnen worden gedestilleerd zonder de oude systemen al te veel te veranderen. Als dat kan, kunnen de nieuwe systemen eenvoudig de oude systemen via de service-interface gebruiken.

Figuur 2. Voorbeeld van opbouw van SOA

Figuur 3. Voorbeeld van hergebruik van services voor andere systemen die gedeeld werd tussen de eerste en de tweede interface om zo de juiste services in laag B te definiëren. Uiteindelijk zitten er negen services in laag A en drie services in laag B. Het bouwen van laag A was een apart project dat gedreven werd door de integratie van de back officesystemen na de fusie. Het bouwen van laag B is tegelijk met het bouwen van de web interface gedaan, een project van vijf mensen dat ongeveer drie maanden heeft gekost.


Om een succesvol voorbeeld uit de praktijk te geven behandelen we de case van een van onze klanten. Het betreft een bedrijf dat services levert aan zowel particuliere als zakelijke klanten, traditioneel via de telefoon en via makelaars en de laatste paar jaar steeds meer via het web. Het bedrijf automatiseert al ruim veertig jaar en is door een recente fusie eigenaar geworden van een tiental backoffice-legacysystemen met overlappende functionaliteit. De eerste paar webportals die dit bedrijf bouwde waren, op allerlei manieren aan de backoffice verbonden. Door de fusie werd dat steeds moeilijker. De organisatie besloot een servicelaag te bouwen boven op de legacysystemen (laag A in figuur 2). Deze laag ‘weet’ welke dienst door welke collectie van legacysystemen geleverd wordt en weet op welke manier en in welke volgorde die systemen moeten worden uitgevraagd om tot het goede antwoord te komen. De services die laag A aanbiedt, hebben veel opties. Er is bijvoorbeeld een service ‘Geef prijs voor product X, gegeven kortingscode Y, klant-ID Z en makelaarsdiscount A’. Degene die deze service geleverd wil krijgen, moet dus weten dat product X bestaat en moet al een klant-ID hebben. Deze services worden via een interface gebruikt door de makelaars. De makelaars doen dit al jaren en hebben personeel in dienst dat al deze codes kent, begrijpt en kan gebruiken. Toen er een nieuwe webportal gemaakt moest worden voor particuliere klanten, besloot de organisatie boven op laag A eerst een nieuwe servicelaag (laag B) te bouwen die de services voor de particuliere klanten definieerde. Laag B praat alleen met laag A en gebruikt haar services, maar biedt minder opties aan. In termen van het eerdere voorbeeld wordt de service dan ‘Geef prijs voor product X’, waarbij de kortingscode en de klant-ID zijn weggevallen of op standaardwaarden zijn gezet. De tweede servicelaag (laag B) is tegelijk met de tweede webinterface gebouwd. Er is een webinterface voor een speciaal type particuliere klanten en een tweede voor een ander type klanten. Terwijl de tweede interface gebouwd werd, heeft het ontwikkelteam constant gekeken naar functionaliteit

21


t


SOA is ingevoerd, hoe nu verder?

22

Als een SOA (deels) is ingevoerd, is dat geen reden om te stoppen met nadenken. Een SOA op zich levert immers geen financiële winst voor de organisatie op. Hiervoor moet er nog meer gebeuren. SOA maakt het stapsgewijs opschonen en uitfaseren van legacysystemen mogelijk. Om terug te komen op het voorbeeld van zojuist: als blijkt dat je negen services hebt die worden uitgevoerd door een tiental legacysystemen, kun je service voor service die legacysystemen vervangen, zonder je druk te maken over de interfacing tussen de diverse legacysystemen. Hierdoor worden de grootste moeilijkheden uit de vervanging gehaald. Ook is het eenvoudig geworden om nu gecreëerde services te hergebruiken voor andere consumerende systemen (zie figuur 3 voor een voorbeeld). SOA maakt het uitbesteden van services mogelijk. De meeste IT-outsourcing bestaat nu nog uit het uitbesteden van collecties van systemen, die even complex zijn na uitbesteding als ervoor. Daardoor lopen de kosten na uitbesteding doorgaans ook eerder op in plaats van dat de IT goedkoper wordt. Als er services zijn gedefinieerd, wordt het mogelijk om één specifieke service uit te besteden, bijvoorbeeld aan een leverancier die stroomopwaarts zit. Als je leverancier je voorraad heeft, kan hij ook het voorraadbeheer in de IT-zin wel als service leveren. Met name voor salarisadministraties wordt dit nu al op grote schaal gedaan. SOA maakt het inkopen van services mogelijk. Er is al een markt voor generieke services (zoals salarisadministratie). Deze markt wordt groter en zal specifieker worden. Een voorbeeld hiervan is de betalingsafhandeling (denk aan iDeal, Amazon Payment Services en Google Checkout). Wij kunnen ons bijvoorbeeld ook een btw-service voorstellen die voor heel Europa weet hoeveel btw voor welk product waar moet worden afgedragen. Aangezien er weinig organisaties concurreren op btw-afdracht, is dit een aanlokkelijk alternatief voor geïntegreerde financiële pakketten als SAP. SOA maakt het afrekenen per service mogelijk. Zowel binnen een organisatie als daarbuiten wordt het mogelijk de kosten van IT transparant te maken en direct door te berekenen. Een organisatie kan dan direct zien hoeveel IT-kosten er gemaakt wor-

den om een product te verkopen. Dat zou wel eens invloed kunnen hebben op analyses van welke producten het meest winstgevend zijn. Nu worden de IT-kosten gemiddeld genomen over de hele productportfolio verdeeld. Ook voor de inkoop van IT-services extern is dit een interessante ontwikkeling. De eerdergenoemde betalingsafhandelingsservices worden nu al per geleverde service afgerekend. Zo kun je als softwarebouwer kiezen uit het betalen van 0,70 euro (iDEAL), 2 procent van de transactie plus 0,12 euro (Google) of 2 procent van de transactie plus 0,02 euro (Amazon). En deze services worden goedkoper bij een hoger volume. Het wachten is natuurlijk op een organisatie die een service aanbiedt die automatisch de goedkoopste betalingsafhandeling kiest, afhankelijk van een aantal parameters. En deze prijsinzichtelijkheid zal er ongetwijfeld toe leiden dat de prijzen van de afhandeling omlaag gaan. Hoe dan ook heeft de organisatie de kosten van het betalingsverkeer per transactie inzichtelijk. En deze kosten zouden (net als bijvoorbeeld verzendkosten) direct aan de klant doorberekend kunnen worden. En dat zal er zeker toe leiden dat de prijzen omlaag gaan.

Conclusie Het is een goed idee om na te denken over IT-systemen in termen van ‘diensten uitgevoerd voor een klant’. Dit aspect wil nog wel eens ondergesneeuwd raken in de (technische) complexiteit van de dagelijkse IT-praktijk. Service-oriented architecture is een pragmatisch model dat helpt bij het nadenken over IT-systemen in termen van werkelijke geleverde diensten. SOA kan en moet in de doorsnee organisatie stap voor stap worden ingevoerd en is niet afhankelijk van het invoeren van een specifieke technologie. Het invoeren van SOA levert op zichzelf geen winst op, het gaat erom wat je doet nadat de services beschikbaar zijn. Ons advies is om SOA op pragmatische wijze in te voeren, door klein te beginnen en niet door de hele IT-organisatie op de schop te nemen. Het gemiddelde IT-systeem levert een verrassend klein aantal services, zorg er tijdens en na het invoeren voor dat dit aantal klein blijft; als het aantal te groot wordt, is het abstractieniveau te laag en verlies je elk voordeel dat je met services juist wilde behalen. Tot slot maken de ingevoerde services het mogelijk het IT-landschap te versimpelen, maken ze outsourcing per service mogelijk, en zelfs het afrekenen per geleverde service. Dat zou wel eens een vergaande en blijvende impact op de IT-industrie kunnen hebben.

Dr. Tobias Kuipers is technisch directeur van de Software Improvement Group. E-mail: t.kuipers@ sig.nl. Dr. Per John is hoofd Software Development bij de Software Improvement Group. E-mail: [email protected].

haarlemmerolie van de IT? Tobias Kuipers en Per John

Recommend Documents