SOA niet gebaat bij improvisatie

Service oriented architecture (soa) staat volop in de belangstelling. In projecten wordt steeds meer ervaring opgedaan, maar er is vaak nog geen ingebedde methodische aanpak. De tijd is daarom rijp om het implementeren wat professioneler aan te pakken, door methoden te ontwikkelen op basis van ervaringen en best practices.

Bij soa-projecten ontbreekt nog vaak een methodische aanpak. We gaan hier in op methodische manieren om services te identificeren. Onze stelling is dat langdurige discussies over granulariteit, ‘fingerspitzengefühl’ of vakmanschap tot het verleden kunnen behoren. Er zijn nog steeds valkuilen zoals ‘and never the two shall meet services’, ‘perfect non-existing services’ en ‘spaghetti services’ die op het pad liggen naar een succesvolle soa-implementatie. We hebben vanuit onze ervaringen en op basis van recente publicaties geïnventariseerd welke methoden er zijn ontstaan. In dit artikel beschrijven we methode 1 t/m 5 van de top 10 methoden om tot services te komen. In deel 2 komen methoden 6 t/m 10 en de valkuilen aan bod.

Wat is een service?

In een informatievoorziening die volgens service oriented architecture is opgezet, worden de functionaliteit en gegevens van applicaties via services ter beschikking gesteld. Deze services kunnen uniform gedefinieerd worden op basis van internationale standaarden (XML, SOAP, etcetera). De nieuwe integratietechnologie enterprise service bus (esb) zorgt ervoor dat de services overal kunnen worden aangeroepen, ongeacht platform en programmeertaal. Door services in de gewenste volgorde te ‘orkestreren’ kunnen bedrijfsprocessen optimaal worden ondersteund met functionaliteit en gegevens uit alle interne systemen én systemen van partners. Sinds soa en services populair zijn geworden, wordt er gediscussieerd over de vraag hoe services het beste kunnen worden geïdentificeerd. Wanneer is een service ‘te groot’ of ‘te klein’, wanneer is deze ‘te specifiek’ of juist precies ‘goed’? Voordat we ingaan op de meest gebruikte methoden, is het relevant om enkele observaties te maken. Allereerst zijn er algemeen aanvaarde architectuurprincipes voor services die een rol spelen bij het identificeren. In SOA: Principles of Service Design (zie kader) worden er acht genoemd: standardized service contracts, service loose coupling, service abstraction, service reusability, service autonomy, service statelessness, service discoverability en service composability. Kortom, bij het identificeren van een service dient getoetst te worden of de service aan deze principes voldoet.

Ten tweede kunnen services op verschillende manieren worden getypeerd. Een bekende indeling in de typen functionaliteit is: presentatieservices, processervices, business-services, applicatieservices en dataservices (Enterprise SOA, zie kader). Voor elk type service gelden verschillende methoden voor het identificeren. In dit artikel gaan we vooral in op de methoden voor business- en applicatieservices. Ook deze twee typen services kunnen echter nog verder worden getypeerd, zoals raadplegen, selecteren, registreren, muteren, verwijderen, beëindigen, transformeren, genereren, selecteren, waarde, valideren en berekenen (SOA, een praktische leidraad voor invoering: Socrates, zie kader).

Tot slot: wat een goed afgebakende service is, hangt uiteraard ook af van de invalshoek. Zo stelt een beheerder andere eisen dan een procesontwerper of een tester.

De nummering en volgorde van de volgende vijf methoden is geheel willekeurig en zegt dus niets over welke methode het meest in gebruik is of ‘het best is’. In de praktijk zien we meestal combinaties van methoden terugkomen.

Methode 1: Bedrijfsprocessen

Een veelgebruikte aanpak om tot services te komen gaat uit van de bedrijfsprocessen. Het bedrijfsproces wordt in een aantal stappen opgedeeld, van processen via deelprocessen naar activiteiten en taken. Het laagste niveau (taken) bestaat uit kleine samenhangende ‘logical-units-of-work’ (LUW’s). Iedere LUW wordt ondersteund door de functionaliteit die door één service beschikbaar gesteld wordt. De geïdentificeerde services zijn hierdoor sterk door de vraagkant gedreven. Een groot voordeel van deze manier van werken is dat de resulterende services goed aansluiten bij de functionele behoefte. Daarnaast is deze methode erg intuïtief; in vrijwel alle proof-of-concepts maken organisaties gebruik van deze methode om snel tot services te komen. De sterke focus op sturing vanuit de vraagkant heeft ook een nadeel: er kan een (te) grote kloof met de applicaties ontstaan. Ook worden de services erg specifiek voor de activiteiten of taken uit het procesmodel. Daardoor kunnen services lastig opnieuw te gebruiken zijn. De services passen immers precies bij het proces waaruit ze voortgekomen zijn. Het is echter de vraag hoe goed ze andere processen ondersteunen en hoe robuust het totale ontwerp is als het proces gewijzigd wordt. Daarnaast bestaat de kans dat in verschillende activiteiten ongeveer dezelfde functionaliteit gevraagd wordt: ontdubbeling en combinatie van services zal dan ook specifiek aandacht moeten krijgen. Tot slot kunnen services die op deze manier afgeleid worden erg fijnmazig worden, wat hergebruik in in de weg staat.

Methode 2: Functies

Een heikel punt bij het identificeren van services vanuit de bedrijfsprocessen is de sterke koppeling tussen processen en services, waar services juist zouden moeten dienen als ontkoppelvlak tussen bedrijfsproces en informatievoorziening. Een mogelijke oplossing voor dit probleem is om het bedrijfsfunctiemodel als vertrekpunt te nemen. Hiermee wordt geabstraheerd van de inrichting van de bedrijfsprocessen. Analoog aan de bedrijfsprocessenaanpak wordt via een stapsgewijze decompositie toegewerkt naar services: in dit geval worden echter de meest gedetailleerde bedrijfsfuncties in de functionele decompositie vertaald naar services. Deze aanpak is net als de op procesmodellen gebaseerde aanpak erg vraaggedreven, met dezelfde risico’s van dien. Door uit te gaan van de bedrijfsfuncties is het risico dat er services gedefinieerd worden die significante overlap hebben sterk verminderd: in het bedrijfsfunctiemodel zijn de gevolgen van functionele overlap al meegenomen en heeft een ontdubbelingsslag plaatsgevonden.

Een ander voordeel is dat het bedrijfsproces dynamisch is en aan regelmatige wijzigingen onderhevig is, terwijl het functiemodel relatief stabiel is.

Een mogelijke hindernis is dat weinig organisaties een uitgewerkt en bruikbaar bedrijfsfunctiemodel beschikbaar hebben.

Methode 3: Bedrijfsobjecten

Verreweg de meeste services zijn gericht op de verwerking van bedrijfsinformatie. Door de bedrijfsinformatie in een bedrijfsobjectenmodel te modelleren, kunnen de hoog-niveau ‘CRUD’-operaties op de objecten een goed startpunt zijn voor de identificatie van services. Zo’n model heet een canonical data model (cdm), een gemeenschappelijk gegevensmodel van alle informatie die tussen applicaties wordt uitgewisseld. Deze methode is dan ook aanbodgedreven. ‘Canonieke’ services roepen ‘onder water’ applicaties aan die hun eigen gegevensmodellen gebruiken. Om te zorgen voor onderlinge consistentie van de gegevens bestaan er mappings tussen gegevensmodellen op applicatieniveau en het cdm. De concrete gegevens bij één object uit het cdm kunnen dus onderliggend in verschillende applicaties worden bijgehouden. Vrijwel alle esb-producten bieden al ondersteuning voor het opstellen van cdm’s. De echte uitdaging ligt echter in het bereiken van overeenstemming over de precieze definities van de gemeenschappelijke objecten.

Een voordeel van deze methode is dat op voorhand goed nagedacht wordt over de semantiek van services, zodat hier tijdens een productiefase geen discussie meer over ontstaat.

Een gevaar van het gebruik van een bedrijfsobjectenmodel is proberen een volledig corporate data model op te stellen. Hierbij kan een ‘analysis paralysis’ ontstaan, terwijl eigenlijk alleen de bedrijfsobjecten die een rol spelen in de uitwisseling van informatie van belang zijn.

Methode 4: Verantwoordelijkheid

Dit is niet echt een methode, maar wel essentieel voor het maken van keuzes over welke services worden aangeboden. Voor soa is een duidelijke besluitvormingsorganisatie noodzakelijk, met ingerichte rollen en verantwoordelijkheden voor zowel bedrijfsprocessen als voor services (soa governance). Voor het identificeren van services geldt dat de degene die verantwoordelijk is voor het deel van de informatievoorziening dat de betreffende services aanbiedt, bepaalt welke services er worden aangeboden. Daarbij spelen methodische ontwerpaanpakken die de vraag- en aanbodkant analyseren uiteraard een rol, maar ook talloze andere argumenten bepalen de uiteindelijke keuze: ontwikkel- en beheerkosten, lifecycle management van onderliggende applicaties en platformen, prioriteiten, beschikbaarheid van human resources, etcetera.

Het voordeel van deze ‘methode’ is dat het eigenaarschap van services duidelijk is. In andere methoden blijft dit vaak een discussiepunt, omdat eigenaarschap van services ook politiek nogal wat voeten in de aarde kan hebben.

Een nadeel is dat functionaliteit/services uit verschillende domeinen kan overlappen, zodat coördinatie over domeinen heen nodig is. Bovendien is vereist dat de organisatie een ingerichte governancestructuur heeft: een bepaalde mate van volwassenheid die nog niet overal gemeengoed is.

Methode 5: Bestaand aanbod

Een pragmatische manier om snel tot services te komen is het in kaart brengen van de behoefte aan informatie en functionaliteit. De ingang hiervoor zijn de applicaties. Om te beginnen wordt een verzameling applicaties geselecteerd die de bulk van de primaire bedrijfsprocessen ondersteunen. Met tools en wizards die bijna elke programmeertaal en platform kunnen ontsluiten, worden de gebruikte interfaces, api’s, schermen, transacties, queries en tabellen toegankelijk gemaakt via services. Dit ‘service-enablen’ is in essentie aanbodgedreven. De brokken functionaliteit worden geclusterd en ontdubbeld. Vervolgens wordt een optimalisatieslag gedaan waarin vergelijkbare functionaliteit samengevoegd wordt tot een service.

Het voordeel van deze ‘bottom-up’ aanpak is dan ook vooral de snelheid waarmee services gemaakt kunnen worden. De aanpak is geschikt als de functionaliteit van de bestaande applicaties grotendeels voldoet, voor de bestaande en de nieuwe bedrijfsprocessen, en als composite services worden gebruikt om aanvullende bedrijfslogica te implementeren. 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 levert voldoende input voor het ontwerpproces. De wet van behoud van ellende kan echter opgang doen: slecht ontworpen applicaties die hard gekoppeld zijn aan de huidige procesgang maken het ontwerpen van opnieuw te gebruiken services lastig.

Bronnen

• T. Erl, SOA: Principles of Service Design (Prentice Hall PTR, 2007)
• J. McGovern et al, Enterprise Service Oriented Architectures (Springer, 2006)
• D. Krafzig et al, Enterprise SOA (Prentice Hall, 2005)
• A. Ligthart et al, SOA, een praktische leidraad voor invoering: Socrates (SDU, 2005)
• E. Marks en M. Bell, A planning and implementation guide for business and technology (John Wiley & Sons Inc, 2006)