Noget om monstre og kvælning

Noget om monstre og kvælning

Som små frygter vi monstrene, der gemmer sig under sengen.

Som voksne er det “legacy monstre”, der får ansvarlige for store systemkomplekser til at vågne badet i sved.

Legacy betyder arv, og arv forbinder de fleste med noget positivt, mens baggrunden – fx et dødsfald – er ganske trist. Ganske anderledes er det med nedarvede systemer – ”legacy monstre” – som står for store dele af forretningens IT, men som ingen tør røre ved. Med det beklagelige resultat, at IT pludselig står i vejen for udvikling i stedet for at støtte den. Dem lader vi gerne afgå ved døden og erstattet af yngre og mere agile arvtagere.

Ofte er disse systemer monolitter (store sten), som kun vanskeligt kan hugges i mindre dele. Det betyder, at de er svære at få til at passe ind i en microservice-arkitektur, og at det er svært og uoverskueligt at udskifte dem.

Fodboldklubbens kalendersystem

Lad os tage et eksempel fra fodboldklubben, hvor Jürgen er træner:

Klubben har et gammelt system, der både kan håndtere inddrivelse af kontingent, udbetaling af løn til trænere, bestilling af pølser til kantinen og med en kalenderfunktion til at holde styr på kampe.

Nu er der bare sådan, at der findes et nyt og meget smartere kalendersystem, der automatisk bliver opdateret, når kampene i turneringen ændres.

Problemet er, at flere andre systemer bruger legacy-systemets kalenderoversigt. Det sker gennem et API – en “kontrakt” for de services, der udstilles af systemet.

Løsningen kan her være at starte med indskyde en proxy, der blot viderestiller til legacy-systemet.

De gamle systemer skal nu blot ændre en konfiguration, så de peger på proxyen i stedet for legacy-systemet.

Med proxyen på plads, kan du lave en adapter oven på det nye system, der kan udstille kalenderfunktionaliteten på samme måde som legacy-systemet – fuldstændig som en adapter til stik, du tager med på ferie til lande med eksotiske stikkontakter.

Endelig kan proxyen ændres, så den peger på det nye system.

Hvis legacy-systemet ikke har et API

Desværre er det ikke givet, at legacy-systemet har et API. Måske er du nødt til at fiske data fra interne tabeller. Det gør det selvfølgeligt lidt mere tricky, men tankegangen er den samme:

Nu starter vi med at lave et API oven på legacy-systemet. Det API, er det eneste, der kender til systemets indre, og andre systemer kan kun tilgå kalenderfunktionaliteten gennem dette.

Det er ikke nødvendigvis så let, som det lyder, da det jo kræver, at du får styr på, hvilke dele af systemet, der bruges af hvem. Fordelen er til gengæld betydelig: Vi får et overblik over afhængigheder – i første omgang til kalenderfunktionaliteten, og så er vejen til udskiftning banet.

Med tiden kan dette gøres for flere og flere af legacy-systemets funktioner – så systemet langsomt bliver kvalt for til sidst at være erstattet af nye systemer.

Står I med et ”legacy monster”, der får dig til at skrige i søvne? Kontakt Openminds og få livsglæden tilbage!

Morten Hauch

Mail: mha@openminds.dk
Mobil: +45 3023 7021

Læs mere

Seneste blogindlæg

Er ny teknologi ét skridt frem og to tilbage?

Danske virksomheder kan trække rigtig meget forretningsværdi ud af deres eksisterende it-setup uden at skulle investere i en masse ny teknologi. Men ny teknologi som fx AI og big data er blevet så hypet, at virksomhederne bliver i tvivl, om det overhovedet er muligt at udnytte data uden et CERN-lignende arrangement.

Giv jeres legacy-system en agil skygge

Legacy-systemer bliver ofte set som den tunge arv fra fortiden. En arv man gerne vil slippe af med på samme måde, som man ønsker at slippe af med en jernlænke og kugle om anklen.

Men legacy-systemet er også en værdifuld arv, man ikke kan eller vil leve uden. Årtiers investeringer i specialiseret systemudvikling fokuseret på én virksomheds (eller branches) behov kan ganske enkelt ikke erstattes med noget, der når legacy-systemet til sokkeholderne.

Sådan finder i jeres sweet spot for systemovervågning

Allerede når man begynder at udvikle software, og den første kode skrives, er der fokus på hele tiden at teste for fejl. Men for udvikleren stopper fokus på fejlsøgning ikke, når den færdige kode er sat i drift.
I godt it-udviklingsarbejde tager udvikleren også højde for den efterfølgende overvågning og vedligeholdelse af softwaren, så systemet kan holdes kørende, og fejl og uregelmæssigheder bliver opdaget og håndteret.