Een service-oriented achitecture (soa)wordt door velen geprezen als dé oplossing om verschillende bedrijfssystemen flexibel via internet of een bedrijfsnetwerk met elkaar te laten communiceren. Het zou voor wereldwijd opererende bedrijven dé oplossing zijn om diensten beschikbaar te maken voor diverse productlijnen en landen. Bedrijven die in soa een efficiënte, kosteneffectieve, allesomvattende oplossing zien voor hun it-infrastructuur kunnen echter van een koude kermis thuiskomen.
Soa is een technische oplossing die maar al te vaak slecht toegepast kan worden op het organisatorisch model van een bedrijf. Niet iedere afdeling gebruikt dezelfde diensten of stelt dezelfde prioriteiten aan een applicatie. Hierdoor ontstaat een situatie waarin vraag, verantwoordelijkheden en geldstromen niet parallel lopen.
Neem bijvoorbeeld een bedrijf waarbij it-budgetten per productlijn of regio worden vastgesteld. Vanuit het centrale kantoor wordt besloten dat de bedrijfsonderdelen in alle landen toegang moeten krijgen tot een dienst om postcodes te valideren. Hoewel de functie voor alle medewerkers noodzakelijk is, heeft niet iedereen dezelfde eisen. Sommige afdelingen hebben er baat bij als de gegevens 24/7 gecontroleerd worden, voor een ander is één keer per dag voldoende. Hierdoor is niet voor iedere budgetverantwoordelijke de gevraagde investering in verhouding met het afnameprofiel.
Beperkingen
Hier wringt duidelijk de schoen. De beperking van soa is voornamelijk gelegen in niet-technische redenen. Veel businessunits willen niet zomaar een oplossing opgedrongen krijgen. Een dienst moet aan bepaalde randvoorwaarden voldoen om als betrouwbare oplossing geaccepteerd te worden. De belangrijkste voorwaarden zijn wel persoonlijke relevantie en risico.
Bedrijfsculturen zijn er op ingesteld dat werknemers afgerekend worden op hun individuele succes. Wanneer een soa-concept bedrijfsbreed geïmplementeerd wordt, is het eigen succes echter niet meer duidelijk te bepalen en zijn werknemers minder bereid kosten of risico's te dragen.
Soa versus eda
Om voordeel te behalen uit een soa zit er een maximum aan de reikwijdte van de soa binnen een onderneming. Soa is alleen effectief als zoveel mogelijk mensen van een dienst gebruik maken. Denk hierbij aan een service die het mogelijk maakt om een e-mailaccount aan te maken. Bij veel huidige bedrijfsmodellen, waar geldstromen en verantwoordelijkheden bepalend zijn voor handelingen en beslissingen, is een event driven architecture (eda) effectiever.
Door de schaalbaarheid van deze architectuur sluit deze beter aan bij de filosofie dat bedrijfsonderdelen hun eigen eisen en budgetten kunnen bepalen. Bedrijven die overwegen een soa te implementeren, zouden daarom beter eerst hun bedrijfsstructuur kunnen reorganiseren en toewerken naar een model waarbij de dienstverlening bepalend is voor de inrichting van de it-infrastructuur.
Ondernemingen die een soa willen implementeren, doen er daarnaast goed aan bestaande grenzen binnen het bedrijf te respecteren. Een landsgrens is hiervoor een redelijke afrastering: door budgetten en beslissingen op landsniveau te bepalen, wordt een afhankelijkheid gecreëerd waarin het mogelijk is een balans te vinden tussen de aanbieders en gebruikers van diensten. Door eenzelfde technologie te kiezen voor eda en soa is het daarna een peulenschil om een soa over alle eda's heen te leggen.
Mengvorm
Er kan geconcludeerd worden dat een eda meer geschikt is voor het coördineren van informatiestromen tussen verschillende domeinen. Een soa kan beter ingezet worden binnen een domein. Voor veel bedrijven zou echter een mengvorm het meest geschikt zijn: een enterprise service bus (esb), beter bekend als MOM. Hierdoor kan een soa eerst geïntroduceerd worden binnen één domein voordat diensten verder uitgebreid worden. Het devies is dan ook: ‘follow the money' bij de keuze voor een soa of eda.
Bert Hooyman, chief architect Europe bij MphasiS
Wij van idainnovatie zijn al langere tijd op de service oriëntatie gaan zitten; het is mede een manier van denken, een manier van “zijn”, een manier van naar de wereld kijken zelfs. We noemen wat we doen de “per”architectuur, vanaf de business doelen, processen, vereisten. Je wilt altijd weten wat de business wil doen: per klant, per dag, per incident, per overschrijding van een norm, per …, per … Vandaar dat begrip “per”architectuur. Je structureert hiermee op meer niveaus van detail tegelijk, en laat dat nu juist heel voor de hand liggend werken ipv. moeilijk. EDA en SOA als ontwerpprincipes vallen hierin samen. Je richt de business hiermee, en deze structuur voor de business is meteen bruikbaar als services-architectuur als je al dan niet je ICT service-georiënteerd wilt inrichten en realiseren.
De optimale business-ict alignment is hiermee binnen bereik gekomen.
Eens met Abraham. Soa is geen 0 of 1. Iets als “een soa implementeren” bestaat in mijn ogen dan ook niet. Denken en ontwikkelen met services kan altijd. Maar wel met gezond verstand op een manier die past bij de omstandigheden waarbinnen je werkt.