Service oriëntatie is in wezen een oud principe, maar doordat grote spelers als IBM, Microsoft, Sun en anderen de afgelopen jaren afspraken hebben gemaakt over de communicatie tussen hun verschillende platformen kunnen nu organisatiebreed heel gemakkelijk berichten uitgewisseld worden.
Waar gaat het eigenlijk om bij service oriëntatie?
Service oriëntatie is in wezen een oud principe. Kijk eens naar een groot bedrijf of een grote organisatie uit de tijd van voor de automatisering. Een organisatie waar zaken worden gedaan. Het functioneert. Geen computers. Hoe werkte dat?
Het werkte omdat er papier rondging, er waren processen. Er was goed gedefinieerd wat er op een formulier moest staan en voor wie het bestemd was. Het was goed gedefinieerd hoe de berichtkanalen waren, direct of via de interne post. Was dit efficiënt? Natuurlijk niet.
Neem nu dit idee van het rondsturen van berichten, met duidelijke schema’s (dat zijn formulieren ook), en bouw op deze manier systemen. Als je kijkt naar de taken in een organisatie, dan kunnen die worden uitgevoerd door mensen of door machines. Machines zijn goed in de deterministische taken, het toepassen van eenduidige regels of berekeningen. De machines ontvangen berichten en reageren daarop door ze af te handelen en weer andere berichten uit te sturen. Mensen zijn beter in de non-deterministische taken, bijvoorbeeld beslissingen waarbij het onderbuikgevoel een rol speelt. Maar ook zij reageren op binnenkomende berichten, handelen deze af en sturen weer andere berichten uit.
Dit is naar mijn mening wat het concept van service oriëntatie inhoudt.
Als het zo oud is, waarom is SOA dan nu in de mode geraakt? De grote spelers als IBM, Microsoft, Sun en anderen hebben de afgelopen jaren afspraken gemaakt over de communicatie tussen hun verschillende platformen. Dat heeft tot gevolg dat de er nu, organisatiebreed, heel gemakkelijk berichten uitgewisseld kunnen worden, een voorwaarde voor SOA. Door het ontbreken van die standaarden was dat voorheen veel te problematisch.
Wat gaat er mis? De afgelopen decennia zijn applicaties gebouwd met eigenlijk als basis gedachte om zoveel mogelijk onder eigen controle te hebben. De processen zijn gecentraliseerd in applicaties en silo's. Dit big-brother denken zit er diep in. Het zogenaamde service-enablen van bestaande applicaties door het aanbieden van een nieuwerwetse, gestandaardiseerde interface doet hier niets aan af.
Bij service oriëntatie zijn de processen juist niet-centraal, de processen bestaan omdat de spelers, die zijn verspreid door de organisatie, precies dat doen wat ze moeten doen. Het gaat bij service oriëntatie in wezen om vertrouwen durven te hebben in de spelers. In mens én machine.
In mijn optiek draait het bij de implementatie van SOA’s niet méér om vertrouwen dan in de traditionele applicatie silo’s (zoals beschreven in het artikel) het geval is. Ook bij laatstgenoemde hebben klant en leverancier te zoeken naar de juiste balans tussen contractuele vastlegging en vertrouwen. Het verschil zit hem met name in het aantal partijen waarmee afspraken gemaakt moeten worden en waartussen vertrouwen gecreeerd dient te worden. Was traditioneel in het gunstigste geval sprake van een één op één relatie, bij een SOA architectuur zijn veel meer partijen betrokken. Werken op basis van vertrouwen wordt dan ineens een stuk aantrekkelijker, omdat anders wel heel veel (contractuele) afspraken gemaakt, gemeten en gerapporteerd moeten worden. Om te kunnen bouwen op vertrouwen zijn echter wel een aantal randvoorwaarden zoals wederzijds begrip en goed verwachtingenmanagement nodig. Veelal een taak van de service manager; ik ben erg benieuwd of er al service managers zijn die hier ervaring mee hebben?