Integrasjoner er det stedet i en anskaffelse der arbeid oftest faller mellom to leverandører. Deres nye leverandør skal snakke med et system noen andre eier. Begge priser sin ende av røret. Ingen priser selve koblingen, fordi ingen vet hvor mye jobb den andre parten faktisk krever.
Løsningen er ikke å beskrive teknisk hvordan integrasjonen skal bygges. Det er å beskrive hva som skal utveksles, i hvilken retning, hvor ofte, og hvem som eier hvilken del.
Fem spørsmål per integrasjon
- Hvilke data? Ikke «kundedata», men hvilke felt, og hvilken definisjon de har. Se begreper og definisjoner.
- Hvilken vei? Ut, inn eller begge veier. Hvem er kilden, og hvem har fasit hvis de to er uenige?
- Hvor ofte, og hvor raskt? Sanntid, hvert kvarter eller nattlig batch. Dette er den enkeltopplysningen som endrer prisen mest.
- Hva skjer ved feil? Skal det prøves på nytt, varsles, køes? Hvem får varselet, og hva er akseptabelt tidsvindu før noen gjør noe?
- Hvem eier grensesnittet? Hvem bygger det, hvem drifter det, hvem betaler når systemet i den andre enden oppgraderes.
Fagsystemer oppgraderes. Når X kommer i ny versjon om to år og grensesnittet må justeres — er det inkludert i forvaltningsavtalen, eller er det en endringsordre? Avklar det nå, mens du fortsatt har forhandlingsstyrke.
Beskriv behovet, ikke protokollen
Det er fristende å skrive «integrasjonen skal benytte REST med JSON over HTTPS». Noen ganger er det riktig — når dere allerede har en integrasjonsplattform som krever det. Ellers har du låst en teknisk løsning uten å vinne noe.
K-510 (skal) Når det fattes vedtak i en sak, skal vedtaksdata gjøres tilgjengelig for økonomisystemet innen 5 minutter, med sakens identifikator, vedtaksdato, beløp og gebyrtype.
K-511 (skal) Grensesnittet skal være dokumentert og maskinlesbart, slik at det kan brukes uten bistand fra leverandøren.
K-512 (skal) Feilet overføring skal logges og varsles til driftsansvarlig, og skal kunne kjøres på nytt uten tap eller dublering av data.
K-511 er verdt særlig oppmerksomhet. Et dokumentert, åpent grensesnitt er den billigste forsikringen du kan tegne mot innlåsing — og den henger tett sammen med exit.
Ta med det manuelle
Mange «integrasjoner» er i dag en person som eksporterer et regneark og laster det opp et annet sted. De teller. Beskriv dem, for de representerer arbeid som enten skal automatiseres eller fortsette å eksistere — og begge deler er en beslutning noen må ta.
Nasjonale fellesløsninger
I offentlig sektor er det ofte fellesløsninger i bildet: innlogging, meldingsformidling, folkeregister, matrikkel, arkivstandarder. Nevn dem eksplisitt med navn og hvilken rolle de har. De har egne krav til tilkobling, egne godkjenningsløp og egne tidsfrister som påvirker prosjektplanen mer enn folk regner med.
Vanlige feil
- «Systemet skal kunne integreres med våre øvrige systemer.» Dette er ikke et krav, det er et håp. Hver integrasjon må stå for seg.
- Den andre enden er ikke spurt. Sjekk at eieren av fagsystem X faktisk har et grensesnitt, og hva det koster å bruke det.
- Ingen eier feilhåndteringen. Da oppdages feil av en bruker, i gjennomsnitt flere dager for sent.
- Integrasjoner nevnes bare i én setning i avgrensningen. Se kapittel 3 — de skal både avgrenses og beskrives.