Het kiezen van softwareversies voor uitrol

Iets wat ik zeer vaak besproken zie worden in IT-kringen is “welke versie van software moet ik installeren.” Dit kan van toepassing zijn op een database, een applicatie, firmware of, waarschijnlijk het vaakst, besturingssystemen, en met het naderende einde van de ondersteuningslevensduur van Windows XP heeft het onderwerp een koortsachtige intensiteit bereikt.

Er zijn in wezen twee kanten aan deze discussie. De ene kant gelooft dat altijd de nieuwste en, naar verondersteld, beste software gebruikt zou moeten worden. De andere kant gelooft dat software moet rijpen en hanteert een “de kat uit de boom kijken”-benadering, of beschouwt zelfs elke versie als een ander product en niet als een continuüm van ontwikkeling.

Beide benaderingen hebben hun verdiensten en geen van beide zou volledig zonder de andere moeten bestaan. Software blindelings en lukraak updaten is niet verstandig, en het zonder reden vermijden van patches en updates is evenmin verstandig. Een zorgvuldige afweging van de factoren en inlevingsvermogen in het softwareontwikkelingsproces zijn belangrijk om in gedachten te houden bij het nemen van deze beslissingen.

Ten eerste zijn er twee volledig verschillende scenario’s om te overwegen. Het ene is het updaten van huidige, bestaande software. Daarbij wordt aangenomen dat de huidige stand van zaken “werkt”, met de aanvaarde mogelijkheid dat “werkt” ook een beveiligingsblootstelling kan omvatten die is ontdekt en updaten vereist om die te dichten. Het andere scenario is een nieuwe uitrol waarbij er momenteel niets is en we vanaf nul beginnen.

Laten we beginnen met het tweede geval, aangezien het veel eenvoudiger is om hier richtlijnen voor te geven.

In het geval van nieuwe software-uitrollen (of nieuwe besturingssystemen) gebruik altijd de huidige, meest recente versie van de software, tenzij er een duidelijk bekende technologische beperking is die dit verhindert – zoals bekende bugs of software-incompatibiliteiten.

Software is niet zoals andere soorten producten, zeker niet in de huidige wereld van online uitgebrachte patches en updates. Ik neem aan dat de mentaliteit dat oude versies van software de voorkeur zouden kunnen verdienen boven de huidige, voortkomt uit een combinatie van fysieke producten (horloges, auto’s, serviesgoed, meubilair, wijn), waarbij een specifiek jaar of model om uiteenlopende redenen superieur kan zijn aan een nieuwer model, en uit verouderde manieren van softwarelevering, waarbij voltooide softwareproducten eenvoudigweg “over de muur werden gegooid” en de eindtoestand simpelweg de eindtoestand was, zonder enige redelijke mogelijkheid tot updates, patches of fixes. Geen van beide gevallen is van toepassing op moderne bedrijfssoftware (slechts op de zeldzaamste uitzonderingen na).

Softwareontwikkeling is grofweg een continuüm. Bij normale ontwikkelingsprocessen wordt nieuwe software bovenop oude software gebouwd, hetzij rechtstreeks (door updates voor een bestaande codebasis te creëren), hetzij onrechtstreeks (door opnieuw te bouwen op basis van kennis die is opgedaan bij het bouwen van een eerdere versie van de software). Het idee daarbij is dat elke volgende versie van de software superieur is aan de voorgaande. Dit is uiteraard niet gegarandeerd; er bestaan concepten als regressiefouten en simpelweg slechte ontwikkeling, maar over het algemeen verbetert software in de loop van de tijd – zeker wanneer we het hebben over software van enterprise-klasse die in bedrijven wordt gebruikt en actief in ontwikkeling is. Nieuwe software is niet slechts de volgende fase van de oude software, maar vertegenwoordigt in vrijwel alle gevallen ook de huidige stand van patches, bugfixes, updates en, waar nodig, veranderingen in aanpak of techniek. Nieuwe software, afkomstig van kwaliteitsbedrijven, is vrijwel altijd beter dan oude software. Software evolueert en rijpt.

Naast de kwaliteit van de software zelf is er het concept van investeren in de toekomst. Software is niet iets wat eeuwig op de plank kan blijven liggen. Ze moet tot op zekere hoogte actueel blijven, anders houdt ze op te functioneren omdat het platform waarop ze draait verandert, een nieuw artefact aan het licht komt, beveiligingslekken worden ontdekt of behoeften veranderen. Het installeren van oude software betekent dat er wordt geïnvesteerd in het verleden, een investering in het installeren, leren, gebruiken en ondersteunen van oude technologie. Dit wordt “technische schuld” genoemd. Deze oude technologie kan jaren of zelfs decennia meegaan, maar oude software verliest in de loop van de tijd aan waarde en wordt steeds duurder om te ondersteunen, zowel voor de leveranciers, indien zij die blijven ondersteunen, als voor de eindgebruikers, die ze moeten ondersteunen.

Hetzelfde concept van technische schuld is van toepassing op de betreffende softwareleveranciers. Er zijn zeer grote kosten verbonden aan het creëren van software en in het bijzonder aan het onderhouden van meerdere versies van die software. Softwareleveranciers hebben veel prikkels om de ondersteuning voor oudere versies te beperken teneinde middelen te concentreren op huidige softwarereleases (dit is een belangrijke reden waarom SaaS-uitrollen zo populair zijn: de leverancier beheert de beschikbare versies en kan verouderde versies via updates elimineren). Indien klanten ondersteuning voor oude versies vereisen, moeten de kosten ergens worden gedragen, en vaak worden ze gedragen zowel in de vorm van financiële gevolgen voor alle klanten als in een verminderde focus op het nieuwe product, aangezien ontwikkelingsteams moeten worden opgesplitst om zowel het patchen van oude versies te ondersteunen als de nieuwe te ontwikkelen. Hoe meer inspanning er in oude versies moet worden gestoken, hoe minder inspanning er in nieuwe verbeteringen kan worden gestoken.

Binnen het kader van wat ik al heb gezegd, is het belangrijk om te spreken over coderijpheid. Coderijpheid wordt vaak aangevoerd als reden om “oude code” uit te rollen, maar ik denk dat dit een misverstand binnen de IT is over softwareontwikkelingsprocessen. Als we nadenken over een uitgebrachte coderegel: het feit dat deze is uitgebracht en in gebruik is, maakt haar niet werkelijk rijper. Code verandert niet in het wild, ze blijft daar gewoon staan. Haar rijpheid is “vastgezet” op de dag dat ze wordt uitgebracht. Als ze wordt gepatcht, dan zou ze inderdaad na de release “rijpen”. Latere versies van dezelfde software, gebaseerd op dezelfde codebasis maar actueler, zijn werkelijk de rijpere code, aangezien deze in grotere mate is herzien, geüpdatet, getest, enzovoort, dan de vroege release van diezelfde code.

Dit is contra-intuïtief ten opzichte van bijvoorbeeld een auto, waar elke release iets nieuws is met nieuwe mogelijkheden voor mechanische problemen en andere betrouwbaarheidsbezorgdheden – waar een paar jaar wachten je de kans geeft om te zien welke betrouwbaarheidsproblemen aan het licht komen. Software is niet zo. Het concept van het verlangen naar rijpere software zou je er dan ook toe aanzetten om de “nieuwste en beste” uit te rollen in plaats van de “beproefde en vertrouwde”.

Als we softwareversienummers eerder als leeftijden beschouwen, komt dit duidelijk naar voren. Linux 3.1 is, in termen van softwarerijping, veel ouder dan Linux 2.4. Het heeft een decennium aan extra ontwikkeling achter de rug.

Laten we een voorbeeld uit de echte wereld gebruiken dat vandaag de dag zeer relevant is. Je bevindt je in een bedrijf dat op het punt staat zijn eerste server(s) te installeren. Windows Server 2012 R2 is zojuist uitgebracht. Moet je Windows Server 2008, 2008 R2 (2010), Server 2012 of Server 2012 R2 (eind 2013?) installeren?

Voor veel bedrijven klinkt dit alsof we het hebben over ergens tussen de twee en vier geheel verschillende producten, die waarschijnlijk elk verschillende redenen hebben om te kiezen. Dit is over het algemeen onjuist. Elke nieuwere versie is simpelweg een upgrade, update, patch en functie-uitbreiding van de voorgaande. Elke versie is op zijn beurt geavanceerder en rijper dan de versie die eraan voorafging. Elke nieuwe versie profiteert van het werk dat is verricht aan de oorspronkelijke release van zijn voorganger, alsook van bugfixes, patches en functietoevoegingen die zijn gedaan in de tussenperiode tussen de oorspronkelijke release en de opvolgende release. Elke nieuwe release is in werkelijkheid een “minor release” van de voorgaande. Als we kijken naar de kernelrevisienummers in plaats van naar de marketingnamen van de releases, wordt het misschien begrijpelijker.

Windows Server 2008 was Windows NT 6.0. Windows Server 2008 R2 was Windows NT 6.1, klaarblijkelijk een minor revisie of zelfs een “patch” van de vorige release. Windows Server 2012 was Windows NT 6.2 en ons huidige Windows Server 2012 R2 is Windows NT 6.3. Als we de revisienummers in plaats van de marketingnamen zouden gebruiken, klinkt het bijna krankzinnig om opzettelijk een oude, minder rijpe, minder geüpdatete en minder gepatchte versie te installeren. We willen de nieuwste updates, de nieuwste bugfixes en willen dat de nieuwste beveiligingsproblemen zijn aangepakt.

Voor nieuwe software-uitrollen geldt: hoe nieuwer de geïnstalleerde software, hoe beter de gelegenheid om de nieuwste functies te benutten en hoe meer tijd vóór de onvermijdelijke veroudering haar tol eist. Alle software veroudert, dus het installeren van nieuwere software biedt de beste kans dat die software het langst zal meegaan. Het biedt de beste flexibiliteit voor de onbekende toekomst.

Deze gedachtegang volgend zouden we kunnen denken dat het uitrollen van pre-release- of zelfs bètasoftware eveneens zinvol zou zijn. En hoewel er specifieke gevallen kunnen zijn waarin dit wel zinvol is, zoals in “testgroepen” om software te beproeven voordat deze aan het bedrijf als geheel wordt uitgebracht, is dit over het algemeen niet het geval. De aard van pre-release-software is dat deze niet ondersteund wordt en code kan bevatten die nooit ondersteund zal worden. Het gebruik van dergelijke code in isolatie kan nuttig zijn, maar voor algemeen gebruik wordt het afgeraden. Er zijn belangrijke processen die worden gevolgd tussen preview- of bètareleases en de definitieve releases van code, ongeacht het rijpheidsniveau van het algehele product.

Dat brengt ons bij de andere situatie, die waarin we bestaande software updaten. Dit is uiteraard een volledig ander scenario dan een verse installatie en er zijn veel, veel meer factoren bij betrokken.

Een van de grootste factoren in de meeste situaties is die van licentiëring. Het regelmatig updaten van software kan licentiekosten met zich meebrengen die moeten worden meegewogen in de afweging tussen voordelen en kosten. Sommige producten, zoals de meeste opensourcesoftware, hebben deze kosten niet en kunnen worden geüpdatet zodra nieuwe versies beschikbaar zijn.

De andere werkelijk grote factor bij het updaten van software is een kostenpost in de vorm van menselijke inspanning voor het updaten – anders dan bij een verse installatie, waarbij de installatie-inspanning in feite gelijk uitvalt tussen oude en nieuwe software. In werkelijkheid is nieuwe software doorgaans eenvoudiger te installeren dan oude software, simpelweg vanwege verbeteringen en vooruitgang. Een enkele versie van software gedurende een decennium onderhouden betekent dat er in die tijd geen middelen werden gewijd aan upgradeprocessen. Gedurende die periode jaarlijks upgraden betekent dat er tien keer middelen werden gebruikt om afzonderlijke upgrades uit te voeren. Dat maakt het veel moeilijker om het updaten op grond van kosten te rechtvaardigen. Maar er is meer dan alleen de inspanning van het updateproces zelf; er is ook de voortdurende training die nodig is voor eindgebruikers die door constante upgrades gedwongen worden om meer veranderingen, vaker, te ervaren.

Dit zou updaten als iets negatiefs kunnen doen klinken, maar dat is het niet. Het is simpelweg een vergelijking waarbij elke kant moet worden afgewogen. Regelmatige updates betekenen vaak kleine, incrementele veranderingen in plaats van grote sprongen, waardoor eindgebruikers zich op natuurlijkere wijze kunnen aanpassen. Regelmatige updates betekenen dat updateprocessen vaak eenvoudiger en voorspelbaarder zijn. Regelmatige updates betekenen dat technische schuld altijd beheerst wordt en dat de voordelen van de nieuwere versies – of dat nu functies, efficiëntieverbeteringen of beveiligingsverbeteringen zijn – eerder beschikbaar zijn, waardoor ze gedurende een langere periode kunnen worden benut.

Uit wat we van de twee bovenstaande scenario’s hebben geleerd, valt hier echter nog een belangrijke les te trekken. Zodra de beslissing om een update uit te voeren is genomen, luidt de vraag vaak “naar welke versie updaten we?” In werkelijkheid is echter elke update die meer is dan een standaard patchproces eigenlijk net als een miniatuur-“nieuwe software”-aankoopbeslissing, en de logica achter waarom we “altijd” de nieuwste beschikbare versie installeren bij een verse installatie is ook hier van toepassing. Bij het uitvoeren van een update zouden we dan ook vrijwel altijd zo ver moeten updaten als we kunnen – hopelijk naar de huidige versie.

Om het Microsoft-voorbeeld opnieuw toe te passen: we kunnen een organisatie nemen die vandaag de dag Windows XP heeft uitgerold. Het bedrijf besluit te investeren in een updatecyclus naar een nieuwere versie, niet slechts in voortgezet patchen. Er zijn verschillende versies van het Windows-desktopplatform die nog steeds actief door Microsoft worden ondersteund. Daartoe behoren Windows Vista, Windows 7, Windows 8 en Windows 8.1. Updaten naar een van de minder actuele versies resulteert in minder tijd vóór het einde van de levensduur van die versie, wat het organisatorische risico verhoogt; het gebruik van oudere versies betekent voortgezette investering in reeds oude technologieën, wat een toename van technische schuld betekent en minder toegang tot nieuwe functies die nuttig kunnen blijken zodra ze beschikbaar zijn. In dit specifieke voorbeeld worden nieuwere versies tevens als veiliger beschouwd en vereisen ze minder hardwarebronnen.

Elk bedrijf moet voor zichzelf de juiste balans vinden voor de updatecycli van bestaande software. Elk bedrijf en elk softwarepakket is anders. Enterprisesoftware zoals Microsoft Windows, Microsoft Office of een Oracle Database volgt deze modellen zeer goed. Kleine softwareprojecten en projecten die in de buurt van het maatwerksegment vallen, kunnen een dynamischere en onvoorspelbaardere releasecyclus hebben, maar zullen over het algemeen toch de meeste van deze regels volgen. Overweeg om inlevingsvermogen toe te passen op het softwareontwikkelingsproces om te begrijpen hoe jij en je softwareleverancier het beste kunnen samenwerken om de grootste waarde aan je organisatie te leveren, en combineer dat met je behoefte om technische schuld te verminderen, teneinde je software-investering op de best mogelijke manier voor je organisatie te benutten.

Maar de vuistregels zijn relatief eenvoudig:

Streef bij het uitrollen van nieuwe software of bij het updaten naar de nieuwste redelijke versie van de software. Benut elke gelegenheid tot uitrol om technische schuld zoveel mogelijk te elimineren.

Wanneer software al bestaat, weeg dan factoren zoals menselijke inspanning, licentiekosten, omgevingsconsistentie en compatibiliteitstesten af tegen voordelen op het gebied van functies, prestaties en technische schuld.