Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Der er alt for mange eksempler på, at forældede it-projekter ender med at koste tid og penge til service og vedligeholdelse, selvom de for længst burde være lukket ned.
Ansvarlig it-udvikling handler ikke kun om at skabe morgendagens fantastiske løsninger. Det handler også om at planlægge, hvordan du lukker løsningen ned.
Og det skal du faktisk starte med at gøre.
It-konsulenter og it-arkitekter finder naturligt nok glæde ved at skabe og udvikle morgendagens digitale løsninger.
Vi drømmer om at optimere processer og effektivisere, og naturligvis udvikler vi noget, som opfylder folks behov i mange år – eller gør vi?
Igen og igen ser vi, at løsninger bliver forældede, at krav til funktionalitet skifter, og at it-systemer skal aflives og lukkes ned. Desværre er den sidste del af processen ofte ikke gennemtænkt fra begyndelsen, og det kan ende med at blive meget dyrt for både offentlige og private organisationer.
Kravene til opbevaring og tilgængelighed af data er steget i de senere år. GDPR har udbredt kravet om, at brugere skal kunne få oplysninger om, hvorvidt en virksomhed/organisation har personoplysninger liggende om brugeren, som så har ret til at få indsigt i oplysningerne.
Der kan også være krav om opbevaring af “bevaringsværdige” data i flere år, eller andre regler, som skal overholdes. Altsammen krav, som betyder, at man ikke bare kan løbe videre til næste projekt, hvis noget ikke fungerer optimalt.
Service og vedligeholdelse af halvdøde projekter kan blive en høj omkostning, som ofte ikke var medregnet fra starten.
“Brug det nedlukkede system, please”
Vores branches innovationsevne er bredt anerkendt, men så sker det også, at der nogle gange bliver udviklet systemer, som er bedre og hurtigere end de nuværende.
Og derfor skal systemer kunne lukkes ned, så noget nyt og bedre kan tage pladsen.
I UK er der eksempler på, at data i store offentlige projekter ikke er blevet isoleret til det konkrete projekt, men bliver brugt i andre digitale services eller statistiske sammenhænge, og derfor reelt ikke kan lukkes ned.
I hvert fald ikke uden at der sættes betragtelige ressourcer af til at flytte data over på nye platforme, som lever bedre op til de nye behov.
Da der i UK blev indført gratis skolemad til alle elever under en vis alder, var der ikke længere brug for et system til at ansøge om gratis skolemad.
Men data fra det oprindelige system blev brugt til mange andre formål, for eksempel særlige ydelser og statistik over børnefattigdom mm.
Derfor endte man i den bizarre situation, at familierne blev opfordret til ansøge om en ydelse, som de allerede fik.
Det var i praksis blevet svært at lukke systemet, selv om det fra et brugerperspektiv ikke længere gav mening. Vi kan ryste på hovedet, men det er ikke usandsynligt, at noget lignende kan foregå i Danmark.
Planlæg nedlukning fra starten
Det handler om, at kunne skille services og data ad i de dele, som de naturligt udgør.
Spørg dig selv i starten af et projekt: Hvis vi lukker denne delproces i løsningen, kan vi så også fjerne de data, der vedrører delprocessen?
Hvis vi senere tilføjer en proces, kan vi så slette den igen? Og kan den delproces skilles ud og leve videre uden det oprindelige system?
Uden sammenligning til skolemaden i UK, så arbejder man i Danmark med gamle data hos Arbejdsmarkedets Erhvervssikring (AES) under ATP, som hvert år håndterer omkring 50.000 sager om arbejdsskader.
Sagsbehandlingen er tidligere foregået i et 30 år gammelt DOS-baseret it-system, men nu er det aflivet og sagsbehandlingen er flyttet over på en ny it-løsning. Og det er jo rigtig godt.
Men gennem årene har data hobet sig op i systemet, fordi det i mange tilfælde er nødvendigt at gemme data om arbejdsskaderne. Aflivningen tager derfor flere år, blandt andet fordi store mængder data skal sendes til Rigsarkivet for eftertiden.
Pointen i dette eksempel er, at man sjældent bare kan slukke på stikkontakten, men skal bruge tid og penge på at lukke systemer ned og sikre at data, som bliver brugt i andre sammenhænge, kan leve videre.
Og den del af budgettet skal man huske, når man starter et projekt, eller især når man begynder at bruge data i et system til andre formål, end de oprindeligt var tiltænkt.
Der kan være mange gode grunde til, at aflivning af it-projekter kan blive nødvendigt.
Det kan være ændringer af den overordnede strategi, nye og smartere løsninger i markedet, men også systemnedbrud og sårbarhed over for hackerangreb kan gøre nedlukninger nødvendige.
Som designere af fremtidens løsninger er det vigtigt, at vi spørger os selv, om om de løsninger vi udvikler nu er med til at skabe morgendagens problemer?
Tænk på hvor mange business cases, der aldrig indfries, fordi der er en “long tail” af gamle databaser, systemer og services, der gør det besværligt at migrere til nye platforme, som f.eks MS Azure eller AWS.
Hvad er løsningen?
Nogle nøgleord er at forebygge “technical debt” og “design debt”, og tænke mere i Service Design end “bare” i UX, så man får helheden og livscyklus for løsningen med i udviklingsprocessen.
Og så handler det lavpraktisk om at spørge sig selv:
“Hvordan vil vi skille denne service ad, hvis det bliver nødvendigt?”
Dette simple spørgsmål, tidligt i processen, kan gøre en kæmpe forskel og introducere designs som er mere fleksible, nemmere at vedligeholde og nemmere at skille ad, hvis det bliver nødvendigt.
Instagram benytter sig af af hvad de kalder ”unshipping”, der som navnet antyder er en “antidote” til det mantra i den digitale verden der siger, at det er godt at levere nyt og mere i en konstant strøm.
Hvilken sletning af en feature, skal du fejre næste gang?
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
