Dette indlæg er alene udtryk for skribentens egen holdning.

Sådan får du bedst styr på dine forældede it-systemer

15. december 2020 kl. 03:341
Sådan får du bedst styr på dine forældede it-systemer
Illustration: Seamartini/Bigstock.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

De seneste par år har vi set store sikkerhedsbrud, skærpede compliance krav og højere forventninger fra forbrugerne, som presser mange virksomheder til at tage stilling til deres stadig forældede IT systemer og IT arkitektur, der skaber en voksende teknisk gæld.

Et stigende antal virksomheder investerer derfor aggressivt i at øge deres business agility for at blive bedre til at imødekomme kundernes konstant ændrende adfærd og sikre aktualitet i en verden fyldt med forandring og forstyrrelser.

Andreas Hyun Kirkegaard er ekspert i it-transformationer hos PA Consulting.

Det vi ofte oplever, er dog, at bestræbelserne – hvor ihærdige de end må være – ikke står mål med udbyttet. I stedet for at fokusere på at styrke fundamentet til en digital rejse og transformation gennem øget mandat til IT arkitekterne og erstatte legacy-systemer, bliver pengene ofte brugt på nye digitale tiltag. De digitale tiltag er afhængige af IT fundamentet og har derfor svært ved at skaleres og bruges bredt, hvis tilstrækkelig fokus ikke har været på at løfte IT fundamentet.

Artiklen fortsætter efter annoncen

Vi ser to forskellige typer initiativer i de store virksomheder rundt om i Danmark, som reelt gør en forskel.

Det skal gøres enkelt – for at virke

Det første initiativ går ud på, at man gør op med sin tekniske gæld gennem store simplifikationsprogrammer, ofte i milliardklasssen. Missionen er at simplificere IT landskabet ved at reducere antal af systemer, konsolidere processer, standardisere services og fokusere på færre og smartere integrationer.

Anton Bohse er ekspert i it-transformationer hos PA Consulting.

Nordea tog konsekvensen af den ophobede tekniske gæld, som de havde samlet sig i 2014. Det gjorde de hovedsageligt gennem opkøb og konsolideringer fra begyndelsen af deres store simplificeringsrejse. Her havde man i første omgang dedikeret €1 milliard til programmet, og 6 år senere er man fortsat i gang, hvilket siger noget om kompleksiteten ved sådan en øvelse. Nordeas mål er at skabe en skalerbar, modstandsdygtig og digital relationsbyggende bank og Nordea er langt fra alene om at ville simplificere.

Artiklen fortsætter efter annoncen

Den type programmer har den fordel, at den generelt skaber en hurtigere ”time-to-market” og reducerer de operationelle omkostninger, når der skal udvikles nye digitale produkter til enten kunder eller til internt brug i virksomheden.

Vid, hvorfor du bruger rammeværket

Den andet type af initiativ, handler om at øge sit fokus på at undgå ny teknisk gæld ved at definere og følge IT arkitektprincipper gennem øget investering og mandat til IT arkitekturen. Arkitektprincipperne skal facilitere og tale for det optimale IT landskab, hvor arkitekterne balancerer mellem, hvornår de må stå fast på principperne og ikke lade sig påvirke af ”fast-track” beslutninger, og hvornår de er nødt til at gå på kompromis med principperne for ikke at bremse en handlekraftig organisation.

Mange arkitekter læner sig metodisk op af de helt store rammeværker, som f.eks. TOGAF, men vi oplever, at der er et essentielt yderligere behov, som mange glemmer. Nemlig at få defineret en metode og en arkitektonisk forståelse for den enkelte organisation.

Det er vigtigt at man får gjort det arbejde, så man på pædagogisk vis fremhæver de principper, der lægges hovedvægt på og dermed får en fælles forståelse af, hvordan rammeværket knytter sig til og understøtter den overordnede IT strategi. For få laver ”fokuserede projekter”, hvor rammeværket fra start kommer helt på plads og derefter bliver ordentligt kommunikeret ud på tværs af organisation. Når det bliver et projekt, hvor ressourcer ikke er 100 pct. allokeret, kommer det ikke til at blive en succes. Det bliver hverken fuldendt eller kommer ud at leve i organisationen.

For at undgå at gentage den samme situation med høj teknisk gæld, som mange store organisationer står i lige nu, har størstedelen taget imod rammeværker og metoder, som tidligt i leverancen fokuserer på at skære kraftigt ned på al teknisk gæld, når nye løsninger skal indgå i IT landskabet.

Det såkaldte ”Architectural Runway” er en af de tilgange leverancefokuserede projekter og programmer benytter sig af. Det er en af nøglerne i det agile rammeværk SAFe, hvor man laver en agil arkitekturstrategi. Den er byggestenen til at undgå, at projekter oparbejder teknisk gæld både i selve projektets levetid og i hele organisation sideløbende. Det sker ved at udarbejde det arkitektoniske fundament, der er behov for. En yderligere fordel ved et sådant initiativ er, at time-to-market mindskes ved på forhånd at have udarbejdet fundamentet, så man undgår store overraskelser, usikkerheder og minimerer ricisi.

Vi mener, at de to nævnte initiativer er blandt de vigtigste og største, hvis man vil øge sin business agility og fjerne og forhindre teknisk gæld. Vi oplever gang på gang, at virksomheder udskyder at komme i gang, da det på kort sigt er dyrt og kompliceret, men på langt sigt er en absolut nødvendighed for at forblive konkurrencedygtig både ift. kundernes ændrede behov og driftsomkostninger.

1 kommentar.  Hop til debatten
Denne artikel er gratis...

...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.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
15. december 2020 kl. 11:59

Det er naturligvis nødvendigt at tegne de store streger og have overblikket fra helikopterperspektivet. Og der er naturligvis mange årsager til at systemer forældes. En af de væsentlige årsager er at sourcekoden slides ned og sander som konsekvens af "sparsommeligt" vedligehold. Der kan ofte afses midler til de store armbevægelser - men der er langt fra altid hverken anseelse i, eller ressourcer nok til, det løbende vedligehold. Et underkendt nøgleord i denne forbindelse er kodekvalitet - således som det eksemplevis er beskrevet af CodeImprover herSelvom det kan være fristende at forsøge at revolutionere sig ud af problemerne, så er det min opfattelse at man oftest er bedre tjent med en evolution.