Utlendingsdirektoratet

Bildet: Teltleiren bygget innendørs i hall i Råde i Østfold består av 24 telt med 640 sengeplasser. Tildeling av senger skjer etter definerte regler for hvem som kan bo sammen gjennom FLYT.

Logistikk i adkomst 

I 2014 opplevde vi en fremvekst av terrororganisasjoner, borgerkrig i Syria og generell uro i Midtøsten som ga et voldsomt flyktningepress mot Europas yttergrenser i sør. Gjennom sommeren og høsten 2015  satte strømmen av flyktninger en rekke land i Europa under press, og høsten 2015 ble også Norge en del av denne krisen. Enkelte dager kom så mange som 500 nye flyktninger til Norge. Dette la et så stort press på hele vårt apparat for mottak av flyktninger, at enkelte statlige organer ble satt i kriseberedskap.

Mye av krisen besto i at vi ikke hadde nødvendig logistikk for å ta imot flyktningene. Det handlet om å gi de mulighet til å få dekket helt grunnleggende helsetilbud, mat, drikke, sanitærtilbud, og en seng å sove trygt og varmt i. Og behovet for økning i kapasitet økte raskt- veldig raskt!

For å kunne møte dette behovet ble det bygget et helt nytt mottak sentralt i Østfold. De aller fleste flyktningene som kom til Sør-Norge ble sendt hit for å bli tatt imot på en verdig og ryddig måte. Dette mottaket ble bygget opp fra å være en tom, nedlagt hall, til å være et første bosted i noen dager fra ankomst til en mer varig mottaksplass kunne bli gitt. Her ble alle nyankomne registrert av flere statlige etater, bagasje ble registrert, samlet inn og desinfisert (fryst), helsesjekk gjennomført og flyktningene fikk overnatting, klær, hygieneartikler og mat. Og alt dette ble imponerende nok bygget opp i løpet av bare 2 uker.

Behov for et Logistikksystem

En slik logistikkorganisasjon kan ikke drives effektivt uten et godt verktøy for logistikk. Et slikt system fantes ikke 2 uker før oppstart, og måtte derfor utvikles. Det ble i regi av Utlendingsdirektoratet etablert et IT-prosjekt som skulle levere 2 uker etter prosjektforslaget ble påbegynt. Utfordringene sto i kø. Hvordan definere krav for en ikke-opprettet organisasjon på to uker? Hvordan spesifisere systemet som skulle gjøre organisasjonen effektiv? Hvordan utvikle og teste, sette opp milljøer, installere og levere, integrere med hardware for logistikk etc.? Suksessfaktoren var DevOps!

DevOps

DevOps er et relativt nytt begrep, og som alle nye populærord, har det også noe ulik betydning og bruk i dagligtalen. Selv om forvirringen omkring hva DevOps nøyaktig er kan være stor, er det overliggende prinsippet bak ganske klart: DevOps handler om å hjelpe en organisasjon å raskt utvikle programvare og tjenester som kan leveres raskt og drives effektivt. Det ligger også i selve begrepet at DevOps er en sammenstilling av Utviklingen av programvaren (Dev) og drift/driftsmiljø (Ops). Slektskapet mellom DevOps og Smidig utvikling er også åpenbart. Men der Smidig utvikling oppfordrer til kontinuerlig samhandling mellom analyse, design, implementering og kvalitetssikring, bringer DevOps den kontinuerlige samhandlingen videre til driftsmiljøet. DevOps er en tilnærming til softwareutvikling som spenner over hele leveranseløpet.

Viktige karakteristika ved et vellykket DevOps prosjekt:

• Svært kort prosjektperiode frem til første release i produksjonsmiljø
• Hyppige releaser til produksjon for feilrettinger - Hyppige releaser av ny funksjonalitet
• Høy grad av automatisering
• Høy brukskvalitet og brukerengasjement
• Lav feilrate for integrering av hardware og driftsmiljøet generelt
• Høy samlet sikkerhet for system og miljøer  
• Lave leveransekostnader
• Lave driftskostnader

FLYT i front

Systemet som ble utviklet for UDI og mottaket ble raskt gitt navnet FLYT. Det er et godt navn som beskriver både bruksverdien av systemet og prosessen som ledet frem til lansering. Systemet har allerede fra første produksjonssetting (12 dager etter prosjektstart) blitt et sentralt verktøy for å sikre god håndtering av asylsøkerne som ankommer hver dag. FLYT er det første møtet mange fremtidige nordmenn har med IT. Det er det første systemet de møter i norsk statsforvaltning, og det står helt i front i flyktningestrømmen.

Mottaket benytter det for å gjøre en første registrering av personer (selvbetjent på 13 språk). Det brukes til å registrere bagasje og eiendeler og merke disse. Systemet sikrer kontroll på hvilke personer som har vært til visitasjon, intervju, helsesjekk mm. Politiets Utlendingsenhet, mottaksoperatøren, søkerne selv og helsepersonell er ulike brukergrupper for systemet.

Mottaket benytter systemet til å holde oversikt over hvilke deler av mottaket den enkelte person befinner seg i til enhver tid, hvem som har fått utdelt materiell, er tildelt sengeplasser og ankommet/forlatt mottaket.

For flyktningene er kortet nødvendig for å passere deler av mottaket, gi eierskap til bagasje og tilhørighet på mottaket.

Helseprøver som blir tatt av de ankomne kan også i mange tilfeller gi utslag på alvorlige sykdommer. Da er systemet viktig for raskt å kunne gjenfinne enkeltpersoner på et stort fysisk område når prøveresultatene foreligger.

Systemet integrerer en stor mengde hardware, blant annet inngår det RFID-kort printere, kortlesere, etikettprintere, bagasjelapp- printere og klient-apps i levert løsning. Innkjøp, tilpasning, integrasjon og installasjon av utstyr var en sentral del av prosjektet.

Rask oppstart

For at dette prosjektet skulle være mulig å realisere innen en svært tett tidsramme, var det helt nødvendig å sikre en rask oppstart. Det ble derfor valgt ut personell som hadde riktig bakgrunn for å kunne kjøre et DevOps- prosjekt. Utviklere med «komplett»- kompetanse ble prioritert, og rett domenekompetanse var også avgjørende. Det ble i løpet av første time etter prosjektbeslutningen satt sammen et kjerneteam på 4 konsulenter som alle kjente til kundens virksomhet. Alle deltakere hadde bred erfaring med .Net og MS Azure- plattformen. Sammen med UDI sin produkteier klarte disse fire å både etablere komplett utviklingsmiljø i Azure, bygge en prioritert produktkø og igangsette utvikling av første release. Videre bemanning av prosjektet ble gjort fortløpende, men alle nøkkelressurser fra Kunde og Leverandør var på plass første dag.

Smidig utvikling med produkt i fokus

Prosjektet ble gjennomført ved at det var satt en ramme for første ukes utviklingsløp, og funksjonalitet ble fortløpende prioritert og levert til test. Tett involvering av brukere og interessenter gjorde at riktig og rett funksjonalitet ble utviklet først, og prosjektet fokuserte utelukkende på produkt fremfor prosess.

Continuous deploy

Nye versjoner av web-løsningen FLYT blir automatisk bygget og installert direkte i testmiljøet etter hver kode-insjekk. Installasjon videre til produksjon gjøres ved et tastetrykk etter at funksjonaliteten er verifisert i test. Til test, er det satt opp en egen test-lab med arbeidsstasjoner som gjenspeiler de enkelte funksjonene ved mottaket som systemet betjener. Nye stasjoner blir tilført etter hvert som funksjonalitet blir levert og alle versjoner av stasjonsspesifikke apper blir utviklet, bygget og installert fortløpende.

Første produksjonssetting på mottaket ble gjort 12 dager etter utviklingsstart, og da ble all hardware også installert. Allerede første døgn i produksjon hadde de ulike brukergruppene kommet med flere ønsker om tilpasninger og utvidelser. Samtidig ble utfordringer med hardwareintegrasjon avdekket og rettet. Samlet ga dette 18 nye releaser til produksjon første 2 driftsdøgn.  

Bildet: To utviklere i DevOps- teamet feilsøker og retter feil i nettverksoppsett og routerkonfigurasjon ved mottaket som er under bygging, samtidig som FLYT blir installert og siste deler av systemet fremdeles er under utvikling.

Integrasjon med teknisk miljø

De største utfordringene i en så rask prosjektgjennomføring lå i å vurdere ulike hardwarekomponenter raskt nok, få levert tilstrekkelige kvantum raskt nok, og utvikle systemet i parallell. Etter hvert som installasjon onsite på mottak startet, foregikk utviklingen av 2 parallelle team. Ett team arbeidet ved mottaket, mens det andre teamet arbeidet ved UDI sine kontorer i Oslo. Fordi flere av utviklerne hadde kompetanse på programmering av hardware og nettverk, kunne utfordringer som oppsto i grenseland mellom applikasjon, hardware, lokalt nett og miljø løses umiddelbart av de to teamene parallelt.

Kontinuerlig forankring og styring

For at et så tidsdrevet prosjekt skal kunne gjennomføres, er det en forutsetning at det er stor tillit mellom bestiller og leverandør. Denne tilliten var forankret høyt hos både Kunde og Leverandør. Det ble gitt store fullmakter til beslutninger og også kommersielle avgjørelser til alle deltakere i prosjektet. Ledelse fra flere etater var flere ganger tilstede for demonstrasjoner og avklaringer underveis i utviklingen og sikret forankring og støtte for prosjektet.

Styring av prosjektet var i stor grad delegert til teamet selv, inkludert produkteier, og formell rapportering ble begrenset til et minimum. Det var først og fremst ønsket funksjonalitet med sluttproduktet i fokus som var styringslinjen, selvsagt innenfor de rammene som var gitt.

Installasjon og oppsett

Installasjon av alt utstyr, miljøoppsett og idriftsetting ble gjort av det samme teamet som utviklet løsningen. Dette ga svært rask feilsøking, retting og deploy når mangler ble avdekket. Det har i ettertid også sikret svært kostnadseffektive utvidelser av systemet fordi teamet opparbeidet en grundig forståelse for bruken gjennom erfaringer de selv gjorde ved mottaket.  

Bildet: En logistikk-post (bagasje-app) i FLYT installert på mottaket. Denne stasjonen brukes av flyktningene ved levering av bagasje til fryselager. ID-kortet scannes ved kortleser (limt fast med tape til finèrplate) og lange bagasjelapper printes for festing på bagasje. Systemet ble utviklet og levert raskere enn utstyrsleverandør på møbler kunne levere bagasjebenk, så midlertidig benk ble snekret onsite.

Unik forståelse av faktisk bruk og domene

Gjennom prosjektløpet har deltakerne i teamet fått en unik forståelse av faktisk bruk og nytteverdi av FLYT. Dette er verdifull kompetanse når systemet skal videreutvikles og forvaltes. Det var også mange opplevelser fra arbeidet onsite på mottaket etter hvert som det ankom flyktninger. En del av de siste funksjonene i systemet ble utviklet av teamet som arbeidet onsite i samme rom som de nyankomne ble registert. Til tider ble DevOps teamet nødt til å bidra med utdeling av vann og mat til svært slitne og sultne mennesker, og hjelpe til med å anvise sengeplasser mm. Det har gitt en litt annen opplevelse enn en tradisjonell deploy men har også gitt mye motivasjon i en hektisk innspurt.