- Tenk på et tall

Det er ikke første gang jeg har fått spørsmålet. De som spør forventer et tall, en andel av utviklingskostnadene, typen 14 prosent i året. Noe slikt tall eksisterer ikke. Men vi kan si en hel del likevel.

Det er som med en enebolig. Bruker vi gode materialer, gode håndverkere og legger vekt på at huset skal være lett å vedlikeholde, blir det billigere enn om man ikke gjør det. Mye av et systems vedlikeholdskostnader blir avgjort i designfasen. Er vedlikeholdbarhet en av de såkalte ikke-funksjonelle målsetninger? Eller tenker man bare på å bli fort ferdig?

Det første, avgjørende spørsmålet er: Kommer kravene til å forandre seg mye i systemets antatte levetid? Kravene blir stilt av brukerne, lederne, men også av verden rundt dem. Tar vi bank som eksempel vet vi at en dagligbank har omtrent de samme oppgaver og bedrives på nesten samme måte som for 10-20 år siden. Forskjellen ligger i at flere nye kanaler er kommet til, for eksempel nettbank og mobilbank. Alle dagligbanker i Norge gjør det samme på noenlunde samme måte, men noen er flinkere til å forstå og betjene kundene. De er sterkt detaljregulert av myndighetene, kan ikke gjøre store sprell. Derfor kan norske dagligbanker bruke tyve år gamle kjernesystemer.

Investeringsbanker og verdipapirhandel, det er noe helt annet. De konkurrerer ved å finne på lure produkter og nye måter å utføre oppgavene på. Noen av de mest avanserte finansielle løsningene deres ender i rettssaler som vi har sett i det siste. Her er det snakk om systemer som verken kjøper eller selger gjennomskuer. Investeringsbanker er dynamiske, de beste tjener uhorvelig mye penger. De behøver stadig nye produktsystemer og hyppige endringer.

Langsomme eller raske endringer – de skaper to diametralt ulike situasjoner for vedlikehold av systemer.

Stabile systemer betyr selvfølgelig mindre vedlikehold. Det neste spørsmålet er: Hvilke aktiviteter inkluderer vi i vedlikehold? Det er åpenbart at hvis vi skriver om 50 prosent av et system, snakker vi ikke om vedlikehold, men nyutvikling. Hva er suppe og hva er grøt? Hvor går grensen? Gartner foreslår å dele vedlikehold i fem slag. Det første og mest basale er korrigerende vedlikehold, på godt norsk reparasjon, det vil si å fjerne bugs. Det andre er adapterende vedlikehold, det vil si å tilpasse systemet til nye versjoner av operativsystemet og annen underliggende programvare. Underlaget endrer seg selv om systemet er det samme. Disse to danner grunnmuren, uten dem går det lukt til helvete.

Men så kommer de aktivitetene der systemets eier bør gjøre bevisste valg. Det første er preventivt vedlikehold. Som å male huset hvert femte år eller vente til malingen flasser av. Rette feil og mangler før de blir synlige for all verden. Så har vi perfeksjonerende vedlikehold. Systemet gjør sine oppgaver, men er tregt. Brukerne synes systemet er uforståelig, de gjør mange feil. Å utbedre slike svakheter er også vedlikehold. Og så den siste biten: Små forbedringer her og der. Det er alltid noe å rette på hvis man har øyne å se med.

Den som vil vite hvor mye vedlikehold av et datasystem vil koste må ha oppfatninger om hvilke av disse fem elementer som skal inkluderes og i hvilke mengder. Et viktig tema er tidshorisonten. De første fem år er lettere og viktigere å anslå enn de neste ti. Det er rimelig å anta at mesteparten av vedlikeholdet vil falle i de første årene etter at systemet er satt i drift. Deretter vil det enten blitt godt nok eller kassabelt. Kanskje det er direkte meningsløst å se 15 år frem, verden vil være ny til den tid.

Selvfølgelig vil kompetansen hos dem som skal gjøre vedlikeholdet ha mye å si. Klassikeren er at hver gang en bug blir rettet, blir en ny introdusert. Det kommer ofte av tidspress og manglende kunnskaper om hvordan systemet er ment å virke. Det er ikke bare å hente inn en mann fra gata, men vedlikehold blir ofte tildelt dem som ikke er på prosjekt. Neste gang er det noen andre som får jobben. Ustabil arbeidskraft er roten til mye ondt.

En ting som er temmelig sikkert er at vedlikehold og drift over en tiårsperiode vil utgjøre mye mer enn det koster å utvikle og utrulle den første versjonen.

Er du med meg så langt, er resten vanlig, detaljert analysearbeid. Arbeid som svært ofte ikke blir utført.

Og er du med meg så langt, tror jeg du vil være enig i at et slikt nøkkeltall som 14 prosent i året ikke eksisterer.