Förvaltning — vad håller ett system vid liv?

Mönstret är välbekant för de flesta som arbetat med IT-system i producerande bolag. Ett egenutvecklat system levereras, tas i drift och fungerar. Det löser precis det det var byggt för och verksamheten är nöjd. Tre år senare är systemet fortfarande i drift, men varje ändring tar tre veckor och kräver ett samtal med en specifik person. En säkerhetsuppdatering av en beroende komponent skjuts på för att ingen vet vad som påverkas. En ny funktion är "planerad" men har legat kvar i backloggen i arton månader.

Det är sällan ett tekniskt fel. Koden fungerar. Systemet gör vad det gjordes för att göra. Problemet är att ägarskapet har luckrats upp, dokumentationen halkat efter och den tekniska skulden har ackumulerats utan att det märkts förrän den är för stor att ignorera.

Det finns fyra saker som avgör om ett egenutvecklat system håller länge — och alla fyra behöver beslutas och planeras innan systemet levereras, inte efter.

Den första är namngivet ägarskap. Någon i organisationen behöver vara ansvarig för systemet: förstå det tillräckligt bra för att kunna fatta prioriteringsbeslut, vara kontaktpunkt för förändringsönskemål och ha mandat att planera underhåll. Utan det driftar systemet mot ett tillstånd där alla vet att det behöver uppdateras men ingen är ansvarig för att det händer.

Den andra är dokumenterad affärslogik. Inte enbart teknisk dokumentation om hur koden är strukturerad — utan dokumentation av varför varje regel och undantag finns. Affärsbeslut som kodats in försvinner annars ur minnet när de personer som fattade dem slutar, och kvar är en regel som "alltid har funnits" och som ingen vågar röra.

Den tredje är en definierad förändringsprocess. Önskemål om nya funktioner, buggar och förbättringar behöver ha ett hem — ett backloggsystem, en kontaktpunkt och en tydlig väg från önskemål till prioritering till implementation. Utan det lever önskemålen i e-posttrådar och muntliga konversationer, och det som genomförs styrs av vem som råkar fråga vid rätt tillfälle.

Den fjärde är planerat tekniskt underhåll. Plattformsuppdateringar, säkerhetspatchar, beroendekartläggningar — det är arbete som om det skjuts upp skapar teknisk skuld som gör systemet allt svårare att ändra. Det behöver planeras som ett återkommande arbete, inte som ett akutprojekt när något slutat fungera.

Det finns en artikel i den här serien om systemet som fungerar men som ingen vill gå nära. Det är inte ett ovanligt tillstånd för egenutvecklade system som levt länge utan aktiv förvaltning. Koden är odokumenterad eller dokumenterad med kommentarer som inte längre stämmer med hur koden fungerar. Beroenden är inte kartlagda. Ingen vet riktigt vad en ändring på en viss plats faktiskt påverkar.

Det systemet är fortfarande en tillgång — affärslogiken är fortfarande värdefull. Men kostnaden för att förändra det har blivit så hög att man istället bygger workarounds runt det, och de workaroundsen bygger fler workarounds. Vid det laget kostar det mer att underhålla systemet i det tillståndet än vad det hade kostat att förvalta det aktivt under alla åren.

Gaia levererar aldrig ett system utan en förvaltningsplan. Innan systemet tas i drift beslutar vi tillsammans om vem som äger det, hur förändringsönskemål hanteras, hur tekniska uppdateringar planeras och vad som ingår i löpande underhåll. Inte för att det är en formell process — utan för att det är det som avgör om systemet levererar värde om tre år, inte bara i releasestunden.

I de fall Gaia fortsätter som förvaltningspartner innebär det löpande tekniskt underhåll, planerade genomgångar av beroenden och plattformsstatus, och ett tillgängligt tekniskt minne om systemet. I de fall kunden vill ta över förvaltningen internt lägger vi tid på att dokumentera och kunskapsöverföra ordentligt — systemet ska fungera utan oss.