SOA van Ontwerp naar een Effectief Service-Oriented IT Landschap

Verschenen in het jaarboek IT beheer en informatiebeveiliging 2006: Investeren in beheer

p. 1/15

SOA – van Ontwerp naar een Effectief Service-Oriented IT Landschap Door: Hans Bot. Een Service-Oriented Architectuur (SOA) is vandaag de dag ‘en vogue’. En niet voor niets, er valt veel positiefs te zeggen over de architectuurprincipes die de grondslag vormen van een SOA. Scheiding van front-office- en backofficelogica, scheiding van proces- en bedrijfslogica, integratie als uitgangspunt van de architectuur in plaats van als moeizame optimalisatie achteraf, het zijn evenzovele behartenswaardige architectuur-best-practices. Er is al veel geschreven over het ontwerpen van een SOA. Leveranciers doen geloven dat het met hun producten een fluitje-van-een-cent is om de beoogde voordelen van hoge agility en lage kosten te bereiken – daar zijn het leveranciers voor. En consultants, ach, die hopen vooral op een nieuwe hype die alle vorige doet vergeten. Maar iedere rechtgeaarde architect weet –of zou moeten weten– dat het ontwerp van een architectuur pas het begin is op een lange weg naar succes – en vaak allerminst de moeilijkste stap. Dit artikel gaat voor de verandering eens in op de vele uitdagingen die de weg van het ontwerp voor een SOA naar een effectief werkend service-oriented IT Landschap kenmerken. En vanuit onze praktijk bij ADP BUSINESS SERVICES wordt beschreven hoe deze uitdagingen met succes kunnen worden getackeld.

Van SOA naar SOIL Een service-oriented architectuur (SOA) is vandaag de dag en vogue. En niet voor niets, want er valt veel positiefs te zeggen over de architectuurprincipes die de grondslag vormen van een SOA. Scheiding van front-office- en back-officelogica, scheiding van proces- en bedrijfslogica, integratie als uitgangspunt van de architectuur in plaats van als moeizame optimalisatie achteraf, het zijn evenzovele behartenswaardige architectuur-best-practices. Er is al veel geschreven over het ontwerpen van een SOA. Leveranciers doen geloven dat het met hun producten een fluitjevan-een-cent is om de beoogde voordelen van hoge agility en lage kosten te bereiken – daar zijn het leveranciers voor. En consultants, ach, die hopen vooral op een nieuwe hype die alle vorige doet vergeten. Maar iedere rechtgeaarde architect weet – of zou moeten weten – dat het ontwerp van een architectuur pas het begin is van een lange weg naar succes – en vaak allerminst de moeilijkste stap. Dit artikel gaat voor de verandering eens in op de vele uitdagingen die de weg van het


p. 2/15

ontwerp voor een SOA naar een effectief werkend service-oriented IT-landschap kenmerken. En aan de hand van de praktijk bij ADP Business Services wordt beschreven hoe deze uitdagingen met succes kunnen worden getackeld. Zie Figuur 1. Figuur 1: De Service-Oriented Architectuur bij ADP Business Services Het heeft heel wat bloed, zweet en tranen gekost om simpel ogende ontwerp van onze SOA in de praktijk te brengen. Complicerend daarbij was het feit dat we ons als voorloper gedwongen zagen om de Service Bus voor een belangrijk deel zelf te ontwikkelen. De eerste les die we hebben geleerd, en misschien wel de belangrijkste, is dat het hebben van een webservice, of een andere IT oplossing, bij lange na niet voldoende is om een nuttige Business Service te kunnen bieden. We hebben ontdekt dat er daarvoor een hele set aan ondersteunende services geboden moet worden, zoals: •

Contract Management Services

•

Provisioning Services

•

Identity and Access Services

•

Platform Services

•

Housing and Hosting

•

Service Management Services

•

Billing Services

Al deze diensten zijn een wezenlijk onderdeel van ons Service-Oriented IT Landschap (SOIL). Gelukkig zijn deze diensten generiek opgezet – het valt immers gemakkelijk in te zien dat de herbruikbaarheid van dit soort services hoog is. Dat wil zeggen, als de software in te passen is in het SOA framework – voor veel ‘off-the-shelf’ of semi ‘off-the-shelf’ producten ondanks onze inspanningen om het framework zo generiek mogelijk te maken, toch vaak nog een hele tour. Dat een Service-Oriented Architectuur staat of valt bij een service infrastructuur dat is inmiddels breed geaccepteerd – lees de verhalen van de enterprise service bus-leveranciers er maar op na. Wat helaas nog minder bekend is, is het feit dat een SOIL, het geheel van services en de infrastructuur die de services gebruiken, fundamenteel verschilt van een applicatie of een specifieke service. Het SOIL is immers continu aan het veranderen – is het niet door het wijzigen of toevoegen van services, dan is het wel door het upgraden van de infrastructuur. Deze continue evolutie vraagt om een principieel andere benadering dan gebruikelijk is in de meeste IT organisaties – een benadering die doorgaans onderscheid maakt tussen een projectgedreven creatie organisatie en een procesgedreven beheerorganisatie. Het doorbreken van de organisatorische barrières tussen deze afdelingen blijkt een tweede kritieke succesfactor in de realisatie van een SOIL. Een SOIL vraagt om een nieuwe organisatievorm, een Service-Oriented IT Organisatie (SOIO) – iets waarvan de contouren langzamerhand zichtbaar beginnen te worden. Aan de hand van een veel gebruikt ontwikkelprocesmodel –het Rational Unified Proces (RUP)– en een veelgebruikt procesmodel voor Service Management –ITIL– bespreken we de impact van serviceoriëntatie op de ITorganisatie.

Impact van SOA op het Ontwikkelproces Het Rational Unified Process (RUP) maakt onderscheid tussen de primaire disciplines •

Business Modeling

•

Requirements


•

Analysis & Design

•

Implementation

•

Test

•

Deployment

p. 3/15

Zie Figuur 2. Zonder op de details van het model in te gaan, is het nuttig om voor de verschillende disciplines eens te verkennen wat de impact van Service-Oriëntatie zou kunnen zijn .

Figuur 2: Disciplines en fasering van het Ontwikkelproces volgens RUP

Business Modeling Niets is makkelijker dan het ontwerpen van een eilandoplossing. Een SOA beoogt een einde te maken aan al die goedbedoelde maar uiteindelijk suboptimale eilandoplossingen. Dat begint bij het modelleren van de bedrijfsprocessen en -functies. Het onderscheiden van generieke shared services met alle basisfunctionaliteit en de kanalen, labels of landen die deze services als ondersteuning van hun specifieke processen gebruiken, vereist een andere manier van werken. Businessanalisten hebben meer inzicht in en overzicht over het gebruik van shared services nodig, maar ook de mindset om met alle stakeholders samen een optimale oplossing te ontwerpen. En als het al moeilijk is om uit het niets een dergelijke architectuur te ontwerpen, dan vereist het veel visie, geduld en doorzettingsvermogen om de stakeholders vanuit een bestaande situatie langzamerhand naar een gewenste situatie toe te leiden.

Requirements In het verlengde van het opstellen van een businessmodel is het vaststellen van gezamenlijke requirements voor gemeenschappelijke services al snel een tour de force. Hoe groter de herbruikbaarheid van een dienst, hoe meer personen


p. 4/15

en partijen betrokken zijn of zich betrokken voelen. Al gauw dreigt een mêlee van conflicterende eisen en wensen, of op zijn minst tegengestelde prioriteiten. ‘Mastering requirements’ is het nieuwe credo. Maar hoe doe je dat? En wie gaat alle stakeholders managen om commitment te creëren voor het gemeenschappelijke programma van eisen en wensen?

Analysis & Design Architecten propageren een losse koppeling om complexiteit te beheersen; sinds de jaren van Edsger Dijkstra is dat een basisregel voor ieder goed ontwerp. Binnen een SOA is er sprake van horizontale ontkoppeling tussen de verschillende toepassingen en services onderling, van verticale ontkoppeling tussen de front-office en de back-office, maar ook nog van een transversale ontkoppeling tussen de applicaties en de onderliggende infrastructuur. Omdat in een SOIL die infrastructuur veelomvattender is dan vroeger gebruikelijk was – en naast zaken als een DBMS en een fileserver tegenwoordig bijvoorbeeld ook een applicatieserver, enterprise-integratie, een workflow engine en enterprise security omvat – is effectieve ontkoppeling een loffelijk maar moeilijk te bereiken streven. Toegegeven, er ontstaan steeds meer standaarden die de architect kan inzetten om de ontkoppeling te bereiken, maar in de praktijk blijkt maar al te vaak dat een verandering in de serviceinfrastructuur toch een risico met zich meebrengt voor de kwaliteit van de geleverde service, hetzij aangaande de stabiliteit, hetzij aangaande de performance, hetzij aangaande de beschikbaarheid. Een goede impactanalyse van veranderingen in gedeelde componenten wordt lastiger naarmate de complexiteit van het SOIL toeneemt en de onderlinge afhankelijkheden toenemen. Toch is dat precies wat een SOA impliceert. Een betrouwbare registratie van de bestaande situatie wordt dan ook steeds onmisbaarder. En die situatie wordt er door de ontkoppeling niet makkelijker op. Immers, door een goede ontkoppeling tussen applicaties en de service-infrastructuur wordt het mogelijk na een initiële deployment allerlei veranderingen door te voeren, zonder dat er sprake is van een herontwerp van applicaties. Beheersorganisaties maken daar ook dankbaar gebruik van, heterogeniteit is immers complexiteit, en complexiteit bedreigt de stabiliteit en is kostbaar. Dus is er een sterke drang om infrastructuur te standaardiseren en van tijd tot tijd op een nieuwere standaard over te gaan. Logisch, toch? Het tekenen van een ontwerp is één ding, het monitoren van een goede uitvoering is iets totaal anders. Vooral wanneer een organisatie ervoor kiest (een deel van) de ontwikkeling en/of het testen te outsourcen, worden architecten gedwongen diep na te denken over manieren om te valideren dat een product voldoet aan het ontwerp. En natuurlijk om zichzelf dusdanige beperkingen op te leggen dat alles wat niet gevalideerd kan worden, ook niet dwingend opgelegd wordt (daar worden specificaties overigens doorgaans beter van, maar dat is weer een heel ander verhaal).

Implementation Vraag een groep cursisten naar een voorbeeld van een ontwerpprincipe, en het adagium ‘buy before build’ – tegenwoordig vaak nog voorafgegaan door ‘reuse before buy’ – is steevast een van de eerste die wordt genoemd. Een SOA heeft vaak mede als doel hergebruik te bevorderen en het inpassen van shelfware te vergemakkelijken. In theorie is dit lang niet zo lastig als in de praktijk. Er zijn een heleboel redenen waarom hergebruik niet populair is. Vaak krijgen de ontwikkelaars de schuld toegeschoven, die zouden onvoldoende vertrouwen hebben in componenten die ze niet zelf hebben bedacht en gemaakt, en daarom altijd wel een reden zoeken om iets wat er eigenlijk al is – of wat er al voor een groot deel is – weer opnieuw te ontwikkelen. Echter, vaak zijn er ook allerlei organisatorische belemmeringen om bestaande code eenvoudig te


p. 5/15

kunnen aanpassen, zaken als eigenaarschap, release management en cost management. Helaas. Maar het lijkt wel alsof er ook nog een ongrijpbare kracht in het geding is. Hergebruik is gewoon niet sexy, het heeft iets van tweedehands kleding of het kopen van een verrassend wrakkige occasion. Gelukkig kunnen we dít met een SOA voor de verandering eens eenvoudig oplossen. Stop gewoon vanaf nu met het gebruik van het woord ‘hergebruik’. Je gebruikt services immers precies waar ze primair voor bedoeld zijn: als generieke softwarediensten die meerdere applicaties of processen ondersteunen. En dat is best wel cool. Trouwens, de ervaring leert ook dat het integreren van bestaande applicaties of services in het SOIL met de nodige teleurstellingen gepaard kan gaan, ongeacht of het gaat om dure producten uit een magisch kwadrant, om open-source producten of om iets ertussenin. Het lijkt wel of je tijdens de productselectie niet achterdochtig genoeg kunt zijn met het specificeren van requirements. Alles wat common sense is binnen een eigen ontwikkelorganisatie blijkt ineens ook anders te kunnen. Integreerbaar met LDAP betekent bepaald niet altijd dat het aansluit op het bestaande LDAP. Win2003-compliant betekent helaas niet dat het op een standaardcluster kan draaien en dat tabelnamen niet hard gecodeerd worden, blijkt ook niet overal gebruikelijk. Overigens, ook omgekeerd komt het voor dat een leverancier er blind van uitgaat dat er in de omgeving een eigentijdse versie van een infrastructurele component wordt gebruikt, bijvoorbeeld om met een recente versie van een XML-standaard te kunnen werken, en blijkt er onverwacht achterstallig onderhoud te bestaan. De meeste planningen houden geen rekening met dat soort tegenslagen, want het product is immers al af, het wordt immers al bij 153 organisaties met succes gebruikt, dus...?

Test Dat testen in een sterk gedistribueerde omgeving verre van triviaal is, is oud nieuws. Het inrichten van een voldoende representatieve en toch betaalbare testomgeving is een continu dilemma. Het op een betrouwbare manier testen van nietfunctionele requirements als performance en stabiliteit valt niet mee, immers, om de werkelijke productiesituatie te simuleren moet een applicatie niet in isolement getest worden, maar in combinatie met allerlei andere applicaties en services die gelijktijdig in gebruik zijn. Alleen dan worden ook gemeenschappelijke componenten als proxies, webservers, applicatieservers en databaseservers meegetest. Helaas is dit makkelijker gezegd dan gedaan, want wat is nou een representatieve load voor een nominaal gebruik van een omvangrijke omgeving? Als applicaties steeds meer ontkoppeld worden van de infrastructuur of het platform waarop ze worden gebruikt, zou het dan niet logisch zijn om ook specifieke testen voor het platform zelf te gebruiken? Zou het niet de moeite waard zijn om een manier te hebben om de kwaliteitsattributen van een versie van het platform te kunnen vergelijken met een nieuwe versie, om een onderbouwd oordeel te kunnen vormen over de wenselijkheid om een nieuwe versie door te voeren? En als we platformupgrades los van releases van applicaties willen kunnen doorvoeren, wat voor eisen stelt dat dan aan de testscripts die we nodig hebben om vast te kunnen stellen dat een applicatie op de nieuwe versie van het platform nog (minstens even) goed werkt? Wie gaat zulke scripts dan maken en onderhouden? Tussen twee haakjes, die automatische testscripts worden steeds ingewikkelder, het zijn zo langzamerhand complete programma’s. Wordt het niet eens tijd dat die ook als software ontworpen, ontwikkeld en getest worden? Dat we ook een QA


p. 6/15

voor het testproces inrichten? Of blijven we achter ‘problemen’ aanjagen die na veel gedoe uiteindelijk veroorzaakt blijken te zijn door een fout in de manier van testen?

Deployment In een ontwikkelomgeving werkt een applicatie al gauw, zeker als het een zelf ontwikkelde applicatie is. Maar het kan wel eens tegenvallen om dat te kunnen reproduceren in een beheerde omgeving. Onvolkomenheden in het platform? Kloppen de meegeleverde scripts wel? Is het een gebrek aan flexibiliteit? Of toch een gebrek in de (documentatie van de) applicatie? Misschien is er gebruikgemaakt van een vanwege het beveiligingsbeleid ongeoorloofde bevoegdheid? Het valt vaak niet mee om dit soort kwesties goed te analyseren. De deskundigheid die vereist is om een deployment tot een goed einde te leiden, is in ieder geval al lang niet meer elementair. En hoe complexer het SOIL wordt, hoe meer het erop gaat lijken dat het integreren van applicaties op het platform een apart specialisme wordt. Sizing & scaling van de productieomgeving, data- en serverconsolidatie, middleware-integratie, er worden steeds gewichtiger ontwerpbeslissingen genomen tijdens (re)deployments. Dit vindt voor een belangrijk deel plaats buiten het zicht van de projectorganisatie en buiten controle van de architect, maar het zijn wel beslissingen die in hoge mate bepalend kunnen zijn voor de beleving, en dus de tevredenheid van de gebruikers. Een applicatie kan nog zo schaalbaar ontworpen zijn, als er niet voldoende of niet tijdig capaciteit wordt ingezet om de belasting van het systeem goed te kunnen opvangen, dan helpt dat niets.

Impact van SOA op beheerprocessen De uitdagingen die het realiseren van een SOA met zich meebrengt, kunnen ook worden geïnventariseerd vanuit het perspectief van de beheerprocessen, bijvoorbeeld volgens de ITIL-indeling. De meest voor de hand liggende processen om aan te denken zijn problem management, configuration management en change & release management. Toch is er ook impact op een aantal meer tactische processen (service control, in ITIL-jargon), met name cost management, capacity management, service level management en security. In een SOIL worden alle bedrijfsapplicaties als het ware enterpriseapplicaties – althans vanuit het perspectief van de tactische beheerprocessen. Gelukkig hebben steeds meer organisaties in de afgelopen jaren ervaring opgedaan met het introduceren van allerlei enterprisesystemen, of het nu om ERP, EAI of om enterprise identity management gaat, ze moeten allemaal vanuit een enterpriseperspectief worden beheerd. Daarom wordt in de volgende paragrafen verder ingezoomd op de service-deliveryprocessen.

Configuration Management Een Configuration Management Database (CMDB) behoort alle relevante gegevens te bevatten die nodig zijn om een omgeving effectief te beheren, bijvoorbeeld door de afhankelijkheden tussen alle elementen in een SOIL goed te kunnen bewaken. Wanneer er sprake is van een diversiteit aan serviceleveranciers, een van de lonkende perspectieven in een SOA, en er dus geen centrale autoriteit meer is die alle wijzigingen in het gehele landschap kan managen, wordt dit lastig te realiseren. Gelukkig kunnen steeds meer configuration items met moderne tools in plaats van handmatig geadministreerd, automatisch en foutloos uitgeleze worden uit de omgeving.


p. 7/15

Problem Management Root cause analysis, het traceren van de oorzaak van problemen, vereist een degelijk feitenonderzoek. In een sterk gedistribueerde, heterogene omgeving valt dat niet mee. Al snel bestaat een keten van componenten die samen een applicatie laten werken uit een tiental schakels. Ga er maar aanstaan om de bron van een fout te vinden. Als het probleem zich in een testomgeving laat reproduceren, is een goed feitenonderzoek al geen sinecure, maar als je het moet doen met de event en exception logs uit de productieomgeving, is een goede interpretatie vaak erg lastig. Hoe onderscheid je oorzaak-engevolgschade? Maar al te vaak verschillen de lezingen van de verschillende deskundigen, al naar gelang hun rol in de organisatie en hun ervaringen uit het verleden. Een ontwikkelaar zal een fout eerder in de infrastructuur zoeken, een system engineer verdenkt vanzelfsprekend als eerste de applicatie. En als er verschillende partijen bij het probleem betrokken zijn, hetzij een externe leverancier van de software, hetzij een externe partij die de applicatie host, dan zijn de sentimenten helemaal moeilijk te beheersen. De problem manager heeft intussen de ondankbare taak op basis van tegenstrijdige adviezen de juiste mensen aan te zetten tot de juiste analyseactiviteiten.

Change en Release Management Beslissingen die aan de hand van een request for change genomen moeten worden, zijn in een sterk geïntegreerde omgeving al snel ontwerpbeslissingen met consequenties die verder reiken dan de aanvrager en die soms de architectuur zelf raken. De vraag wanneer een verandering architecturaal relevant is, kan eigenlijk alleen een architect beantwoorden. Maar al te vaak is die jammer genoeg niet beschikbaar bij de uitvoering van de beheerprocessen. Als de ontwikkelingen meer evolutionair verlopen, zoals je dat op het niveau van het SOIL mag verwachten, is er eigenlijk weinig verschil meer tussen de rol van een Change Advisory Board (CAB) en een Architecture Board. Dezelfde stakeholders praten over vergelijkbare problematiek. Misschien is het een idee om deze organen te integreren? Om de veranderingen in het platform in goede banen te leiden zou ‘het platform’, het geheel van infrastructurele en domeinoverstijgende componenten, ook op basis van incidentele releases in plaats van een voortdurende stroom van configuratiewijzigingen, patches, updates, vervangingen en uitbreidingen onderhouden moeten worden. Waar mogelijk kunnen er meerdere platformreleases tegelijkertijd naast elkaar bestaan, zodat de invoering van een nieuw release geen bigbangoperatie hoeft te zijn. Beperk dit wel tot een werkbaar minimum, anders wordt de heterogeniteit van het platform al snel onbeheersbaar. Het daadwerkelijk uitfaseren van vorige releases is een missie die de beste kans van slagen heeft als de kosten van de heterogeniteit in kaart zijn gebracht er een duidelijke verantwoordelijke is aangewezen om de heterogeniteit te beperken.

Analyse van de impact van SOA op de IT processen Er is een opvallende overeenkomst tussen alle gesignaleerde uitdagingen. Of het nu gaat om requirements, analyse en ontwerp, testen, deployment, problem of change management, in alle gevallen is het onderscheid tussen de projecten de beheerorganisatie aan het vervagen. Niet voor niets zijn de ‘gebruiker’ en de ‘beheerder’ twee van de vier stakeholders die volgens IEEE-1471 in iedere architectuurbeschrijving serieus genomen dienen te worden. Maar ook omgekeerd zou het logisch moeten zijn dat bij beheeractiviteiten die de architectuur raken een architect betrokken wordt. Het testen wordt steeds meer


p. 8/15

een specialisme dat tijdens de gehele levenscyclus van systemen een rol speelt om voortdurend te toetsen of het systeem nog (of, bij het oplossen van problemen, weer) naar behoren functioneert. Deployment was altijd al een grensgebied tussen het project en het beheer; nu het besef groeit dat redeployment een reguliere beheeractiviteit zou moeten zijn, wordt dit nog sterker. Ook problem management was al lang een linking pin, al was het maar omdat de ontwikkelaars een onmiskenbare rol spelen bij de derdelijns support. Het vervagende onderscheid noopt tot een herbezinning op de inrichting van de organisatie. Kennelijk past de traditionele tweedeling in ‘projecten’ en ‘beheer’ niet langer bij de processen zoals die voor een service-oriented architectuur verlopen. Het is misschien verleidelijk beheeractiviteiten dan ook maar projectmatig te organiseren. Dat heeft echter een belangrijk nadeel: projecten hebben een behoorlijke aanlooptijd en een projectorganisatie heeft doorgaans een formeel proces voor resource management ingericht. Dat is ook nodig om het projectportfolio goed te kunnen managen. In beheerland is dat vaak niet te verkopen. Je hebt die ene specialist soms met spoed nodig om, laten we zeggen, een mogelijke oplossing voor een acuut probleem even door te testen. Dat is dan vervelend voor het project, maar wel nodig in het hogere belang van de ITorganisatie als geheel. Een service-oriented IT-organisatie (SOIO) heeft een manier gevonden om uit dit dilemma te geraken. Ik verwacht persoonlijk een ontwikkeling waarbij organisaties joint service teams gaan inrichten die zich bezighouden met én de ontwikkeling én het beheer van een portfolio aan services. Zo’n team zou dan moeten worden aangestuurd door een manager die tegelijkertijd verantwoordelijk is voor de projecten binnen het team en voor de service die door het team wordt geleverd. In het team zit alle expertise die nodig is om projecten met succes te kunnen uitvoeren en om services te beheren. De meeste teamleden zullen een dubbelrol hebben en zich zowel met projecten als beheer bezighouden. Een bijkomend voordeel zou zijn dat niemand binnen het team er nog belang bij heeft om oplossingen te bouwen die het beheer nodeloos verzwaren. Zou dat geen verademing zijn?

Hoe ADP de SOA uitdagingen aangaat Het identificeren van uitdagingen schept ook een zekere verplichting om de weg naar mogelijke oplossingen te schetsen. Op basis van de ervaring die we de afgelopen jaren binnen ADP hebben opgedaan worden de volgende best practices uiteengezet


p. 9/15

Werken onder Architectuur Er is al veel geschreven over het belang van architectuur en het werken onder architectuur. Gelukkig convergeren de ideeën daarover meer en meer. De IEEE-1471 recommended practice (zie figuur 3) heeft daarbij een belangrijke rol gespeeld. Hierin wordt de definitie van architectuur naast een model van een architectuurbeschrijving gezet. Het model nodigt uit tot werken onder architectuur: het identificeren van alle relevante stakeholders van een systeem, hun concerns, en actief aan de gang gaan met het adresseren van die zorgen en verantwoordelijkheden. Een architectuurbeschrijving is van nature heel doelgericht, namelijk op het bereiken van afstemming met alle relevante stakeholders. En om een goede beschrijving te kunnen maken voor een specifieke (groep van) stakeholder(s) zal een architect zich terdege moeten inleven in de wereld van de betrokkenen. Bij ADP werken we met een verzameling library viewpoints die uit een eenvoudig model is voortgekomen. Door op de ene as de levenscyclus van een systeem uit te zetten, en op de andere as de vraag- en de aanbodkant, zijn de stakeholders eenvoudig te classificeren. Klanten worden bediend in een customer view, gebruikers in een user view, ontwikkelaars in een development view, testers in een test view en beheerder in een service management view. Werkend met zo’n model hebben we ervaren dat er ook stakeholders zijn die tussen vraag- en aanbod in zitten. Met name die partijen die kijken naar het systeem in zijn omgeving –denk bijvoorbeeld aan de inbedding in de enterprisearchitectuur of aan het altijd heikele onderwerp beveiliging– komen in de eerder genoemde views onvoldoende tot hun recht. Vandaar dat we nu ook een interaction view en een deployment view onderkennen. Verder hebben we ervoor gekozen om de directie van de IT organisatie die wij zelf zijn te bedienen in een business view. Die term is bewust gekozen. Wij vinden dat een IT organisatie zakelijk moet kijken naar het ontwikkelen en exploiteren van IT systemen – wat is de impact op de bestaande organisatie, hoe sluit het aan op de bestaande processen, wat zijn de risico’s en de kansen voor het commerciële succes. Inderdaad, een business case maakt bij ons onderdeel uit van een business view, en daarmee van een architectuurdossier. Ook dat is niet toevallig: alle ontwerpbeslissingen die in de loop van de tijd genomen worden die de business case kunnen beïnvloeden worden door de architect niet alleen in de development en test view, maar ook in de business view verwerkt. Het voortschrijdende inzicht dat soms tot kort-door-de-bocht ‘oplossingen’ leidde, kan op die manier wat evenwichtiger beoordeeld worden. Tenslotte onderkennen we nog de “Common View”, waarin de highlights van een ontwerp worden vastgelegd op een manier die voor alle betrokkenen toegankelijk is.


p. 10/15

Mission fulfills 1..*

Influences Environment

has an System

Architecture

Inhabits has 1..*

is important to 1..*

has 1..*

Stakeholder

identifies 1..*

Architectural Description

is adressed to 1..*

used to cover 1..*

Viewpoint

has source 0..1 Library Viewpoint

provides

Rationale

participates in

identifies 1..* selects 1..*

Concern

described by 1

Combines to

is organized by 1..* View

participates in 1..*

consists of 1..*

establishes methods for 1..*

aggregates 1..*

Model

“Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”

Figuur 3: Het IEEE-1471 model voor architectuurbeschrijvingen Het architectuurdossier zoals wij dat nu kennen, bevordert de betrokkenheid van de architect vanaf het eerste idee tot en met de inbeheername van een systeem. Het werken onder architectuur, waarin de architect een centrale rol speelt bij alle wezenlijke ontwerpbeslissingen, krijgt daarmee ook concreet gestalte. Het is steeds de architect die – in nauwe afstemming met alle relevante stakeholders – vormgeeft aan het succes van het systeem. Het feit dat ADP Business Solutions met name samenwerking tussen marktpartijen ondersteunt, heeft geleid tot een speciale manier waarop wij de businessarchitectuur aanpakken. De ervaring heeft ons geleerd dat een community erg moeizaam van de grond komt als er één marktpartij domineert. Daarom is het van belang dat zo’n samenwerking ook in organisatorische zin wordt vormgegeven. In concreto proberen we ervoor te zorgen dat de partijen samen een vereniging of een stichting in het leven roepen die het gemeenschappelijke belang dient. Het zou aanbeveling kunnen verdienen als shared service centers binnen bedrijven ook zouden streven naar een orgaan van afnemers dat verantwoordelijk wordt gesteld voor de beslissingen die alle partijen aangaan.


p. 11/15

Om de enterprisearchitectuur in kaart te brengen en de views voor een nieuw systeem snel invulling te kunnen geven, hebben wij het ArchiMate-gedachtegoed geadopteerd. Dit sluit nauw aan bij de IEEE-1471 recommended practice en bevordert de consistentie tussen verschillende views. ArchiMate streeft geen vervanging van bedrijfsmodellen, UML-modellen, datamodellen of netwerkmodellen na, maar richt zich juist op het bieden van overzicht door modellen te maken die als het ware als een paraplu over de bestaande detailmodellen heen liggen. Gelukkig is er tegenwoordig prima tooling op de markt om het analyse- en ontwerpwerk te ondersteunen. Het werken onder architectuur gaat met dit soort hulpmiddelen niet ten koste van de doorlooptijd van projecten; verschillende oplossingsscenario’s kunnen snel worden ontworpen en – waar nodig – weer aangepast.

Figuur 3: De Standaard Views in het ADP Architectuur Dossier Samenwerken in een Competence Center We hebben binnen ADP een competence center ingericht waarin we verschillende experts uit de applicatie- en de infrastructuurwereld, maar ook uit de projecten de beheerorganisatie, samengebracht hebben. Het geheim van het competence center is de gezamenlijke inzet, vanuit een gemeenschappelijk gevoelde verantwoordelijkheid, om de lastigste problemen voortvarend aan te pakken en om preventieve maatregelen te nemen om de vitaliteit van het platform op peil te houden – en daar waar mogelijk verder te verbeteren. Doordat een teamgevoel is gecreëerd waar partijen in het verleden tegenover elkaar stonden, is de dynamiek van het SOIL merkbaar toegenomen; de time-to-market voor nieuwe diensten is verkort en de oplostijd van problemen is aanzienlijk afgenomen. Deze investering in samenwerking heeft zijn geld dan ook ruimschoots opgebracht. Binnen het competence center krijgt momenteel een nieuw initiatief vorm. Een vast team gaat als Transition Support Group met de projecten meelopen om in een vroegtijdig stadium al mogelijke risico’s bij de integratie met het platform te


p. 12/15

identificeren en te helpen oplossen. Vooral in projecten waarbij het ontwikkelwerk wordt uitbesteed, verwachten we dat dit leidt tot een betere beheersing van de risico’s en dus tot een veel soepelere overdracht. Het competence center vormt op deze manier de kristallisatiekern die hopelijk op termijn uitgroeit tot een volwaardige service-oriented IT-organisatie.

Service Management Improvement We zijn voortdurend bezig met het verbeteren van de beheerprocessen. Alle onderdelen van ons SOIL zijn gegroepeerd in service-elementen. Er is een speciale service-elementbeheerder aangesteld die als eigenaar van het platform verantwoordelijk is gesteld voor de vitaliteit ervan. In het onderhoud aan het platform wordt net zo goed voorzien als dat voor alle andere service-elementen gebeurt; dit wordt vanzelfsprekend in releases uitgevoerd. Om onderhoud aan het platform te kunnen uitvoeren wordt van alle andere service-elementbeheerders verwacht dat er testscripts zijn waarmee geautomatiseerd kan worden vastgesteld wat het effect van een nieuw release op hun service-element is. De testsuite van de firma Mercury biedt daarbij goede diensten. Het analyseren van problemen in een gedistribueerde omgeving is van origine een onvoorspelbaar en lastig te managen proces. Juist omdat inzicht in de bron van de problemen ontbreekt, is het inschatten van de oplostijd een bijkans ondoenlijke zaak. Gelukkig zijn er leveranciers die dit hebben ingezien en die ondersteunende hulpmiddelen bieden. Wij zijn erg onder de indruk van het product AppSight van Identify Software. Dit is gebouwd rondom de metafoor van een zwarte doos in een vliegtuig. Een flight data recorder neemt tijdens de vlucht alle relevante vluchtgegevens op om, mochten er zich problemen voordoen, achteraf snel te kunnen reproduceren wat er aan de hand is geweest. AppSight biedt iets soortgelijks: vanuit alle systemen in het gehele landschap worden gegevens in een centraal log opgeslagen voor latere analyse. Het maakt niet uit of dit om een testomgeving of een productieomgeving gaat. Het knappe van het product is dat er geen wijzigingen aan de applicaties nodig zijn en dat de impact op de systemen minimaal is. Het inzicht dat met dit hulpmiddel ontstaat in de verwerking van gebeurtenissen door de hele keten in het landschap, is niet alleen onthullend, het maakt het identificeren van de problemen ook veel eenvoudiger. Het is niet langer nodig om op het gevoel van de expert te vertrouwen, de bewijzen hoe het echt is gegaan zijn voorhanden. De waarde van dergelijke bewijsmiddelen is evident: door meteen de juiste specialisten op het goede spoor aan het werk te zetten, is er veel sneller een oplossing. Immers, door zowel discussies over de juiste aanpak overbodig te maken als door het uitwerken van verkeerde oplossingsscenario’s te vermijden, wordt veel tijdverlies voorkomen. Het probleemanalyseproces is daarmee een stuk beheersbaarder geworden. Een ontwikkeling van geheel andere aard is service level monitoring. Gegeven de complexiteit van het gehele landschap voldoet het niet langer om garanties af te geven en te rapporteren over de beschikbaarheid of de performance van een enkele component. Omdat beheerders traditioneel juist verantwoordelijk zijn voor het beheer van zo’n component, kan het lastig zijn performance en beschikbaarheid van een hele keten van componenten die samen de gebruikerservaring bepalen te meten. Toch is het van belang om verantwoording af te leggen over (en te sturen op) de service levels die gebruikers ervaren. Er komen steeds meer producten op de markt die de gebruikerservaring kunnen meten en daarover


p. 13/15

objectieve cijfers rapporteren. Wij hebben gekozen voor het Business Activity Center van de firma Mercury, mede omdat de ervaring die we al met de testsuite van Mercury hebben daarbij goed van pas komt.

Tenslotte Een transitie naar een Service-Oriented Architectuur is geen sprint, maar een marathon met hindernissen. Uithoudingsvermogen is dan ook essentieel. Op weg naar de realisatie van een SOA zijn veel obstakels te overwinnen. Moderne tooling zoals BPM, ESB, BiZZdesign Architect en AppSight, bieden daarbij hulp, maar het adagium ‘a fool with a

tool is still a fool’ moet ook hierbij wel in gedachten worden gehouden. Met andere woorden, voor het succes van een SOA zijn hoog-gekwalificeerde medewerkers, van architect tot en met beheerder, een nog belangrijkere voorwaarde dan de tooling die zij gebruiken. Dit artikel is geen pleidooi om terug te gaan naar de oude praktijk van eilandoplossingen. Geenszins! Het is wel een oproep om de uitdagingen die gepaard gaan met de implementatie van een Service-Oriented Architectuur serieus te nemen. De meeste uitdagingen zijn goed oplosbaar, mits de juiste organisatorische maatregelen genomen worden. Een Service-Oriented IT organisatie is ingericht op de specifieke eisen die het ontwikkelen en beheren van een Service-Oriented IT Landschap met zich meebrengt. Dat dit in de gemiddelde SOA roadmap wellicht nog onderbelicht is gebleven zou geen reden mogen zijn om negatief te oordelen over het SOA gedachtegoed. Want vooruitgang bereikt u niet door vast te houden aan oude gewoonten.

Hans Bot is als Service Architect bij ADP Business Services, pionier op het gebied van web services en service-oriented architectuur, dagelijks bezig met het optimaal laten werken en uitbouwen van een servicoriented architectuur voor business-to-business toepassingen. Daarnaast doceert hij masterclasses op het gebied van Architectuur en Enterprise Integratie bij CIBIT. Hij is bereikbaar via [email protected].


p. 14/15

Aanbevolen bronnen Internet Identify Software – AppSight

http://www.identify.com/solutions/solutions.php

IBM Rational Unified Process

http://www-306.ibm.com/software/awdtools/rup/workbench/

ITIL

http://www.itil.org.uk/

BiZZdesign Architect

http://www.bizzdesign.nl/html/bizzdesignarchitect.html

CBDI Forum

http://www.cbdiforum.com/index.php3

IEEE-1471

http://www.enterprise-architecture.info/EA_Standards.htm

ArchiMate

http://www.telin.nl/projecthome.cfm?id=48&language=nl

Business Availability Center

http://www.mercury.com/us/products/business-availability-center/

Boeken Philippe Kruchten: The Rational Unified Process – An Introduction. Addison Wesley, 1999. David Linthicum: Next Generation Application Integration: From Simple Information to Web Services. Addison Wesley, 2003 David A. Chappell: Enterprise Service Bus. O'Reilly, 2004.

Artikel Richard Veryard: Towards a Service-Oriented Organization – Understanding, Planning, and Managing the

Organizational Change Implicit in Service Oriented Architecture. CBDI Journal, January 2004. Dit artikel is één van de weinige bronnen waarin op een toegankelijke manier de impact van SOA op de business architectuur wordt beschreven. Het centrale thema is “Separation of Concerns”, ook zo’n behartenswaardige SOA best practice.


ADP Business Services ADP Business Services maakt onderdeel uit van het Amerikaanse Automatic Data Processing Inc. ADP is met 500.000 klanten een van de grootste bedrijven ter wereld die zich bezighoudt met geautomatiseerde transactieverwerking, datacommunicatie en informatiediensten. Salarisverwerking, aangifte loonbelasting en Human Resource Management; Effecten transactieverwerking en communicatiediensten naar investeerders; Branchespecifieke computer- en consultancydiensten voor autodealers; Geautomatiseerde berekening van reparatiekosten bij autoschade, voorraadbeheer van auto-onderdelen en verificatie van letselclaims; Procesoptimalisatie door het gebruik van webservices voor communities en individuele klanten. Employer Services, Brokerage Services, Dealer Services en Claims Services zijn de vier grootste business units van ADP. Gezamenlijk vertegenwoordigen deze business units bijna 95% van de omzet en vormen ze de strategische kernactiviteiten van onze groei in de toekomst.

p. 15/15

SOA van Ontwerp naar een Effectief Service-Oriented IT Landschap

Recommend Documents