Service-oriëntatie is een benadering waarbij gedacht wordt in termen van diensten die partijen uitwisselen. In een wereld waarin samenwerking alsmaar belangrijker wordt, kan service-georiënteerd denken en doen nog bruikbaarder worden dan het altijd al was.
In ict-kringen wil de afkorting SOA (Service Oriënted Architecture) nog wel eens werken als de spreekwoordelijke rode lap op een stier: het is luchtfietserij van ivoren toren-architecten (‘SOA-klutsers’), die in de praktijk vooral leidt tot dure en onbeheersbare spaghetti. Om misverstanden te voorkomen: onder de vlag van ‘we doen SOA’ is het inderdaad prima mogelijk om er een puinhoop van te maken. Maar is dat niet iets dat voor iedere benadering geldt?
Diensten
Wat maakt dan dat ik, na meer dan 25 jaar ervaring met projecten waarbij it een rol speelt, service-oriëntatie zie als de geschiktste manier om veel veranderuitdagingen aan te gaan? Voor een deel zit hem dat in het ogenschijnlijk simpele begrip ‘dienst’. Iedereen weet immers wat diensten zijn. De hele dag door hebben we er mee te maken. Van de wekker die ’s ochtends zijn rinkeldienst levert, tot de cateraar die de lunch verzorgt, tot Netflix, die ’s avonds de volgende aflevering van Suits levert. Naast dienstenafnemer, ben je ondertussen ook nog eens doorlopend leverancier van diensten. Bijvoorbeeld wanneer je op aanvraag een product levert of simpelweg wanneer je voor collega’s koffie haalt.
Niks bijzonders dus, diensten. Toch blijkt het opzetten van een dienstenbril bij complexe veranderprocessen heel nuttig te kunnen zijn. De ene keer om te snappen hoe een systeem werkt, de andere keer om te bepalen hoe een systeem het beste met collega-systemen kan gaan samenwerken. Waarbij je ‘systeem’ in de ruimste zin van het woord mag lezen.
Helaas wordt het begrip ‘service-oriëntatie’ vaak beperkt tot de inzet van technologie. Bijvoorbeeld wanneer het gaat om de inzet van een enterprise servicebus of het gebruik van webservices. Dat mag uiteraard, maar het is goed te bedenken dat het slechts een stukje van de werkelijkheid is waar het dienstenmodel bruikbaar is. Ook een bedrijf, of een groep van bedrijven, is bijvoorbeeld te zien als een systeem. Eentje dat zijn bestaansrecht zelfs ontleent aan het leveren van diensten (waarbij it overigens steeds vaker een rol speelt, dat dan weer wel).
Werken aan samenwerken
Om maximale resultaten te bereiken wordt service-oriëntatie toegepast binnen verschillende bedrijfsdomeinen. Binnen ieder domein zijn afspraken nodig over te leveren diensten en de voorwaarden waaronder dit gebeurt. Afhankelijk van het domein zijn er andere uitvoerders bij betrokken en verschilt de aard van de afspraken. Het doel is in de kern echter vaak hetzelfde: het mogelijk maken van goede samenwerking tussen partijen.
Juist dat aspect, het ondersteunen van samenwerking, maakt dat service-oriëntatie voor mij als benadering waardevoller is dan ooit tevoren. Want alles zelf willen doen, is tegenwoordig steeds minder een optie. Niet voor bedrijven, niet voor bedrijfsprocessen en niet voor applicaties. Samenwerken is daarmee nauwelijks nog een keuze, maar eerder een noodzaak om te overleven.
In de praktijk blijkt samenwerken, zowel bij mensen als bij softwaresystemen, veel lastiger te zijn dan het aanvankelijk vaak lijkt. De uitdagingen die er bij horen. worden helaas niet opgelost door service-georiënteerd naar de wereld te gaan kijken. Maar het helpt wel om meer helderheid te creëren en stelt je daarmee in staat om te zorgen dat aan essentiële randvoorwaarden is voldaan. Zodat duidelijk wordt wie het beste wat kan gaan doen en welke partners het beste bij je passen.
Alive and kicking
In tegenstelling tot wat wel eens wordt beweerd, is service-oriëntatie wat mij betreft dus niet dood maar juist springlevend. Niet als heilige graal waarmee alles goed gaat komen, maar als benadering die goed past bij de richting waarin onze maatschappij zich ontwikkelt.
Als een volgend artikel wil ik beschrijven hoe service-oriëntatie in de praktijk kan helpen bij de naderende overdracht van rijkstaken naar gemeenten per 1 januari 2015. Een enorme operatie, waarbij het succes voor een belangrijk deel zal gaan afhangen van de mate waarin het lukt om goed te gaan samenwerken.
Een artikel met een dergelijke abstractie illustreert perfect waarom SOA nooit een succes is geworden.
Hallo Ad,
Ik ben het volledig met je eens. Je ziet in het algemeen dat het “hebben” van dingen en het zelf uitvoeren van dingen steeds minder belangrijk wordt. Het gaat erom dat diensten worden geleverd aan afnemers.
Het helpt overigens wel als deze diensten vervolgens ook op een generieke wijze worden vertaald naar oplossingen. Dit stimuleert hergebruik en dat heeft ook veel met samenwerking te maken. Door samen IT diensten te gebruiken kunnen organisaties (zoals gemeenten) veel geld besparen.
Hey Ad, leuk stuk, wel wat “high over”, maar daardoor niet minder waar. Dit is alvast mijn korte reactie want ik vermoed dat er nog reacties zullen volgen.
“In tegenstelling tot wat wel eens wordt beweerd, is service-oriëntatie wat mij betreft dus niet dood maar juist springlevend.”
Precies dat. En heel goed regie snappen, want dat die heb je nodig om de boel in de klauw te houden. Dat je er een oerwoud van kan maken is alleen maar een indicator dat het dus heel krachtig is.
Zelf ben ik nagenoeg 100% Service-oriented. Weg met de monolithische systemen!
@henri: klopt, behoorlijk “high-over”. Zeker in “Computable” waar het vaak over de inzet van ICT gaat. Ik wil in het vervolg dan ook aan de hand van een actueel voorbeeld toelichten waar ik de grote voordelen van zo’n benadering zie. Zeker ook wat betreft inzet van ICT die er daarbij anders uitziet dan nu vaak het geval is.
@kj: ik hou wel van korte heldere reacties (ook als we het niet eens zijn). “SOA nooit een succes is geworden” maakt het wel lastig om op te reageren. Afhankelijk natuurlijk van wat je onder “SOA” verstaat, zijn er denk ik volop voorbeelden te noemen waar service-oriëntatie tot succes in de praktijk heeft geleid. Zoals gezegd: in het vervolg een aantal praktijkvoorbeelden.
Leuk stukje Ad, ben het ook 100% met je eens.
Zelf gebruik ik een framework binnen Delphi wat sterk leunt op een services concept. Daar geef ik ook regelmatig lezingen over bij gebruikersgroepen en het voorbeeld van diensten laten samenwerken (in plaats van services) helpt vaak bij het uitleggen van het concept.
Waar ik het vaak fout zie gaan zijn de koppelvlakken tussen de services, de API’s. Je ziet daar vaak gebeuren dat onderdelen heel strak aan elkaar gekoppeld worden (en dus kennis van elkaar moeten hebben) in plaats van een los, stateless en bij voorkeur asynchroon koppelvlak. Door zo’n strakke koppeling krijg je nooit een schaalbare en herbruikbare oplossing.
Wat is jouw ervaring met die koppelvlakken?
@Ad. Zie de definitie en kenmerken onder :
http://nl.wikipedia.org/wiki/Service-ori%C3%ABntatie
In de ERP wereld waar ik in werk is SOA nooit een succes geworden omdat een SOA implementatieproject gewoonweg veel te kostbaar is. Je hebt het immers over de implementatie van een architectuur, een compleet frame-work in plaats van de implementatie van een standaard oplossing. Als je het hebt over een standaardoplossing voor een Enterprise Service Bus (ESB) dan kan je denken aan een produkt als SAP PI ( http://help.sap.com/saphelp_nwpi711/helpdata/en/70/e6b9f493bd4cba98b469bb698e2c88/frameset.htm ) dat wel een succes is te noemen.
Echter, iets simpels als een Remote Function call (RFC), voldoet ook aan de kenmerken van SOA. ( http://en.wikipedia.org/wiki/Remote_Function_Call ). Het is een gewoon een functie die in een ander systeem wordt aangeroepen en wat data retourneert. Het SOA concept is in feite oeroud maar binnen de architectuurwereld is het geworden tot een abstractie. SOA kan slechts overleven via bruikbare implementaties en niet als concept.
@benno: de kwaliteit van koppelvlakken is uiteraard sterk mede bepalend voor de kwaliteit van een service. Mijn ervaring daarmee is goed. Het ligt natuurlijk aan het type service, maar bij veel services die ik ben tegengekomen zijn er prima (stabiele) interfaces die volop mogelijkheden bieden voor divers (her)gebruik. Feitelijk zou ook een van drijfveren van de maker moeten zijn als hij zijn afnemers goed wil bedienen. Het heeft me vaker verbaast hoe eenvoudig je services kunt gebruiken en hoe goed ze werken. Dit terwijl ik echt geen meester-programmeur ben.
@kj: het lijkt alsof we een beetje langs elkaar heen praten; in mijn stuk had ik het bewust over service-orientatie om het beladen begrip “soa” te vermijden daar heel verschillende invullingen aan worden gegeven. Dat het concept oeroud is ben in helemaal met je eens. Dat je een ‘compleet framework’ zou moeten implementeren om met SO-principes te werken ben ik niet met je eens. Als dat nodig zou zijn en er is een praktisch alternatief via een standaardoplossing zoals je dat beschrijft, zou ik daar zeker ook voor kiezen.
@Ad
Leuk verhaal maar bij veel SOA implentaties van de overheid gaat het om service naar de ambtenaar in plaats van de belastingbetaler. Gezeur over participatiemaatschappij is ook niet meer dan het continueren van eigen incompetentie onder een andere vlag.
Kijkend naar boekhoudingen laat al dat automatiseren bij gemeenten geen dalende lijn zien maar belastingen wel een stijgende. Als ik even een aantal standaard diensten ga benchmarken tussen gemeenten dan zie ik toch opmerkelijke verschillen in simpele administratieve processen.
Let wel dat we het hier hebben over retributies wat de nodige vragen van de ACM zou moeten oproepen. Misschien wordt het dus gewoon tijd om de gehele overheid te offshoren, voor de communicatie maakt het toch niks uit.
@ewout ik weet niet precies wat je met “SOA implementaties bij de overheid” bedoeld, maar ik vind dat er de laatste 10 jaar -juist op terreinen waar service-georiënteerd werken een rol speelt- veel vooruitgang is geboekt. Bijvoorbeeld in de vorm van een aantal basisvoorzieningen (http://www.e-overheid.nl/onderwerpen/over-de-e-overheid/basisinfrastructuur-i-nup) die het technisch mogelijk maken dat al die overheidsinstellingen beter gaan samenwerken. Voorzieningen als DigiD/eHerkenning en basisregistraties leveren dagelijks enorme voordelen op (oa financieel!) t.o.v. het ‘ieder automatiseert voor zich’ dat tot 10 jaar geleden nog plaats vond.