SOA en middleware kunnen weliswaar heel nuttig zijn, maar zijn lang niet altijd het ei van Columbus. Integendeel: vele ict-managers hebben zich danig in de architectuur verslikt, zeker in de tijd dat het nog een hype was.

Handwerk is passé

Eerst het goede nieuws: SOA en de bijbehorende middleware heeft een grote vlucht genomen als het gaat om implementatie. “Technisch gaat het niet meer zo vaak fout”, zegt Martin van den Berg, docent bij de opleiding Masterclass Architectuur aan opleidingsinstituut Pro Education. Daarnaast is hij enterprise-architect bij dienstverlener Sogeti.

“Eerst moest je zelf al die aansluitingen inrichten tussen de services en de applicaties. Nu kun je met zogenaamde adapters werken.” Dat was voorheen anders. “Ik ken een heel groot bedrijf dat als een van de eersten een middleware-oplossing gekocht heeft. Ze hebben er vervolgens voor miljoenen aan moeten verspijkeren voor het deed wat ze wilden. Nu kun je dat allemaal standaard kopen.”

Ook Marc Lankhorst, principal researcher enterprise architecture bij Novay en bestuurslid van het Nederlands Architectuur Forum, ziet dat de wereld van SOA en middleware een stuk volwassener is geworden. “Er is inmiddels een behoorlijke ervaring opgebouwd door organisaties”, zegt hij.

Toch kan het nog altijd flink misgaan. Lankhorst en Van den Berg noemen een paar van de valkuilen.

Te veel ict, te weinig zakelijk

“Het service-denken gaat verder dan alleen it”, zegt Lankhorst. “Het moet ook voor de business een bepaalde betekenis hebben.”

Waar het misgaat, is vaak bij de financiering. “Het is een beetje te vergelijken met een Betuwelijn: je gaat iets duurs aanleggen, zonder dat je weet wat je wilt”, zegt Van den Berg. “Opeens kom je dan op het idee 'verdomd, dan moeten we onze applicaties ook aanpassen.' Als je als SOA-architect met een nieuw budgetvoorstel naar je directeur stapt, dan vraagt hij zich terecht af waar je in godesnaam mee bezig bent.” In plaats van dat de pijpleiding water of gas transporteert, transporteert het geld. Direct naar de goot.

Lankhorst heeft bij verschillende organisaties gezien dat ze bij het implementeren van een SOA direct de hele infrastructuur naar de nieuwe architectuur om willen zetten. “Je hebt bedrijven die even denken hun hele organisatie te 'ver-servicen'.” Dat is niet verstandig. “Je kunt beter in een hoekje beginnen en laten zien dat het werkt”, aldus Lankhorst. Anders wordt het te complex, duurt het te lang en is het uiteindelijk te duur. “Ik ken horrorstories van grote banken die tientallen miljoenen uitgaven aan SOA-projecten die om deze reden mislukten”, zegt Lankhorst.

“Het service-denken begint met de vraag wat de klant eraan heeft. Dat is echt een businessvraagstuk”, zegt Lankhorst. “Als je alleen maar vanuit de techniek denkt, dan kom je vaak niet uit bij wat de klant nodig heeft. Dan start je aan de verkeerde kant.”

Te kleine services, slecht herbruikbaar

Volgens Lankhorst wordt nogal eens de fout gemaakt dat services te specifiek worden ingericht. Dat druist niet alleen in tegen het 'flexibiliteitsprincipe' van zo'n omgeving. “De granulariteit is dan niet goed. Heel wat bedrijven zijn, zeker in het begin, behoorlijk nat gegaan omdat ze wel een hele berg services hebben gebouwd, maar deze niet geïntegreerd kregen.”

“Even een hypothetisch voorbeeld: je zou een service kunnen bouwen die alleen de straatnaam van het adres van iemand opvraagt. Daar heb je niets aan, want je wilt normaal gesproken het complete adres van iemand hebben”, zegt Lankhorst. “Dat heeft twee nadelen. Ten eerste heeft de business niets aan die service zelf en kun je deze niet hergebruiken, omdat hij dan gecombineerd moet worden met services die de data compleet maken. En ten tweede verhoog je het aantal service calls, wat voor prestatieproblemen kan zorgen.”

De belofte van SOA is juist dat services goed herbruikbaar zijn zodat je dingen niet twee keer hoeft te bouwen. Door je services te klein of te specifiek te maken, zo stelt Lankhorst, is van die belofte weinig meer over. “Ik kom nog steeds services tegen die toch wel heel specifiek zijn en eigenlijk alleen gebouwd zijn omdat van de architecten alles via de Enterprise Service Bus moet. Dan heb je er niet zoveel voordeel van.”

Te batch-georiënteerd

Lang niet alle applicaties zijn geschikt om als een SOA te worden ingericht, vervolgt Lankhorst. Vooral applicaties die grote pieken in het gebruik hebben, moet je niet met een SOA-architectuur willen doen. “Bij een sterk batch-georiënteerde applicatie, waarbij een grote hoeveelheid gegevens in één keer moet worden verwerkt, is het nog maar de vraag of een SOA goed werkt.”

Als voorbeeld noemt Lankhorst de Belastingdienst. “Iedereen doet op één moment in het jaar aangifte. Als je zo’n batch in één keer wilt verwerken, brengt het gebruik van een heleboel verschillende service calls voor iedere individuele belastingsplichtige mogelijk performanceproblemen met zich mee.”

Daarnaast moet je volgens Van den Berg goed verplaatsen in het gedrag van eindgebruikers. Soms doen ze iets langer over het opgeven van bepaalde data. “Je krijgt dan dat er een keten van allerlei acties wordt uitgezet. Als daar onvoldoende rekening mee wordt gehouden, dan kan de actie een timeout krijgen en de applicatie eruit knallen. Dan moet alles worden teruggedraaid, en de vraag is of dat goed gaat.” Hij vergelijkt het met een online creditcard-betaling. “Wanneer de gebruiker iets moet opzoeken en daardoor treuzelt, kan een time-out ervoor zorgen dat de gebruiker niet weet of hij nou betaald heeft of niet.”

Slechte documentatie

Ontwikkelaars zijn geen gedachtenlezers. Als je als bedrijf services gaat toepassen en wilt hergebruiken, dan moet je er ook voor zorgen dat je developers de services kunnen vinden én dat ze direct kunnen opzoeken wat die services doen. “Nog steeds zijn er bedrijven die een hele rits services bouwen, en ervan uitgaan dat de ontwikkelaars ze vanzelf wel vinden en gaan gebruiken”, zegt Lankhorst.

“Je moet een soort van marktplaats in je eigen organisatie hebben om de services zichtbaar te maken.” De ontwikkelaars kunnen een SOA namelijk maken of breken. “Je moet er echt voor zorgen dat het voor de ontwikkelaars loont om gebruik te maken van de services”, benadrukt Lankhorst.