Generieke, herbruikbare services lijken soms de heilige graal van architectuur. Samen met standaardisatie natuurlijk. In theorie is het een goed idee, maar in de praktijk valt het nogal tegen. Vaak kunnen dit soort services alleen met veel moeite gebruikt worden. Herken je dit? Dan zijn twee essentiële zaken niet geregeld.

In theorie is het een prima idee: maak functionaliteit die vaak nodig is generiek en herbruikbaar zodat deze niet telkens opnieuw gemaakt hoeft te worden. Denk daarbij aan het opmaken en verzenden van (elektronische) brieven, het beschikbaar maken van product- of klantgegevens of het publiceren van een live feed over de voortgang van het primaire proces. Maar in de praktijk valt het allemaal nogal tegen. Gebruik blijkt in de praktijk erg lastig en de services worden daardoor het liefst omzeild door de rest van de organisatie. En dat terwijl er veel moeite is gestoken in ontwerp en ontwikkeling. Toch worden vaak twee essentiële zaken niet geregeld, en die hebben alles te maken met de exploitatie van de services…

Generieke services zijn alleen makkelijk herbruikbaar als dit zonder verdere hulp – dus self-service – kan

Vaak zie ik dat er wel gezegd wordt dat er herbruikbare services zijn, maar blijken dit geen “echte” services te zijn – de services zijn gerealiseerd als interfaces of adapters. En wat blijkt dan? Voor ieder (her)gebruik van de desbetreffende “services” moet door de beheerders van deze services ontwikkelwerk worden verricht. De services zijn niet zo maar “clickable”, de integratie moet eerst nog gebouwd worden. En met een beetje pech komt die integratie ook nog aan het einde van een lange backlog terecht.

Typisch in het bovenstaande is dat de services in essentie wel herbruikbaar zijn, maar in de praktijk dus helemaal niet. Wat hier vergeten lijkt, is dat hergebruik vooral ook handig moet zijn voor degene die hergebruikt: effortless. Door de digitale transitie hebben we voor externe partijen al lange een oplossing: API management met een developers portaal. En wat voor externe developers dus al heel gewoon is geworden, kunnen we ook voor interne developers regelen: zet voor generieke services een developer portaal op met self-service onboarding, documentatie van het servicecontract, een testversie met testdata en de echte productieservice. Zorg dat er – eventueel na goedkeuring voor gebruik – alleen nog werk gedaan moet worden door het team dat de service wil gebruiken (en dat dit werk duidelijk en minimaal is). Het team dat de service levert hoeft op dit moment niets (meer) te doen.

Generieke services zijn een product met een business model, en geen ICT-feestje

Een tweede valkuil is om herbruikbare services te zien als een ICT-feestje. En dan draait het vooral om de techniek; hoe ze gemaakt zijn, en waar het endpoint is. Bij vragen of problemen blijkt ondersteuning hap-snap geregeld. Een developer die even tijd heeft licht wat toe, en straalt ondertussen voortdurend uit toch echt weer iets anders te moeten gaan doen. Hier moet het besef indalen dat een herbruikbare service eigenlijk een product is, dat door een leverancier aan een klant wordt geleverd. En wat zien we dan in de echte wereld? Er is een winkel, er is productinformatie, er is een klantenservice. Misschien is er zelfs wel een accountmanager. Allerlei zaken die we ook expliciet voor onze herbruikbare service zullen moeten regelen. Wat collega Rijk van Vulpen al eerder betoogde: Application Programming Interfaces (API’s) moeten eigenlijk Value Proposition Interfaces (VPI’s) zijn.

Een tweede voordeel, en noodzaak, van denken in producten is dat er productmanagement wordt gedaan. In de echte wereld is een product (meestal) een antwoord op een klantbehoefte. Er is onderzoek gedaan naar wat de klanten nodig hebben, en daar is een passend (realistisch, betaalbaar) product bij ontworpen. De leverancier gaat dus niet nadenken over productkarakteristieken als de klant aanklopt, maar heeft meestal al een werkend, en bruikbaar product op de plank liggen. Dit hoort dus ook te gelden voor herbruikbare services: misschien wil een afnemer wel specifieke aanpassingen, maar in eerste instantie hoort er een 85% versie werkend beschikbaar te zijn.

Ontwerpen voor exploitatie

Herbruikbare services vergen een ander ontwerp dan services die als halfproduct in eigen projecten gebruik worden. Ze vragen om een holistisch ontwerp dat business- en ICT-aspecten combineert, en dat de exploitatie van de service als business product centraal stelt. Hou dit in het oog, en het komt wel goed met het gebruik.

Tags: ,