Kosten voor IT oplossingen zitten vaak verborgen. Veel kosten bij standaardproducten zitten niet in de eenmalige aankoop van een oplossing, maar in de periodiek terugkerende onderhoudskosten. Dit geldt voor gebouwen, auto’s en fietsen, maar ook voor software oplossingen.

Bij aanschaf van software spelen de volgende kostenfactoren een rol:

  • Eenmalige kosten. Ook wel investeringskosten (capex, capital expenditures) genoemd.
  • Operationele kosten. Ook wel beheerkosten (opex, operating expenditures) genoemd.

Gebouwen en materieel vergen onderhoud. Anders is een gebouw na verloop van tijd niet meer bewoonbaar of stopt je auto met rijden. Traditioneel worden operationele kosten veroorzaakt door slijtage. Bij tal van tastbare producten is de aanschafprijs dan ook veel hoger dan de periodieke onderhoudskosten.

hiddenfees

De karakteristiek die bij een software product cruciaal anders is, is dat het product zelf niet slijt. Software slijt niet door gebruik, het weer heeft geen vat op software code en oude software kan vaak nog prima bruikbaar zijn. Toch zijn vaak de operationele kosten hoog. Te hoog. Uitgaande dat er geen nieuwe functionaliteit nodig is, bijvoorbeeld bij een ‘simpel’ rekenprogramma, worden kosten veroorzaakt door:

  • Beveiligingsupdates voor de software zelf.
  • Wijzingen op het operating system of infrastructuur, waardoor de software moet worden aangepast.
  • Verbeteringen. Ook verbeteringen waar je niet om hebt gevraagd!
  • Licentiekosten.

 

Om deze onderhoudswerkzaamheden bij software uit te voeren, zijn vaak dure gecertificeerde IT beheerders nodig. Zij weten en kunnen als geen ander de impact van wijzingen van de software inschatten en wijzingen doorvoeren. Ook zijn specialisten nodig om bij wijzingen op infrastructuur of software testen uit te voeren en indien nodig snel problemen op te lossen.

help

Vanuit architectuur is het natuurlijk prima mogelijk om een oplossing te bedenken, waarbij wel de voordelen van de karakteristieken van een software product naar voren komen, maar niet de traditionele nadelen. De belangrijkste ontwerpprincipes zijn dan:

  1. open source
  2.  ‘beheerarm’ zero maintenance
  3.  functionaliteit eenvoudig te wijzigen

Een open source uitgangspunt voorkomt altijd terugkerende licentiekosten. Net als bij gesloten software is een inhoudelijk doordacht selectieproces vanuit functionele en niet-functionele eisen cruciaal voor een goede keus. De beste open source producten zijn ontworpen vanuit een ‘zero maintenance’ ontwerpprincipe. Logisch, want aangezien open source producten vaak worden gemaakt door allerbeste programmeurs wordt alles op alles gezet om vervelende handmatige beheerhandelingen te voorkomen. Goede OSS programmeurs zijn namelijk graag bezig met ontwikkelen van nieuwe functionaliteit en niet met onderhoud door ‘bugs’. Dit betekent dus dat het gebruik van de beste OSS producten het enige noodzakelijke onderhoud volledig automatisch gaat. Denk aan testen, fixes en upgrades uitvoeren. Zo werkt een gebruiker, die voor de browser firefox kiest altijd met een volledig automatisch bijgewerkte en geteste versie, zonder dat dit een extra inspanning van een beheerder of gebruiker vereist. Maar inzicht in een ongewenste vendor lock-in is ook bij OSS software vereist.

Veel beheerkosten worden veroorzaakt om software aan te passen aan veranderende bedrijfsprocessen of parameters. Bij een goed ontworpen software product is vooraf nagedacht over de veranderingen die ooit kunnen komen. Maar nog belangrijker is dat dit ontwerpprincipe heeft geleid tot software waarbij zeer eenvoudig nieuwe functionaliteit aan kan worden toegevoegd of bestaande functionaliteit kan worden gewijzigd. Dit alles zonder langdurig realisatietraject gekenmerkt door een lang software ontwikkelproces. Zelfs met scrum.

Oplossen van business IT problemen onder architectuur lijkt in de aanloopfase soms duur, te abstract en weinig direct toegevoegde waarde te hebben. Echter de praktijk leert dat bij een inhoudelijk kundig doorlopen architectuurfase hoge jaarlijkse beheerkosten worden vermeden. Het is dan natuurlijk wel noodzakelijk dat de businesscase ook vanuit architectuur bewaakt wordt.

deadend

 

Zero maintenance: Fictie of werkelijkheid?