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!