Business Case
Enklere å starte restaurant i Oslo
For å fastslå om de foreslåtte hovedmønstrene for hendelsesdrevet arkitektur har en reell praktisk betydning for digitaliseringsarbeidet i felles økosystem, har Digdir valgt å teste disse mønstrene ut på noen utvalgte forretningsscenarier.
Ett av disse forretningsscenariene tok utgangspunkt i livshendelsen om å starte og drive bedrift. Digdir har sammen med Brønnøysundregistrene, Skatteetaten og Oslo kommune gjennomført et eksperimentløp kalt «Born Digital». Vi har sett på hvordan effektivisere prosessene for selskapsetablering ved å la myndighetsaktørene være de som initierer dialogene med næringslivsaktørene og ikke motsatt. Brukeren (næringslivsaktøren) slipper å finne ut hvem han eller hun må snakke med, slik det tradisjonelt har blitt praktisert.
I dette eksperimentløpet har vi pekt på et område som oppleves som svært komplekse sett fra brukerens ståsted, nemlig det å starte en restaurant i Oslo. En typisk etablering involverer søknader til, og kommunikasjon med en rekke offentlige aktører; Skatt, NAV, Brønnøysundregistrene, Politiet, Mattilsynet, Helsedirektoratet – i tillegg til kommunale etater: Næringsetaten for skjenkebevilling, Plan og bygningsetaten (og kanskje byantikvaren) for uteservering, og Vann- og avløpsetaten. Som restaurantgründer er du overlatt til å navigere i dette mylderet av aktører og finne ut hvem du trenger å snakke med, hva du må søke om av tillatelser og hvilke skjemaer du må fylle ut.
Figuren under viser et overordnet bilde av hvordan samhandlingen mellom ulike utvalgte etater ble gjennomført fra det øyeblikket en restaurant ble registrert i Enhetsregisteret til det forelå en tillatelse som gjorde at restaurantgründeren kunne starte skjenking og/eller servering.
Det er mange detaljer som er utelatt i figuren over, spesielt når det gjelder hva som skjer innad hos ulike etatene underveis i prosessforløpet. Hovedhensikten med figuren er å synliggjøre de hendelsene som knyttet de ulike etatene sammen i et sømløst samspill med et felles mål om å gjøre det enklere for en næringslivsaktør å starte en ny restaurant i Oslo.
Næringslivsaktøren benytter tjenesten Samordnet registermelding til å sende inn en forespørsel om etablering av et nytt foretak av typen serveringssted. Når vedtaket om registrering i Enhetsregisteret er fattet, så publiserer Brønnøysundregistrene denne hendelsen. Denne hendelsen kan trigge tjenester hos både Næringsetaten i Oslo kommune og Skatteetaten. Hos Næringsetaten utløser denne hendelsen en intern digital arbeidsflyt, hvor de blant annet inviterer innehaveren av den nye virksomheten til å starte en søknadsprosess om skjenkebevilling og/eller serveringsbevilling. Tilsvarende hos Skatteetaten utløser denne hendelsen en intern digital arbeidsflyt, hvor de blant annet inviterer innehaveren av den nye virksomheten til å starte en søknadsprosess om MVA-registrering.
Som figuren over viser, oppfyller allerede den første delen av dette forretningsscenariet samtlige kriterier for å etablere en arkitektur for hendelser. Med denne tilnærmingen, løskobles aktøren som produserer en bestemt hendelse fra de potensielt mange som konsumerer den samme hendelsen. Det som da eventuelt måtte skje videre internt hos de ulike hendelseskonsumentene vil foregå i parallell, helt uavhengig av hverandre.
Selve utprøvingen av de tre hovedmønstrene for hendelsesdrevet arkitektur ble ikke gjennomført like grundig eller på en tilstrekkelig formalisert måte som vi hadde håpet på, men det var likevel ett av hovedmønstrene som pekte seg ut som svært aktuelt, nemlig hendelsesmønsteret «Event-Carried State Transfer».
Dette hendelsesmønsteret gjorde Brønnøysundregistrene i stand til ikke bare å varsle interessenter som Skatteetaten og Oslo kommune (Næringsetaten) om at det har forekommet en ny registrering i Enhetsregisteret, men også mulighet til å sende over ytterligere informasjon om hva slags type foretak som ble registrert, hvem som var innehaver av foretaket, og andre viktige opplysninger. Med dette hendelsesmønsteret reduseres graden av dataoppslag, som Skatteetaten og Oslo kommune (Næringsetaten) ville måtte gjøre i etterkant dersom de hadde mottatt kun organisasjonsnummeret til det nye foretaket i varslet fra Brønnøysundregistrene.
Av hensyn til prinsippet om dataminimering, kunne hendelsesmønsteret «Event Notification» være aktuelt for dette forretningsscenariet, gitt at det ikke forelå noe behov for konsumentene av en hendelse å vite noe mer utover det som allerede var blitt varslet. Dersom disse konsumentene ikke hadde behov for å gjøre noe dataoppslag i etterkant av varslingen, kunne dette hendelsesmønsteret være aktuelt. Det var ikke blitt gjort noen formell utprøving av akkurat dette hendelsesmønsteret for dette forretningsscenariet.
I eksperimentløpet «Born Digital» bestemte man seg for å ta i bruk Altinn Events som felles hendelseshåndteringssystem, men utvekslingen av hendelser kunne i teorien skje gjennom aktørenes egne hendelseshåndteringssystem. Altinn Events er en HTTP REST basert mikrotjeneste for sikker håndtering av hendelser med funksjonalitet for å håndtere abonnenter, ta imot hendelser og levere hendelser til abonnenter. Formatet på hendelsene er basert på en åpen standard – CloudEvents (https://cloudevents.io/)
«Ved å velge Altinn Events som fellesløsning for hendelsesformidling, så kunne Brreg, Oslo Kommune og Skatteetaten som hhv. produsenter og konsumenter av hendelser komme raskere i gang med å dele hendelser enn hvis vi skulle blitt enige om andre løsninger. Altinn Events tilbyr forskjellige mekanismer for konsumenter å hente ut hendelser («hendelsesuttak»), både abonnement og oppslagsmønster, noe som gjør at produsenten ikke behøver å legge til rette for forskjellige behov for sine konsumenter. For konsumentene betyr dette at de kan få tilgang til hendelser på samme måte uavhengig av hvem som produserer de. Det er også en fordel at Altinn Events er integrert med og fungerer godt sammen med andre nasjonale fellesløsninger som Dialogporten og Altinn Autorisasjon.»
(Anne Lise Furmyr, Skatteetaten)
Under forklarer vi hvordan en arkitektur for hendelser i felles økosystem kan realiseres for dette forretningsscenariet gjennom bruk av Altinn Events som felles hendelseshåndteringssystem. Vi har valgt å vise kun samhandlingen mellom næringslivsaktøren, Brønnøysundregistrene og Oslo kommune (Næringsetaten).
- Næringslivsaktøren benytter tjenesten Samordnet registermelding til å sende inn en forespørsel om etablering av et nytt foretak av typen serveringssted.
- Når registreringen er fullført og godkjent, så vil Brønnøysundregistrene produsere hendelsen «vedtak om registrering i Enhetsregisteret» hvor de legger ved organisasjonsnummeret til det nye foretaket.
- Hendelsen «vedtak om registrering i Enhetsregisteret» blir publisert til et hendelseshåndteringssystem med organisasjonsnummeret til det nye foretaket som nyttelast, som i dette eksemplet er skissert som Altinn Events, men det kunne i teorien ha vært et hvilket som helst annet hendelseshåndteringssystem.
- Oslo kommune (Næringsetaten) er abonnent av denne type hendelse og mottar derfor et varsel om at det har blitt foretatt en ny registrering i Enhetsregisteret. Varslet inneholder også organisasjonsnummeret til det nye foretaket, slik at Oslo kommune (Næringsetaten) ikke behøver å gjøre noe dataoppslag i etterkant.
- Hendelsen sparker i gang en intern arbeidsflyt hos Oslo kommune (Næringsetaten), som initierer en dialog med det nyregistrerte foretaket gjennom Dialogporten. Dialogporten er et felles sted hvor offentlige tjenestetilbydere kan tilgjengeliggjøre digitale dialoger i en felles arbeidsflate og andre sluttbrukerløsninger. Hensikten med denne arbeidsprosessen er å invitere innehaveren av det nye foretaket til å starte søknadsprosess om skjenkebevilling og/eller serveringsbevilling. Det er viktig å bemerke seg her at det er Oslo kommune (Næringsetaten) som eksplisitt må opprette en varslingsjobb gjennom API-er som varslingskomponenten i Altinn tilbyr, hvor de oppgir det samme organisasjonsnummeret som adressat og kan referere dialogen. Varslingskomponenten vil da slå opp alle kontaktpunktene (mobilnumre/epost adresser) for de personene som er autoriserte til å motta varsler for denne dialogen på vegne av organisasjonsnummeret, og sende ut disse.
- Selv om Dialogporten produserer en tilgangskontrollert hendelse for opprettet dialog, så vil det i seg selv ikke avstedkomme noen varsler fra Altinn Events som ville manifestere seg i Altinn brukerportal. Det vil dog være mulig for et autorisert sluttbrukersystem, som gjerne kan være den digitale flaten sluttbrukeren har foretatt etableringen av foretaket sitt gjennom, å motta denne varselmeldingen fra Altinn Events, og omsette denne til noe som traff innehaveren.
- Dialogporten vil sørge for at det blir etablert en dialog mellom Oslo kommune (Næringsetaten) og innehaveren av det nye foretaket.
Funn og læringspunkter
Vi har gjennom dette forretningsscenariet gjort oss noen betraktninger, som vi ønsker å dele med andre som vurderer å ta i bruk hendelsesdrevet arkitektur i sitt miljø:
- Eksperimentløpet til Born Digital tok utgangspunkt i forretningsscenariet om å starte restaurant i Oslo og brukte metoden «Kart for tjenestekjeder» til å identifisere hvilke hendelser som koblet sammen henholdsvis Brønnøysundregistrene, Skatteetaten, Oslo kommune (Næringsetaten) og eventuelt øvrige aktører på et overordnet nivå. Det ble anbefalt å starte med den minst komplekse varianten av den utvalgte brukerreisen for å avdekke minimumskravene for å skape en god sømløs digital brukeropplevelse. Formålet var å identifisere de såkalte nøkkelhendelsene som kobler sammen relevante aktører på et overordnet nivå. Når disse kom på plass, kunne man se nærmere på henholdsvis hvilke dataendringer som hadde utløst disse hendelsene og hvilke forretningsprosesser som ble trigget av disse hendelsene.
- Siden det foreligger en løs kobling mellom de som produserer hendelser og de som konsumerer hendelser, så kan de tjenestene, som blir eksekvert i kjølvannet av disse hendelsene skje i parallell, uavhengig av hverandre i regi av ulike virksomheter. Det er dette som er skjønnheten i konseptet om koreografi av tjenester, hvor det ikke foreligger en sentral prosess som styrer interaksjonene med tjenestene som inngår i tjenestekjeden. Når hendelsen «Vedtak om registrering i Enhetsregisteret» inntraff, så ville dette trigge både MVA registreringsprosessen hos Skatteetaten og søknadsprosessen om skjenkebevilling hos Oslo kommune. Disse to prosessene kunne skje i parallell, helt uavhengig av hverandre.
- Det er som regel konsumenten av en hendelse som vet best hvordan denne bør ageres på internt hos seg, gitt at det handler om noe som bare denne konsumenten enten er pålagt til- eller er best på å håndtere alene. En hendelse utløser behov for en tjeneste, og denne tjenesten er ofte mer sammensatt enn man tror og er som oftest eid av en bestemt aktør i offentlig forvaltning. Denne tjenesten fremstår ofte som en forretningsprosess hos denne aktøren. Utfallet av denne prosessen vil skape en hendelse som i de fleste tilfeller bør deles med andre aktører. Når hendelsen «Vedtak om registrering i Enhetsregisteret» inntraff, så ville dette trigge MVA registreringsprosessen hos Skatteetaten. Siden dette dreide seg om et fagområde som Skatteetaten hadde best kompetanse på og hadde ansvaret for, var det Skatteetaten alene som bestemte hva som burde gjøres videre for å hjelpe eieren av det nye foretaket med å søke om MVA registrering. Utfallet av denne søknadsprosessen derimot ville resultere i en hendelse som burde deles med andre relevante aktører i forvaltningen.