Lise Gerd Pedersen bloghoved

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.

Relateret indhold

Lise Gerd Pedersens billede
Lise er selvstændig it- og enterprise-arkitekt (www.archit.dk). Hun har arbejdet professionelt med it - tilfældigvis især offentlig IT - siden 1980, både på leverandørsiden og som offentligt ansat.

Kommentarer (11)

Kommentarer (11)
Jan Ferré

Dette er en sjældent smuk og velstruktureret beskrivelse af et desværre alt for hyppigt problem - både ved store programkomplekser og ved små utilities.

Om løsningsforslaget så vil løse problemet kan jeg ikke gennemskue, men det er et godt bud.

Henrik Sørensen

Så vidt jeg kan huske, har man i Estland en No Legacy paragraf i lovgivningen. Paragraffen siger, at når et it-system er blev 13 (?) år så må man ikke længere bruge penge på at udvikle eller vedligeholde systemet, men man skal i stedet skrive det om fra bunden.

Rationalet er, at man derved undgår den situation artiklen beskriver og samtidig sikrer at interfaces, sikkerhed mv. bliver bragt op til dagens standarder.

Noget lignende ville være måske være relevant i Danmark... hvad synes du?

Bente Hansen

Noget lignende ville være måske være relevant i Danmark... hvad synes du?


Latterligt forslag.
Og hvorfor skal Interface være op til dagens standard. Windows og Tablet GUI, er på mange måde blevet sværet at bruge, og lagt mere rodet. Hvis du skal slå OneDrive fra, skal du ind 6-7 steder. At noget er nyt, er ikke det samme som at det virker bedre.

Sikkerhed er jo ikke bedre i et nyt system, snarere omvendt. Hvis sikkerhed har været en del af systemets ide fra starten. Så findes der per definition jo flere huller og fejl i nye system.

Et sunds eftersyn er vel altid på plads, om tingene er 20 år eller 1 månede. Min XP system levet længere end 13 år, og min Win8 levet under en uge.

Skal Linux kerne smides ud, fordi den nu er gammel, har vundet indpas mange stedet. Og der er god understøttelse i hardware. Samt meget software og andet til den. Selv om dele af softwaren, sikkert er skrevet om fra bunden flere gange gennem tiden, så smider man jo ikke det hele ud, bare fordi det er blevet moden og dermed mere færdig.

Men du vil sikkert kunne få en stilling i Microsoft, hver gang de har et produkt, som er nogenlunde stabil, og synes moden og færdigt. Så starter de forfra hver gang.

Lise Gerd Pedersen Blogger

Noget lignende ville være måske være relevant i Danmark... hvad synes du?

Det var en interessant oplysning, som fik mig til at google lidt videre. Det er vist ikke lov i Estland, men et vejledende princip ... men alligevel. Blot det officielt at erkende problemstillingen er et fremskridt.

Jeg fandt også ud af, at EU-kommissionen har udarbejdet en handlingsplan for e-forvaltning 2016-2020. Så sent som i en roadmap i november 2015 stod der som et nyt princip: no legacy principle: no infrastructures or applications older than 15 years should be kept.

Men i den endelige udgave er det blødet op til: The Commission will assess the implication of a possible implementation of the 'no legacy principle' (renew IT systems and technologies after a certain amount of time, to keep in line with the ever-changing environment and development of technology) in public administrations.

Det er nok svært at sætte meget firkantede regler op på dette område. Internettet er for eksempel mere end 15 år gammelt ;-)

Lasse Mølgaard

Det er nok svært at sætte meget firkantede regler op på dette område. Internettet er for eksempel mere end 15 år gammelt ;-)

Apropos Internettets alder: Lige denne pasus falder ned i en af mine kæpheste.

... Hvor gammel er IPv6...? :-)

Så vidt jeg kan se var protokollen defineret i 1998, men det er besynderligt få internetudbyder, der lige nu tilbyder IPv6 til private, selvom IPv4 har haft sin besøgstid.

Og det til trods for der er skrevet rigtigt meget om "Internet of things", som skulle være det næste store eventyr. Dog kan vi ikke komme rigtig i gang med det, på grund af at der er ikke nok ledige IP adresser.

Man kan ikke gøre andet end at undre sig.

Jesper Frimann

Problemet med business cases er, at set i en Enterprise Architecture kontekst, der bliver en business case ekstrem kompleks. Lise skriver det jo ret tydeligt "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."

Så hvis man skal kunne løse dette med en Business case som et tool, så vil man ofte skulle lave en business case, der er så kompleks, at den defacto er ubrugelig. Hvis man KUN bruger business cases til at udvikle og advance sin IT, så kommer man netop i den situation som Lise beskriver. Netop fordi business cases som regel kun udviklet på et 'taktisk' niveau. Altså for enkelt projekter.
Min personlig holdning er, at det er jo derfor at man skal have Enterprise Arkitektur. Hvis man har en god EA funktion, så vil du have arkitektur principper (Som Henrik Sørensen jo nævner et glimrende eksempel på), der så at sige står over business casen. Så hvis man har Arkitektur princip der siger, at legacy der opfylder kriterie X,Y og Z skal erstattes af nyt, så løser man problemet med, at man ikke kan formulere en business case for det, fordi det er for komplekst. Husk på at Arkitektur principper på EA plan er takket af med og har Direktionens opbakning.

Arkitektur principper behøver så ikke, nødvendigvis at være lavet på baggrund af en business case. Men kan være, hvad man kan kalde IT arkitektur faglig sund fornuft. Og hvor begrundelsen måske er lidt usubstantiveret.

Et godt eksempel på at det umålbare kan være det rigtige er at, nu hvor jeg har brugt alt for meget af weekenden på at se NFL draft (altså hvor holdene i Amerikansk fodbold vælger nye spillere i et super planøkonomisk system) så kører jeg lidt videre i den rille, der snakker man tit om at en spiller har 'The intangibles'. Altså det umålbare som skal til. Presse dækningen af den her draft (valg af spillere) kører meget på 'Hvor hurtig løber de 40 yards', hvor meget kan de bænkpresse, hvor høje er de, hvad vejer de, hvem er de i familie med etc. etc. altså det målbare om spillerne. Men alligevel så snakker man om at det vigtigste er 'The Intangibles'. Altså det man ikke kan måle veje og beskrive.
Og det bedste eksempel på, at der er noget om dette, er nok bedste beskrevet i et tweet fra sidste års vindende Quater back (Generalen på angrebet), som lød

#199 + #232 + 5 undrafted in the huddle = #51 (trophy emoji).

Altså at på et af de vindende spil på den største scene i sidste års "World Championship game", der var der fra det vindende hold, en som var valgt nr. 199 en nr. 232 og fem der slet ikke var gode nok til at blive valgt i draften. Altså spillere, som på det målbare ikke var gode nok til at blive valgt tidligt. Men som når det galdt om at vinde.. havde hvad der skulle til.

Så med gode Arkitektur principper og selvfølgelig EA, så kan man IMHO overkomme behovet for at kunne lave en business case from hell, på det som man godt ved som erfaren fagperson.. er det rigtige.

// Jesper

Lise Gerd Pedersen Blogger

Husk på at Arkitektur principper på EA plan er takket af med og har Direktionens opbakning. Arkitektur principper behøver så ikke, nødvendigvis at være lavet på baggrund af en business case. Men kan være, hvad man kan kalde IT arkitektur faglig sund fornuft. Og hvor begrundelsen måske er lidt usubstantiveret.

Gid det var så vel. Virkeligheden i en DJØF-styret organisation kan imidlertid være, at der i beslutningslaget ikke er forståelse for "faglig sund fornuft" og generelt manglende kendskab til EA. Her er det kun økonomiske argumenter, der tæller. Business cases!

Men, Jesper, vi er formentlig enige om, at der er god økonomi i at tænke EA! Så der burde ikke være modstrid mellem EA og økonomer. Det handler (igen) om kompetence og formidling. Indtil der kommer mere faglig kompetence på ledelsesgangen, er vi nødt til at spille på økonomernes banehalvdel.

Somme tider spekulerer jeg på, om det er en god business case at udarbejde business cases ... for noget, som man med "faglig sund fornuft" kan se, skal gøres.

Jesper Frimann

Gid det var så vel. Virkeligheden i en DJØF-styret organisation kan imidlertid være, at der i beslutningslaget ikke er forståelse for "faglig sund fornuft" og generelt manglende kendskab til EA. Her er det kun økonomiske argumenter, der tæller. Business cases!

Ja, og i mange store private virksomheder, er 'pattern'et' det samme.

Men, Jesper, vi er formentlig enige om, at der er god økonomi i at tænke EA! Så der burde ikke være modstrid mellem EA og økonomer. Det handler (igen) om kompetence og formidling. Indtil der kommer mere faglig kompetence på ledelsesgangen, er vi nødt til at spille på økonomernes banehalvdel.

Jup. Det er vi enige om. Selvfølgelig behøver EA ikke at være 'det store forkromede', især ikke i mindre virksomheder, hvor EA ofte kan være implementeret af, at man simpelt hen har en konsensus om 'hvordan man gør tingene'.

Jeg mener så ikke at du behøver IT-faglig kompetence på ledelsesgangen, for at have EA. Det du behøver, IMHO, er respekt for fagligheden i IT. Altså at du som ledelse skal forstå, at hvis IT betyder noget for virksomheden (eller styrelse eller ..) så skal du sætte kompetente folk med IT-baggrund til at udforme IT-strategien og have indflydelse på hvorledes denne eksekveres.

Ellers så går det galt . Og IMHO.. så er det reglen at det går galt.. ikke undtagelsen.

Og ja.. vi skal have mad på bordet.. så ja.. selv om det ofte er frustrerende, så må vi bare gøre vores bedste.

Somme tider spekulerer jeg på, om det er en god business case at udarbejde business cases ... for noget, som man med "faglig sund fornuft" kan se, skal gøres.

Heh.. ja :)=

// Jesper

Lise Gerd Pedersen Blogger

Jeg mener så ikke at du behøver IT-faglig kompetence på ledelsesgangen, for at have EA. Det du behøver, IMHO, er respekt for fagligheden i IT. Altså at du som ledelse skal forstå, at hvis IT betyder noget for virksomheden (eller styrelse eller ..) så skal du sætte kompetente folk med IT-baggrund til at udforme IT-strategien og have indflydelse på hvorledes denne eksekveres.


Nej, ikke detailkompetence, men trods alt så meget IT-faglig forståelse, at du kan genkende kompetencen, når du møder den. Har i min tid oplevet et par fejlrekrutteringer, hvor der blev lagt mere vægt på store ord og armbevægelser end solide kompetencer og reelle erfaringer.

Jesper Frimann

Nej, ikke detailkompetence, men trods alt så meget IT-faglig forståelse, at du kan genkende kompetencen, når du møder den. Har i min tid oplevet et par fejlrekrutteringer, hvor der blev lagt mere vægt på store ord og armbevægelser end solide kompetencer og reelle erfaringer.

Den tror jeg vi er mange, der har oplevet. Også når det kommer til folk i toppen af pyramiden. Folk hvor man nærmest har sat en ære i, ikke at ville forholde sig til fagligheden og forretningen. Og hvor det har været vigtigere, at bestemme.. end at have ret.

// Jesper

Log ind eller opret en konto for at skrive kommentarer