Kluddermor!
På det seneste har jeg arbejdet med et projekt, som gav mig mindelser om en leg, vi legede i skolegården: Alle deltagerne på nær én tog hinanden i hænderne i en kreds og filtrede sig derefter mest muligt ind i hinanden uden at slippe naboens hænder. Det var nu “kluddermor”’s opgave at forsøge at rede trådene ud.
Sådan kan det føles, når man forsøger at analysere et kompliceret IT-landskab, som har rødder 20, 30, 40, ja måske 50 år tilbage i tiden. Undervejs er der sket mange knopskydninger og nyudviklinger. Mange beslutninger var muligvis rigtige, da de blev truffet, men resultatet fungerer nu som dødvægt i forhold til fremtidig udvikling. Vedligeholdelsesbyrden stiger, og forretningen bliver låst til de arbejdsgange, der er implementeret i de gamle systemer.
Hvordan får vi ryddet op? Problemet er enormt, ikke mindst for de store, gamle statslige systemer, hvor dokumentationen mangler, og specialisterne er gået på pension. Jeg tror ikke, at det er noget tilfælde, at staten har undladt at udbyde driften af de store systemer i årevis. Jeg er bange for, at ingen er i stand til at beskrive den opgave, der skal udbydes. Der er systemer, man ikke tør pille ved, fordi man ikke kan overskue konsekvenserne. Nogen kalder det "teknisk gæld".
I visse TV-programmer udstiller man folk, hvis private rod er vokset til et så uoverstigeligt problem, at de må have professionel hjælp til at rydde op. De fleste voksne ryster på hovedet af det og ved, at for at undgå at havne i den situation, er man nødt til at rydde op løbende. Det gælder også, selv om man må bruge lidt tid på det hver dag. Det samme gælder IT-arkitektur. Et simpelt eksempel:
Lad os sige, at man for længe siden har udviklet en IT-løsning, der opfylder et formål. Nu skal man udvikle en ny løsning til et formål, som ligner, men som ikke er helt det samme. Måske ser man ikke sammenhængen og genopfinder derfor den dybe tallerken. Måske ser man sammenhængen, men har travlt, og kopierer derfor bare koden fra den gamle løsning og retter lidt til.
På den lange bane vil det imidlertid - set ud fra et arkitektursynspunkt - være bedst at foretage et tilbageløb, når man opdager potentialet for genbrug. Man kan med fordel udskille den genbrugelige funktionalitet i en selvstændig komponent, som bliver anvendt både af den gamle, den nye og eventuelt fremtidige løsninger. En lille oprydningsopgave. Fremover kan man nøjes med at vedligeholde en komponent, i stedet for at man skal vedligeholde næsten-identisk kode i flere forskellige løsninger.
Men det kan være svært at få en sådan oprydningsopgave finansieret. Når nu den gamle løsning kører fint, hvorfor så røre ved den? Og når nu man kan fremstille den nye løsning billigt ved at kopiere koden fra den gamle løsning og rette den til, hvorfor så fordyre projektet ved at etablere en selvstændig komponent? Det gør ikke finansieringen lettere, hvis de to løsninger ejes af forskellige forretningsenheder. Og måske har forretningen svært ved at forstå, at to forskellige konkrete problemstillinger faktiske er den samme abstrakte problemstilling. Hvad har reservation af bøger fx at gøre med bookning af mødelokaler?
I en business case ser man på omkostninger og gevinster i forhold til, hvad det ville koste at videreføre den nuværende situation (nulscenariet). Men hvordan behandler man en sådan oprydningsopgave i en business case? Typisk omfatter business casen kun den nye løsning, og den bliver ikke i sig selv billigere at udvikle ved at udskille den genbrugelige del i en komponent, snarere tværtimod.
Den synlige gevinst ved den skitserede oprydningsopgave kan være billigere vedligehold på de to løsninger, samlet set. Det kan man måske godt værdisætte. Men den store gevinst på den lange bane er, at alle fremtidige løsninger, som kan anvende den genbrugelige komponent, bliver både billigere og hurtigere at udvikle, hvilket gør forretningen mere fleksibel. Det er ikke så konkret, at det kan værdisættes - især fordi man ikke kender fremtidige behov.
Derfor fortsætter man ofte med at kopiere/tilrette og træffe andre kortsigtede beslutninger, indtil ens systemlandskab er en stor portion kluddermor … og på et eller andet tidspunkt bryder det hele sammen. Ingen kan mere overskue, hvad der foregår.
Regnestykket ville se anderledes ud, hvis den gamle løsning var afskrevet og indgik med værdien nul. Hvis vi skulle udvikle begge løsninger fra bunden, ville det være oplagt at strukturere den samlede løsning som en komponent med to anvendelser. Det ville give en helt anden business case. Forskellen på de to regnestykker er, at man i dag de-facto tillægger den gamle løsning en positiv værdi, uanset hvor gammel den er ... fordi den af forretningen opfattes som bedre end ingenting. Men i forhold til IT-arkitekturen kan en gammel løsning være en klods om benet og dermed være værre end ingenting.
Derfor mener jeg, at man må være mere konsekvent i forhold til at afskrive IT-løsninger. Efter afskrivningsperioden må værdien af en gammel IT-løsning ikke længere påvirke udfaldet af en ny business case, men skal ignoreres. Oven i købet kunne man lade afskrivningsperioden afhænge af arkitekturen på løsningen. Hvis man investerer lidt mere i at opdele i pæne, veldokumenterede og genbrugelige komponenter, kan man få lov at afskrive over en længere periode.
Man bør også afsætte midler i et årligt vedligeholdelsesbudget for enhver løsning til løbende renovering og oprydning. I eksemplet ovenfor ville der i så fald findes midler til omstrukturering af den gamle løsning.
En business case er i princippet et godt redskab til at styre, hvilke løsninger der skal udvikles, og hvilke der skal blive ved tanken. Kan IT-løsningen ikke tjene sig selv hjem i løbet af afskrivningsperioden, er business casen negativ, og så skal man nok lade projektet fare. Mange IT-løsninger burde aldrig have været udviklet.
Men forudsætningen for en troværdig business case er, at værdiansættelserne af omkostninger og gevinster afspejler virkeligheden. Gevinsterne ved en fleksibel og vedligeholdelsesvenlig IT-arkitektur skal værdsættes. Udgifter til løbende vedligeholdelse (inkl. oprydning) må ikke undervurderes, og en i princippet afskrevet løsning må ikke de-facto tillægges værdi, således at den bliver dødvægt i forhold til fremtidig udvikling.
Ellers fortsætter "kluddermor"-legen i det uendelige ... indtil det bryder sammen.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
