integrasjoner

Integrasjon, fabeldyret alle jakter på

Hvordan skal du få alle systemene til å snakke fornuftig sammen?

Det er den ultimate drømmen, både for oss utviklere, og for dem som kommer til oss for å få laget et system. At alle arbeidsoppgaver sømløst håndteres av ett system, slik at man kun behøver å legge inn informasjon én gang, ett sted. Og så må gjerne dette systemet ta hånd om kalendere og liknende også, slik at jobbdagen går sømløst sammen med planleggingen av privatlivet.

Realiteten er ofte en litt annen. Man har ett økonomisystem for regnskap, et timesystem for timeføring, et crm-system for kundehåndtering og så videre. Så er ønsket selvfølgelig å lage integrasjoner, slik at disse oppfører seg som ett system. Idéen er god, da det av mange årsaker stort sett er umulig å lage ett fellessystem for hele pakka. Og målet er absolutt noe som er verdt å strebe etter.

Men resultatet ender dessverre for ofte med flere problemer enn løsninger. Alle brukere eller forvaltere av et system med integrasjoner vet at det ofte er i integrasjonen det feiler. Det er her data blir korrumpert, eller at systemet rett og slett bryter sammen. Er det så forbannet vanskelig å lage en fungerende integrasjon da? Hvorfor er dette blitt fabeldyret alle jakter men ingen finner i systemutvikling?

Først er det selve naturen i det å integrere. Av én eller annen grunn er det en oppfatning både i teknologikretser, og i forretningsverden, at bare systemene snakker samme «språk» (gjerne xml eller lignende) så er det lett å lage en integrasjon. For en del år siden, da MAPI ble lansert som språket alle systemer skulle snakke, og som skulle forene verdens systemer til ett, stod spørsmålet akkurat like klart for meg. Hvis garasjen min og postkassen min begge snakker MAPI, har de noe å snakke om da? I hvert fall der jeg er vokst opp, hadde de begge noe med biler å gjøre. Garasjen huser en bil, og postkassen får posten sin fra en bil, så bil er vel noe de kanskje kunne snakke om? Men hvis man tenker etter, så er bil to helt forskjellige ting for postkassen og garasjen, så det gir liten mening i å dele informasjon.

Det er det samme i systemverden. Selv om både timeføringssystemet og økonomisystemet behandler persondata, er det vidt forskjellige ting de bruker dem til. Det er derfor ikke opplagt at det gir mening å integrere denne informasjonen mellom dem.

Første post i en vellykket integrasjon, er altså å undersøke nøye om det faktisk skal være en integrasjon.

Den neste utfordringen er duplisering av data. Nesten alle integrasjoner jeg har sett opp gjennom årene har handlet om kopiering av data fra ett system til ett annet. Det er få ting som gjør brukere så utrygge på et system som at informasjon ett sted er forskjellig fra samme informasjon et annet sted. Si at det ett sted står at et salg var på 25.000 kr. og et annet sted står det at samme salget var på 23.400 kr. Du kan ikke helt stole på noen av de tallene da? Å lage kopier av data, og tro at man skal klare å holde dem synkronisert, er utopi! Finnes det to versjoner, blir det på ett eller annet tidspunkt til to forskjellige versjoner.

Integrasjoner bør derfor etterstrebe å ha én kilde til data. For eksempel bør ordrehistorikk ligge kun i økonomisystem. Andre systemer (som statistikk og styringssystemer) bør hente informasjonen sin fra økonomisystemet ved behov. Ikke lagre noe av det selv. Dette kan dessverre i mange tilfeller være umulig å få til. Ofte er systemene allerede konstruert med sine egne datakilder når integrasjon skal planlegges. Men ta da med i betraktningen at det kommer til å oppstå forskjeller mellom systemene, og vurder hvilke konsekvenser dette kan få, før man lager en integrasjon.

Hvor ofte har jeg ikke hørt følgende scenario utfolde seg: Ansatt: «Kundebehandlingssystemet virker ikke. Det kommer en feilmelding når jeg starter opp». Drift: «Ja, vi vet det og jobber med saken. Vi oppgraderte økonomisystemet i går, og nå fungere ikke integrasjonen til kundebehandlingssystemet». Integrasjon er samhandling mellom to helt forskjellige systemer. Integrasjoner er derfor svært utsatt for en nesten uendelig mengde feilkilder. Man må alltid ta høyde for at en integrasjon på et eller annet tidspunkt ikke virker. Følgende spørsmål må være besvart i enhver funksjonell spesifikasjon som omhandler en integrasjon: Hva skal skje når integrasjonen ikke virker? Hvordan skal systemene oppføre seg da? Er mangelen på informasjonsflyt så alvorlig at ingen av systemene kan benyttes? Eller er det grunnlag for at noen av de involverte systemene fortsatt kan være tilgjengelig?

Den observante leser fikk kanskje med seg at jeg skrev «funksjonelle spesifikasjonen» i avsnittet over. Integrasjoner regnes nemlig ofte som en «back end»-greie som handler om å kopiere litt data mellom databaser. Integrasjoner er definitivt ikke en «back end» noe som helst! Integrasjoner skal ikke, og kan ikke, fungere uten et klart definert funksjonelt behov. De må komme som en følge av den funksjonelle spesifikasjonen, og ikke som et tillegg til. Selv om alle systemene som skal integreres allerede er laget og ikke kan endres, må det utformes en god funksjonell spesifikasjon på selve integrasjonen. Her må blant annet brukerens opplevelse av en fungerende – og feilende – integrasjon beskrives.

En annen meget god grunn til ikke å se på integrasjon som kopiering av data fra at system til et annet, er at integrasjoner ofte blir feilhåndtert i arkitekturen. De lages som nettopp dette, en rutine som kopierer data fra den ene databasen til den andre. Det er definitivt ikke det vi ønsker med en integrasjon. Den går da bak ryggen til forretningslogikken i systemene. Det er ikke gitt at en operasjon som er gyldig i det ene systemet, også er gyldig i det andre. Slike integrasjoner på lav-nivå har derfor en tendens til å lage ugyldige data i ett av systemene, i verste fall med den konsekvensen at systemet som rammes ikke fungerer lenger.

Dette er spesielt viktig når integrasjonen skrives som et tillegg mellom to eksisterende systemer. Forretningslogikken i disse systemene kan jo over tid endre seg, slik at forutsetningene for integrasjonen også gjør det. Dette vil bli et stort vedlikeholdsproblem hvis ikke integrasjonen benytter forretningslogikken i den enkelte applikasjon. I noen tilfeller (færre og færre heldigvis) tilbyr ikke eksisterende applikasjoner et grensesnitt som tillater integrasjon gjennom forretningslogikken. Det kan gjøre integrasjon på datanivå til den eneste muligheten. Da må farene med en slik integrasjon vurderes nøye før integrasjonen settes ut i livet.

En siste ting fra en som har skrevet noen integrasjoner: Det er enda en veldig god grunn for å la integrasjonen gå gjennom forretningslogikken. Applikasjonene har forhåpentligvis implementert gode feilmeldinger. Jeg har enda til gode å lage en integrasjon hvor ikke utviklerne av begge systemene som skal integreres må være svært delaktige. Grunnen til dette er at det kan være utfordrende å få en integrasjon til å virke i første omgang. Stort sett får man bare en ubrukelig feilmelding fra systemet man integrer mot hver gang man prøver å utføre en operasjon. Så må man få utviklerne av dette systemet til å finne ut hva som feiler. Og sånn går nå dagene. Feilmeldinger som er nyttige for brukerne, er akkurat like nyttige for et system som skal integrere seg. Det hadde hjulpet uendelig mye å få fornuftige feilmeldinger fra systemene. Ikke minst også for å kunne presentere noe fornuftig til brukerne hvis en integrasjonsoperasjon feiler.

En integrasjon kan være det mest arbeidssparende du noen gang investerer i. Det kan også bli til den største frustrasjonen du noen gang har hatt. Integrasjoner er ikke likefrem, og må planlegges nøye før de kan utvikles til nyttige verktøy. Først og fremst i en funksjonell spesifikasjon, men også i en teknisk spesifikasjon. Legg merke til at begrensninger i den tekniske spesifikasjonen også sterkt kan påvirke den funksjonelle. Hvis du i tillegg husker på å se på konsekvensen av – og systemenes oppførsel ved – mulige feilsituasjoner, er du bedre skodd for å kunne lage en god opplevelse.

Publisert