Att koppla ihop system som inte pratar med varandra

Ett installationsföretag med tjugo montörer har sällan ett systemproblem. Det har ett informationsproblem som ser ut som ett systemproblem.

Ordern kommer in via mejl. Någon skriver in den i ordersystemet. Montören rapporterar tid i en app. Materialet ligger på ett följesedelfoto i en telefon. När fakturan ska ställas ut går någon igenom allt tre gånger för att se om det stämmer. Ingen av delarna är svår. Det är att de inte hänger ihop som kostar.

Först: bestäm vad som är sant

Det här är det steg som tar längst tid, och det är inte tekniskt.

Om kundens adress finns i både ordersystemet och ekonomisystemet — vilket av dem gäller när de skiljer sig åt? Om montören rapporterar fyra timmar i appen och projektledaren skriver tre i efterhand, vilket är rätt?

Innan de frågorna har svar går det inte att bygga något vettigt. En integration flyttar information snabbare, den avgör inte vilken version som stämmer. Kopplar man ihop två system som är oense får man samma oreda, fast med högre hastighet och sämre överblick.

I praktiken betyder det att varje uppgift får en sanningskälla: ett system som äger den, och övriga som tar emot. Det är ett verksamhetsbeslut, inte ett utvecklarbeslut.

Sedan: hur kopplingen faktiskt går till

Systemen pratar med varandra på en av fyra nivåer, i fallande ordning av hur trevligt det är att arbeta med dem.

Öppet API. Systemet har ett dokumenterat gränssnitt för att läsa och skriva. Det är det som gör tvåvägsflöden möjliga: en ändring i ett system slår igenom i det andra, och tvärtom.

Webhooks. Systemet hör av sig självt när något händer, istället för att någon behöver fråga det med jämna mellanrum. Snabbast, och minst belastning.

Schemalagd export. Systemet kan lägga en fil någonstans eller mejla en rapport varje natt. Det räcker förvånansvärt långt för enkelriktade flöden — orderrader till ekonomi, till exempel. Nackdelen är att informationen alltid är upp till ett dygn gammal.

Ingenting. Systemet är stängt. Då återstår att skriva av från skärmen, och det är ingen integration.

När det inte är värt pengarna

De flesta som säljer integrationer säger att allt går att lösa. Tekniskt sett stämmer det ofta. Ekonomiskt gör det inte det.

Ett par ärliga fall där vi avråder:

• Systemet är stängt och ska bytas inom ett år ändå. Bygg inte en bro till en byggnad som ska rivas.
• Uppgiften sker tio gånger om året. Ett halvdagsjobb för hand slår en integration som ska förvaltas.
• Ingen vill äga sanningskällan. Om organisationen inte kan bestämma vilket system som gäller är den inte redo, och tekniken löser inte den oenigheten.

Vad som händer när det går fel

Den skadligaste integrationen är inte den som kraschar. Det är den som misslyckas tyst.

En order som inte kom fram, ett fält som slutade fyllas i efter en systemuppdatering, en koppling som legat nere sedan i tisdags — sådant upptäcks vid månadsskiftet, och då är det dyrt att reda ut. Därför byggs varje flöde så att fel larmar och köas: posten som inte gick fram ligger kvar och körs om när systemet svarar igen, och någon får veta att det hände.

Det är samma princip som gäller överallt där automation ersätter en människa. En människa som inte hinner med säger till. Ett skript som inte hinner med säger ingenting, om ingen har byggt in att det ska göra det.

Vem äger kopplingen efteråt

Fråga alltid det, oavsett vem ni anlitar. Flödena ska ligga i er egen miljö, vara dokumenterade, och byggda på tillräckligt vanliga komponenter för att en annan utvecklare ska kunna ta över.

En lösning som bara leverantören förstår är inte en trygghet. Det är en risk ni betalar för.