Het eind van het jaar komt snel dichterbij. Dit jaar hebben we veel aandacht besteed aan soa. Deze architecturele benadering zou de oplossing voor al onze problemen zijn. Zoals gewoonlijk bleek dit niet het geval en hebben we alleen nieuwe problemen geïntroduceerd. Kennis rond een nieuwe technologie moest worden verkregen, nieuwe benaderingen werden bedacht en iedereen had wel een powerpack om klanten te overtuigen om vooral met hen soa aan te pakken. Vervolgens voegen we nog nieuwe architecturele benaderingen toe: event driven en model driven architecture. Wat is er nu werkelijk nieuw?
Er is veel beweging geweest rond soa, in elk geval via deze opiniepagina van Computable. Veel aspecten zijn de revue gepasseerd en ook nieuwe uitdagingen zijn toegevoegd. Zijn er nu ook veranderingen geweest in bedrijfsvoering door soa te gebruiken? Om deze vraag te beantwoorden moeten we terug naar het wezen van dienstverlening, waar soa een technische invulling aan kan bieden.
Dienstverlening gaat over het verschaffen van diensten aan een ieder die daaraan behoefte heeft. Dit kan volgens een aloude economisch theorie van Williamson (1974) in twee uitersten vorm krijgen: vaste contracten met afnemers of per transactie een relatie tussen leverancier en afnemer. Deze transactiekostentheorie heeft alles te maken met de kosten van een individuele transactie en om van leverancier te wisselen. De kosten van individuele transacties nemen sterk af door gebruik van nieuwe technologie. Dit zou betekenen dat afnemers ook sneller de neiging hebben om te 'shoppen'. Als nu leveranciers gelijksoortige technologie gebruiken, soa conform open standaarden met identieke semantische begrippen, dan kan dit ook. Het andere kostencomponent, ook wel switching costs genoemd, is afhankelijk van de waarde van een dienst voor een afnemer. Naarmate deze waarde groter is, zal de neiging ontstaan om niet van dienstverlener te wisselen. Een andere aspect van switching costs heeft te maken met de afhankelijkheid van technische koppelingen: open standaarden met semantisch gelijke begrippen zijn hier van groot belang.
Wat betekent dit nu voor service-orientatie? Semantiek en open standaarden spelen een belangrijke rol om switching kosten te verlagen en dus transactionele relaties aan te gaan. Een tweede aspect bij dienstverlening is de samenhang tussen interacties, de zogenaamde orchestratie. Een transactie voor een dienst bestaat bijvoorbeeld uit aanvraag van een offerte, offerte, opdracht en factuur. Complexiteit wordt toegevoegd door annulering toe te staan en een offerte te laten volgen in een bijgestelde offertevraag. Elke interactie of samenhangende interacties zijn te vertalen naar webservices conform soa. Aan de andere kant kun je een interactie ook beschouwen als een 'event' dat een proces start, bijvoorbeeld om een offerte uit te brengen. Ontvangst van een event 'offerteaanvraag' kan verschillende interne services opstarten, bijvoorbeeld om te controleren of de klant al bekend is, het betalingsgedrag van de klant te controleren, etc. Deze interne services zijn met een intern (BPEL-) proces te modelleren, terwijl de services de verschillende achterliggende systemen benaderen. Als het event 'offerteaanvraag' is beantwoord met een 'offerte', zal vervolgens een timer worden ingesteld om te wachten op een opdracht of een afwijzing van de offerte. Ook deze samenhang is in een proces te vangen. Een afnemer kan dan nog besluiten om te wachten op deze offerte (synchrone processen) of ondertussen andere processen uit te voeren en de offerte te verwerken als die binnenkomt (asynchrone processen).
Dit is niet anders dan in het verleden. Wat we met nieuwe architecturen hebben gedaan is interacties als events beschouwen en functionaliteit uit achterliggende systemen in een proceslaag vatten. Deze verandering zal waarschijnlijk ook in het nieuwe jaar doorgaan, maar er komen weer nieuwe uitdagingen bij. Hoe past een dienstverlener zijn diensten optimaal aan klantwensen aan? Is dit wel nodig of hebben potentiële klanten voldoende kennis om hun eigen diensten samen te stellen ('empowered users')? Kan een dienstverlener klantspecifieke diensten leveren en voor die diensten dynamisch de processen modelleren? Op welke wijze weet een afnemer welke dienstverlener ook daadwerkelijk levert conform aangegeven afspraken? Dynamsiche service compositie en procesorchestratie met trust vormen twee belangrijke uitdagingen voor de komende periode.
