Valg af softwareversioner til udrulning

Noget jeg ser diskuteret meget ofte i IT-kredse er "hvilken version af software skal jeg installere." Dette kan gælde en database, en applikation, firmware eller, sandsynligvis oftest, operativsystemer, og med den kommende ophøring af supportlivscyklus for Windows XP har emnet nået et kogende punkt.

Der er reelt to sider i denne diskussion. Den ene side mener, at den nyeste og formodentlig bedste software altid bør bruges. Den anden mener, at software skal modnes og anlægger en "vent og se"-tilgang eller betragter endda hver version som et separat produkt og ikke en kontinuitet i udviklingen.

Begge tilgange har deres fordele, og ingen af dem bør eksistere helt uden den anden. Blind opdatering af software uden eftertanke er ikke klogt, og undgåelse af patches og opdateringer uden grund er heller ikke klogt. Omhyggelig overvejelse af faktorerne og forståelse for softwareudviklingsprocessen er vigtig at have i tankerne, når man træffer disse beslutninger.

Først er der to helt forskellige scenarier at overveje. Det ene er opdatering af eksisterende, aktuel software. Med den antagelse at den aktuelle tilstand "virker", med den accepterede mulighed at "virker" kan inkludere en sikkerhedssårbarhed, der er blevet opdaget og kræver opdatering for at lukke. Det andet scenarie er en ny udrulning, hvor der ikke er noget i forvejen, og vi starter fra bunden.

Lad os starte med det andet tilfælde, da det er langt lettere at give vejledning om.

I tilfælde af nye softwareudrulninger (eller nye operativsystemer) skal man altid bruge den aktuelle, nyeste version af softwaren, medmindre der er en klart kendt teknologibegrænsning, der forhindrer det – såsom kendte fejl eller softwareinkompatibiliteter.

Software er ikke som andre typer produkter, især ikke i nutidens verden med online patch-udgivelser og opdateringer. Jeg antager, at mentaliteten om, at ældre versioner af software måske er at foretrække frem for aktuelle, stammer fra en kombination af fysiske produkter (ure, biler, tallerkener, møbler, vin), hvor et bestemt år eller en bestemt model kan være overlegen over for en nyere model af forskellige årsager, og fra ældre softwareleveringsmetoder, hvor færdige softwareprodukter simpelthen blev "kastet over hegnet", og den endelige tilstand var, ganske enkelt, den endelige tilstand uden nogen rimelige muligheder for opdateringer, patches eller rettelser. Ingen af disse tilfælde gælder for moderne forretningssoftware (med kun de sjældneste undtagelser.)

Softwareudvikling er groft sagt en kontinuitet. Normale udviklingsprocesser indebærer, at ny software bygges oven på gammel software enten direkte (ved at oprette opdateringer til en eksisterende kodebase) eller indirekte (ved at genopbygge baseret på viden opnået fra at have bygget en tidligere version af softwaren.) Idéen er, at hver efterfølgende version af softwaren er overlegen over den foregående. Dette er ikke garanteret; der findes begreber som regressionsfejl og dårlig udvikling, men overordnet set forbedres software over tid – især når vi taler om enterprise-klasse software brugt i virksomheder og under aktiv udvikling. Ny software er ikke kun den næste fase af den gamle software; den repræsenterer også, i næsten alle tilfælde, den aktuelle tilstand af patches, fejlrettelser, opdateringer og, når det er nødvendigt, ændringer i tilgang eller teknik. Ny software, fra kvalitetsvirksomheder, er næsten udelukkende bedre end gammel software. Software udvikler sig og modnes.

Ud over selve softwarekvaliteten er der begrebet at investere i fremtiden. Software er ikke noget, der kan stå på hylden for evigt. Det skal i et vist omfang holdes opdateret, ellers holder det op med at fungere, fordi den platform, det kører på, ændres, der opstår nye artefakter, sikkerhedshuller opdages, eller behov ændrer sig. Installation af gammel software betyder en investering i fortiden – en investering i at installere, lære, bruge og understøtte gammel teknologi. Dette kaldes "teknisk gæld." Denne gamle teknologi kan holde i årevis eller endda årtier, men gammel software mister værdi over tid og bliver stadig dyrere at understøtte, både for leverandørerne, hvis de fortsætter med at understøtte den, og for slutbrugerne, der skal understøtte den.

Det samme begreb om teknisk gæld gælder for de pågældende softwareleverandører. Der er en meget stor omkostning ved at skabe software og især ved at vedligeholde flere versioner af den software. Softwareleverandører har et stort incitament til at reducere support for ældre versioner for at fokusere ressourcer på aktuelle softwareudgivelser (dette er en vigtig grund til, at SaaS-udrulninger er så populære – leverandøren kontrollerer de tilgængelige versioner og kan eliminere legacy-versioner gennem opdateringer.) Hvis kunder kræver support for gamle versioner, skal omkostningerne absorberes et sted, og det absorberes ofte både som en monetær påvirkning for alle kunder og som et fald i fokus på det nye produkt, da udviklingsteams skal deles for at understøtte patching af gamle versioner samt at udvikle det nye. Jo mere indsats der skal gå i gamle versioner, jo mindre indsats kan der lægges i nye forbedringer.

Inden for rammerne af det, jeg allerede har sagt, er det vigtigt at tale om kodemodning. Kodemodning angives ofte som en grund til at implementere "gammel kode", men jeg mener, at dette er en IT-misforståelse af softwareudviklingsprocesser. Hvis vi tænker på en frigivet kodelinje, gør det den ikke virkelig mere moden blot fordi den er frigivet og i brug. Kode ændrer sig ikke i naturen; den sidder bare der. Dens modenhed er "låst" på den dag, den frigives. Hvis den patches, ville den jo "modnes" efter frigivelse. Senere versioner af den samme software, baseret på den samme kodebase men mere opdateret, er virkelig den mere "modne" kode, da den er blevet gennemgået, opdateret, testet osv. i langt højere grad end den tidlige udgivelse af den samme kode.

Dette er kontraintuitivt i forhold til, siger vi, en bil, hvor hvert udgivelsesår er en frisk ting med nye muligheder for mekaniske problemer og forskellige pålidelighedsproblemer – hvor ventetid giver dig en chance for at se, hvilke pålidelighedsproblemer der afdækkes. Software er ikke sådan. Så ønsket om mere moden software ville skubbe dig mod at implementere det "nyeste og bedste" snarere end det "velkendte og afprøvede."

Hvis vi tænker på softwareversionsnumre lidt som aldre, fremgår dette tydeligt. Linux 3.1 er meget ældre, med hensyn til softwaremodning, end Linux 2.4. Det har et årti med yderligere udvikling.

Lad os bruge et eksempel fra den virkelige verden, der er meget relevant i dag. Du er i en virksomhed og er ved at installere dine første servere. Windows Server 2012 R2 er netop udgivet. Skal du installere Windows Server 2008, 2008 R2 (2010), Server 2012 eller Server 2012 R2 (sen 2013)?

For mange virksomheder lyder dette som om, vi taler om et sted mellem to og fire helt forskellige produkter, der sandsynligvis har forskellige grunde til at vælge hvert enkelt. Dette er overordnet set usandt. Hver nyere version er blot en opgradering, opdatering, patch og funktionsforøgelse af den foregående. Hver ny version er til gengæld mere avanceret og moden end den foregående. Hver ny version drager fordel af det arbejde, der er gjort på den originale udgivelse af dens forgænger samt fejlrettelser, patches og funktionsadditioner, der er foretaget i mellemtiden mellem den originale udgivelse og efterfølgerudgivelsen. Hver ny udgivelse er i virkeligheden en "minor release" af den foregående. Hvis vi ser på kernerevisionsnumrene i stedet for de markedsføringsmæssige navne på udgivelserne, giver det måske mere mening.

Windows Server 2008 var Windows NT 6.0. Windows Server 2008 R2 var Windows NT 6.1, åbenlyst en minor revision eller endda en "patch" af den foregående udgivelse. Windows Server 2012 var Windows NT 6.2, og vores nuværende Windows Server 2012 R2 er Windows NT 6.3. Hvis vi brugte revisionsnumrene i stedet for markedsnavnene, ville det lyde næsten vanvittigt bevidst at installere en gammel, mindre moden, mindre opdateret og mindre patchet version. Vi ønsker de seneste opdateringer, de seneste fejlrettelser og de seneste sikkerhedsproblemer adresseret.

For nye softwareudrulninger er jo nyere den installerede software er, jo bedre mulighed er der for at udnytte de nyeste funktioner og jo mere tid er der, inden uundgåelig forældelse tager sin tol. Al software ældes, så installation af nyere software giver den bedste chance for, at den software holder i længst mulig tid. Det giver den bedste fleksibilitet for den ukendte fremtid.

At følge denne tankegang kan få os til at føle, at det ville give mening at implementere pre-release eller endda betasoftware. Og selvom der kan være specifikke tilfælde, hvor dette giver mening, f.eks. i "testgrupper" for at tjekke software ud, inden den frigives til virksomheden generelt, gælder det generelt ikke. Karakteren af pre-release software er, at den ikke er understøttet og kan indeholde kode, der aldrig vil blive understøttet. Brug af sådan kode isoleret set kan være gavnligt, men til generel brug frarådes det. Der er vigtige processer, der følges mellem preview- eller betaudgivelser og endelige udgivelser af kode, uanset hvilket modningsniveau det overordnede produkt befinder sig på.

Det bringer os til den anden situation, den hvori vi opdaterer eksisterende software. Dette er naturligvis et helt andet scenarie end en frisk installation, og der er mange, mange flere faktorer involveret.

En af de største faktorer i de fleste situationer er licensering. Regelmæssig opdatering af software kan medføre licensgebyrer, der skal indregnes i fordele- og omkostningsligningen. Nogle produkter, som de fleste open source-software, har ikke denne omkostning og kan opdateres, så snart nye versioner er tilgængelige.

Den anden virkelig store faktor ved opdatering af software er en menneskelig indsatsomkostning ved opdatering – i modsætning til en frisk installation, hvor installationsindsatsen reelt er et break-even mellem gammel software og ny. I virkeligheden har ny software en tendens til at være nemmere at installere end gammel software simpelthen på grund af forbedringer og fremskridt. At vedligeholde en enkelt version af software i et årti betyder, at ressourcer ikke var dedikeret, i den tid, til opgraderingsprocesser. At opgradere årligt i den tid betyder, at ressourcer bruges ti gange til at gennemføre separate opgraderinger. Det gør opdatering meget sværere at retfærdiggøre omkostningsmæssigt. Men der er mere end blot indsatsen fra selve opdateringsprocessen; der er også den løbende træning, der er nødvendig for slutbrugere, der vil blive tvunget til at opleve flere ændringer, oftere, gennem konstante opgraderinger.

Dette kan få opdatering af software til at lyde negativt, men det er det ikke. Det er simpelthen en ligning, hvor hver side skal vejes. Regelmæssige opdateringer betyder ofte små, trinvise ændringer snarere end store spring, hvilket giver slutbrugere mulighed for at tilpasse sig mere naturligt. Regelmæssige opdateringer betyder, at opdateringsprocesser ofte er nemmere og mere forudsigelige. Regelmæssige opdateringer betyder, at teknisk gæld altid håndteres, og fordelene ved de nyere versioner, som kan være funktioner, effektivitetsforbedringer eller sikkerhedsforbedringer, er tilgængelige hurtigere, hvilket giver mulighed for at udnytte dem i en længere periode.

Med udgangspunkt i det, vi har lært af de to scenarier ovenfor, er der dog endnu en vigtig pointe at finde her. Når beslutningen om at foretage en opdatering er truffet, er spørgsmålet ofte "til hvilken version opdaterer vi?" I virkeligheden er enhver opdatering, der er mere end en standard patch-proces, virkelig som en mini-"ny software"-indkøbsbeslutning, og logikken om, hvorfor vi "altid" installerer den nyeste tilgængelige version, når vi foretager en frisk installation, gælder også her. Så når vi foretager en opdatering, bør vi næsten altid opdatere så langt vi kan – forhåbentlig til den aktuelle version.

For at anvende Microsoft-eksemplet igen kan vi tage en organisation, der har Windows XP implementeret i dag. Virksomheden beslutter at investere i en opdateringscyklus til en nyere version, ikke blot fortsat patching. Der er flere versioner af Windows desktop-platformen, der stadig er under aktiv support fra Microsoft. Disse inkluderer Windows Vista, Windows 7, Windows 8 og Windows 8.1. Opdatering til en af de mindre aktuelle versioner resulterer i kortere tid, inden den versions supportophør, hvilket øger organisationsrisikoen; brug af ældre versioner betyder fortsat investering i allerede gammel teknologi, hvilket betyder en stigning i teknisk gæld og mindre adgang til nye funktioner, der kan vise sig at være gavnlige, når de er tilgængelige. I dette specifikke eksempel anses nyere versioner også for at være mere sikre og kræve færre hardwareressourcer.

Enhver virksomhed skal finde den rette balance for dem for eksisterende softwareopdateringscyklusser. Enhver virksomhed og ethvert softwarepakke er forskellig. Enterprise-software som Microsoft Windows, Microsoft Office eller en Oracle Database følger disse modeller meget godt. Små softwareprojekter og dem, der nærmer sig bespoke-området, kan have en mere dynamisk og uforudsigelig udgivelsescyklus, men vil generelt stadig følge de fleste af disse regler. Overvej at anlægge empati over for softwareudviklingsprocessen for at forstå, hvordan du og din softwareleverandør bedst kan samarbejde om at levere den største værdi til din organisation, og kombiner det med dit behov for at reducere teknisk gæld for at udnytte din softwareinvestering på den bedst mulige måde for din organisation.

Men tommelfingerreglerne er relativt enkle:

Når du implementerer ny software eller opdaterer, sigt mod den nyeste rimelige version af softwaren. Brug enhver implementeringsmulighed til at eliminere teknisk gæld så meget som muligt.

Når software allerede eksisterer, afvej faktorer som menneskelig indsats, licensomkostninger, miljøkonsistens og kompatibilitetstest mod fordele i funktioner, ydelse og teknisk gæld.