De flesta system blir inte dåliga över en natt. De blir det lite i taget. En uppdatering som skjuts upp för att det är mitt i säsongen. En snabb lösning som skulle vara tillfällig. En utvecklare som slutar och tar med sig kunskapen om varför saker är byggda som de är.
Till slut sitter man med en webbplats eller ett verksamhetssystem som fungerar, men som ingen riktigt vågar ändra i. Det är det som brukar kallas teknisk skuld.
Vad teknisk skuld faktiskt kostar
Teknisk skuld syns sällan i en budget. Den märks i stället när en enkel ändring tar tre veckor i stället för tre dagar, eller när en offert på en ny funktion blir oväntat dyr för att "det måste göras om en del först".
Precis som ett lån har den ränta. Ju längre den får ligga, desto mer kostar varje förändring. Och någon gång kommer den att behöva betalas, antingen planerat eller i samband med att något går sönder.
Säkerheten är oftast det som avgör
Under det senaste året har det återigen kommit flera allvarliga säkerhetsluckor i PHP och i populära tillägg till WordPress. Det är inget unikt för PHP, det händer i alla miljöer. Skillnaden är vad som händer sedan.
Den som har ett system i gott skick installerar uppdateringen och går vidare. Den som kör en gammal PHP-version, ett tillägg som inte längre underhålls eller ett CMS som är flera versioner efter, har ofta inget enkelt sätt att uppdatera. Då står man plötsligt med en öppen dörr in i systemet och inget bra sätt att stänga den.
Det är oftast där frågan om teknisk skuld slutar vara teoretisk.
Tecken på att det är dags att agera
Några saker vi ofta ser när vi tar över äldre system:
- Ingen vill röra koden. Små ändringar kräver långa tester eftersom ingen vet vad mer som kan påverkas.
- Plattformen har passerat sitt supportdatum. Det gäller till exempel äldre PHP-versioner, Umbraco 7 och 8 eller gamla versioner av .NET Framework.
- Kunskapen sitter hos en person. Eller hos någon som inte längre jobbar kvar.
- Integrationerna är sköra. Kopplingar mot affärssystem eller CRM går sönder när något annat uppdateras.
- Det blir allt dyrare att göra något nytt. Varje ny funktion kräver att man först bygger runt gamla begränsningar.
Känner ni igen er i två eller fler av dem är det värt att titta närmare.
Modernisera eller bygga nytt?
Det här är den svåra frågan, och svaret är inte alltid att bygga nytt. Ett nytt system innebär att man också bygger in nya fel, och att mycket av det som fungerar bra i dag måste göras om.
Modernisering är ofta rätt när grunden är rimlig, när affärslogiken stämmer och när problemet främst ligger i en gammal plattform eller föråldrade beroenden. Då kan man flytta systemet steg för steg, till exempel från en äldre Umbraco-version till Umbraco 17 på .NET 10, och samtidigt städa i det som har blivit krångligt.
Att bygga nytt brukar vara rätt när koden inte går att förstå, när plattformen saknar en rimlig väg framåt eller när verksamheten har förändrats så mycket att det gamla systemet löser fel problem.
Ofta landar det någonstans mittemellan. Man behåller data och det som fungerar, och byter ut de delar som håller tillbaka.
Börja med en genomlysning
Innan man fattar beslut är det bra att veta var man står. En teknisk genomlysning behöver inte vara ett stort projekt. Vi brukar gå igenom kod, beroenden, versioner, integrationer och drift, och sedan beskriva läget på ett sätt som går att använda som beslutsunderlag.
Ibland visar det sig att det räcker med några uppdateringar och lite städning. Ibland är det dags för något större. Men i båda fallen är det bättre att veta än att vänta på att något går sönder.
Har ni ett system som börjar kännas tungt att förvalta hör gärna av er, så tittar vi på det tillsammans.