Just Enough Architecture

Een praktische, succesvolle SOA aanpak!

In de afgelopen jaren heeft Inter Access een groot aantal SOA projecten gedaan. Met vallen en opstaan. Ondanks de vele boeken die er in de afgelopen jaren op het gebied van SOA zijn verschenen, is concrete informatie moeilijk te vinden. Het blijft beperkt tot de grote lijnen, of tot een beschrijving van webservices. Bij organisaties die starten met SOA blijkt er bovendien nog een fl inke kloof te overbruggen tussen wat de boeken vertellen en de dagelijkse praktijk. Er is behoefte aan een pragmatische en op de omgeving afgestemde aanpak.

Door het uitvoeren van die projecten zijn we een hoop wijzer geworden. Op grond van die ervaringen hebben we een concrete aanpak opgesteld die vandaag de dag de Inter Access leidraad is bij het uitvoeren van SOA projecten. Deze leidraad willen we graag met jullie delen.

Om te beginnen: wat is SOA nu eigenlijk? SOA staat voor Service Oriented Architecture. Met andere woorden een architectuur gebaseerd op service orientatie. Hmm, dat geeft nog niet veel aanvullende informatie. En wat is dan in dit verband een architectuur? De term komt uit de bouwkunde. Wikipedia zegt er het volgende over: Architectuur is de kunst en wetenschap van het ontwerpen van de gebouwde omgeving.

Onze omgeving is echter niet de bouwkunde; wij houden ons bezig met informatievoorziening in organisaties. Inter Access hanteert daarom de volgende defi nitie voor SOA: Een servicegerichte architectuur (SOA) is een bouwstijl voor het inrichten van de informatievoorziening van een organisatie met behulp van services.

Informatievoorziening wordt hier gebruikt in de breedste zin van het woord: het voorzien van alle processen in de organisatie van de noodzakelijke informatie. Architectuur zien we dan als een set van principes, die vanuit een visie op het te realiseren doel, richting geeft aan het ontwerp en de realisatie. Aardig zo’n defi nitie, maar hoe ga je hiermee nu concreet aan het werk?

Opstellen architectuur

Deze vragen moeten een beeld geven over wat de organisatie doet, in welke omgeving zij opereert, hoe de organisatie haar doelen wil bereiken en waarmee zij dat doet.

Vooral de toekomstverwachtingen zijn hierbij belangrijk, omdat zij richting geven aan de architectuur: ze voorzien in de visie op het te realiseren doel. Zij bepalen tevens welke vrijheidsgraden die in de toekomst van belang zijn: op welke gebieden is flexibiliteit vereist, en in welke mate? Dit heeft een directe weerslag op de inrichting van de informatievoorziening en moet dus in de architectuur worden vastgelegd (o.a. in de set principes). De bedrijfsarchitectuur vormt zo de basis voor de service-architectuur. Belangrijk hierbij is het om zich te realiseren dat er niet iets is als een ‘afgeronde bedrijfsarchitectuur’. Integendeel zelfs! Een organisatie moet beschouwd worden als een levend organisme dat zich voortdurend aanpast aan de veranderende omgeving waarin ze opereert. Dat betekent dat de architectuur steeds bijgesteld moet worden aan de zich wijzigende omstandigheden.

Een ander belangrijk aspect bij het opstellen van de architectuur is: hoe ver ga je? Stelregel daarbij is: doe wat noodzakelijk is, niet meer en niet minder. Veel architectuurprojecten willen niet alleen de volledige breedte afdekken, maar ook de volledige diepte. Dit moet dan leiden tot een volledige blueprint van alle componenten, hun onderlinge relaties en de concrete invulling. Het gevolg hiervan is, dat het architectuurproject zo lang duurt, dat het wordt ingehaald door de werkelijkheid. Wij kiezen ervoor om in een beperkt tijdsbestek van enkele maanden een architectuur in de volle breedte op te stellen, maar met slechts beperkte diepgang. De diepgang kan per onderdeel verschillend zijn, afhankelijk van de onderkende risico’s. We noemen dat ‘Just Enough Architecture’.

Proof-of-Concept

Bij het uitvoeren van de PoC is het ook goed om vooraf de acceptatiecriteria vast te stellen. Dit schept duidelijkheid richting het ontwikkelteam over wat er van hen wordt verwacht.

Herijking architectuur

Opstellen projectkalender

Uitvoeren projecten

Top-down benadering gaat uit van de bedrijfsprocessen. Door deze te modelleren (procesdecompositie) moet duidelijk worden welke bedrijfsfuncties noodzakelijk zijn. Dit zijn dan de zogeheten ‘candidate-services’ die verder uitgewerkt worden tot feitelijke services.

Bottom-up is een benadering die vaak wordt gekozen vanuit de bestaande systemen. Hier worden services onderkend op basis van de in deze systemen aanwezige functionaliteit. Eén van de nadelen van deze werkwijze is dat ze nogal technisch gericht is. De onderkende services hoeven namelijk niet overeen te komen met de door de business gewenste services.

Tijdens de procesanalyse wordt in eerste instantie het proces op hoofdlijnen in kaart gebracht. Dit proces wordt tot werkprocessen uitgewerkt. Een nette decompositie zorgt ervoor dat werkprocessen eenvoudig binnen andere (hoofd)processen kunnen worden ingezet. Voor de werkprocessen wordt bepaald welke gebruikersobjecten benodigd zijn.

Gelijktijdig wordt in de gegevensanalyse bepaald welke gegevens nodig zijn en wat de samenhang van deze gegevens is. Bestaande systemen worden hier veelal als uitgangspunt genomen. Echter, hier valt één ding op. In een SOA project is het niet voldoende om alleen een verticale ontkoppeling te realiseren (process services, business services en domein services), maar ook een horizontale ontkoppeling van de (gegevens) domeinen. Uitgaande van de autonomie en integriteit van services is dat ook een logisch gevolg: hoe kan ik een service autonoom maken als deze niet zijn eigen data kan beheren? Dat betekent dat deze gegevensverzamelingen worden gescheiden in autonome domeinen. Deze domeinen vormen de basis voor domein- of informatiegerelateerde services.

Meet In The Middle

Zo ontstaat een laag van taak- en functiegerelateerde services die aansluit op de daadwerkelijke behoefte in de werkprocessen, waarmee de belofte van business en IT alignment eindelijk wordt waargemaakt.

Op basis van de 15 SOA projecten waarin wij deze werkwijze hebben ontwikkeld, kunnen we concluderen dat we daarmee in staat om SOA projecten snel te starten en grondig uit te voeren, tot voordeel van onze klanten.


Mike van Alst, Architect
Peter Paul van de Beek,
Information Architect