Artikel

Services - Hoe kom je tot een bruikbare indeling?

Iedereen gebruikt het begrip dienst en service. Is hier een verschil tussen? Waarom is het onderkennen van services zo handig? En hoe definieer je de juiste services?

Het verschil tussen dienst en service

Als we naar een restaurant gaan vinden we het verzorgen van een kopje koffie een dienst die geleverd wordt. Een dienst is een prestatie als resultaat van een aantal uitgevoerde activiteiten, taken en handelingen, waarbij er een vergoeding verschuldigd is voor de geleverde prestatie (niet voor de geleverde inspanning).

In Nederland zeggen we vaak dat iets een service is, als het boven het niveau zit dat we het verwachten. Als we het kopje koffie omstoten en gratis een nieuw kopje koffie krijgen met een koekje erbij dan zeggen we: kijk dat is nog eens service! Datzelfde geldt ook voor de conducteur die iemand die moeilijk ter been is meer tijd geeft en helpt om in te stappen in de trein. Ook dat, de ongevraagde dienstverlening van hoge kwaliteit, noemen we service.

In de praktijk zien we binnen service oriented architectuur en bij internet dat applicaties en interfaces ‘services’ worden genoemd. Theoretisch gezien is dit onjuist. Een dienst (service) wordt geleverd door een dienstverlener (service deliverer).

De applicatie of interface via welke een dienst wordt geleverd is niet de dienst zelf. Een webservice wordt bijvoorbeeld door W3C gedefinieerd als ‘een soort softwaresysteem’. Een dergelijke definitie veroorzaakt volgens velen onnodig verwarring binnen service oriëntatie en zet een remt op succes met webservices.

Binnen de overheid is het gebruikelijk om bepaalde organisatorische eenheden een dienst te noemen, zoals de dienst Bouw-en-WoningToezicht. Ook veel organisaties hebben voor klanten een klantenservice in het leven geroepen. Ook hier wordt de dienstverlener zelf dienst genoemd. Voor organisatorische eenheden geeft dit geen probleem. Echter bij het definiëren van services in het ICT-domein werkt dit echter wel verwarrend als een service ook services kan leveren.

Waarom is het inkopen van services handig voor organisaties?

Voor een organisatie is het interessant om te kijken naar services. Immers als we afspraken maken met een leverancier over de geleverde prestaties en kwaliteit, is het de zorg van de leverancier om activiteiten te kunnen uitvoeren die tot het gewenste resultaat leiden. Als opdrachtgever of afnemer van diensten hebben we in feite weinig tot geen bemoeienis met technologie of oplossingen die de leverancier gebruikt.

Stel we willen als organisatie een webshop hebben voor de verkoop van producten en diensten met een koppeling naar een verkoopadministratie en relatiebeheeradministratie. Dan kunnen we bij bijvoorbeeld drie organisaties diensten inkopen (het hosten en verzorgen van een informatiesysteem) die op basis van open standaarden de drie systemen aan elkaar koppelen. Als dan de technologie van een systeem verandert dan heeft de opdrachtgever daar weinig mee te maken. De opdrachtgever heeft daarmee geen afhankelijkheid naar technologie of producten waar een leverancier gebruik van maakt. Als de ene leveranciers over gaat op bijvoorbeeld Alfresco als open source content management en de andere leverancier gaat werken met een Oracle en ASP.NET combinatie, dan heeft de afnemer hier weinig last van implementatie technisch gezien. Hij heeft namelijk geen afhankelijkheid naar de inhoudelijke oplossing van de leverancier toe.

Voor veel organisaties is daarom op ICT- gebied dan ook het credo: koop zo hoog mogelijk in de keten (lees diensten) in. Daar waar men vroeger meer een ‘make or buy-decision’ nam.

Welke services zouden organisaties kunnen definiëren?

Naast het inkopen van complete services of services ter grootte van een bedrijfsfunctie of bedrijfsproces, kan een organisatie ook werken met services ter grootte van activiteiten, taken en handelingen.

Stel een organisatie heeft twintig informatiesystemen in de ICT-omgeving. Deze twintig informatiesystemen bestaan elk uit dertig specifieke gebruikersapplicaties en twintig generieke systeemapplicaties die op hun unieke en afhankelijke wijze met elkaar communiceren.

Een voorbeeld van een generieke systeemapplicatie is bijvoorbeeld het afhandelen van printopdrachten of het versturen van informatie en transacties naar andere organisaties. Als nu de dubbele generieke systeemapplicaties zouden kunnen worden uitgefaseerd, dan komt dat de kwaliteit weer ten goede.

Als het afhandelen van printopdrachten altijd op dezelfde wijze gaat, staan er al gauw minder fouten in bijvoorbeeld de brieven naar klanten. De generieke systeemfuncties zouden applicatiefunctionaliteit als service beschikbaar kunnen stellen aan de gebruikersapplicaties in de informatiesystemen. Als er dan een generieke systeemfunctie moet worden vernieuwd, dan hoeven in de gebruikersapplicaties geen aanpassingen te worden gedaan en kan ook vaker en eerder een wijziging worden doorgevoerd, zoals bijvoorbeeld ‘priority security’ updates.

Deze wijze van service oriented communicatie tussen applicaties wordt ook wel loosely coupled interfacing genoemd: de met elkaar communicerende applicaties hebben geen weet van elkaar en maken zich niet afhankelijk van elkaars werking.

Criteria voor services

Als een organisatie voor het werk dat gebeurt in applicaties services wil gaan inzetten is het nodig om te weten hoe groot of hoe klein de services moeten zijn, om niet als organisatie je voor de toekomst te beperken of, aan de andere kant van het spectrum, teveel regie op service. Een vraag die dan op tafel ligt is: is elke applicatiefunctie ook een service? Of is een gehele applicatie een service?

Een bruikbaar gebleken criterium voor een organisatie is om de processen, activiteiten, taken en handelingen als vertrekpunt te nemen voor het definiëren van services en niet de applicaties, informatiesystemen of interfaces. Een reden om de eigen activiteitenindeling te kiezen als basis voor een services indeling is dat een organisatie in de loop der tijd evolutionair het werk zo heeft ingedeeld.

Hoe meer vertrouwen men in leveranciers heeft, hoe minder kennis of hoe minder controle men over bepaald werk men wilt hebben, des te groter kunnen de services zijn die worden gedefinieerd. Andersom geldt het natuurlijk ook.

Wanneer je meer controle, regie en sturing wilt: maak dan de services kleiner. Ook verdient het aanbeveling om alle implementatieafhankelijkheid en technologieafhankelijk uit de namen van services te halen. Immers het voordeel van services is dat je niet jezelf onnodig afhankelijk maakt van de wijze van uitvoeren. Dus die kennis wil je ook niet hebben.

Op basis van wat hiervoor is beschreven, zijn voorbeelden van correcte namen voor applicatieservices:

  • Verwerken klantmutaties
  • Afhandelen printopdrachten
  • Controleren facturen
  • Verzorgen polisopmaak
  • Afwijzen aanvraag
  • Samenstellen klantbeeld

En voorbeelden van incorrecte namen voor applicatieservices zijn:

  • Klantenservice
  • Printmodule
  • Controle
  • Polis
  • Afwijzingenservice

Dit zijn meer namen van de dienstverleners en niet de namen van de te leveren diensten.

Daarbij zouden deze dienstverleners verschillende diensten kunnen verlenen. Voor de duidelijkheid en om verwarring te voorkomen is het verstandig verschil te maken in diensten en dienstverleners (services & service deliverer).

Business Proces Redesign

Het definiëren van services moet voor een organisatie, en in ieder geval de architecten van de organisatie, worden aangegrepen om fundamenteel na te denken over het waarom van het indelen van het werk in bepaalde activiteiten, taken en handelingen. Trends en ontwikkelingen kunnen een veel slimmere en efficiëntere werkwijze mogelijk maken.

Dus architecten: maak gebruik van service oriëntatie om fundamenteel bedrijfsprocessen te herontwerpen.

Volgende maand komt in XR Magazine een DORA-artikel over een generieke indeling in services voor gemeenten.

Categorie:   
Auteur(s)
afbeelding van markpaauwe
Mark Paauwe
Dragon1 Inc. - CTO

Mark is zeer actief in het enterprise architectuur vakgebied. De kans is groot dat je hem op een evenement tegenkomt en dat het gesprek al gauw over architectuurvisualisaties en architectuurprincipes gaat.

 
Reacties
Ad Gerrits op woensdag 13 februari 2013 22:46

Helder stuk. Met terecht de constatering dat er in praktijk vaak onnauwkeurig wordt omschreven wat wordt bedoeld ("gegevensuitwisseling moet via webservices verlopen"). Gelet op het steeds grotere belang van werken met services, dus goed initiatief om hier aandacht aan te geven.

In feite speelt dit natuurlijk bij veel meer begrippen. Een voorbeeld dat ik in mijn eigen werkveld vaak tegenkom is bijv. "zaakgericht werken". Heel veel gebruikt, maar zonder dat er een heldere definitie is van wat daarmee bedoeld wordt. En dus kun je van de 'vrucht' naar voorkeur een appel of een peer maken. In praktijk vaak geen ramp, maar wanneer het gaat over 'architectuur' mag je meer diepgang verwachten.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.