Zelf investeren in software ontwikkeling?

Photo credits
Shutterstock
22 februari 2023  -  10 minuten

HydroLogic research paper

Door Arnold Lobbrecht

Organisaties die starten met ontwikkelen van software, stappen op een glijbaan die eindigt in de ballenbak van beheer, onderhoud en onverwacht hoge kosten. Ik heb het niet over professionele ICT-bedrijven, die weten wat softwareontwikkeling op de lange termijn betekent. Ik heb het over organisaties die specifieke bedrijfsprocessen willen verbeteren door gebruik te gaan maken van de tegenwoordig zeer toegankelijke software ontwikkeltools en cloud diensten. Ziet u ook fraaie kansen in data science en wilt u investeren in de ontwikkeling van software? Lees dan verder.

Geavanceerde ICT is nodig, maar er zijn valkuilen

Optimaliseren van bedrijfsprocessen vereist tegenwoordig inzet van geavanceerde ICT. In het watermanagement is de introductie van ICT in volle gang, wat noodzakelijk is in de strijd tegen de effecten van klimaatverandering. Er is op het moment een keur aan tools om ICT en data science in het waterbeheer in te zetten. Data lakes, intelligente scripting, visualisaties, portals; het is tegenwoordig allemaal vlot ingericht. Op zichzelf biedt dit kansen, maar er zit ook een andere kant aan en die wil ik in dit artikel nader toelichten.

Het gaat me namelijk om de periode na de proof-of-concept fase, als duidelijk is dat geavanceerde ICT meer inzicht en handelingsperspectief biedt. Het gaat om de fase waarin wat is ontwikkeld, ook moet worden beheerd. De fase waarin de data in de lakes zich opstapelen; waarin regie op die data nodig is om ervoor te zorgen dat de kwaliteit gewaarborgd blijft; er moet worden gezorgd voor aantoonbaar werkende back-ups; de fase waarin er versiebeheer nodig is op de software en waarin documentatie up-to-date moet worden gehouden; er testversies van de software nodig zijn, die onafhankelijk van de productieversie kunnen draaien; er moet worden nagedacht over security en 24/7 support voor als er iets mis is met een bedrijfskritische applicatie; de fase waarin tijdens intensief gebruik meer processing capaciteit nodig is; enz.

Praktijkervaring met kostenontwikkeling van software

De afgelopen 20 jaar hebben we bij HydroLogic  ervaring opgedaan met de bovenstaande onderwerpen. Wat al vroeg duidelijk werd is dat er voor professionele softwareontwikkeling ook een bijbehorende professionele organisatie nodig is met een typisch ICT-bedrijfsmodel, organisatiestructuur en werkwijze. In dit artikel focus ik op de ervaringen die wij en ook andere ICT bedrijven hebben opgedaan; over kosten die samenhangen met software ontwikkeling, beheer, onderhoud en infrastructuur.

In de praktijk blijkt dat de kosten van operationele software veel hoger zijn dan velen zich realiseren, met name op de lange termijn. Na efficiënte jaren van productie van nieuwe software functionaliteit ontstaat er veelal vertraging waarbij organisaties meer bezig zijn met het onderhouden van oude software dan met het maken nieuwe functionaliteit. Ook blijken de kosten voor processing en opslag van data vaak een veel grotere vlucht te nemen dan verwacht.

DevOps – het standaard model

In de ICT is DevOps de gangbare benadering voor ontwikkeling van software, waarbij praktijkervaring met het draaien van de software (Operations) wordt meegenomen in de ontwikkeling van nieuwe software (Development). Door het werken in snelle ontwikkel- en beheer cycli wordt adaptief gewerkt en blijft de kwaliteit van het product hoog. Het betekent dat het team van ontwikkelaars zich ook bemoeit met het draaien van de software en het verhelpen van problemen indien die zich hierbij voordoen.

Ter illustratie zetten we een eenvoudig denkmodel op. Een klein team van drie softwareontwikkelaars werkt aan nieuwe software, maar ze gaan ook werken aan het onderhoud van wat ze zelf hebben gemaakt. In het eerste jaar is al hun tijd beschikbaar voor nieuwe functionaliteit. Maar, vanaf jaar twee, moeten ze wat eerder is gemaakt ook onderhouden.

Dat laatste omvat eenvoudig gezegd: door gebruikers ontdekte problemen onderzoeken; eventuele bugs opsporen en verhelpen; robuuster maken van de software om onder alle omstandigheden goed te draaien; updates van gebruikte pakketten doorvoeren; herstructureren van de code; documentatie updaten; beheer en planning van tickets; etc.

In de praktijk blijkt het met onderhoud van software zo te zijn dat circa 20% van de tijd die gemoeid was met het ontwikkelen, besteed moet worden aan het onderhouden van die software. Dus alles wat wordt ontwikkeld kost de jaren daarna 20% van de oorspronkelijke ontwikkeltijd aan beheer en onderhoud. Dat klinkt als veel, en dat is het ook, en als je het grafisch uitzet dan ontstaat een onthutsend beeld (Fig. 1).

Fig. 1. Kostenverloop DevOps, bij jaarlijks gelijkblijvende capaciteit voor nieuwe ontwikkeling en beheer & onderhoud (B&O); het B&O van nieuwe software kost 20% van de ontwikkeltijd.

Al na vijf jaar is 60% van de tijd van de ontwikkelaars nodig voor beheer en onderhoud; en na 10 jaar is dat ruim 85%! Zelfs als een organisatie extreem toekomstgericht en zeer professioneel software ontwikkelt en de kosten voor beheer en onderhoud van de gangbare 20% naar 15% zou kunnen terugbrengen, dan nog is na vijf jaar de helft van alle beschikbare tijd van ontwikkelaars nodig voor beheer en onderhoud. Kortom: met dit eenvoudige model, vooral bedoeld om inzicht in het fenomeen te geven, gaat uw investering in software in de loop van de tijd grotendeels over in een kostenpost voor beheer en onderhoud.

Meer effectief met herontwikkelen van software en teamgroei

In het eenvoudige voorbeeld is ervan uitgegaan dat eenmaal ontwikkelde software niet wordt vervangen door nieuwe. Op die manier raakt de gehele software veruderd. Daarom is het gebruikelijk om de software gedeeltelijk te herontwikkelen. Als de ontwikkelaars ook tijd gaan besteden aan het herschrijven van de software en als alle softwarecode gemiddeld na 7 jaar wordt vervangen door nieuwe, dan blijft de software bij de tijd en blijft ook de afhankelijkheid van detailkennis van oude software beperkt. Maar hoe je het ook went of keert, de beschikbare tijd voor ontwikkeling van geheel nieuwe software functionaliteit neemt niet toe.

De enige manier om ervoor te zorgen dat de jaarlijkse capaciteit voor nieuwe software ontwikkeling gehandhaafd blijft, is het laten groeien van het team. Fig. 2 laat zien wat er gebeurt als het team ieder jaar met 15% groeit en alle ontwikkelde software iedere 7 jaar wordt vervangen door nieuwe. In die situatie is een organisatie in staat om na jaar 5 nog krap de helft van de capaciteit te besteden aan nieuwe softwareontwikkeling. Daar staat tegenover dat het oorspronkelijke team van 3 fte in jaar 10 is gegroeid naar ruim 10 fte.

Fig. 2. Verloop van de teamcapaciteit (fte) voor nieuwe ontwikkeling, herontwikkeling en beheer & onderhoud, bij een jaarlijkse teamgroei met 15% en vervanging van software componenten telkens na 7 jaar. Op termijn is krap de helft van de capaciteit beschikbaar voor nieuwe softwareontwikkeling.

Kosten van infrastructuur

Bij moderne cloud infrastructuur wordt gebruik gemaakt van fysieke servers waarvan de beschikbare capaciteit is geclusterd. Op die geclusterde servers kunnen virtuele machines (VM’s) worden geïnstalleerd, die zich gedragen als fysieke servers. Zo kunnen bijvoorbeeld tientallen VM’s draaien op slechts een paar fysieke servers. Dit maakt de inrichting en het beheer van infrastructuur flexibel en maakt het mogelijk om specifieke taken aan verschillende servers toe te kennen.

Of nu wordt gewerkt met een private cloud in een datacentrum van uw provider of in de publieke cloud, bijvoorbeeld bij Microsoft of Amazon, u werkt met virtuele servers en de kosten die daarvoor worden gemaakt worden bij u in rekening gebracht. Deze externe kosten zijn over het algemeen gunstig ten opzichte van eigen hardware met de bijbehorende inzet van eigen beheerders.

Is eenmaal een virtuele omgeving ingericht, dan kunt u beschikken over allerlei diensten die flexibel kunnen worden ingezet: processors met cores naar keuze, RAM-geheugen, datatransport en firewalls. Alles wordt separaat afgerekend en dat geldt ook voor licenties van besturingssystemen, voor licenties op standaardsoftware en voor de niet te onderschatten energie die de infrastructuur gebruikt. Het voordeel van de publieke cloud is dat er gemakkelijk toegang is tot een wereld aan databases en analyse tools, visualisatie software en dashboarding. Dit zijn allemaal essentiële componenten voor de data scientist.

Data science vereist toegang tot veel data

Er is nog een andere reden waarom de externe inzet en vooral publieke cloud providers interessant zijn voor toepassing van ICT in het waterbeheer, en dat heeft te maken met de opslag van data. In ons waterdomein is de optimale inzet van de waterhuishoudkundige infrastructuur in belangrijke mate afhankelijk van data over het gedrag van het watersysteem. Denk aan data van waterstandsmetingen, afvoermetingen, regenmeters, regenradar, satellietbeelden en weermodellen.

De genoemde bronnen genereren van meting tot weermodel oplopende hoeveelheden data, van vele gigabytes tot terabytes per jaar. Dat zou op zich nog geen probleem hoeven te zijn, ware het niet dat we voor analysedoeleinden juist historische reeksen nodig hebben. In het operationele waterbeheer is het belangrijk om te zien hoe een actuele of op handen zijnde situatie in het watersysteem zich verhoudt tot wat we kennen uit het verleden.

De jaarlijks ingewonnen data moeten dus behouden blijven. Daarbij komt nog dat er steeds meer publieke databronnen bijkomen en dat de resolutie in tijd en ruimte van deze databronnen telkens hoger wordt. Ook is het in de praktijk heel moeilijk om van eenmaal beschikbaar gemaakte data afscheid te nemen omdat er in een organisatie altijd wel een proces te vinden is dat van die data gebruik maakt. Kortom, de hoeveelheid data die moet worden opgeslagen kan makkelijk exponentieel groeien en dat vraagt de nodige opslagcapaciteit.

Welke kant gaat het op met de kosten?

Het moge duidelijk zijn dat het investeren in software veel bijkomende aspecten met zich meebrengt waar aandacht aan moet worden geschonken. Infrastructuur kosten om het geheel te laten draaien zijn daar een belangrijk onderdeel van en bovendien gaan die kosten in de loop van de tijd alleen maar omhoog. We hebben een schatting gemaakt van de kosten van infrastructuur voor een organisatie die serieus aan de slag gaat met ICT voor operationeel en strategisch watermanagement.

Fig. 3 geeft het totale plaatje dat past bij de eerder geschetste organisatie die start met drie softwareontwikkelaars, het team jaarlijks 15% laat groeien en alle software componenten na 7 jaar vervangt door nieuwe. In de berekening zijn we er voor de eenvoud vanuit gegaan dat een fte een ton aan werkgeverslasten kost. Alle data die door de software worden verwerkt worden opgeslagen en geback-upt. Na 10 jaar zijn de kosten ruim verviervoudigd, van oorspronkelijk 3 ton naar 1.3 miljoen euro.

Fig. 3. Verloop van de totale kosten voor DevOps en infrastructuur, waarbij een ontwikkelteam van 3 fte jaarlijks groeit met 15%, alle softwarecomponenten na 7 jaar worden herontwikkeld en alle ingewonnen data bewaard blijven.

Conclusies

ICT geeft mooie mogelijkheden om het watermanagement veel slimmer in te richten en beter paraat te staan voor de effecten van klimaatverandering. Beslissingen kunnen weloverwogen worden genomen op basis van historische, actuele en verwachte informatie en dat is een enorme winst. Daar staat tegenover dat als een organisatie dit professioneel wil borgen, het grote inspanning en aanzienlijke kosten vereist.

Binnen het moderne waterbeheer vinden veel digitale ontwikkelingen plaats, en wordt data science een essentiële schakel in de keten. Wat ik met dit artikel wil bereiken is dat ook serieus wordt nagedacht over de toekomst, want het blijft niet bij een goede start. Er volgt nog een lange reeks aan uitdagingen om alles op ICT-gebied goed geregeld te krijgen en te houden en bovendien zijn de kosten daarvan fors en nemen ze jaarlijks alleen maar toe.

Samenwerking tussen organisaties kan in de geschetste problematiek verlichting brengen: kosten kunnen worden gedeeld en sommige software hoeft niet dubbel te worden ontwikkeld. Dat gaat wat mij betreft verder dan samenwerking tussen overheden onderling. Bij de ontwikkeling van HydroNET hebben we de samenwerking breed getrokken en hebben we eindgebruikers, andere bedrijven en ook instituten betrokken. Hierdoor is en wordt veel kennis gedeeld en worden extreem hoge kosten per organisatie voorkomen.

Samenwerking neemt niet weg dat de ‘total cost of ownership’ van software voor waterbeheer groot zijn, en dan vooral voor de instandhouding en het operationeel gebruik ervan. Die kosten lopen in de tijd op tot wel driemaal de kosten van ontwikkeling van nieuwe functionaliteit! Van alles wat u denkt te investeren verdwijnt 2/3 naar ‘onzichtbare’ herontwikkeling, beheer, onderhoud en infrastructuurkosten.

Daarom is mijn advies: zoek de samenwerking op in de gouden driehoek van ICT bedrijven, overheden en onderzoeksinstellingen. Het credo moet zijn: ‘bestaande en bewezen software zo veel mogelijk delen en hergebruiken’, vooral waar het gaat om generieke processen zoals data-inwinning, processing, opslag en het toegankelijk maken van data en informatie. De toch al grote budgetten die nodig zijn voor ICT kunnen daarmee veel effectiever worden ingezet en de focus kan gericht blijven op de zo noodzakelijke innovatie in het waterbeheer.

Investeren in software ontwikkeling? Bezint eer ge zelf begint!

Over Arnold Lobbrecht

Arnold Lobbrecht is oprichter en een van de eigenaren van HydroLogic. Hij is aan de TU Delft gepromoveerd op Sturing van Watersystemen en in zijn 35-jarige loopbaan altijd actief geweest op het snijvlak van waterbeheer en ICT. Naast diverse functies in het bedrijfsleven is hij als Associate Professor verbonden geweest aan UNESCO-IHE, het internationale waterinstituut in Delft, waar hij bij de afdeling Hydroinformatics 15 jaar leiding gaf aan de onderzoeksgroep Operationeel Waterbeheer / Real-Time Control (RTC). Naast deze werkzaamheden was en is Arnold actief in diverse werkgroepen van het Koninklijk Instituut van Ingenieurs, het Koninklijk Nederlands Waternetwerk, Nederland ICT en NLingenieurs. Zijn onderzoeksinteresse ligt op het gebied van hybride modellering met op fysica gebaseerde modellen en data-gedreven modellen, gebaseerd op technieken uit de Artificiële Intelligentie.