Integration i ett verksamhetsnära system

Scenariot är välbekant. Systemet är byggt, testat och levererat, och första dagen i produktion frågar någon: "Hur kommer orderdata in från affärssystemet?" Någon annan undrar hur systemet skickar vidare till ekonomisystemet när en transaktion är klar, eller säger rakt ut: "Vi registrerar ju allting manuellt i två system nu, var det tanken?"

I många systemprojekt behandlas integrationen som något som kommer sen. Den dyker upp i slutet av projektet, vid den tekniska genomgången eller i värsta fall när systemet redan är i drift och någon frågar varför siffrorna inte stämmer. Då hastas kopplingar fram som är svåra att underhålla och skapar beroenden som ingen har dokumenterat ordentligt.

SystemintegrationHur ett system utbyter data och händelser med andra system: vad det tar emot, vad det skickar vidare och vilka händelser som startar vilka flöden. Den bör vara bestämd innan systemet byggs. i ett verksamhetsnära system omfattar tre ytor. Den första är inkommande data, alltså det systemet behöver veta från er befintliga miljö, som kunduppgifter, produktdata, lagerstatus eller leveranstider beroende på vad systemet gör. Var datan finns, i vilket format den ligger och hur ofta den behöver uppdateras behöver vara utrett tidigt.

Den andra är utgående data, det vill säga vad andra system behöver veta om det som händer i det nya systemet: att en order har bekräftats, att en kvalitetsbrist har registrerats eller att ett avtal har signerats. Det kan vara uppdateringar till ekonomisystemet, notiser till ett CRM eller anrop som startar något i ett logistiksystem. Utan de flödena blir systemet isolerat från resten av verksamheten.

Den tredje är händelser, när något som sker i det nya systemet ska sätta igång något någon annanstans, eller tvärtom. Den ytan är svårast att planera för, men den ger också ofta mest nytta, eftersom ett helt flöde då kan gå automatiskt i stället för att någon måste samordna varje steg för hand.

I system som har byggts utan ordentlig integrationsplanering hittar vi oftast en samling punktkopplingar, alltså direkta anslutningar mellan två system som byggdes för att lösa ett akut problem. De fungerar tills ett av systemen uppdateras, tills volymen växer förbi vad kopplingen klarar eller tills den som byggde dem har gått vidare och ingen längre vet hur de fungerar.

Samtidigt växer manuella steg fram. Data som borde gå automatiskt exporteras i stället till Excel, redigeras för hand och importeras på andra sidan. Det löser problemet för stunden, men det gör er beroende av att rätt person gör rätt sak vid rätt tidpunkt. Med tiden blir de manuella stegen egna processer som måste underhållas, fast de egentligen är ett tecken på att integrationen aldrig planerades.

I praktiken betyder det att gränssnitten mot andra system definieras redan i kravarbetet, i stället för att läggas till som ett tekniskt tillägg i slutet. Vilka system ska det nya systemet utbyta data med, och vad behöver de veta, i vilket format, hur ofta och med vilken tillgänglighet? Svaren påverkar hur systemet byggs, vilka API:er det exponerar och hur det hanterar fel och fördröjningar.

Verktygen vi använder är oftast Azure Integration Services, med Logic Apps, API Management, Service Bus eller Event Grid beroende på vad flödet kräver. Valet av verktyg kommer ändå i andra hand efter designbesluten: vad som är synkront och måste svara direkt, vad som är asynkront och kan vänta, och var felhanteringen är kritisk och var det räcker att logga och flagga.

Integrationerna behöver också vara dokumenterade så att verksamheten förstår dem, och inte bara tekniskt. En beskrivning som "Det här API:et anropas av CRM:et när en ny kund har registrerats och startar då ..." ska gå att förstå för nästa person som förvaltar systemet, och inte bara för den som byggde det.

Ett bra första steg, oavsett om systemet redan finns eller bara är en idé, är att lista vilka system det ska hämta data från och vilka system som behöver veta vad som händer i det.