De valkuilen bij SOA

Het identificeren van services voor een service oriented architecture is van groot belang voor het functioneren ervan. Het is hierbij belangrijk om systematisch te werk te gaan. In dit artikel bieden de auteurs hiervoor de helpende hand.

In deel 1 van dit artikel hebben we vijf methoden gepresenteerd om tot services te komen. In dit deel zijn methode 6 tot en met 10 en valkuilen als ‘and never the two shall meet services’, ‘perfect non-existing services’ en ‘spaghetti services’ aan de beurt.

Methode 6 t/m 10

Methode 6: Doelen
Deze methode gaat uit van een decompositie van de bedrijfsdoelen tot het niveau van een service is bereikt. Een service wordt hierbij gezien als een doelstelling die geautomatiseerd uit te voeren is. Een doelstelling ‘het behouden van klanten’ kan bijvoorbeeld resulteren in een service ‘registratie klant voor vaste-klantenprogramma’.
Het voordeel van deze methode is de sterke relatie tussen services en de bedrijfsstrategie.
Er zijn echter twee duidelijke nadelen, namelijk: doelstellingen zijn subjectief en veel ict-functionaliteit is niet direct aan een bedrijfsdoelstelling te koppelen. Door de subjectieve inslag kan het zijn dat voor twee doelstellingen een aparte service wordt geïdentificeerd, terwijl de gewenste functionaliteit voor de twee doelstellingen hetzelfde kan zijn (en dus dezelfde service gebruikt had kunnen worden). Hierdoor bestaat het gevaar dat services dubbel geïdentificeerd worden. Omdat veel ict-functionaliteit niet direct aan een bedrijfsdoelstelling te koppelen is, bestaat daarnaast het gevaar dat een hoop services over het hoofd gezien worden.

Methode 7: Componenten
De kerngedachte achter het gebruik van componenten is het opdelen van ict-functionaliteit in brokken met intern maximale samenhang en onderling zo min mogelijk afhankelijkheden. Componenten zijn echte ‘self-contained’ stukken functionaliteit. Diverse methoden om deze componenten te identificeren zijn al voorgesteld in de wereld van component based development, waarbij altijd voorop staat dat elke component één eigenaar heeft en dat de verantwoordelijkheid van elke component zo scherp mogelijk moet worden gedefinieerd. Bij het identificeren van de services van een component kan de gedefinieerde verantwoordelijkheid als uitgangspunt dienen.
Component based development leidt in principe tot een functioneel net ingerichte ict-omgeving. Componenten kunnen zelf gebouwd worden of off-the-shelf ingekocht worden. Een nadeel van deze methode is dat het applicatielandschap van organisaties in werkelijkheid niet geheel componentgebaseerd is opgezet. Bovendien zal er vaak de noodzaak zijn tot het samenstellen van services van componenten tot composite services. Er is een tendens van leveranciers van grote softwaresystemen (bijvoorbeeld erp-systemen) om de systemen steeds meer modulair op te zetten en te ontsluiten via services, waarbij deze modules min of meer overeenkomen met componenten. De richting die Oracle ingeslagen is met Fusion is hiervan een goed voorbeeld.

Methode 8: Gebruiksanalyse front-office applicaties
Een pragmatische manier om snel tot services te komen, is het in kaart brengen van de huidige behoefte aan informatie en functionaliteit. De ingang hiervoor wordt gevormd door de bestaande applicaties. Om te beginnen wordt een verzameling applicaties geselecteerd die gezamenlijk de bulk van de primaire bedrijfsprocessen ondersteunen. Door te inventariseren welke queries en transacties/operaties door de bestaande applicaties gedaan worden, ontstaat een beeld van de functionaliteit zoals die door de bestaande backoffice-applicaties aangeboden wordt. De brokken functionaliteit worden geclusterd en ontdubbeld. Vervolgens wordt een optimalisatieslag gedaan waarin vergelijkbare functionaliteit samengevoegd wordt tot een service.
Een voordeel van deze aanpak is dat op deze manier snel resultaten te bereiken zijn. In feite wordt via de bril van de applicaties naar het bedrijfsfunctiemodel gekeken: de gevonden services zijn daarom (mits goed geclusterd en samengevoegd) goed herbruikbaar. Een prettige bijkomstigheid is dat deze aanpak toegepast kan worden in een context waar weinig bruikbare proces- of functiemodellen beschikbaar zijn: de kennis van beheerders en de inhoud van geautomatiseerde tools (beheer, architectuur) levert voldoende input voor het ontwerpproces. De wet van behoud van ellende kan echter opgang doen: slecht ontworpen en veelvuldig verbouwde applicaties die hard gekoppeld zijn aan de huidige procesgang, maken het ontwerpen van herbruikbare services lastig.

Methode 9: Infrastructuur
Deze methode gaat er van uit dat services niet in alle gevallen onafhankelijk van de gebruikte technische infrastructuur geïdentificeerd kunnen worden. Weliswaar is platformonafhankelijk een algemeen aanvaard architectuurprincipe voor services, maar vooral de composite services vragen extra aandacht. Hoe ‘handig’ is het als een (functioneel onderkende) composite service een tweetal applicatieservices samenstelt die op verschillende platformen draaien, bijvoorbeeld op zowel een mainframe als een Unix-machine? Denk daarbij aan de connectiviteit, aan het uitvoeren en eventueel moeten terugdraaien van transacties, aan verschillen in uptime, aan security en monitoring, netwerkverkeer, etcetera. Let wel, bijna altijd is het technisch wel mogelijk en zijn er (binnen enterprise service bussen) voorzieningen te treffen voor de genoemde punten, maar de vraag is of deze kosten-batenafweging altijd positief uitvalt. Ook de non-functional requirements spelen hierbij een rol (zie methode 10). In essentie raakt deze methode de vraag in welke mate software platformonafhankelijk kan worden gebouwd.
Over de voordelen van deze methode zijn we snel uitgesproken. Dit is een methode die alleen toegepast wordt indien deze uit nood geboren is. Serviceoriëntatie heeft als uitgangspunt dat de onderliggende applicatielaag niet meer zichtbaar is, laat staan de infrastructuurlaag!

Methode 10: Non-functional requirements
Deze methode gaat uit van een afbakening van services op basis van niet-functionele eisen. Het is niet zozeer een methode, maar een aantal technieken die werken als aanvulling op andere methoden. Wanneer op basis van een van de andere service-identificatiemethoden een eerste slag is gemaakt in de identificatie van de services, toetst de (toekomstig) aanbieder van de service de haalbaarheid van de niet-functionele eisen van de (toekomstige) afnemer(s). Wanneer één of meer niet-functionele eisen voor een bepaalde service niet haalbaar blijken en qua belang zwaarder wegen dan de ontwerpprincipes uit de gebruikte methode, dan kan dit leiden tot een herinrichting van de services.
Twee bekende niet-functionele eisen die een rol kunnen spelen zijn security en performance. Ter illustratie: om een service S in te kunnen vullen, is functionaliteit nodig uit applicaties A en B. Als applicatie A wel aan de security-eisen voldoet waaraan service S moet voldoen en applicatie B niet, dan kan het zinvol zijn service S te splitsen in 1 secure en 1 unsecure service. Of: wanneer een organisatie ervoor kiest soa met web services/soap te implementeren, kan blijken dat voor sommige services de performance-eisen niet gehaald kunnen worden. Keuzes die hierbij gemaakt kunnen worden zijn bijvoorbeeld het samenvoegen van services (zodat minder communicatie met de esb noodzakelijk is) of het afwijken van de web services-standaard voor de betreffende service.
Overigens, als performance-overwegingen leiden tot een noodzaak voor aanpassing van een groot deel van de services, dan is het zeker nog te analyseren of de huidige ict-architectuur wel geschikt is voor het werken met services c.q. of soa wel een geschikte architectuurstijl is voor dit deel van de informatievoorziening.

Valkuilen

Op de weg naar een goed portfolio aan services liggen vele valkuilen. Een valkuil waar veel organisaties instappen is ‘services in name only’. De termen soa en service worden te pas en te onpas gebruikt, maar wanneer het op implementatie aankomt krijgen de programmeurs het voor het zeggen. Zij maken een hele set (meestal technisch gerichte) web services waarbij niet gedacht is aan business/it alignment, herbruikbaarheid of alle andere eigenschappen waar een service aan zou moeten voldoen. Een ander uiterste ligt in de ‘perfect non-existing services’: architecten hebben prachtige services geïdentificeerd, maar deze zijn met geen mogelijkheid, of alleen tegen hoge kosten, te implementeren. Een populaire valkuil is ook het alleen vanuit de business of alleen vanuit de techniek werken. We spreken dan ook wel over ‘and never the two shall meet services’. Wanneer organisaties geen canonical data model in gebruik hebben en dus de semantiek van services niet helder is, zien we zogenaamde ‘babel services’ ontstaan: services die niet dezelfde taal spreken. Of services kunnen op verschillende granulariteitsniveaus gedefinieerd zijn met technische terminologie en business-terminologie door elkaar: de ‘spaghetti services’.

Een belang punt om in ogenschouw te nemen is dat soa geen haarlemmerolie is voor flexibiliteit. Denk goed na hoe de services stabiel ontworpen kunnen worden en hoe de orkestratielaag gebruikt kan worden om services in veranderde contexten aan te roepen. Wat voorkomen dient te worden is continu veranderende service interfaces; de zogenaamde ‘never ending service changes’. Met al deze valkuilen blijkt wel hoe lastig het is om een goede set aan services te identificeren en stapt een architect mogelijk in de valkuil van de ‘analysis paralysis’; het blijven zitten aan de ontwerptafel, waardoor het traject uiteindelijk meer kost dan oplevert.

Samenvatting

We hebben 10 methoden beschreven, maar dit zijn zeker niet de enige methoden. De vraag is daarom wat we hieruit kunnen leren. Is het vakgebied nog niet ver genoeg ontwikkeld waardoor er nog te veel varianten bestaan? Is er wellicht geen eenduidige methodische manier om tot services te komen? Of is het ‘fingerspitzengefühl’ waarin een architect op basis van zijn kennis en ervaring komt tot services wellicht zo gek nog niet? In onze visie is enige vorm van systematisch werken zeker nodig om bijvoorbeeld het werk tussen architecten te kunnen verdelen en te traceren waarom sommige beslissingen zijn genomen. Geen enkele methode is op dit moment echter compleet. Dus aan u de vraag wat de voorkeur heeft: een incomplete methode of geen methode?

Jan-Willem Hubbers, Art Ligthart, Linda Terlouw, Solution architecten bij Ordina