Der kan være flere udfordringer ved at integrere sine systemer med hinanden. Når man starter et helt friskt projekt, helt nye systemer og mulighed for at vælge alle de systemer (eller de fleste af dem) som skal bruges har man nogle andre forudsætninger for at lykkes med sine integrationer – dette er ofte kendt som “green field” – et helt nyt kapitel som man selv har indflydelse på. Virkeligheden er ofte en anden – her er der gamle systemer typisk skrevet uden tanke for at integrere med andre systemer. Der er måske endda hjemmeudviklede systemer som har nogle år på bagen og som man ikke bare lige smider ud. Dette er ofte kendt som “brown field” – det vil sige et eksisterende miljø som skal med i overvejelserne.
Der er i hvert af de scenarier, beskrevet ovenfor, forskellige krav til de typer af integrationer man skal udvikle. Ofte er der mange flere “bevægelige dele” i forbindelse med integrationer mellem eksisterende systemer, da de er udvalgt ud fra nogle andre kriterier end man måske ville bruge til at udvælge systemer, skulle man gøre det igen i dag.
Typer af integrationer
Når man arbejder med integrationer er der overordnet set 3 generelle måder at gøre det for, dette gælder for på tværs af alle forskellige “generationer” af systemet, det er helt fra en “moderne tilgang til integration” og til at kunne håndtere integration ved at eksportere/importere filer med data.
- Delte filer
- Delte databaser
- Direkte kald (API / Services)
- Messaging
Der er flere fordele og ulemper ved disse forskellige måder at integrere på, nogle af dem kan endda gå hånd-i-hånd. Resten af denne artikel vil beskrive fordele og ulemper ved hver tilgang.
Delte filer
Specielt ved ældre systemer er det nogle gange nødvendigt at lave integrationen ved at det ene system eksporterer en fil med data og så importerer et andet system disse data – dette sker så med nogle bestemte intervaller og så har man en integration.
Man vil måske kigge på denne integration og tænke at det kan da ikke passe at man i dag skal have integrationer som er baseret på filer og denne “primitive” tilgang til at få moderne systemer integreret. Dette er nogle gange præmissen når man arbejder med legacy (ældre) systemer. Det er faktisk ikke længere væk end at en stor del af arbejdet ved webshops til dels arbejder med store mængder billedfiler (produktbilleder) som skal integreres ind i en webshop.
Fordelen ved delte filer er at det er “laveste fællesnævner”, næsten alle systemer kan lave en eller anden form for eksport til en fil – og ja, i mange tilfælde er det ældre systemer som skal integreres.
En af ulemperne ved at integrere ved at bruge filer er at man “kun” får data, det vil sige at man flytter data, modtager-systemet ved ikke noget omkring data og opdager kun at der nu er ekstra data importeret som det skal præsentere. Dette betyder at den data der importeres ikke har været underlagt forretningsreglerne og valideringerne inden det importeres. Traditionelt vil man gerne have “informationen” eller “notifikationen” om at der har været opdateret noget data, fx. en kundes adresse, således man vil kunne reagere på denne handling med mere end blot at have opdateret data (måske skal der tjekkes for forsendelse eller momszone – som ellers ville ligge i forretningslogikken i et givet system).
Delte databaser
Lidt i samme boldgade som med delte filer, måske en anelse mere “suspekt” i visse henseender og nogle gange er dette slet ikke muligt. At snuppe data direkte fra en database fra et system stiller store krav til forståelsen for systemet og det kan bestemt ikke anbefales at gøre dette.
En anden vinkel på dette er at man måske kan køre flere systemer på den samme database (i teorien kan dette lade sig gøre, men i praksis ses det meget sjældent) og så et sæt tabeller til hvert system. Det vil give en masse fordele i forhold til at kunne synkronisere data ved at bruge funktionalitet som allerede findes i databasen (fx. triggers og stored procedures).
Ulempel ved denne type af integration er helt klart at man går direkte til data og går uden om forretningslogikken som findes i selve applikationerne. Igen aner de enkelte applikationer intet omkring de handlinger, der sker og har ikke mulighed for selv at styre sikkerhed, valideringer og forretningsmæssige tjeks.
Direkte kald
Direkte kald er den mest benyttede form for integration. Det er typisk, der hvor man binder flere systemer sammen ved at bruge et SDK (som integreres i ens kode) eller et eksternt interface som fx. en RESTfull service. Det er en enkel måde at integrere på og der, modsat delte filer og databaser, får man et “håndtag” ind i applikationen som giver applikationen mulighed for at køre forretningslogik inden der persisteres til en database eller lignende.
Dette er langt den simpleste måde at integrere på og fungerer hurtigt og pålideligt. Ulemperne kan være at både kalder og modtager SKAL være online på samme tid, kalder SKAL kende til modtager og det format som modtageren modtager data i. Det stiller nogle krav til denne måde at integrere på, noget som diskuteres mere i dybden i dette blogindlæg.
Messaging
Messaging er til integrationer, hvor der er store mængder data som skal flyttes eller hvor der er større krav til selve arkitekturen i integrationerne omkring at integrere mellem adskillige systemer. Ved at bruge messaging får man et løst koblet system, hvor kalderen ikke kender til modtageren, men hvor det hele sker ved at udveksle beskeder (fx. en kommando eller noget data) og en til mange forskellige modtagere kan så behandle disse beskeder.
Messaging har nogle klare ulemper i at det er avanceret og det er ikke til de fleste, mindre integrationsopgaver, måske mere til større opgaver eller i situationer, hvor kravene til projektet afspejler en vis kompleksistet.
Fordelene er at også til at tage at føle på, man vil opleve flere, mindre integrationer intet behov for at kalder og modtager skal være online på samme tid og muligheder for nemt at udvide systemet løbende med nye integrationer. Dette er beskrevet mere i dybden i dette blogindlæg.
Kan alt integreres?
Det korte svar er JA! (med alle forbehold, alt det med småt og alle de “men” man kan komme i tanke om). Det handler måske mere om rentabiliteten i det, bare fordi man kan integrere noget behøver det ikke give mening at rent faktisk gøre det. Her er det i høj grad op til den enkelte business case at afgøre dette.
Ud fra gennemgangen af ovenstående kan man godt få den ide at man skal vælge een af disse tilgange. Praksis er mere i retning af at man skal vælge en som den primære (her anbefaler vi messaging eller direkte kald) og så lave små stykker software (adaptere / proxies) som så kan tilpasses til de systemer som ikke direkte kan integreres.
Vi ser flere og flere gange også at det handler meget om at kombinere teknologier. Et godt eksempel på dette er at bruge RPA til at validere en integration og på sigt transformere den ind til en fuld integreret integration.
Kontakt os, hvis du har systemer som skal integreres, så kommer vi med limpistolen.