Teknikskulden sitter ofta mellan systemen

Varje system kan fungera stabilt på egen hand, samtidigt som helheten blir dyr och riskabel att förändra. När ingen längre har full kontroll över hur data rör sig mellan systemen kan även en mindre uppdatering få oväntade konsekvenser.

Teknisk skuld är mer än gammal kod

Teknisk skuld uppstår när en kortsiktig lösning skapar framtida kostnader, merarbete eller risker. Det kan handla om kod som snabbt har lagts till för att lösa ett akut problem, men också om integrationer som byggts utan tydlig dokumentation eller långsiktig plan.

En koppling mellan två system behöver inte vara särskilt komplicerad från början. Med tiden kan den däremot få fler regler, undantag och specialanpassningar. Nya fält läggs till, data behöver behandlas på olika sätt och manuella kontroller införs när systemen inte beter sig som förväntat.

Problemet är därför sällan att systemen kommunicerar med varandra. Det blir kännbart först när organisationen inte längre vet exakt hur kommunikationen fungerar eller vad som händer om en del förändras.

Integrationsskuld kan bland annat bestå av odokumenterade dataflöden, manuella moment, gamla API-kopplingar och regler som bara enstaka medarbetare känner till. Den kan också bero på att ingen har ett tydligt ansvar för helheten.

Ett systembyte avslöjar de dolda beroendena

Integrationsskulden förblir ofta osynlig så länge systemen fortsätter fungera som tidigare. Det är först när ett centralt system ska ersättas som beroendena blir tydliga.

Problemen märks exempelvis när företag planerar sina integrationer vid byte av bokföringsprogram. Det räcker inte att flytta saldon, kundregister och historiska uppgifter. Flöden för ordrar, betalningar, fakturor, lagerhändelser och ekonomiska underlag behöver också fungera efter övergången.

Ett systembyte kan därför väcka frågor som ingen tidigare behövt besvara. Vilka kopplingar är fortfarande aktiva? Vilken information skickas mellan systemen? Finns det manuella undantag som inte har dokumenterats? Vem vet varför en viss regel infördes?

Risken ökar ytterligare om gamla och nya integrationer körs parallellt. Samma händelse kan då registreras två gånger, data kan hamna i fel system eller olika versioner av samma uppgift kan börja cirkulera i verksamheten.

Det som först såg ut som ett avgränsat systembyte blir snabbt ett större projekt där teknik, processer och ansvarsfördelning måste hanteras samtidigt.

När en enkel koppling blir svår att förvalta

Integrationsskuld byggs vanligtvis upp stegvis. Den växer fram ur summan av alla tillägg som gjorts längs vägen, ofta av olika personer och vid olika tidpunkter.

Den tekniska komplexiteten växer gradvis

Komplexiteten kan handla om API-versioner, autentisering, datamodeller, synkronisering och felhantering. Ett system kanske skickar data i realtid, medan ett annat bara uppdateras en gång per dygn. En ändring i ett fält kan påverka flera mottagare utan att det är uppenbart för den som genomför förändringen.

När allt fler system kopplas samman ökar också antalet möjliga felkällor. En misslyckad överföring kan påverka allt från lagersaldo och leveransstatus till fakturering och ekonomisk rapportering. Utan övervakning upptäcks problemet ibland först när någon saknar information i nästa steg.

Oklart ansvar förstärker problemen

Samtidigt finns en organisatorisk komplexitet. IT-avdelningen kan ansvara för den tekniska driften, ekonomiavdelningen för reglerna och en extern leverantör för själva kopplingen. Om ansvarsfördelningen är oklar blir även mindre fel svåra att utreda.

Gamla integrationer är inte automatiskt dåliga. En äldre koppling kan vara både stabil och effektiv. Skulden uppstår när företaget inte längre kan förstå, övervaka eller förändra den på ett kontrollerat sätt.

Så minskar företag skulden mellan systemen

Det första steget är att skapa en samlad bild av systemlandskapet. Företaget behöver veta vilka system som skickar och tar emot data, hur ofta överföringarna sker och vilka manuella moment som finns runt omkring.

Några åtgärder är särskilt viktiga:

• Dokumentera vilka system som är kopplade och vilken information som överförs.
• Utse en ansvarig för varje affärskritiskt dataflöde.
• Beskriv verksamhetsreglerna, inte bara den tekniska lösningen.
• Inför övervakning som upptäcker avbrutna eller felaktiga överföringar.
• Testa verkliga transaktioner före större förändringar.
• Avveckla kopplingar som inte längre används.

Dokumentera varför flödet finns

Dokumentationen behöver även förklara varför ett flöde fungerar på ett visst sätt. Ett API-anrop kan vara tekniskt korrekt, men ändå bygga på en ekonomisk regel eller ett arbetssätt som inte framgår av koden.

Det är också viktigt att dokumentera undantagen. Om vissa ordertyper hanteras manuellt, om återbetalningar följer ett särskilt flöde eller om data korrigeras innan den skickas vidare behöver detta vara känt inför en förändring.

Företag tjänar samtidigt på att hålla antalet direkta beroenden nere till vad verksamheten kräver. Tydligt definierade och versionshanterade gränssnitt gör det lättare att byta ut en komponent utan att hela miljön påverkas.

Varje integration behöver inte vara perfekt. Det viktiga är att känna till riskerna och kunna genomföra förändringar utan att förlita sig på gissningar.

Målet är inte färre integrationer

Integrationer är en förutsättning för automatisering, snabb informationsdelning och effektiva processer. Färre kopplingar löser alltså ingenting.

Det som avgör är i stället om beroendena är tydliga, dokumenterade och möjliga att förändra. Företaget behöver veta var informationen kommer från, vilket system som äger den och vem som ansvarar när något går fel.

Den mest kostsamma teknikskulden är inte alltid den som syns i koden. Den kan finnas i ett dataflöde som ingen vågar ändra, en specialregel som saknar dokumentation eller en koppling som verksamheten blivit beroende av utan att någon längre har kontroll över helheten.