haarlemmerolie van de IT? Tobias Kuipers en Per John

Complexiei onder conrole, kosen inzichelijk? Naar een diensbare Gezien de populariei van is he goed eens erug e gaan naar de basis en e kijken naar wa SOA eigenlijk is, wa de redenen zijn om he in e voeren, hoe je da dan doe en wa de vervolgsappen zijn. Is SOA de haarlemmerolie van de IT? Tobias Kuipers en Per John Daaprocessing, corporae informaiesysemen en waar we nu saan Om e begrijpen waarom (SOA) een ineressan gespreksonderwerp is, is he een goed idee even sil e saan bij de geschiedenis van de corporae informaiesysemen. Die heef namelijk geleid o de siuaie die wij voor he gemak maar even sysem-oriened noemen. He is een bekend, maar relevan verhaal. We nemen als voorbeeld de banksecor en beginnen me een bank in de jaren zesig. Die begin me he auomaiseren van één aciviei: rekening-couran. In plaas van in boeken bij e houden hoeveel iedereen op zijn rekening heef saan, doe men da me de compuer. Da is efficiëner en minder fougevoelig. Als da blijk e werken, doe men hezelfde me de effecenrekeningen. En de spaarrekeningen. En de hypoheken. Al deze sysemen zijn zogenaamde sovepipes: ze saan los van elkaar en doen alles (zie figuur 1a). Di werk allemaal flisend, oda iemand zich realiseer da je bij een verhuizing iemands nieuwe adres vier keer moe invullen. En dan kom er iemand van de markeing en die wil graag ween wie van de rekeninghouders me een saldo van meer dan 1000 gulden een spaarrekening heef (zie figuur 1b). Dan worden er weer nieuwe sysemen geïnroduceerd: een syseem da klangegevens bijhoud, en die gegevens worden elke nach gerepliceerd in de oorspronkelijke sysemen. Er kom een syseem da gegevens ui he spaarrekeningsyseem kan halen, en ui he effecenrekeningsyseem (zie figuur 1c). Iemand wil inernebankieren invoeren, enzovoor (zie figuur 1d). Zo onsond de siuaie da een moderne bank honderden sysemen heef en da er op een heleboel plaasen dezelfde daa worden opgeslagen. Uieindelijk heef niemand meer overzich van wa al die aan elkaar geknoope sysemen nu eigenlijk doen. Wa is he probleem en hoe los SOA da op? He aan elkaar knopen van sysemen zoals gesches in he bovensaande scenario hee enerprise applicaion inegraion (EAI). Er zijn allerlei manieren verzonnen om sysemen e inegreren, bijvoorbeeld door alle daa in één daabase e soppen (daa-inegraie), de applicaies elkaar e laen aanroepen (applicaie-inegraie), daa via schermen e gebruiken (screenscraping) of applicaies via messages e koppelen (message queueing, message broker). SOA is de nieuwse rend in EAI en hierin worden applicaies geïnegreerd door middel van services. 18

Samenvaing Service-oriened (SOA) is een vorm van enerprise applicaion inegraion (EAI) waarin applicaies worden geïnegreerd door middel van services. Een service is een aciviei uigevoerd voor een klan, anders dan fabricage. He aanal services da via SOA word aangeboden moe klein zijn. SOA gaa nie over echnologie maar is een manier van nadenken over informaiesysemen. a) b) He verschil me de oude EAI-sraegieën is da men bij SOA hergebruik nasreef, erwijl de oude EAImehoden puur bezig waren me he aan elkaar knopen van applicaies. Wa is een service? Een service is een aciviei uigevoerd voor een klan, anders dan fabricage. He succes van he invoeren van SOA in een organisaie val of saa me in hoeverre deze definiie word gevolgd. Me andere woorden: hoe groo definieer je je services? Zoals blijk ui de reguliere definiie van he woord service is he woord klan hierin van groo belang. In he lich van SOA kan een d) c) Figuur 1. De onwikkeling van corporae informaiesysemen 19

klan zowel een eche (exerne) klan zijn als een inerne klan, maar zeker nie de IT-afdeling. In he voorbeeld van de bank me de legacysysemen zouden Wa is mijn huidige saldo? en Hoeveel kan ik lenen? een service zijn, maar nie Wa is de sauscode van de replicaie van daabase 2?. He idee van serviceoriënaie is om een absracielaag over de besaande informaiesysemen heen e leggen en zo de inerne complexiei e verbergen. Da beeken da een organisaie de services in de SOA-zin moe aanbieden die ze ook in werkelijkheid aanbied, en nies meer. He aanal services da via SOA word aangeboden moe dus klein zijn. In onze adviesprakijk komen we eigenlijk nooi (legacy)sysemen van klanen egen die meer dan zeven services aanbieden, en de meese nie meer dan vier. Minder services is beer e begrijpen. Bovendien hoef je minder e inegreren als je minder services heb. We kennen één organisaie die overwoog haar legacysysemen ui e faseren door weeduizend services e inroduceren, namelijk alle inerfaces die de legacysysemen nu ook al aan elkaar boden. He is eviden da je daarmee nie he probleem oplos en zelfs een nieuw probleem inroduceer. He gaa nie over echnologie SOA is een manier van nadenken over informaiesysemen. Er is zeker echnologie die SOA kan onderseunen, maar als je alleen maar die echnologie inroduceer, dan is er nog geen SOA. En andersom kun je SOA invoeren zonder enige echnologie aan e schaffen. Zo zijn webservices een veelgebruik middel om SOA in e voeren. Als je echer de oorspronkelijke inerfaces repliceer me behulp van services, heb je nog geen SOA, maar is er slechs een exra laag geïnroduceerd boven op he legacysyseem. Omgekeerd suggereren veel aanbieders da door he inpluggen van hun SOA-echnologie, bijvoorbeeld een enerprise service bus (ESB), eenvoudig een SOA kan worden gerealiseerd. Elk legacysyseem krijg dan direc een of meer inerfaces naar de ESB. He eerse probleem is da di lang nie alijd kan. In onze adviesprakijk komen wij maandelijks zeer creaieve inerfaces me legacysysemen egen die de doorsnee ESB nie onderseun, van screenscraping o aan he schrijven van assembly-inerfaceprogramma s. He weede probleem is da wa deze inerfaces bieden geen service is. Ze bieden een (klein deel van een) echnisch aspec van de oale service die he syseem lever. Een inerface kan bijvoorbeeld een record in een specifiek formaa wegschrijven naar een abel in een daabase, vervolgens een Cobolprogramma aanroepen en o slo een record in een abel ui een andere daabase uilezen, om zo de eerse sap van he proces da leid naar he klannummer uigevoerd e hebben. Als di soor ineracie me legacysysemen nodig is (en da is zo, daarom heen ze immers legacysysemen), dan is he vrijwel onmogelijk, en in ieder geval onwenselijk, om deze inegraie in de fraaie grafische XML-omgeving van de ESB o sand e brengen. De XML is er simpelweg nie expressief genoeg voor en vereis inegraieprogrammauur die dan weer onderdeel word van de XML-inegraielaag. Hierdoor word he probleem nie kleiner, om nog maar e zwijgen van de esinspanning om di überhaup aan de praa e krijgen.»een SOA op zich lever geen financiële wins voor de organisaie op«hoe voer je SOA in? He invoeren van SOA in een besaande organisaie is geen eenvoudige operaie. He is ook geen projec. He invoeren van SOA lever in eerse insanie geen enkele waarde voor de organisaie op. Pas op ermijn zal de IT koseneffeciever worden door he gebruik van services. He invoeren van services kan he bese sap voor sap gebeuren, egelijk me IT-projecen die och al worden uigevoerd. Dan breng he geen onoverkomelijke kosen me zich mee en worden er ook geen services bedach die uieindelijk och nie gebruik gaan worden. Een onversandige aanpak is om een commissie in e sellen die langdurig gaa vergaderen over wa nu eigenlijk de services zijn die de organisaie lever en/of nodig heef. Als je een commissie nodig heb om e bedenken wa je bedrijf eigenlijk doe, dan is IT nie he belangrijkse probleem van he bedrijf. Een beer idee is om in één à wee weken vas e sellen wa globaal de services zijn en waar die zich ongeveer in he applicaielandschap bevinden. Als 20

er dan een nieuw syseem gebouwd of vervangen gaa worden, is he de moeie waard om e kijken of de benodigde services ui de oude sysemen kunnen worden gedesilleerd zonder de oude sysemen al e veel e veranderen. Als da kan, kunnen de nieuwe sysemen eenvoudig de oude sysemen via de service-inerface gebruiken. Om een succesvol voorbeeld ui de prakijk e geven behandelen we de case van een van onze klanen. He beref een bedrijf da services lever aan zowel pariculiere als zakelijke klanen, radiioneel via de elefoon en via makelaars en de laase paar jaar seeds meer via he web. He bedrijf auomaiseer al ruim veerig jaar en is door een recene fusie eigenaar geworden van een ienal backoffice-legacysysemen me overlappende funcionaliei. De eerse paar webporals die di bedrijf bouwde waren, op allerlei manieren aan de backoffice verbonden. Door de fusie werd da seeds moeilijker. De organisaie besloo een servicelaag e bouwen boven op de legacysysemen (laag A in figuur 2). Deze laag wee welke diens door welke collecie van legacysysemen geleverd word en wee op welke manier en in welke volgorde die sysemen moeen worden uigevraagd om o he goede anwoord e komen. De services die laag A aanbied, hebben veel opies. Er is bijvoorbeeld een service Geef prijs voor produc X, gegeven koringscode Y, klan-id Z en makelaarsdiscoun A. Degene die deze service geleverd wil krijgen, moe dus ween da produc X besaa en moe al een klan-id hebben. Deze services worden via een inerface gebruik door de makelaars. De makelaars doen di al jaren en hebben personeel in diens da al deze codes ken, begrijp en kan gebruiken. Toen er een nieuwe webporal gemaak moes worden voor pariculiere klanen, besloo de organisaie boven op laag A eers een nieuwe servicelaag (laag B) e bouwen die de services voor de pariculiere klanen definieerde. Laag B praa alleen me laag A en gebruik haar services, maar bied minder opies aan. In ermen van he eerdere voorbeeld word de service dan Geef prijs voor produc X, waarbij de koringscode en de klan-id zijn weggevallen of op sandaardwaarden zijn geze. De weede servicelaag (laag B) is egelijk me de weede webinerface gebouwd. Er is een webinerface voor een speciaal ype pariculiere klanen en een weede voor een ander ype klanen. Terwijl de weede inerface gebouwd werd, heef he onwikkeleam consan gekeken naar funcionaliei Figuur 2. Voorbeeld van opbouw van SOA Figuur 3. Voorbeeld van hergebruik van services voor andere sysemen die gedeeld werd ussen de eerse en de weede inerface om zo de juise services in laag B e definiëren. Uieindelijk zien er negen services in laag A en drie services in laag B. He bouwen van laag A was een apar projec da gedreven werd door de inegraie van de backofficesysemen na de fusie. He bouwen van laag B is egelijk me he bouwen van de webinerface gedaan, een projec van vijf mensen da ongeveer drie maanden heef gekos. 21

SOA is ingevoerd, hoe nu verder? Als een SOA (deels) is ingevoerd, is da geen reden om e soppen me nadenken. Een SOA op zich lever immers geen financiële wins voor de organisaie op. Hiervoor moe er nog meer gebeuren. SOA maak he sapsgewijs opschonen en uifaseren van legacysysemen mogelijk. Om erug e komen op he voorbeeld van zojuis: als blijk da je negen services heb die worden uigevoerd door een ienal legacysysemen, kun je service voor service die legacysysemen vervangen, zonder je druk e maken over de inerfacing ussen de diverse legacysysemen. Hierdoor worden de groose moeilijkheden ui de vervanging gehaald. Ook is he eenvoudig geworden om nu gecreëerde services e hergebruiken voor andere consumerende sysemen (zie figuur 3 voor een voorbeeld). SOA maak he uibeseden van services mogelijk. De meese IT-ousourcing besaa nu nog ui he uibeseden van collecies van sysemen, die even complex zijn na uibeseding als ervoor. Daardoor lopen de kosen na uibeseding doorgaans ook eerder op in plaas van da de IT goedkoper word. Als er services zijn gedefinieerd, word he mogelijk om één specifieke service ui e beseden, bijvoorbeeld aan een leverancier die sroomopwaars zi. Als je leverancier je voorraad heef, kan hij ook he voorraadbeheer in de IT-zin wel als service leveren. Me name voor salarisadminisraies word di nu al op groe schaal gedaan. SOA maak he inkopen van services mogelijk. Er is al een mark voor generieke services (zoals salarisadminisraie). Deze mark word groer en zal specifieker worden. Een voorbeeld hiervan is de bealingsafhandeling (denk aan ideal, Amazon Paymen Services en Google Checkou). Wij kunnen ons bijvoorbeeld ook een bw-service voorsellen die voor heel Europa wee hoeveel bw voor welk produc waar moe worden afgedragen. Aangezien er weinig organisaies concurreren op bw-afdrach, is di een aanlokkelijk alernaief voor geïnegreerde financiële pakkeen als SAP. SOA maak he afrekenen per service mogelijk. Zowel binnen een organisaie als daarbuien word he mogelijk de kosen van IT ransparan e maken en direc door e berekenen. Een organisaie kan dan direc zien hoeveel IT-kosen er gemaak worden om een produc e verkopen. Da zou wel eens invloed kunnen hebben op analyses van welke producen he mees winsgevend zijn. Nu worden de IT-kosen gemiddeld genomen over de hele producporfolio verdeeld. Ook voor de inkoop van IT-services exern is di een ineressane onwikkeling. De eerdergenoemde bealingsafhandelingsservices worden nu al per geleverde service afgerekend. Zo kun je als sofwarebouwer kiezen ui he bealen van 0,70 euro (ideal), 2 procen van de ransacie plus 0,12 euro (Google) of 2 procen van de ransacie plus 0,02 euro (Amazon). En deze services worden goedkoper bij een hoger volume. He wachen is nauurlijk op een organisaie die een service aanbied die auomaisch de goedkoopse bealingsafhandeling kies, afhankelijk van een aanal parameers. En deze prijsinzichelijkheid zal er ongewijfeld oe leiden da de prijzen van de afhandeling omlaag gaan. Hoe dan ook heef de organisaie de kosen van he bealingsverkeer per ransacie inzichelijk. En deze kosen zouden (ne als bijvoorbeeld verzendkosen) direc aan de klan doorberekend kunnen worden. En da zal er zeker oe leiden da de prijzen omlaag gaan. Conclusie He is een goed idee om na e denken over IT-sysemen in ermen van diensen uigevoerd voor een klan. Di aspec wil nog wel eens ondergesneeuwd raken in de (echnische) complexiei van de dagelijkse IT-prakijk. Service-oriened is een pragmaisch model da help bij he nadenken over IT-sysemen in ermen van werkelijke geleverde diensen. SOA kan en moe in de doorsnee organisaie sap voor sap worden ingevoerd en is nie afhankelijk van he invoeren van een specifieke echnologie. He invoeren van SOA lever op zichzelf geen wins op, he gaa erom wa je doe nada de services beschikbaar zijn. Ons advies is om SOA op pragmaische wijze in e voeren, door klein e beginnen en nie door de hele IT-organisaie op de schop e nemen. He gemiddelde IT-syseem lever een verrassend klein aanal services, zorg er ijdens en na he invoeren voor da di aanal klein blijf; als he aanal e groo word, is he absracieniveau e laag en verlies je elk voordeel da je me services juis wilde behalen. To slo maken de ingevoerde services he mogelijk he IT-landschap e versimpelen, maken ze ousourcing per service mogelijk, en zelfs he afrekenen per geleverde service. Da zou wel eens een vergaande en blijvende impac op de IT-indusrie kunnen hebben. Dr. Tobias Kuipers is echnisch direceur van de Sofware Improvemen Group. E-mail:.kuipers@ sig.nl. Dr. Per John is hoofd Sofware Developmen bij de Sofware Improvemen Group. E-mail: p.john@sig.nl. 22