Service-oriented intelligentie

Transcriptie

1 evaluatie SOA t Service-oriented intelligentie SOA als oplossing voor problemen op enterpriseschaal Een architectuurstijl zoals SOA is alleen met succes toe te passen als je heel goed weet waarom bepaalde principes worden voorgeschreven en wat voor prijskaartje daaraan hangt. Met andere woorden, als je goed de sterktes én zwaktes kent van SOA in zijn meest rechtlijnige vorm, kun je de stijl ook veel slimmer aanwenden. De auteur gaat in op de problemen waarvoor SOA oplossingen aanreikt en op de oplossingsstrategie. Ook schetst hij problemen die zich kunnen voordoen wanneer SOA te naïef wordt toegepast. Joris Van denstorme Elke architecturale stijl presenteert oplossingen voor de meest prangende problemen van zijn voorgangers en tracht tegelijkertijd de goede dingen van die voorgangers zoveel mogelijk te behouden. Dat laatste is echter lang niet zo evident als het klinkt. Het is immers simpelweg onmogelijk om alle architecturale kwaliteiten die je maar kunt bedenken, te bereiken door op alle fronten voor exact dezelfde oplossingsstrategie te gaan. En dus gebeurt het dat nieuwe oplossingen voor nieuwe problemen oude oplossingen voor andere (oude) problemen onderuithalen. Niks mis mee, zolang die oude problemen niet langer je prioriteit zijn en de nieuwe problemen ook écht jouw problemen zijn. Heel veel mis mee, als dat niet het geval is. Daarom is het erg belangrijk om telkens opnieuw stil te staan bij de obligate waarom doen we dit ook alweer -vraag. Een architectuurstijl is immers een middel en geen doel op zich. Een stijl zoals SOA kun je alleen met succes toepassen als je heel goed weet waarom bepaalde principes worden voorgeschreven en wat voor prijskaartje daaraan hangt. Als je goed de sterktes én de zwaktes kent van de stijl in zijn meest rechtlijnige vorm, kun je hem ook veel beter met succes aanwenden daar waar hij echt relevant is, én de nodige verfijningen of alternatieven inzetten voor de aspecten die bij blind toepassen slechter zouden lopen dan vandaag het geval is. Specifiek SOA: de problemen, de oplossingen en de nieuwe problemen Oké, laten we eens stilstaan bij de problemen waarvoor SOA oplossingen aanreikt, om vervolgens te bekijken wat de oplossingsstrategie juist inhoudt en, last but not least, welke andere problemen er kunnen opduiken door de stijl te naïef toe te passen. Typische problemen die SOA op het gebied van software wil aanpakken, zijn zaken zoals: Slechte beheersbaarheid van de enterprisesoftwareportfolio door: Wildgroei, versnippering en redundantie van functionaliteit en gegevens over vele verschillende brokken software. 14

2 Samenvatting SOA als basis voor een nieuwe architectuur heeft veel te bieden, maar dan gaat het wel om oplossingen voor problemen op enterpriseschaal. De ROI moet je dus ook op grote schaal meten: over voldoende lange tijd en met voldoende grote scope. Verlies intussen de architectuurkwaliteiten die niet specifiek door SOA worden opgelost, niet zomaar uit het oog. SOA moet je vooral op een intelligente manier toepassen, het is geen one size fits all -oplossing. Als gevolg hiervan: onduidelijkheden over ownership, en moeizaam loodgieterijwerk om bestaande softwareoplossingen met elkaar te verbinden of op zijn minst inhoudelijk te synchroniseren. Vendor- en technologie-lock-in: veranderingen van implementatie/technologie die impact hebben vér buiten de module waar men de update voor ogen had, omdat de aangeboden functionaliteit en gegevens niet geëncapsuleerd zijn achter een nette interface met een duidelijk gespecificeerd contract. Arbeidsintensieve deployment van nieuwe versies van softwareonderdelen, omdat het beheer daarvan niet per definitie centraal gebeurt en het daardoor lastig is om te weten wie vandaag met welke versie werkt. Het maar moeizaam kunnen volgen van grote business- of organisationele veranderingen. Moeizame kennisoverdracht bij vertrek van human resources verbonden aan één applicatie, omdat er van alles en nog wat inzit en toch van geen enkel thema alles. Organisch gegroeide applicatiesilo s bieden daardoor weinig flexibiliteit qua inschakelen van resources in het softwareteam met de hoogste nood, omdat de mensen zich telkens tot op implementatieniveau moeten inwerken in een brede waaier van thema s en technieken. En ga zo maar door... Qua problematiek kunnen we de lijn perfect doortrekken naar het SOA-gedachtegoed enkel en alleen op zuiver businessniveau. Hier doen zich immers soortgelijke problemen voor, los van software, als we kijken naar de manier waarop de verschillende bedrijfsprocessen (of de aan de buitenwereld geleverde diensten) ondersteund worden door interne diensten/afdelingen. Sommige bedrijven worstelen inderdaad met: competenties die als je het bedrijfsbreed bekijkt niet optimaal gebundeld zijn; onduidelijke interne afspraken over verantwoordelijkheid en ownership, bijvoorbeeld van bepaalde cruciale gegevens; interne diensten die niet goed op elkaar afgestemd zijn en dus niet optimaal samenwerken; moeite met het verteren van grote marktveranderingen en nieuw aan te bieden producten. Eén ding is echter duidelijk: of je het nu door een IT-, een business- of een gemengde ITbusinessbril bekijkt: SOA richt zich duidelijk op problemen op grote schaal, problemen die zich pas manifesteren na een tijd aanmodderen, die je pas ziet door met een helikopterview naar bijvoorbeeld de IT-investeringen of de werking van bedrijfsdiensten te kijken, en waarvan de pijn pas voelbaar wordt als je een onverwachte grote verandering moet verteren. Dat is waar SOA goed in is, dankzij een slim en doordacht pakket van principes en designrichtlijnen om de bovenstaande problemen het hoofd te bieden. Ook hier geldt de business-en-it-parallel: de problemen zijn in essentie analoog, de oplossingsstrategieën zijn dat dus ook. Typische SOA-oplossingsstrategieën, verpakt als designprincipes, om genoemde problemen het hoofd te bieden zijn: Openlijk gepubliceerde, contractueel vastgelegde afspraken van de aangeboden en gevraagde diensten, ondubbelzinnig uitgedrukt in termen van een al even openlijk gepubliceerde woordenschat (een service-informatiemodel dat ook deel uitmaakt van het contract). Over de interne implementatie dan weer helemaal niets publiceren aan de afnemers van de diensten. Het vastleggen van duidelijke SLA s boven op die contracten, eventueel verschillend per type afnemer. Duidelijkheid over wie eigenaar is van bepaalde gegevens en van bepaalde logica. Denken in termen van briefjes die services naar elkaars postbussen sturen, in plaats van denken in termen van klassieke telefoongesprekken tus- 15

3 evaluatie SOA t sen twee gesprekspartners, die tijdens dat gesprek bezet zijn voor enige andere communicatie, hoe dringend die ook is. Zo n postbussysteem geeft dienstverleners immers de nodige interne autonomie om hun taken af te handelen op zo n manier dat de SLA s het makkelijkst gehaald worden. Het maakt de koppeling tussen de services lager en de bestaande diensten veel makkelijker schaalbaar, dankzij een ingebakken stateless communicatiestijl: je hoeft je het begin van het gesprek niet meer te herinneren: elke zin bevat genoeg context om op zich duidelijk te zijn. So far so good, overal die principes toepassen dus en klaar is Kees. Echter, door de focus op de kwaliteiten die door de bovenstaande strategie worden gepromoot, komen andere onderwerpen er veel bekaaider van af, tenminste, als je de principes op een naïeve, eenheidsworstmanier toepast. Ook dit geldt langs zowel de business- als de IT-kant, maar we focussen ons hier op de softwarekant van SOA. Typische kandidaten voor slechte punten in die context zijn: het snel opleveren van schermen of rapporten met query s over veel services heen; het snel opleveren van (kleine) nieuwe features in software; pure performantie van de opgeleverde applicaties. Die zwaktes zijn niet per definitie problematisch. Je moet er alleen bewust mee omgaan en indien nodig voor een aangepaste oplossingsstrategie gaan. We bespreken de eerste twee problemen uit het bovenstaande rijtje. Terminologie Nog kort even wat terminologie de SOA-wereld is al verwarrend genoeg. Zo n autonome, apart te beheren brok software die via contractueel beschreven interfaces diensten aanbiedt rond één thema en zelf de bijhorende gegevens opslaat en beheert, noem ik hierna softwareservice, bijvoorbeeld de FacturatieService. De concrete instructies of vragen-om-actie die je naar zo n softwareservice kunt sturen, noem ik softwareserviceoperaties, bijvoorbeeld BerekenFactuurVoor- Prestaties of GeefOnbetaaldeFacturen. SOA en snelle query s Als je een SOA-architectuurstijl voldoende breed kunt uitbouwen, wordt data ownership heel expliciet duidelijk. Softwareservices zijn immers zelfstandige stukken software die elk hun eigen pakket informatie beheren (samen met de bijhorende functionaliteit). Als de services volgens de regels van de kunst geïdentificeerd zijn, kun je elk businessconcept waarvoor enige automatisering bestaat, toewijzen aan één en ook slechts één eigenaar -service. Deze categorie van services noemen we een corebusiness-service, om aan te duiden dat die eigenaar en beheerder is van één welbepaald (liefst belangrijk) businessthema. Wie iets wil doen rond of weten over dat thema, vraagt het aan die specifieke service, en aan niemand anders. Als je een canoniek enterprisebreed informatiemodel tekent van alle belangrijke businessbegrippen, kun je eenvoudigweg met kleuren aanduiden welk cluster van bij elkaar horende begrippen door welke corebusiness-softwareservice beheerd wordt. Geen sprake van enige dubbelzinnigheid over informatieownership dus. Voor alle duidelijkheid: dit betekent hoegenaamd niet dat softwareservices altijd hun werk kunnen doen zonder gegevens die ze niet zelf beheren. De nuance hier is dat zulke gegevens worden aangeleverd door andere services, zonder mandaat om ze ook aan te passen. Een voorbeeldje zijn de inputparameters in een message die een concrete dienst (het uitvoeren van een serviceoperatie) aanvraagt. Merk op dat het publieke informatiemodel van een service dient als woordenschat om zijn operatiecontracten ondubbelzinnig te kunnen begrijpen en bewust niets onthult over de manier waarop de gegevens worden opgeslagen. Dat laatste is een interne designkeuzevrijheid, daar hoeft de gebruiker van het servicecontract niets over te weten. Switchen van database vendor of technologie kan dus geruisloos, zolang maar aan het afgesproken contract blijft worden voldaan. De enige manier om gegevens te manipuleren is immers via operaties aangeboden op de interfaces van de service en nooit door rechtstreeks in de database van een collega-service te gaan roeren. Tot zover de theorie, en ook de praktijk, want deze strategie werpt zeker haar vruchten af voor applicaties die vooral draaien rond het inbrengen van nieuwe gegevens en het uitvoeren van berekeningen of manipulaties hierop. Echter, door het probleem van onder andere data ownership op deze manier op te lossen, introduceert SOA op 16

4 een ander vlak een nieuw probleem: plots is het niet meer zo vanzelfsprekend om kort op de bal te spelen als eindgebruikers op hun scherm of in een rapportje de resultaten willen zien van een nieuwe grote query die gebruikmaakt van gegevens waarvan nu verschillende services eigenaar zijn. Vroeger ging je daarvoor gewoon even langs bij de database administrator, die in het beste geval ter plekke een query uit zijn mouw schudde van een aantal tabellen uit de database, en als het er niet te fancy moest uitzien, had je in een mum van tijd je lijstje. Dat was pas agile, niet? Of de datakwaliteit van het lijstje ook goed was en de gegevens ook echt van de juiste authentieke bronnen kwamen, daarover hebben we het natuurlijk niet... Hetzelfde scenario in een SOA-context vraagt schijnbaar oneindig veel meer moeite. Nu is er niet één, maar mogelijk een hele batterij aan databases, die bovendien volgens de regels van het spel geëncapsuleerd zijn in telkens een andere softwareservice. De databases kunnen in principe zelfs van verschillende vendors zijn, en hun schema s zijn niet gepubliceerd aan de buitenwereld, zodat indien nodig het implementatieaspect database kan worden veranderd zonder dat de afnemers die een contract hebben met de softwareservice in kwestie daar ook maar iets van merken. Super, die encapsulatie, maar meteen ook het einde van snel even query en. Er zijn verschillende reacties mogelijk op dit fenomeen: Een eerste mogelijkheid is het probleem te negeren onder het motto dat hoort er nu eenmaal bij. Voor elke query die gegevens combineert uit bijvoorbeeld vijf softwareservices, ga je dan krampachtig streng minstens een vijftal nieuwe kleine get-dit-by-dat-operatietjes definiëren, die elk een stukje van de query realiseren, eventueel zelfs de resultaten vanuit een nieuwe service aggregeren, van elke betrokken service in kwestie een nieuwe release plannen, die testen, deployen et cetera. Het zal wel duidelijk zijn dat je niet diezelfde dag nog je nieuwe rapport zult hebben. En het zal ook wel duidelijk zijn dat de performantie van het geheel niet bepaald flitsend zal zijn, alleen al vanwege het aantal messages dat het netwerk over moet. Als het om grote volumes aan gegevens gaat, kan het ook voor de individuele services een hele uitdaging worden om op dat moment te blijven voldoen aan hun bestaande SLA s voor gewone operationele werking. Een tweede mogelijke reactie is al even slecht: alle SOA-principes overboord gooien en ad hoc rechtstreeks in de databases van de respectievelijke softwareservices gaan snuffelen, voor zover dat technisch kan natuurlijk. Zonder goede governance een erg gevaarlijk precedent, want waarom zou je voor een volgende opdracht niet meteen snel een update en een insert via diezelfde achterpoort doen. Als het snel klaar moet zijn, is dat veel handiger, toch? Hiermee haal je natuurlijk de intrinsieke kracht en zin van een SOA-architectuur volledig onderuit. Mogelijke businesslogicachecks die via normaal gebruik plaatsvinden voordat de gegevens echt de database bereiken, kunnen hier schaamteloos worden omzeild, om maar een voorbeeld te noemen. Gelukkig er is een derde, elegante oplossing die tegemoetkomt aan de nood, maar tegelijkertijd niet de andere verwezenlijkingen onderuithaalt: ingewikkelde en/of realtime query s steeds aanbieden via een aparte specifieke softwareservice, die in feite de functie van datawarehouse vervult (en waarbij implementatie via aangekochte datawarehousetechnologie dan ook een van de keuzes is). Is oplossing 3 daardoor dan slechte SOA? Nee, integendeel: het is slim toegepaste SOA. Het inzetten van een dergelijke datawarehouse-softwareservice botst met geen enkele van de SOAbasisprincipes, zolang deze service maar geen interfaces aanbiedt die ook toelaten om de brongegevens te wijzigen. Het datawarehouse vervult perfect de rol van een softwareservice, maar dan niet een uit de categorie corebusiness-services; het is eerder een utility-service: eentje die op zich geen puur businessequivalent heeft. Hij is geen eigenaar van de gegevens in kwestie, maar bevat enkel read-only kopietjes van gegevens die eigendom zijn van andere services. Hij kiest er intern voor om die gegevens op te slaan op een manier die het best uitkomt om aan zijn SLA s voor snelle query s en mogelijk grote volumes te voldoen, namelijk al een beetje voorgekauwd en niet per se genormaliseerd (bijvoorbeeld via een sterschema). Hij geeft nochtans niet zomaar per definitie al zijn implementatiegeheimen prijs, maar heeft zijn eigen interfaces via welke je met hem kunt praten, telkens in termen van een weliswaar specifiek maar publiek informatiemodel, en als dit publieke logische model hier hetzelfde is als een view op de interne fysieke opslagstructuur, is dat een bewuste designkeuze. Zijn contracten met afnemers houden in dat query s bijvoorbeeld via SQL of MDX 1 kunnen worden verwerkt, in beide gevallen uitgedrukt in termen van dat informatiemodel. Typische afnemers zijn bijvoorbeeld reportingservices 1. MDX staat voor MultiDimensional expressions en is een querytaal voor OLAP (On Line Analytical Processing)- databases, net zoals SQL een querytaal is voor relationele databases. 17

5 evaluatie SOA t die de datewarehouseservice gebruiken en hiermee mooie rapporten genereren, of BI-tools om fancy dashboards te tonen en businessconclusies uit de gegevens te trekken. Hoe zit het met de aanvoer van gegevens naar zo n datawarehouseservice, verloopt die wel volgens SOA-normen? Ook hier is het antwoord ja: zo n datawarehouse-utility-service heeft evengoed echte contracten met de leveranciers van de gegevens, via zijn required interface(s). Ook hier geldt evengoed dat deze slim moeten worden opgezet, zonder daardoor dirty te gaan. Een waaier aan mechanismen is mogelijk, afhankelijk van de opgelegde SLA s (hoe vers moeten de gegevens zijn?): informatie kan gepusht of gepulled worden, bijvoorbeeld via ETL-jobs, maar ook met publish- en subscribe-mechanismen voor events die uitgaan van de corebusiness-services om het datawarehouse op de hoogte te stellen van een nieuw gegeven. Even terug naar het voorbeeld van daarstraks: in plaats van de query op te knippen in vijf of meer kleine stukjes, kan hij in één keer worden uitgevoerd op de datawarehouse-utility-service, zonder hierdoor het ownership onderuit te halen, aan SLA s die veel hogere snelheid bieden dan oplossing 1 (query opsplitsen in een opeenvolging van kleine operaties), maar in ruil daarvoor ingebakken toegevingen bevatten naar de versheid van de gegevens toe. Het is een win-winsituatie: de SOA-architectuur zelf overwint een potentieel performantie- en agilityprobleem en de opzet van een datawarehouse verloopt veel makkelijker als er een volwassen set van corebusiness-services aanwezig is, vanwege het intrinsiek aanwezige canonieke informatiemodel en het ondubbelzinnige ownership van elk element daarin. SOA en het snel opleveren van functionele veranderingen Grotendeels hetzelfde scenario lijkt zich af te spelen als je kijkt naar een dringende vraag naar een nieuwe functionaliteit in een of andere applicatie. Het hoeft dus niet om data te gaan. Al is het hier wat subtieler. Er zit natuurlijk een intrinsiek stuk vertraging in de SOA-opzet op zich: onder andere door het strenge expliciete ownership moet je de functionaliteit die je quick and dirty in één stuk code zou kunnen stoppen, verdelen over de rechtmatige eigenaars en zorgen dat die eigenaars de juiste boodschappen naar elkaar sturen. Bij een compleet nieuwe feature die allerhande manipulaties uitvoert binnen één thema, zal dit nauwelijks tot vertraging leiden omdat alles in dezelfde doos terechtkomt. Maar bij een feature die bijvoorbeeld functionaliteit en gegevens combineert uit drie thema s, moet je met drie partijen gaan onderhandelen over eventueel nieuw toe te voegen zaken en die moeten contractueel worden vastgelegd en geïmplementeerd. Intrinsiek meer werk dus, al hangt hier ook veel af van de granulariteit van de gekozen services: SOA werkt handiger met weinig en grote services dan met heel veel en kleine services. Net in die intrinsieke vertraging door het werk over verschillende services te moeten verdelen, schuilt ook de grootste opportuniteit: naarmate je SOA-architectuur volwassener wordt, neemt ook de kans toe dat een of meer bouwsteentjes van wat je nodig hebt al blijken te bestaan, én eveneens dat je ze erg makkelijk kunt vinden. Bij een volwassen SOA kun je er immers niet naast kijken: alles rond thema X zit netjes in softwareservice X en nergens anders, ver hoef je dus niet te zoeken. Maar dat terugverdieneffect speelt pas na een paar jaar investeren in het opzetten en uitbouwen van de corebusiness-softwareservices van een bedrijf. Maak je dus zeker geen illusies over de opleversnelheid van nieuwe applicaties bij het begin van een SOA-programma: in het begin zal alles trager gaan. De redenen liggen voor de hand: In den beginne was er niets : bij de eerste volledig uit softwareservices opgetrokken applicaties is de kans erg klein dat je meteen zaken kunt hergebruiken. Bij SOA komt sowieso meer administratie kijken door het denken in termen van contracten. Last but not least, er is een niet te onderschatten leercurve door te maken in servicegeoriënteerd denken, voor alle betrokkenen, van zuiver business tot heel technisch. Quick wins komen er zo goed als zeker, maar pas voor softwareprojecten die starten binnen bijvoorbeeld twee jaar Dat is het vervelende aan SOA: om er iets aan te hebben moet je het altijd op grote schaal bekijken, zowel in de tijd als in volume. Je moet met je servicecatalogus vrij breed gaan in 18

6 Figuur 1. SOA en snelle query s. Door het invoeren van een specifieke softwareservice die de functie van datawarehouse vervult (rechts onderaan), lopen brede query s voor rapporten of dashboardschermen een stuk vlotter, zonder daarbij te zondigen tegen SOA-basisprincipes. scope, én de tijd kunnen nemen om te bouwen aan een basisaanbod van services voordat je kunt genieten van de voordelen. De veranderingen waartegen je je via SOA beter wapent, zijn immers ook de grote veranderingen, zoals nieuwe producten, veranderende markten en interne reorganisaties, en niet zozeer de kleine individuele veranderingen van bestaande applicaties. De positieve kant is dan wel weer dat de ROI op grote schaal bekeken ook groot is, maar je moet wel met een helikopterview kijken om die te zien. SOA maakt de onderneming in haar geheel veel wendbaarder, maar niet de individuele applicatietrajecten (tenzij dankzij hergebruik dan). Een typisch menselijk probleem dat hier speelt, is het subtiele samenspel tussen het eigen belang (lees: softwareprojectbelang) en het algemene (lees: enterprisearchitectuur) belang. Quick and dirty levert nu eenmaal veel sneller meer waarde op voor je eigen project, maar hypothekeert collega-projecten zowel nu als later en zorgt op grotere schaal voor suboptimale investeringen. Er bestaat namelijk het risico dat telkens opnieuw varianten op hetzelfde thema worden ontwikkeld, waardoor de totale kosten een stuk hoger kunnen uitkomen dan wanneer het één keer centraal beheerd echt goed wordt gedaan. Maar leg dat maar eens uit aan je ongeduldige projectsponsor die gewoon snel een applicatie wil. Om uit die blokkerende situatie te geraken is het cruciaal om bewust veel tijd te investeren in het verkrijgen van echte buy-in van het hoogste management. Je kunt niet zinvol aan SOA doen zonder enterprisebreed te denken en dus ook door een enterprisebrede bril naar het kostenplaatje te kijken. Wil je van het uitrollen van een SOA een succes maken, dan moeten álle betrokken partijen heel goed de vraag waarom doen we dit eigenlijk? begrijpen én ondersteunen. Opdrachtgevers en sponsors van nieuwe applicaties, of van veranderingen in bestaande applicaties, moeten op een open manier antwoord krijgen op de vraag waarom het nu iets langer duurt en waarom er zoveel partijen bij betrokken zijn. Maar zodra er eens tijdwinst geboekt wordt door hergebruik, zelfs al gaat het maar om een kleine applicatie, vergeet dan vooral niet om hier volop mee uit te pakken naar al wie het horen wil! 19

7 evaluatie SOA t Zo n draagvlak creëren in je organisatie doe je niet in één dag! Change management en een zorgvuldig uitgestippelde roadmap zijn hiervoor belangrijke elementen. Een big bang -benadering, met alle daaraan gekoppelde verwachtingspatronen, is voor SOA dus géén goede strategie. Nee, ga dan liever stap voor stap te werk, kies je stappen in functie van een bepaald doel en speel in het begin van een SOA-programma dus niet op de verwachting om sneller applicaties op te leveren dankzij quick wins door hergebruik. Stel, het is voor de business in een bepaald geval cruciaal om een heel korte time-to-market te hebben en jij bent bezig met de uitbouw van een SOA-programma dat nog niet volwassen genoeg is om te renderen. Wees dan niet te beroerd om bewust voor een wegwerp-, quick and dirty applicatie(tje) te gaan, terwijl je daarnaast strategisch verder bouwt aan de toekomstige SOAarchitectuur, met inbegrip van ondersteuning van die nieuwe dringende vraag. Eén gigantisch belangrijke randvoorwaarde hierbij: maak glasheldere afspraken en werp dat applicatietje dan ook echt weg. Spreek de vervaldatum (en dus opleverdatum van een betere oplossing) op voorhand af en trap niet in de val om dat wegwerpproduct toch organisch verder uit te bouwen. Dat laatste klinkt veel gemakkelijker dan het in praktijk is... Een andere evidente best practice is: bouw geen services voor thema s die intrinsiek toch nooit van enig SOA-voordeel kunnen profiteren omdat ze geen corebusiness zijn of omdat je geen voordeel haalt uit centraal beheer ervan. Het is een groot misverstand dat zomaar alles per se een service zou moeten worden: Zo zou het een dwaas idee zijn om te investeren in een bedrijfsbrede spellingcontroleservice, centraal beheerd en uitgevoerd op één server tenzij je firma natuurlijk woordenboeken uitgeeft en in zijn organisatie een spellingcompetence-center heeft dat core diensten levert aan collega s of klanten. Terug naar de probleemstelling: stel, je SOA is al geen onvolwassen beginsel meer en je bent over het ergste stuk van de leercurve heen. Hoe kun je dan in een SOA toch behoorlijk agile opleveren? Het is immers absoluut niet waar dat SOA en het agile ontwikkelen van applicaties niet mooi samen kunnen gaan. Je moet een beetje aan agility inboeten ten opzichte van een extreem agile aanpak, maar dat is geen excuus om domweg voor een ouderwets (en al even extreem) watervaltraject te gaan, met alle bijbehorende nadelen. Net als bij het probleem van SOA en snelle query s komt het erop aan om je slim te organiseren, zodat de essentie van de SOA-principes overeind blijft, samen met de essentie van (in dit geval) agile ontwikkelen. Zo zegt geen enkel SOA-principe dat je contracten eerst volledig moet specificeren en tot in de puntjes documenteren voordat je kunt beginnen met code schrijven. Oké, je doet wat extra denkwerk, maar niemand heeft ooit gezegd dat je de administratie daarvan volledig van tevoren moet doen. Op het moment van oplevering van een sprint (korte iteratie) moet die contractdocumentatie wél klaarstaan, dat is de enige extra beperking. Zorg er daarom voor dat iemand in je team de rol van contractendocumenteerder op zich neemt. Dat is vaak een natuurlijke rol voor een analist/designer of architect, iemand die zich van nature graag met die materie bezighoudt en typisch in de eerste helft van een sprint samen met de ontwikkelaars high-level designs tekent, en naar het einde toe zorgt voor nette contractdocumentatie, parallel met het ontwikkelen. Een andere slimme zet: besteed bij de start van het project gerust een sprint (of meer zelfs) aan het high-level design van je applicatie, zodat je met een redelijke zekerheid weet welke softwareservices erbij betrokken zullen zijn en hoe de architectuur van je applicatie er grofweg gaat uitzien. Is dat slechte agile development? Nee, wat je in zo n sprint oplevert is erg waardevol: een test van je architectuur, verstopt achter een niemendalletje aan functionaliteit. Waarom zou je niet bewust pas na zo n vroege fase een moment inbouwen waarop je je projectteam pas definitief samenstelt, met leden die telkens in een andere sofwareservice thuis zijn. Als er moet worden onderhandeld met de eigenaar van de ser- 20

8 »SOA is geen one size fits all -strategie«vices, kan dat alvast zo efficiënt mogelijk gebeuren door iemand die de service ook vanbinnen kent en dus zowel het algemene belang als het projectbelang goed kan inschatten. En voor de mensen afkomstig uit dedicated serviceteams is het ook leuk om eens aan wat kruisbestuiving te doen in een applicatiedeliveryproject. SOA en agile development kunnen dus wel degelijk in een win-winconfiguratie samen: de SOAinsteek geeft meer duurzaamheid aan de agile ontwikkelde software, en de agile aanpak zorgt ervoor dat je snel van eventuele foute designbeslissingen kunt leren en dus kunt bijsturen. Tot slot Een service-oriented softwarearchitectuur biedt krachtige oplossingen voor softwareproblemen op enterpriseschaal. De ROI moet je dus ook op grote schaal meten: over voldoende lange tijd en met voldoende grote scope. Bij het toepassen van SOA-principes moet je architectuurkwaliteiten die niet specifiek door SOA worden opgelost, niet zomaar uit het oog verliezen en per geval bekijken met welke oplossingsstrategie je de gewenste mix van architectuurkwaliteiten kunt bereiken, zonder ad hoc de SOA-principes overboord te gooien. Slim toepassen dus, geen one size fits all -strategie. Zo zijn er met reden verschillende categorieën softwareservices, met andere designs en andere bestaansreden, andere implementatiestrategieën en ook andere manieren om ingezet te worden in een applicatie. Een softwareservice specifiek bedoeld om tegemoet te komen aan een vraag naar brede en snelle query s is daar een mooi voorbeeld van. Een ander voorbeeld van het naïef toepassen van SOA is om het zomaar te koppelen aan een klassieke watervalmethode, die de intrinsieke vertraging door het contractdenken nog veel verder uitvergroot. SOA is een architectuurstijl, geen projectmethodologie, en kan perfect samengaan met agile development, zij het alweer slim toegepast en in een niet-extreme vorm die voldoende inspeelt op de behoefte aan agility op kleine schaal, zonder de agility op grote schaal waar SOA per definitie goed in is, daardoor onderuit te halen. Bovendien, een oplossingsstrategie zoals de SOAarchitectuurstijl is geen doel op zich, maar een middel. Dat betekent ook dat je stukken software die totaal geen fit vertonen met de problemen die je met SOA wilt oplossen, niet dwangmatig tot service moet bombarderen. Een herbruikbaar componentje mag dus rustig een herbruikbaar componentje blijven als het niet om een corebusinessthema gaat met behoefte aan centraal beheer. Joris Van denstorme is principal consultant applicatiearchitectuur bij AE ( joris.vandenstorme@ae.be. 21