De tijd van volledig bespoke software is voorbij. Iedere klant een eigen versie geven van een stuk software of steeds vanaf nul beginnen, is duur en onhoudbaar geworden. Hergebruik van software lijkt het antwoord. Toch zitten ook daar haken en ogen aan, blijkt tijdens de rondetafel ‘Software re-use’, die Link Magazine en TIOBE Software organiseerden.
- – ‘Als een klant een bijzondere wens heeft, maken we het onderdeel van de standaard.’
- – Klanten blijven vaak liever op oudere versies werken, om niet te hoeven updaten.
- – ‘Alles ziet er herbruikbaar uit als je ver genoeg weg staat.’
- – ‘Ambitie, verwachting en realiteit sluiten vaak niet op
Maatwerk kan niet meer, maar ook hergebruik heeft plussen en minnen
Nog geen twee decennia geleden werd software op eenzelfde manier verkocht als veel machines. Een eindgebruiker – of dat nu een consument of een bedrijf is – betaalt voor een stuk software, gebruikt deze en dat is dat, tot ze eens wat nieuws willen. Iedereen weet dat dit nu anders is: software wordt afgenomen als een dienst, veelal op basis van abonnementen, met doorlopend onderhoud en regelmatige updates.
‘Softwarebedrijven zijn vaak volumebedrijven, waarbij de toekomstige marge uit herhalende omzet komt’, zegt Han Schaminée tijdens de rondetafel. Tegenwoordig is hij onder meer agile coach en lecturer bij de Technische Universiteit Eindhoven en consultant, maar in het verleden werkte hij ook bij TomTom, waar hij als laatste senior vice president Location Technology Products was. ‘Toen ik bij TomTom begon, bedroeg de waarde van een navigatietunnel 64 euro. Bij mijn vertrek jaren later was dat nog maar 6 euro.’
‘Hergebruik moet gericht zijn op een specifiek doel’
De winst wordt nu vooral gehaald uit het verkopen van zo veel mogelijk goedkopere software. Daarmee is het niet langer houdbaar om voor iedere klant iets geheel nieuws te maken. De research- en ontwikkelkosten zijn daar doorgaans veel te hoog voor. Bovendien ontstaat zo een wildgroei aan versies of zelfs verschillende soorten software, die allemaal gemaakt én onderhouden moeten worden. Daar is weer voldoende capaciteit voor nodig, terwijl IT-personeel momenteel schaars en duur is. ‘Je kunt beter standaardproducten hergebruiken en afstemmen’, concludeert Schaminée.
Eén versie, meerdere gebruikers
In een ideale wereld is er een enkele master codebase – of een enkele versie van de software – waar meerdere klanten op zitten. Voor die klanten wordt geïnventariseerd welke functies nodig zijn en die worden toegevoegd, waarna ze voor iedereen beschikbaar zijn. Worden nieuwe zaken toegevoegd of onderdelen verbeterd, dan verschijnt er een update en gaat iedereen over naar de volgende versie.
Zo’n aanpak hanteert Bronkhorst High-Tech, vertelt enterprise architect Thijs Hekelaar. Het bedrijf heeft één standaardplatform dat door alle klanten gebruikt wordt. ‘Als een klant een bijzondere wens heeft, kunnen wij dat wel aanbieden, maar dan maken we het onderdeel van de standaard.’ Op die manier wordt nog altijd met een enkel platform gewerkt waar iedereen gebruik van maakt, maar kan Bronkhorst toch tegemoetkomen aan enkele klantspecifieke wensen. ‘De functie wordt dus beschikbaar voor alle klanten.’
Prijs belangrijker dan service
De situatie bij deze Ruurlose onderneming lijkt echter een uitzondering, zegt Schaminée. Bij veel bedrijven willen klanten helemaal niet op deze manier werken, onder meer omdat ze dan steeds moeten updaten als er nieuwe functionaliteiten worden toegevoegd, zelfs als zij geen interesse hebben in die functionaliteit. ‘Bij iedere update moeten ze valideren of de machines wel goed blijven werken’, voegt Schaminée toe. Klanten blijven vaak liever op oudere versies werken, om niet te hoeven updaten. Maar die versies moeten dan wel onderhouden worden, bijvoorbeeld om eventuele nieuwe securityrisico’s af te dichten.
Diverse bedrijven blijven steeds nieuwe producten of versies aanbieden, ook omdat de sales-afdeling graag een deal willen binnenhalen met een nieuwe klant. Daarbij wordt dan vooral gekeken naar wat de klant wil en niet wat op de lange termijn misschien de betere optie is. ‘Ik zie weleens bij salessituaties dat de prijs van een project belangrijker is dan de twintig jaar service die je in de schaduw van dat project kunt verkopen’, zegt Mart Schoenmakers, executive director Software Warehousing bij Vanderlande.
Afwegingen maken
Nu zijn er zeker use cases waarbij een enkel platform aanbieden geen optie is. Als een bedrijf software levert voor wezenlijk andere machines, zijn ook verschillende soorten software nodig. Maar ook bij dit type producten is een zekere vorm van hergebruik mogelijk. Veel software bevat namelijk componenten of stukken code die hergebruikt kunnen worden. Binnen een enkel project of over meerdere soorten software heen.
De meest voor de hand liggende manier van code hergebruiken, is door het stuk code te kopiëren en ergens anders te plakken. ‘Dat is hergebruik, maar vergroot ook de kosten op onderhoudbaarheid’, benadrukt Paul Jansen, oprichter en ceo van het Eindhovense TIOBE. ‘Als er een fout in zit en dat stuk code staat op allerlei verschillende plekken gekopieerd, wie gaat dan vinden waar het probleem precies zit?’ Bovendien moet de fout vervolgens op alle plekken waar die code gekopieerd staat aangepast worden. ‘Dat kost veel tijd en klauwen met geld.’
De oplossing is om herbruikbare libraries te bouwen. Zo’n library vormt één centrale plek waar de code staat, die vervolgens op verschillende plekken aangeroepen kan worden. Zo is de code wel herbruikbaar, maar hoeft deze maar op één plek onderhouden te worden. Toch ziet Jansen ook daar wel uitdagingen in: als de code gewijzigd wordt voor één project, heeft dat effect op alle andere projecten waarin die library gebruikt wordt. Die moeten dus afzonderlijk getest worden, om te zien of de wijzigingen daar geen problemen opleveren. ‘Als je code dupliceert, is dat niet het geval. Dit is een bedrijfsrisico waar je afwegingen in moet maken’, aldus Jansen.
Organisatorische vraagstukken
Kies je ervoor om duplicatie weg te nemen en inderdaad met libraries te gaan werken, dan volgt een nieuwe uitdaging. ‘Waar gaan we het gezamenlijke stuk code in stoppen? Daar moet een infrastructuur voor komen, maar wie is daar verantwoordelijk voor? Wie gaat dat onderhouden? Wie bepaalt de requirements?’, zegt Jansen. Dergelijke organisatorische vraagstukken moeten beantwoord worden, voor een engineer met deduplicatie aan de slag kan.
‘Als je gaat schalen vanuit een instabiele basis, gaat het mis.’
Dirk Jan Swagerman, chief On Demand Innovation & Technology bij Buffadoo in Eindhoven, sluit zich daarbij aan. Hij helpt organisaties onder meer om inzicht te krijgen in hun code en architectuur. ‘De belofte van hergebruik is dat de kosten naar beneden gaan, omdat je maar één codebase hoeft te onderhouden voor meerdere producten. Maar wat niet mee wordt genomen, zijn de kosten van delen. Het kost tijd om goed te begrijpen wat code doet, in welke domeinen die gebruikt wordt en wat de gemene delers zijn tussen die domeinen.’
Begin met de zakelijke behoefte
Zomaar aan de slag gaan met hergebruik, zonder daar verder goed over na te denken, is dus niet de juiste aanpak, blijkt wel uit deze rondetafel. Toch kan hergebruik wel voordelen opleveren. Er is minder onderhoud nodig, het wiel hoeft niet steeds opnieuw te worden uitgevonden en er zijn minder engineers nodig om het werk uit te voeren.
Dus hoe ga je dan wel goed aan de slag met hergebruik? ‘Hergebruik moet gericht zijn op een specifiek doel’, zegt Swagerman. ‘Begin altijd met de zakelijke behoeften en use cases van klanten. Kijk dan of je herbruikbare component te gebruiken is bij deze klant.’ Daarbij is het belangrijk goed te kijken naar de oplossing, waar deze voor dient en in welk domein dit product zich bevindt. ‘The devil is in the details’, benadrukt Swagerman. ‘Alles ziet er herbruikbaar uit als je ver genoeg weg staat.’
Link magazine juli/augustus 2025. Thema: Investment, private equity en overnames. Cover Robin Knoops oprichter Inreda Diabetic. Lees het artikel digital of vraag exemplaar op bij mireille.vanginkel@linkmagazine.nl
Stabiele basis vereist
Als voorbeeld noemt hij imaging-software voor de zorgsector. Een dermatoloog kan een gedetailleerde foto maken van een verdachte moedervlek. Verderop in het ziekenhuis maakt een röntgenapparaat een beeld van een gebroken arm. In beide gevallen gebeurt dit met imaging-software, dus je zou zeggen dat je veel van de software kunt hergebruiken. Maar hoe preciezer je naar de twee use cases kijkt, hoe meer je ontdekt dat er grote verschillen zijn. ‘Van een afstand lijken dingen hetzelfde, maar bij nadere inspectie kunnen er grote verschillen zijn’, vat Swagerman het samen.
Daarnaast benadrukt hij dat er altijd sprake moet zijn van een stabiele basis, voor een component hergebruikt wordt. Met andere woorden: je wil zeker weten dat iets goed werkt, voor je het in tal van producten gaat stoppen. ‘Als je gaat schalen vanuit een instabiele basis, gaat het mis.’
Verwachtingen managen
De deelnemers aan de rondetafel zijn het erover eens dat goed hergebruik van software tijd kost. Tijd om te identificeren wat herbruikbaar is en te begrijpen hoe deze componenten werken. Daarna kost het tijd om componenten zo in te richten dat ze ook echt herbruikbaar zijn en goed onderhouden kunnen worden.
Probleem is dat die tijd er niet altijd is, zeker niet als de volgende projecten al klaar staan om uitgevoerd te worden. ‘Er is ambitie, er is verwachting en er is realiteit. Die sluiten vaak niet op elkaar aan’, klinkt het vanuit de zaal. ‘Dus het is zaak om verwachtingen te managen, zodat ze wel voldoen aan de realiteit’, concludeert Schaminée tot slot.
Deelnemers zijn o.a. Cyclomedia, Tias, DHL, Philips, ASML, Bosch, Lely, tricas, Selmers, Mapscape, Trymax, Thermo Fisher enz.
De deelnemers hebben naar elkaar uitgesproken om op regelmatige basis bij elkaar te komen om met elkaar in gesprek te gaan over de productiviteit van softwareontwikkeling. Heeft u Interesse om deel te nemen aan de platform bijeenkomsten? Neemt u dan contact op met John van Ginkel Link magazine(john.vanginkel@linkmagazine.nl) of met Laurens Jansen van Tiobe(laurens.jansen@tiobe.com).
