Het concept van Service Oriented Architecture is eigenlijk heel eenvoudig: functionele bouwstenen (services) via open standaarden (vooral vanuit de internetwereld) met elkaar laten samenwerken in een bedrijfsproces. Dit klinkt redelijk eenvoudig, maar wat kun je ermee?
De meest voorkomende antwoorden die ik hoor zijn:
1) Kosten besparen op softwareontwikkeling en -beheer, door hergebruik van services.
2) Afnemen of leveren van services buiten de bedrijfsgrenzen.
3) Bedrijfsprocessen flexibel inrichten door deze uit services op te bouwen.
Natuurlijk zijn er meer antwoorden, maar vaak zijn deze afgeleid van bovenstaande. Als je als organisatie overweegt om ‘iets met SOA te gaan doen’, heb je echter weinig aan deze antwoorden. Voeg daaraan toe dat we als IT-industrie een flinke hype en mogelijke verwarring rondom SOA hebben gecreëerd en je hebt een van de oorzaken te pakken achter de nog beperkte adoptie van SOA door klantorganisaties.
Als softwareproducent met als core business het ontwikkelen en verkopen van software, heb je baat bij de vele voordelen van SOA. Het is dan ook niet verassend om te constateren dat de grote softwareproducenten SOA omarmen als architectuur voor hun applicaties. Klantorganisaties hebben echter een andere core business en maken dus ook een andere afweging. Laten we het rijtje eens aflopen:
1) Hergebruik van services: Het ontwikkelen van bouwstenen is nodig om een beheersbare en kwalitatief goede applicatie te realiseren. Het hergebruiken van componenten stamt echter al uit het Cobol-tijdperk en (later) het Component Based Development. De standaarden voor Web Services bieden nu een nieuw recept voor deze componenten. Misschien kun je, dankzij de bredere acceptatie van de onderliggende standaarden, hergebruik meer toepassen. Maar daar krijg je moeilijk een business case mee rond. Zonder twijfel is ‘hergebruiken van services’ dan ook de zwakste argumentatie om met SOA aan de slag te gaan.
2) Afnemen of leveren van services van/aan derden: In potentie kan dit een zeer goede business case opleveren. Kanttekening is wel dat veel bedrijfskritische services op dit moment toch binnen de bedrijfsgrenzen worden gehouden. Dit heeft te maken met de complexiteit, en daarmee risico's, die verbonden zijn aan dit scenario. Denk hierbij aan aspecten als beveiliging, betrouwbaarheid van infrastructuur, afhankelijkheid van derde partijen, gebrek aan kennis en ervaring bij IT-ers. Vaak kiest men dus voor kleinschalige SOA-implementaties, zoals het voorbeeld van een credit check bij een bank op het moment dat je een nieuwe klant vastlegt. Leuk, maar de impact blijft gering.
3) Flexibelere bedrijfsprocessen: u voelt hem al aankomen, dit is wat mij betreft de hoek waar u de échte voordelen moet zoeken. Hier ligt ook de belangrijkste link tussen IT en business. De meeste bedrijfsprocessen worden ondersteund door IT. Het veranderen van bedrijfsprocessen moet dus altijd synchroon plaatsvinden met het aanpassen van de automatisering. De tijd en moeite die hiermee gepaard gaan zijn vaak een argument om slechts met grote intervallen, gemiddeld vijf tot zeven jaar, grote aanpassingen in bedrijfsprocessen door te voeren. Gevolg is dat IT als een rem op verandering wordt ervaren.
Juist hier biedt SOA uitkomst. Door een bedrijfsproces te automatiseren met een aaneenschakeling van services kun je het bedrijfsproces aanpassen zonder impact op de onderliggende applicaties of infrastructuur. Door het wegnemen van die impact neem je ook enkele van de grootste kosten- en tijdsfactoren weg die procesverbetering frustreren.
Er zijn natuurlijk ‘mitsen en maren’, waardoor je meer moet doen dan het ‘sleuren en pleuren’ van services om een nieuw proces te ondersteunen. In mijn volgende bijdrage wil ik graag op een van die aspecten ingaan. Laat u mij weten waar u meer over wilt lezen? Ik dacht aan een van de volgende onderwerpen, maar ik sta ook open voor andere suggesties:
– inpassen van de huidige applicaties
– infrastructuur en tooling
– nieuwe dynamiek in projecten
– de eindgebruiker nieuwe stijl
