Hverdagsdigitalisering - som også naboen setter pris på - Lær hvordan!

Digitalisering i virkeligheten – det er eNabovarsel et godt eksempel på. Når du som privatperson eller profesjonell arkitekt skal søke kommunen om byggetillatelse – så må du varsle naboene dine.

I 2018, og tidligere, måtte du finne riktig skjemaer, skrive de ut, finne all informasjon om eiendommen din – og naboene dine. Deretter sørge for at alle naboene er underrettet. Dette gjøres som regel via rekommandert post – ja – det som kommer i postkassen som du må hente ut på postkontoret med legitimasjon – og som koster en snau tohundrelapp.

Er dette en digital hverdag i 2019?

Norkart synes ikke det. Vi synes en digital hverdag skal være så enkel som mulig. Derfor lager vi eNabovarsel. Men vi gjør ikke dette alene. Vi bygger videre på offentlige felleskomponenter fra Altinn, DiBK, DiFi, Kartverket – og selvfølgelig Azure – Microsoft sin cloud-tjeneste.

Når brukeren går inn på siden for eNabovarsel på e-Torg.no, så er dette en React/Redux-klient skrevet i TypeScript. Her veileder vi brukeren gjennom ulike steg for å enklere fylle ut påkrevd informasjon. Vi logger inn brukeren via ID-porten til DiFi. ID-porten er sikkert som «banken» og er det offentlige sin felles innloggingsportal. Dette sørger for at vi er autentisert client-side og kan hente inn eiendomsinformasjon og preutfylle en del av eNabovarselet. Vi bruker vår dataplattform, Norkart Datavarehus, til å preutfylle mye av informasjonen. Her står vi på skuldrene til over 150 geografiske datasett som er oppdatert, kvalitetssikret og enkelt å analysere og utvikle mot.

Det er Direktoratet for byggkvalitet (DiBK) som står bak initiativet til å ha et digitalt nabovarsel som er offentlig godkjent. For å integrere mot tjenestene må vi ha konsesjon til dette fra DiBK – som vi selvfølgelig har. Teknisk sett er integrasjonstjenestene bygget på Altinn-plattformen som vi integrerer oss mot. Et krav i tjenestene er at vi må sende all data client-side – på XML. Ja, du leste riktig: fra client til Altinn med XML. Dette har utfordret oss litt siden vi skal sende en god del filer som vedlegg til nabovarselet – som situasjonskart. Vi utvikler web-native, så for å unngå og herje for mye med XML i Javascript/TypeScript, så har vi lagd et eget internt API-endpoint «OrhanAPI» (don’t ask) – som tar imot JSON-data fra klienten og oversetter til Altinn-XML og gjør sjekk mot Altinn/DiBK-API’et om alt er OK. Deretter sender vi riktig XML fra webklienten til Altinn-API’et – og da med riktig ID-Porten-innlogging. Vi skulle gjerne hatt en mulighet for å sende nabovarselet server-side til Altinn siden vi da kunne gitt en enda mer robust brukeropplevelse. En svakhet er blant annet hvis brukeren er på mobil og switcher mellom 4G og WiFi – akkurat idet hun trykker «send». Da kan ikke vi garantere innlogging med ID-Porten lenger og det vil ikke bli sendt. Påskeønske fra Altinn og DiBK er dermed: server-server API – og gjerne med JSON som payload 😉.

Før vi sender nabovarselet tar vi betalt fra brukeren – dette gjør vi med en integrasjon via NETS som sørger for korrekt og trygg betaling og tilbyr en rekke betalingsformer. Dette fletter vi inn mot våre egne API som driver mye av «handlekurv»-funksjonaliteten til Norkart sin dataplattform som blant annet står bak e-Torg, meglerpakkeautomatisering, eiendomsanalyser og lignende. Rent teknisk innebærer dette en rekke round-trips mellom klient, server, NETS-API og tilbake igjen. Her har vi også laget litt ekstra funksjonalitet som sjekker om innsending faktisk gikk bra, før vi trekker betalingen. Dette er for å sikre at vi ikke tar betalt hvis noe går galt hos Altinn eller på veien til Altinn. Det gjør sjeldent det, men vi ønsker ikke å ta betalt for noe vi ikke leverer. Disse sjekkene og flere andre «utilities» har vi implementert som en håndfull Azure Functions.

Når alt går fint – så venter vi på Altinn – en god stund. For det tar en god stund å sjekke opp alle eiere til alle naboer – og sjekke om disse er korrekte, er i live, har kontaktinformasjon, har reservert seg mot digital kontakt (why?) og lignende. Faktisk er den aller største grunnen til at eNabovarselet ikke blir sendt fullstendig at den registrerte eieren til en nabo er død. Og da ikke kan motta et nabovarsel, digitalt eller analogt. Dette er dessverre dårlig datakvalitet i det offentlige eiendomsregisteret – matrikkelen – noe vi, og bransjen jobber for skal bli bedre.

Etter vi har ventet – og pollet – en stund på Altinn, så får vi OK eller «Noe mangler». Dette blir liggende i Altinn-innboksen til brukeren som er logget inn – men vi sender også en epost direkte for å gi beskjed om hvordan det har gått.

Så – en digital hverdag i 2019 innebærer en del samspill mellom ulike API’er og partnere, både offentlige og private. Vi bruker Altinn, DiBK, NETS, DiFi, Azure, Matrikkelen og sFKB. Og vi setter det sammen med smarte utviklerhoder som finner praktiske løsninger – ikke teoretiske. Det er vi stolte av!

Med dette skaper vi litt smartere samfunn – sammen.

Og forresten – sa jeg at løsningen er utviklet av over 50% unge #Techkvinner?