Architectuur op basis van services. Het totale plaatje

Transcriptie

1 Architectuur op basis van services Door: Marcel Grauwen en Ronald Coenen Het totale plaatje De balans van de eerste ervaringen omtrent Service Oriented Architecture (SOA) valt niet onverdeeld gunstig uit. Onderzoek van Forrester toont aan dat een kleine minderheid van 24 procent van alle bedrijven die SOA inzetten, daar de beoogde voordelen mee behalen. De overige driekwart implementeert het niet op de juiste wijze of onvolledig en heeft daardoor te maken met hogere kosten en complexiteit. Dat is meer dan jammer te noemen, aangezien het tegenovergestelde lagere kosten en veel grotere flexibiliteit absoluut haalbaar is. Dit artikel beschrijft hoe ondernemingen met hun SOA implementatie die stijgende lijn te pakken kunnen krijgen. Het ICT-landschap wordt met toenemende functionaliteiten en de voortschrijdende globalisering alleen maar omvangrijker en complexer. De onderlinge afhankelijkheid van alle ICT-componenten, die vrijwel voortdurend aan verandering onderhevig zijn, is daarmee navenant complex geworden. Veel ICT-projecten overschrijden hun planning en budget doordat belangrijke sleutelinformatie ontbreekt, onvolledig of onjuist is. Het is dan ook niet verwonderlijk dat er steeds meer stemmen opgaan die zeggen dat projecten die qua kosten of doelstelling ernstig uit de rails lopen het beste kunnen worden stopgezet. Steeds vaker worden SOA projecten ook geschaard onder het soort projecten dat veel meer kost dan dat ze uiteindelijk oplevert. En dat terwijl juist SOA de meest wezenlijke bijdrage kan leveren aan het weer soepel maken van de steeds logger wordende en moeizamer draaiende ICT-machine. Een van de redenen waarom SOA in het merendeel van de gevallen teleurstelling oproept, is het feit dat het eveneens als een van de vele projecten wordt beschouwd. Daardoor zijn er voornamelijk suboptimale integratieoplossingen gerealiseerd (veelal te omschrijven als pointto-point oplossingen), die geen integraal deel uitmaken van een SOA. Eén van de lessons learned is dan ook om een SOA implementatie niet te beschouwen als een project, maar als een programma of roadmap: bouw het zoals het een Enterprise Architectuur betaamt, stukje bij beetje op. Dit is exact wat de bedrijven hebben gedaan die bij die 24 procent horen die voordelen behalen uit hun SOA implementatie. Bovendien heeft het management van deze ondernemingen de ontwikkeling en implementatie van SOA volledig gesteund en zijn ze door externe partijen goed begeleid. De evolutie Figuur 1. De evolutie van Integratie Architectuur geeft de evolutie weer van de Integratie Architectuur van klassieke Enterprise Architecture (EA) naar een Service Oriented Architected (SOA) organisatie. Aan de hand daarvan is af te leiden op welk niveau van SOA volwassenheid een onderneming zich bevindt. Veel bedrijven menen oprecht dat ze conform de SOA uitgangspunten zijn ingericht, terwijl ze in werkelijkheid op het niveau van een EAorganisatie opereren. Dat zijn bijvoorbeeld organisaties die veel aandacht hebben besteed aan BPM, maar deze nog niet effectief kunnen inzetten als gevolg van het ontbreken van de benodigde business services. Een aantal bedrijven doet een tweede poging en streeft naar een

2 zogenoemde Event Driven Architecture (EDA). Uitgangspunt van een EDA is dat alles event driven is; pur sang zijn er geen batchprocessen en geen achterlopende processen meer. Alles verloopt dan on-time en real-time. Figuur 1. De evolutie van Integratie Architectuur. SOA niet het doel Organisaties die SOA als een technische oplossing invoeren, dus SOA als doel en niet als middel, zal bij de eerder genoemde 76 procent van teleurgestelden gaan horen. Een dergelijk uitgangspunt is namelijk gedoemd tot mislukken. Een ICT architectuur op basis van services gaat nog meer voordelen opleveren wanneer het wordt gekoppeld aan Business Process Management (BPM) en business intelligence (BI). Hiermee worden bestaande applicaties en gegevensbronnen door middel van services op efficiënte en beheerbare wijze ontsloten, waarmee de IT organisaties sneller en effectiever in staat zijn nieuwe business processen te implementeren alsmede sneller nieuwe gegevensbronnen ten behoeve van BI rapportages aan te leveren. Zoals gesteld dient een SOA implementatie te worden beschouwd als een roadmap, een projectoverstijgend onderwerp dat moet worden gedragen door alle betrokkenen, dus ook door ICT-beheer, de business en het management. Van oudsher heeft de business vanuit haar perspectief slechts oog voor efficiënt ingerichte bedrijfsprocessen op basis van BPM. Dat een succesvolle BPM implementatie niet los is te zien van een efficiënte SOA, wordt nog maar weinig door organisaties onderschreven. BPM

3 zonder onderliggende SOA kan beschouwd worden als een auto zonder wielen - het kan er prachtig gestroomlijnd en modern uit zien, maar zonder wielen kom je nergens. SOA is de best denkbare architectuur naar de toekomst toe om twee hoofdredenen: 1. het is een perfecte enabler voor BPM en BI; met goed ingerichte SOA kun je enorm besparen op de ICT-kosten 2. het kan ongekende flexibiliteit (agility) creëren; zodat ICT met groot gemak kan meebewegen met marktbewegingen van haar business, of die zelfs voor zijn. Welke paden dienen te worden bewandeld om tot een gewenste succesvolle SOA implementatie te komen? Daartoe zijn in de markt een aantal oplossingen en visies ontwikkeld. Één ervan heet: Total SOA. Total SOA en Referentie Architectuur Total SOA kan niet los worden gezien van een referentiearchitectuur. In het kader van Total SOA bevat een referentiearchitectuur op de eerste plaats een beschrijving van het product onder ontwerp in andere woorden een blauwdruk van de structuur van een stuk informatievoorziening. In deze structuur kunnen we een aantal aspecten onderscheiden, zoals: Data-aspect: beschrijft de structuur van relevante data, bijvoorbeeld een Canonical Data Model (CDM). Proces-aspect: beschrijft de structuur van relevante processen, bijvoorbeeld een workflow model. Communicatie-aspect: beschrijft de structuur van de interfaces naar externe systemen. Platform-aspect: beschrijft de structuur van de abstract technologieklassen die gebruikt worden voor de realisatie van de systemen die beschreven worden. Organisatie-aspect: beschrijft de organisatiestructuur rond de realisatie en het gebruik van de systemen die beschreven worden. Alle aspecten van Total SOA zijn relevant voor iedere referentiearchitectuur, zij het dat bepaalde aspecten dominant kunnen zijn voor een specifieke referentiearchitectuur. Een referentiearchitectuur bevat dan bij voorkeur ook verscheidene aspectarchitecturen. Iedere aspectarchitectuur is gespecificeerd in een geschikte notatie de verschillende notaties moeten onderling natuurlijk consistent zijn. Het verdient sterke aanbeveling gestandaardiseerde notaties met duidelijke semantiek te gebruiken (bijvoorbeeld UML diagrammen). Naast de beschrijving van de structuur van een product bevat een referentiearchitectuur ook principes en richtlijnen; bouwvoorschriften voor het ontwerpen van een Total SOA architectuur of specifieke architectuur op basis van de referentiearchitectuur. Daar waar de structuur zeer gedetailleerd beschreven is, kunnen de richtlijnen vaak summier zijn (de richtlijnen zijn dan al voor een groot deel in de structuur verwerkt). Daar waar de structuur globaal van aard is, zijn meer gedetailleerde richtlijnen wenselijk om tot een goede en consistente toepassing te komen.

4 Figuur 2. Total SOA model. Total SOA referentiearchitecturen zijn abstracte architecturen en de basis voor meer specifieke architecturen. Zij zijn daarmee een belangrijk gereedschap voor het hergebruik op architectuurniveau. De roadmap Succesvolle implementaties van SOA oplossingen behelzen de nodige complexiteit en investeringen in zowel tijd als geld. Deze investering voorkomt het worst case scenario van een niet meer te ontwarren wildgroei aan services. Vanaf het moment dat de services goed gestroomlijnd kunnen worden hergebruikt, betalen de investeringen zich terug. De roadmap voor Total SOA maakt de verbinding tussen EA als onderdeel van lifecycle management met de reeds geïmplementeerde SOA-landschappen en de met elkaar geïntegreerde applicaties (Enterprise Application Integration, EAI). Kort gezegd stelt de roadmap voor om op de verschillende lagen (zie hiervoor figuur 2. Total SOA model) oplossingen neer te zetten als onderdeel van de complete SOA architectuur. Iedere stap in de roadmap, al dan niet geïnitieerd door de business, begint met een business case. Daar wordt ook de architectuur bij betrokken, waar de nodige beslispunten in zitten. In het procesmodel van de roadmap staat wie op welk punt wat beslist en wanneer de implementatie naar een volgende fase kan overgaan. Op die manier beschikt een organisatie over een duidelijke fasering en structuur voor implementatie van Total SOA.

5 De stappen Startpunt van de Total SOA roadmap is dat er al services zijn gebouwd en in gebruik zijn genomen. Dit hoeven niet alleen maar zelf ontwikkelde services te zijn. Het kan ook bestaan uit een systeem van SAP of Oracle, dat interne functionaliteiten op basis van services aan de buitenwereld beschikbaar stelt. Uitgangspunt is dat binnen de organisatie gebruik gemaakt wordt van servicecontracten. Deze servicecontracten leggen vast hoe een service eruitziet, op welke wijze hij kan worden aangeroepen, wie de eigenaar is, enzovoort. Figuur 3. Total SOA roadmap. De stappen van de roadmap voor Total SOA staan schematisch weergegeven in figuur 3. Total SOA roadmap en worden hieronder nader toegelicht: Stap 1. Inrichting van een SOA Operational Governance tool ter vergroting van het inzicht in het services landschap door middel van het verzamelen van operationele informatie en statistieken over de services, berichten en ketens 1. Stap 2. Implementatie van een centrale servicecatalogus. Deze servicecatalogus vormt de spil van het gehele servicemodel en wordt gevoed vanuit diverse bronnen in het Total SOA model. De belangrijkste bron is het Operational Governance tool (stap 1). Stap 3. Een optionele stap is het implementeren van policy enforcement. 1. Zie ook de white paper over SOA Operational Governance: Het ontwarren van spaghetti.

6 Stap 4. Inzet van specifieke SOA testtooling. Veelal zijn deze al in een eerder stadium van de SOA implementatie aangeschaft. Stap 5. Implementatie van service lifecycle management. Stap 6. Implementatie van versiecontrole en -management. Inzicht in services Zolang het aantal services en het gebruik daarvan ongecoördineerd en zonder oog voor de kwaliteit van die services blijft toenemen, stevent een organisatie op een intransparante SOA. Derhalve is inzicht in het services landschap van primordiaal belang. SOA Operational Governance levert inzicht in het service landschap door informatie te leveren over de berichtenstroom naar en van de services. Hiertoe correleert het services op basis van de berichtenstromen en bewaakt het afspraken omtrent services (SLA s) in termen van volumes, doorlooptijd en beschikbaarheid. Door middel van het dynamisch ontdekken van services kunnen ook niet gedocumenteerde (versies van) services en koppelingen aan het licht worden gebracht. Een adequaat SOA Operational Governance tool vult alle bovengenoemde functies in. In het artikel Het ontwarren van spaghetti 1 wordt nader ingegaan op een van de beschikbare tools. Het hart Inzicht in een SOA landschap staat of valt met het eenduidig en accuraat vastleggen van de kenmerken en details ervan. De indexering van het landschap vindt plaats op basis van services, waarbij de informatie over de services wordt vastgelegd in servicecontracten. Deze contracten worden ondergebracht in een zogenaamde service catalogus. De servicecatalogus vormt hiermee de spil van het gehele Total SOA model. Ook functioneert het als een ontkoppelpunt tussen de verschillende lagen in het Total SOA model (zie figuur 2. Total SOA model). Andere benamingen voor een servicecatalogus is een Service Repository of UDDI. Afdwingen van afspraken Bijna haaks op de eigenschappen van services staat het afdwingen van generieke afspraken of policies. Policy enforcement biedt hierin een oplossing door deze centraal voor het hele service landschap vast te leggen. In policies kan worden aangegeven welke afnemer welke services mag aanroepen en uitvoeren. Dit kan worden toegepast op gebruikers van buitenaf, en intern binnen de eigen organisatie. Ook kunnen prioriteiten aan afnemers worden toegewezen waardoor iemand met een bepaalde username en password een hogere voorrang krijgt bij het aanroepen van een bepaalde service dan iemand die lagere prioriteit heeft. Kwaliteit door testen Hergebruik van services vindt veelal beperkte mate plaats als gevolg van onduidelijkheid over de kwaliteit van de beschikbare services. Door de kwaliteit van de services met enige regelmaat te valideren met daartoe beschikbare test tools wordt additionele

7 kwaliteitsinformatie verkregen, zoals de maximale belasting (hoe vaak kan een service binnen een seconde worden aangeroepen), de snelheid bij toenemende belasting, enzovoort. Door deze kwaliteitsinformatie onder te brengen in de servicecatalogus, wordt de inzichtelijkheid in de kwaliteit van de services vergroot en daarmee de kwaliteit van het complete service landschap. Managen van de levenscyclus Lifecycle management wordt doorgaans meer met BPM en Enterprise Architectuur geïdentificeerd dan met SOA. In de Total SOA visie is lifecycle management echter een belangrijk onderdeel om hergebruik van services eenvoudig mogelijk te maken. Door middel van service lifecycle management kan de business worden voorzien van bouwblokken op grond waarvan snel en eenvoudig in het betreffende service lifecycle tool nieuwe BPM processen kunnen worden geïmplementeerd. De andere kant op biedt service lifecycle management de mogelijkheid om in een nieuw geïmplementeerd BPM proces, benodigde IT services of uitbreidingen/verbeteringen erop te definiëren. De ontbrekende of aan te passen services kunnen, met de bijbehorende nieuwe specificaties, aan de servicecatalogus worden aangeleverd en daarmee input zijn voor IT services development teams. Hulp bij versiecontrole Een belangrijk onderdeel voor het succes van een SOA implementatie, is de invoering van versiecontrole. Dit houdt de onderlinge afhankelijkheden van services bij, bijvoorbeeld in geval dat services elkaar aanroepen over alle omgevingen heen. Het bijhouden van deze afhankelijkheden, die in een snel groeiende omgeving kan oplopen tot services of meer, handmatig niet te doen is. In een OTAP straat (ontwikkel, test, acceptatie en productie), waar diverse versies van services actief zijn, is het belangrijk te weten welke combinatie van services en versies een integratietest is uitgevoerd en welk testrapport deze test beschrijft. Slechts op grond van een dergelijk rapport kan een in productie name van een nieuwe versie van een service worden beoordeeld. Een versie controle tool kan de centrale servicecatalogus verrijken met de vastgelegde versieinformatie en afhankelijkheden. Informatie als deze kan dan worden doorgegeven aan het eerder beschreven policy enforcement point, zodat deze beschikt over alle relevantie informatie van een service om daar betere policy op toe te kunnen passen. Dit kan bijvoorbeeld van dienst zijn in geval een verouderde versie van een service alleen nog door een specifieke groep gebruikers of applicatie mag worden aangeroepen. Van visie naar tools Voor het opstellen van een Referentie Architectuur alsmede alle hierboven beschreven stappen is het raadzaam om professioneel advies in te winnen welke roadmap en als invulling hiervan, welke tools het meest geschikt zijn voor uw organisatie. Voor zover bekend is er nog geen Integratie Software leverancier die alle producten levert waarvan de functionaliteiten in het kader van de Total SOA visie zijn beschreven. Op grond

8 hiervan kan worden gesteld dat de invulling van de set aan producten vrijwel altijd een zogenaamde multi-vendor oplossing zal zijn. Het voert voor dit artikel te ver om de opties voor tools bij de diverse stappen in de roadmap uiteen te zetten. Dit artikel richt zich vooral op de samenhangende strategie, onafhankelijk van enige leverancierskeuze, die succesvolle een succesvolle SOA implementatie mogelijk maakt. De voordelen van Total SOA Samengevat levert implementatie van de Total SOA roadmap de volgende voordelen: Verbeterde transparantie van de SOA-omgeving. Positioneert SOA als succesvolle enabler voor BPM en BI. Volledige lifecycle management voor services. Hogere kwaliteit van services (en daarmee ook een hogere CMMi). Betere capaciteitsplanning van de ICT infrastructuur. Dankzij inzichtelijke en historische/statistische informatie kan beter worden geanticipeerd op groei of juist afname van het gebruik van services. Verbeterde security implementatie door het toepassen van dat policy enforcement points en hieruit voortvloeiende informatie over het gebruik van de services. Grotere voorspelbaarheid van de kwaliteit van services waardoor de uitrol van nieuwe functionaliteiten met minder afbreukrisico kunnen worden uitgevoerd. Het beheren van de ICT omgeving op basis van business ketens in plaats van silo s. De impact van een verstoring in een ICT omgeving op de business services kan sneller inzichtelijk worden gemaakt, wat een kortere hersteltijd van de services tot gevolg heeft. De ontwikkeling en afhankelijkheid van services wordt veel beter gestroomlijnd dankzij de betere informatievoorziening. Inzichtelijke resultaten van services ten opzicht van gemaakte service level afspraken.

9 Conclusie SOA is pas succesvol als er op structurele en gecontroleerde wijze hergebruik van services plaats kan vinden door middel van grip op en inzicht in de kwaliteit van de services. SOA kan nog succesvoller worden wanneer het wordt gekoppeld aan Business Process Management (BPM) en business intelligence (BI). In die arena s levert SOA namelijk de meeste toegevoegde waarde. Benader een SOA implementatie niet als één project, maar bouw het stukje bij beetje op als een Enterprise Architectuur. Een van de benaderingen hiervoor wordt omschreven als de Total SOA visie, welke aan de hand van een beschreven roadmap kan worden geïmplementeerd. Iedere fase van de roadmap dient op basis van een business case te worden gedefinieerd. Kern van de Total SOA visie is de implementatie van SOA Operational Governance en een centrale servicecatalogus. Deze laatste is het ontkoppelpunt tussen de onderliggende services het hoger gelegen lifecycle management. Voor het vormgeven van Total SOA bestaat niet één model dat voor iedere organisatie kan worden gekopieerd. Er is ook geen één software leverancier die de ideale Total SOA oplossing kan leveren. De markt biedt een verscheidenheid aan tools en oplossingen om een Total SOA oplossing te implementeren. Voorwaarde is dat voor de implementatie van de diverse onderdelen voldoende kunde en kennis beschikbaar is, welke vanwege de specifieke kennis van de materie en producten veelal van buiten de onderneming zal moeten worden ingehuurd.