Det är ett välbekant scenario. Systemet är byggt, testat och levererat. Första dagen i produktion frågar någon: "Hur kommer orderdata in från affärssystemet?" Eller: "Hur skickar det här till ekonomisystemet när en transaktion är klar?" Eller, mer specifikt: "Vi registrerar ju allting manuellt i två system nu — var det tanken?"
Integration hanteras sällan som en förstaklassens krav i systemutvecklingsprojekt. Den dyker upp i slutet av projektet, under teknisk genomgång, eller ännu värre — när systemet är i drift och någon frågar varför data inte stämmer. Konsekvensen är att lösningar hastas ihop, är svåra att underhålla och skapar beroenden som ingen dokumenterat ordentligt.
Vad integration faktiskt innebär Tre ytor att planera för
SystemintegrationHur ett system utbyter data och händelser med andra system i en IT-miljö — vad det tar emot, vad det levererar och vad som triggar vilka flöden. Definieras bäst innan systemet byggs, inte efter. i ett verksamhetsnära system handlar om tre ytor.
Den första är inkommande data: vad systemet behöver veta från er befintliga miljö. Kunduppgifter, produktdata, lagerstatusar, leveranstider — beroende på vad systemet gör. Var den datan finns, i vilket format och hur ofta den behöver vara aktuell är frågor som måste besvaras tidigt.
Den andra är utgående data: vad andra system behöver veta om vad som händer i det nya systemet. En order bekräftad, en kvalitetsbrist registrerad, ett avtal signerat. Det kan röra sig om uppdateringar till ekonomisystemet, notifieringar till ett CRM eller triggers till ett logistiksystem. Utan det här är systemet ett isolat.
Den tredje är händelser och triggers: när något händer i det nya systemet ska något annat hända någon annanstans, och vice versa. Det är den mest komplex-a ytan att planera för, men också den som ofta ger mest värde — ett flöde som automat-iseras end-to-end i stället för att kräva manuell koordinering i varje steg.
Integration planerad som en efterhandslösning är en skuld som räntan på stiger varje år. Integration planerad som en del av systemarkitekturen från dag ett är ofta den faktor som avgör om systemet levererar faktiskt värde — eller skapar ett nytt silot att förvalta.
Vad som händer när det inte planeras Punktkopplingar och manuella steg
Det vanligaste mönstret vi ser i system som byggts utan ordentlig integrationsplanering är en samling punktkopplingar: direkta anslutningar mellan specifika system, byggda för att lösa ett omedelbart problem. De fungerar tills ett av systemen uppdateras, tills volymen ökar bortom vad punktkopplingen klarar, eller tills personen som byggde dem har gått vidare och ingen vet hur de fungerar.
Parallellt uppstår manuella steg. Data som borde flöda automatiskt exporteras istället till Excel, redigeras för hand och importeras på andra sidan. Det löser problemet kortsiktigt — och skapar ett nytt beroende av att rätt person gör rätt sak vid rätt tidpunkt. De manuella stegen syns sedan som egna processer som måste underhållas, när de egentligen är symptom på att integrationen aldrig planerades ordentligt.
Ärligt
De dyraste integrationsproblemen vi hanterar är sällan tekniskt komplicerade. De är logistiskt komplicerade — systemet är i drift, beroenden är odokumenterade, och att ändra något kräver att man förstår vad som påverkas. Det är ett förvaltningsproblem som börjar med ett integrationsdesignproblem. Och det är lättare att lösa innan systemet är i produktion.
Hur integration görs rätt API-design som en del av systemarkitekturen
Det praktiska svaret är att integrationsgränsytor definieras som en del av kravarbetet, inte som ett tekniskt tillägg. Vilka system pratar det nya systemet med? Vad behöver de systemen veta — och i vilket format, med vilken frekvens, med vilken tillgänglighet? Svaren på de frågorna påverkar hur systemet byggs, vilka API:er det exponerar och hur det hanterar fel och fördröjningar.
I praktiken jobbar vi med Azure Integration Services — Logic Apps, API Management, Service Bus och Event Grid beroende på vad flödet kräver. Men valet av verktyg är sekundärt mot de designbeslut som föregår det: vad är synkront och måste svara omedelbart, vad är asynkront och kan vänta, var är felhanteringen kritisk och var räcker det att logga och flagga?
En annan aspekt är att integrationerna är dokumenterade — inte bara tekniskt, utan affärsmässigt. "Det här API:et kallas av CRM:et när en ny kund är registrerad, och trigger ..." Det ska vara begripligt för nästa person som förvaltar systemet, inte bara för den som byggde det.
Serien i korthet — klicka för att läsa
Ta med dig
- Integration är en del av vad systemet är — inte ett tekniskt tillägg som hanteras i slutet. De tre ytorna att planera för är inkommande data, utgående data och händelsetriggers.
- Integration som planeras sent leder till punktkopplingar och manuella steg som ackumulerar underhållsskuld och skapar personberoenden.
- Rätt approach är att definiera integrationsgränsytor som en del av kravarbetet, dokumentera dem affärsmässigt och välja tekniska lösningar utifrån vad flödet faktiskt kräver.
Läs vidare
Vad är ett verksamhetsnära system? — hörnstenen i serien → Äga eller hyra — när ska man bygga eget? → Förvaltning — vad håller ett system vid liv? → Data i fem system som inte pratar med varandra →Gaia System AB
Microsoft Azure, .NET och systemutveckling i Norrköping sedan 1995