Systemintegration er arbejdet med at få selvstændige it-systemer til at udveksle data og udløse handlinger hos hinanden, så en forretningsproces kan løbe fra ende til anden uden manuelle mellemled. En ordre, der oprettes i webshoppen, skal ende i ERP-systemet, udløse en plukliste på lageret, sende et spor til fragtleverandøren og opdatere kundens historik i CRM-systemet. Hvert af de spring er en integration, og det er dem, der afgør, om digitaliseringen faktisk sparer tid.
Behovet opstår, fordi ingen organisation køber alle sine systemer på én gang. Webshoppen kom i 2018, økonomisystemet i 2012, lønsystemet er leverandørens standard, og et opkøb har medbragt et fjerde system, der gør det samme som et af de tre andre. Regnearket, hvor en medarbejder hver morgen kopierer tal fra ét system til et andet, er ikke en arbejdsgang; det er en integration, der ikke er bygget endnu, og den koster både tid og fejl.
Punkt til punkt-integrationer er den mest almindelige og på lang sigt dyreste tilgang. Hvert system forbindes direkte til hvert andet system, hvilket fungerer fint ved tre systemer og bliver uoverskueligt ved ti. Antallet af mulige forbindelser vokser kvadratisk, og hver enkelt skal vedligeholdes, når et af systemerne opdateres. Resultatet kaldes i branchen et integrations-spaghetti, og det er en af de hyppigste kilder til teknisk gæld.
Alternativet er en integrationsplatform, hvor systemerne kun forbindes til ét fælles lag. iPaaS-løsninger som Azure Integration Services, MuleSoft, Boomi og Workato i den tunge ende, og Make eller Zapier i den lette, giver ét sted at overvåge, logge og fejlsøge. Prisen er en fast platformomkostning og en ny kompetence at vedligeholde, og for organisationer med under en håndfuld integrationer er den investering sjældent berettiget.
API'et er den moderne integrationsgrænseflade. Et REST-API stiller systemets data og funktioner til rådighed over HTTP i et defineret format, så andre systemer kan hente og skrive data uden at kende den bagvedliggende database. Ved indkøb af nyt software bør det derfor stå som et skal-krav, at systemet har et dokumenteret og offentligt tilgængeligt API. Et system uden API kan i praksis ikke integreres uden leverandørens medvirken, og det er en afhængighed, der kan blive dyr at komme ud af.
Synkron og asynkron integration løser forskellige problemer. Synkrone kald venter på svar og bruges, når svaret skal foreligge med det samme, som ved lagerkontrol i checkout. Asynkron integration lægger beskeden i en kø, som modtagersystemet henter, når det kan, og det er den robuste model til alt, der ikke haster: fakturering, rapportering, batch-opdateringer. En kø gør også, at et system kan være nede i en time uden at data går tabt, og alene det argument gør asynkron integration til standardvalget for driftskritiske strømme.
Filoverførsel og databaseintegration er de to ældre metoder, der stadig er udbredte. Natlige filudvekslinger over SFTP i CSV- eller EDI-format er robuste og velegnede til store datamængder, men de opdaterer kun én gang i døgnet, og fejl opdages først næste morgen. Direkte opslag i et andet systems database bør derimod undgås helt: den binder integrationen til en datamodel, leverandøren frit kan ændre ved næste opdatering, og den omgår de valideringsregler, systemet ellers håndhæver. Findes muligheden ikke andre steder, er det et argument for at skifte system, ikke for at bygge videre.
Legacy-systemer er den vanskeligste del af integrationsarbejdet. Et 20 år gammelt fagsystem uden API kan i mange tilfælde ikke udskiftes, fordi det rummer forretningslogik, ingen længere kan dokumentere. Den etablerede tilgang er strangler fig-mønstret, hvor et integrationslag lægges foran det gamle system, hvorefter funktionalitet flyttes ud stykke for stykke, indtil kernen kan slukkes. Det er langsomt, men risikoen fordeles over år i stedet for at samle sig på én weekend.
Datamodellen er den usynlige del af enhver integration. To systemer kan sagtens have et felt, der begge steder hedder kunde, uden at det betyder det samme: det ene tæller en juridisk enhed, det andet en leveringsadresse. Uden en fælles begrebsafklaring flytter integrationen bare uenigheden hurtigere rundt. Arbejdet med at definere de centrale forretningsobjekter, og udpege hvilket system der ejer hvilket felt, hører til før den første linje kode.
I den offentlige sektor og i handlen med det offentlige er en del af integrationslandskabet fastlagt på forhånd. Nemhandel og OIOUBL-formatet er obligatoriske for elektronisk fakturering til offentlige myndigheder, MitID og NemLog-in håndterer identifikation, og Serviceplatformen og Datafordeleren stiller grunddata til rådighed for kommuner og styrelser. De grænseflader er veldokumenterede og skal ikke opfindes lokalt; opgaven består i at få den interne systempark til at tale med dem korrekt.
Overvågning skal bygges ind fra start. En integration, der fejler stille, opdages typisk af en kunde, og først når skaden er sket. Hver strøm bør logge sine kald, alarmere ved fejl og kunne genafspille en fejlet besked uden manuel oprydning i databasen. Uden idempotens, altså at den samme besked kan sendes to gange uden at skabe to ordrer, bliver genafspilning i sig selv en ny fejlkilde.
Sikkerhed og governance hører med, fordi integrationer flytter persondata mellem systemer og ofte over organisationsgrænser. Nøgler og tokens skal opbevares i en nøgletjeneste, ikke i kildekoden, adgange skal gives efter princippet om færrest mulige rettigheder, og databehandleraftaler skal dække de leverandører, der reelt får data i hænde. En integrationsoversigt, hvor det fremgår hvilke data der flyder hvorhen, er samtidig et krav under GDPR og det bedste udgangspunkt, den dag arkitekturen skal moderniseres.