Der er ingen tvivl om at der er stor værdi at hente ved at binde virksomhedens systemer sammen, integrere dem med hinanden. Fordelene står i kø:

  • Mindre manuelt arbejde med at holde alle systemer opdateret
  • Automatisering af processer (fx. automatisk fakturering)
  • Bedre rapportering og analyse (se data på tværs af systemer)

Noget af det man skal være opmærksom på når man planlægger integrationer er blandt andet hvor robust det skal være. Med robusthed, mener jeg noget omkring risikoen for fejl, om det går ned og hvor sårbart det er. Der er forskel på en månedsrapportering, hvor alt skal passe på to decimaler og på et live dashboard, hvor et mindre udfald ikke har betydning, da det er opdateret 2 minutter efter.

To typer af integrationer

Der er generelt set to typer af integrationer, begge har deres fordele og ulemper:

  • Punkt til punkt baseret integration (typisk med REST services)
  • Besked-baseret (fra engelsk “message based” – typisk med en service bus)

Forskellen på de to er netop deres robusthed. Der kan være en markant forskel på hvordan og i hvilke scenarier hver af dem passer ind. Der er naturligvis også noget økonomi involveret i det her.

Punkt til punkt integration

Med punkt til punkt integrationer (som er det mest normale, når man taler fx. webshop til regnskabssystem) har man et system online, hvor man har adgang til dets data (fx. en webhook eller et API). Dette system er det ene punkt i “punkt til punkt” – fx. en webshop. Det andet punkt er så det system man vil integrere imod, det kan være et regnskabssystem.

Med disse to punkter kan man binde dem sammen, typisk vil man udvikle en lille stump kode i midten for at oversætte fra det ene system til det andet, og evt. synkronisere dette med faste mellemrum (fx. hver time). Man kan populært sige at i dette tilfælde så kommer der en softwareleverandør med en limpistol og limer systemerne sammen. Der skal ikke nødvendigvis tænkes store tanker omkring kreativitet og andet. Her skal der bygges en stump software som trækker data ud fra punkt 1, transformerer det, og indsætter det i punkt 2 igen. Fordelene ved denne type af integration er mange og for mange virksomheder er dette helt klart den eneste type af integrationer man får brug for.

punkt-til-punkt integration, fx. REST services
Punkt til punkt integration, de grå cirkler og linier symbolisere flere systemer som skal integreres. Hver linie er en softwareintegration.

Fordele
Dette er en simpel type af integration og det bærer fordelene også præg af

  • Hurtigt at udvikle og derfor også forholdsvist billigt (det vender jeg lige tilbage til)
  • Forholdsvist robust, alle tre punkter (punkt 1, punkt 2 og limpistolen i midten) er ofte tilgængelige på samme tidspunkt
  • Lidt eller ingen forretningslogik, der skal tages højde for
  • Høj performance

Ulemper
Der er naturligvis også ulemper. Ulemperne viser sig typisk først, når man kommer med andre krav som fx. oppetid eller hvis der introduceres mange flere systemer eller det vokser med meget data.

  • Alle systemer skal være online på samme tid (alle tre punkter)
  • Alle systemer skal kende adressen på hinanden
  • Bliver hurtigt uoverskueligt når man integrerer flere systemer
  • Kompleksiteten stiger, når alle systemer skal tale med hinanden (i en virksomhed med 10 systemer skal hvert system kende til og kunne kommunikere med 9 andre

Punkt til punkt integrationer er en meget hurtig og enkel integration mellem to systemer og det er noget vi laver rigtig meget af her hos Median Aps. Det er hurtigt at udvikle og det er billigt at drifte. Denne type af integration passer rigtigt godt til mindre virksomheder, fx. webshops, hvor man skal bruge en enkelt eller to integrationer som binder systemerne sammen. Man skal ikke ret meget længere hen inden man skal overveje om der skal en anden løsning til.

Besked-baseret integration

Besked-baseret integration er en oversættelse fra det engelske udtryk “Message based integration”, det giver altid nogle underlige oversættelser, når man tager de tekniske beskrivelser og oversætter dem til dansk. Denne type integration har nogle andre fordele og ulemper end punkt til punkt integrationen. Generelt set kan man vel sige at denne type af integration er “storebror” til punkt til punkt integrationen.

Vi anbefaler at, hvis man starter med at integrere sine systemer kan det godt give mening at starte med en punkt-til-punkt løsning, for at få helt styr på behovet og på de fordele man gerne vil drage af denne integration. Kort sagt – man skal se om business casen holder vand. Hvis dette viser sig at have en gevinst for virksomheden kan man stille og roligt flytte fra en punkt-til-punkt integration til en besked-baseret integration.

Måden det virker på er ved at to eller flere systemer sender beskeder til hinanden, frem for at lave en direkte integration. Disse beskeder kører igennem et avanceret kø-system (bare rolig, det er noget softwareudvikleren skal bekymre sig om) og i den anden ende af køen (eller flere køer) er der en modtager som håndterer beskeden.

Man kan visualisere dette som et “sugerør”, hvor der et lille stykke software i den ene ende som holder styr på fx. ordrer i webshoppen og hver gang der er en ny ordre, tager den ordren og smider en besked på køen. Dette er enkelt og denne har kun et enkelt ansvar. Dette øger robustheden for denne del af systemet. Det betyder at de enkelte dele, som holder kontakten med fx. webshoppen er uhyre simple og derfor også mere robuste og nemmere at vedligeholde.

I den anden ende af køen, er der et andet lille stykke software som tager en besked væk fra køen og sætter den ind i det andet system. Det er i sin enkelthed, alt hvad der sker.

Den her “kø” i midten er hvor alle fordelene kommer frem. Den kan indeholde en masse beskeder, så den fungerer også som en slags stødpude (buffer) således at det stykke software som indsætter ordrer i regnskabssystemet ikke bliver overbelastet. Denne løsning er noget mere avanceret, men den kan løse stort set alle de integrationsbehov der er i virksomheden. Fordelen er at man kan have tusindvis af disse køer og det gør det nemmere at have mange forskellige integrationer uden at det øger kompleksiteten. Denne metode til integration er meget fleksibel og nem at rette og tilpasse og introducere nye integrationer.

Fordele
Mange af fordelene ved denne type af integration har noget at gøre med at skalere sine integrationer, både i forhold til antallet af systemer man binder sammen, men også i forhold til mængden af fx. ordrer man har i systemet.

  • Kildesystemet og destinationen behøver ikke være online på samme tid (køen håndterer dette)
  • Systemerne behøver ikke kende til hinanden (alle skal kun kende til den centrale kø – det vil sige at i en virksomhed med 10 systemer skal hvert system kun kende til 1 central kø) – dette stiger ikke voldsomt efterhånden som nye systemer kommer med.
  • Det er nemt at skalere (man kan starte flere stykker software som læser fra køen og indsætter i systemet – de samarbejder om at tømme køen for beskeder)
  • Stor fleksibilitet, det er nemt at koble nye systemer på (fx. Business Intelligence systemer)

Ulemper
Mange af de her ulemper skal ses i forhold til den simple integration vi talte om i punkt-til-punkt integrationen.

  • Køen er flaskehalsen (de fleste køer er i cloud og er som sådan meget robuste) – dette er typisk aldrig et problem
  • Mere udvikling og vedligehold (værdien er også større) – det er ikke “hyldevarer”
  • En smule mindre performance (specielt i situationer med meget forretningslogik)

Flere detaljer omkring besked-baseret integration

(Opdatering af artikel) Efter en diskussion omkring denne artikel med en kammerat (Freddie Frydkjær) er jeg blevet gjort opmærksom på at der mangler detaljer og nogle flere åbentlyse fordele i denne besked-baseret tilgang.

Det fremgår af diagrammet at ERP systemet, Regnskabssystemer osv har viden omkring besked-køen, det er ikke korrekt. Det er tegnet for at simplificere det en smule. Sagen er jo den, at vi som virksomhed kan jo ikke vide om de systemer, der er bedst for vores virksomhed ved, hvordan vi har implementeret vores integration. Derfor indskyder man en lille “adapter” ind mellem kildesystemet og beskedkøen (det er den jeg har undladt fra mit diagram). Det vil sige at denne lille adapter er den som kan forbinde til kildesystemer og har viden omkring bussen.

Dette har flere fordele, herunder at vi begynder (som virksomhed) at opbygge en enterprise arkitektur som i princippet kan være uafhængig af kildesystemer, på den lange bane kan målet være at være fuldstændig uafhængig og faktisk vælge ud fra, hvad der er bedst for virksomheden (det i sig selv er en længere snak om hvordan man udvælger systemer).

Opgaven for en “Adapter” er at skabe den egentlige integration. Når man ikke kan garantere at kildesystemerne har nogle fornuftige “håndtag” til at bruge til at få data ud fra (fx. API, eller services) så har man nogle gange ikke andre muligheder end. fx. at hente fra systemets database eller “scrape fra skærmen” (screen-scraping). De sidste muligheder er langt fra de mest optimale, men det kan være den eneste løsning, hvis man fx. har legacy systemer som skal integreres, eller man henter data fra nettet som ikke er tilgængelig på andre måder.

Fordelene ved at have denne “adapter” er at man således får en løsere kobling mellem kildesystemerne og de andre systemer i ens virksomhed, da de ikke skal kende til hinanden. Det betyder også i langt højere grad at vi begynder at opbygge en stærk infrastruktur i virksomheden som integrerer alle vores systemer. Det er denne infrastruktur som kan give os en konkurrencemæssig fordel, da denne ikke kan kopieres af vores konkurrenter, da den er unik for netop vores virksomhed (alle konkurrenterne kan nemt købe de samme kildesystemer, men integrationen og den viden der ligger i integrationen – som nu minder mere og mere om en Service Orienteret Arkitektur (SOA) – kan ikke kopieres). I dette tilfælde vil det også være nemmere på sigt at vokse og skifte et system ud, så skifter man “blot” adapteren og så kører alle systemer igen.

Flere detaljer på den besked-orienterede integration. Nu med adaptere.

Anbefalinger

Skal man i gang med at integrere systemer eller er man ved at undersøge om der er værdi i det kan man med fordel starte med at lave simple punkt-til-punkt integrationer. Rigtig mange behøver aldrig at lave andet, da det dækker behovene fint og skaber den nødvendige værdi i virksomheden. Efterhånden som man får et større og større behov (fx. vækster man) så kan man overveje om man skal i en anden retning og kigge på mere avancerede typer af integration.

Nogle af de største udfordringer vi ser for virksomheder er at man laver ad-hoc integrationer uden helt at holde styr på dem. Det vil sige at der er ingen som ved, hvilke integrationer der er lavet (ham der lavede dem, stoppede for 3 år siden) og der er ingen som ved om der er flere ens integrationer, der er heller ingen som tør røre ved systemerne – og mindst af alt skifte det gamle regnskabssystem (fx. C5) ud. Vore råd – vær proaktiv:

  • Indkøb/vælg systemer som faktisk kan integrere med andre
  • Træf beslutning omkring integrationer inden andre gør det for dig
  • Tænk ud af boksen – vidste du fx. at RPA faktisk nemt kan bruges til at lave integrationer med?
  • Tænk mere ud af boksen – nu du alligel trækker data ud, hvorfor indsætter du dem ikke i en database så du kan lave rapporter og analyser (Business Intelligence) fx. med Microsoft Power BI.

Sådan kan vi hjælpe

Lad os rådgive dig om næste skridt. Udfyld kontaktformularen her på siden så er vi klar til at hjælpe jeres virksomhed i gang med at integrere jeres systemer.