Brenn alle broer!

Brenn alle broer!

KRONIKK: Applikasjonsvedlikehold er mer enn feilretting. Et system der man utelukkende retter feil er per definisjon et døende system.

De siste årene har vi sett en eksplosjon av muligheter innen ny teknologi og nye måter å tenke system på. Valget er enkelt hvis du skal skape et helt nytt system.  Man bygger fleksibel og tilpasningsdyktig frontend på et solid fundament av skytjenester. For eksisterende systemer er det vanskeligere.  Virksomhetskritiske systemer kan ikke bare dø. Hva skal til for å bringe virksomhetens it-systemer inn i fremtiden?

Det er ikke lenge siden at man fikk et klaps i bakhodet og en klar DRY-melding dersom man våget å løse tilsynelatende samme ting på flere steder i koden. "Don't repeat yourself" var et credo som skulle sikre vedlikeholdbar kode.

Dette var veldig gyldig i en verden der datasystemer var monolittiske mastodonter. Nå handler det om å gjøre det enkelt. Få store applikasjoner blir til mange små apper, og hver app skal være uavhengig. Det er en tendens til at når man bryter opp applikasjonen i apper, så samler man felles kode i delte biblioteker. Unngå dette! Det skaper direkte avhengigheter mellom appene som da i praksis er blitt en oppdelt monolitt som fortsatt må vedlikeholdes samlet.

Hadde det ikke vært deilig om man bare kunne skru på en bryter, så var applikasjonen magisk over på ny teknologi? I praksis kan man ikke utvikle et nytt, stort datasystem på nytt i en diger operasjon. 

Inntil man skrur om bryteren må det gamle systemet leve, og det må vedlikeholdes.  Det betyr at det nye, store systemet sikter mot et bevegelig mål. Og enda verre, man risikerer å ende opp med legacykode i det nye systemet lenge før det er i drift.

Løsningen er velkjent. Man spiser en elefant i små biter, og slik bryter man også opp det store, gamle systemet og erstatter hver bit med nye apper. Underveis oppstår et nytt dyr. Et stort, minkende dyr med mange små dyr som har avhengigheter til hverandre og til det gamle, store, døende dyret. Det er en symbiose med ett formål: Å til enhver tid tilby brukeren av applikasjonen full funksjonalitet og gradvis bedre opplevelser.

For å oppnå dette bygger man ofte broer av kommunikasjon mellom apper og den gamle løsningen. I beste fall handler dette om navigasjon. Man hopper mellom gamle og nye biter av løsningens apper, slik man hopper mellom websider. Eneste avhengighet er en navigasjonslenke. En slik lett bro kan man leve med og enkelt vedlikeholde.

I verste fall har man avhengigheter til strukturer og datainnhold i den gamle løsningen. Disse tunge broene kan man gjerne se i koden som tjenesteorienterte endepunkter. De følger gjerne en valgt, ny standard, og den gamle mastodonten blir som et baksystem med en integrert tjenestebuss på toppen. Disse solide broene fungerer riktignok, og i front får brukerne en tilsynelatende fantastisk ny opplevelse. Dette bør unngås, og har man slike broer er det nå det er viktig å ikke stoppe!

Når mange apper har direkte avhengigheter til felles legacykode, så har de liten frihet til å utvikle seg. En endring i felles kode betyr da at man må endre og teste alt før man kan være sikker. Alle tunge broer til den gamle løsningen må brennes! Det er ganske enkelt, men ressurskrevende. Dette er teknisk gjeld (hørte jeg "Boring!") og rent applikasjonsvedlikehold. Men det er vedlikehold som gir frihet for videre utvikling for fremtiden. Man må gi hver app ansvar for å hente og bearbeide sin egen informasjon. Når det er gjort kan man arrangere en bålfeiring for friheten. Brenn broene! Begrav mastodonten! Kjenn lukten av frihet! Nå kan hver app forvaltes og videreutvikles som en naturlig del av den daglige driften.

Veien videre er et enklere og billigere applikasjonsvedlikehold, tilpasningsdyktige løsninger og fornøyde brukere.

Rune Offerdal er konsulent i Capgemini i Fredrikstad

Les om: