Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Current »

Status

IN PROGRESS

Impact

HIGH

Driver

Edwin Molina (Unlicensed)

Approver

Per Persson 

Contributors

Jari Koponen (Unlicensed) Jenny Stenman (Unlicensed) Mikael Nordlander (Unlicensed)

Informed

Due date

Outcome

Bakgrund

OeP kommer att integrera mot APIer som i sin tur skickar vidare felanmälningar och ärenden till verksamhetsspecifika system (ISYcase och ByggR t ex), och på sikt mot vårt generiska processtöd.

Det finns behov av att kunna exponera aktuell status på ett sådant ärende via OeP, och vi behöver besluta om hur detta skall implementeras.

Värt att ta i beaktande är att OeP hittills är den enda identifierade klient som inte kan hämta status vid behov från respektive API utan större ingrepp i lösningen (då beroendet till de 150-isch kommuner som använder OeP idag stökar till det) - vi tittar alltså på en lösning specifikt för OeP med låg sannolikhet för återanvändning mot andra klienter (om vi går på något annat alternativ än alternativ 1 nedan).

Alternativ

Alternativ 1 - “on-demand” 1

OeP läser status från respektive API när status efterfrågas av en intressent (“on demand”) - status för dessa ärenden dubbellagras nödvändigtvis inte i OeP.

Alternativ 2 - “on-demand” 2

Vi etablerar ett standardiserat status-API för all typ av status, som i sin tur hämtar statusar från respektive API. OeP läser status från detta standardiserade APIet när status efterfrågas av en intressent (“on demand”) - status för dessa ärenden dubbellagras nödvändigtvis inte i OeP.

Alternativ 3 - pollning 1

Vi etablerar en robot som pollar efter statusförändringar och uppdaterar OeP. Status dubbellagras i OeP.

Alternativ 4 - pollning 2

Vi etablerar något annat, som likt roboten i alternativ 3, pollar efter status och uppdaterar OeP. Status dubbellagras i OeP.

Alternativ 5 - eventdriven arkitektur

Vi etablerar en generisk lösning för publicering av statusuppdateringar där OeP får konsumera en kö. Status dubbellagras i OeP.

Sammanfattning

Alternativ 1: “On demand” 1

Alternativ 2: “On demand” 2

Alternativ 3: pollning 1

Alternativ 4: pollning 2

Alternativ 5: eventdriven arkitektur

Pros/cons

(plus) I linje med API-strategin - framtidssäkert

(plus) Ingen ytterligare utveckling i API-teamet

(plus) Rättssäkert - vi vet alltid att korrekt status visas då den hämtas från källan

(minus) Initialt integrationsarbete i OeP mot två APIer

(minus) Om ytterligare API som håller status tillkommer krävs ytterligare en integration (låg sannolikhet dock)

(minus) Om ett källsystem ligger nere kan inte status visas (vilket dock är mest rättssäkert)

(plus) I linje med API-strategin - framtidssäkert

(plus) Relativ liten utveckling i API-teamet

(plus) Rättssäkert - vi vet alltid att korrekt status visas då den hämtas från källan

(minus) Utveckling i OeP (dock ett engångsjobb och över tid klart mindre än i alternativ 1)

(minus) Om ett källsystem ligger nere kan inte status visas (vilket dock är mest rättssäkert)

(plus) Ingen påverkan på OeP

(plus) Ingen ytterligare utveckling i API-teamet

(plus) Status kan alltid visas (dock vet man inte om det är korrekt status - inte rättssäkert)

(minus) Ej i linje med API-strategin

(minus) Ytterligare en organisation att synkronisera med (RPA-teamet)

(minus) Lösningar baserat på pollning av data leder i regel till komplexa och över tid svårförvaltade lösningar - ej framtidssäkert

(minus) Ej 100% rättssäkert - vi vet inte om det är rätt status som ligger i OeP

(plus) Ingen påverkan på OeP

(plus) Status kan alltid visas (dock vet man inte om det är korrekt status - inte rättssäkert)

(minus) Ej i linje med API-strategin

(minus) Oklart hur detta skall lösas inom API-teamet - det finns flera alternativ att utvärdera och kommer att kräva tid för analys och design

(minus) Lösningar baserat på pollning av data leder i regel till komplexa och över tid svårförvaltade lösningar - ej framtidssäkert

(minus) Ej 100% rättssäkert - vi vet inte om det är rätt status som ligger i OeP

(plus) Ingen ytterligare utveckling i API-teamet

(plus) En eventdriven arkitektur byggd i moderna ramverk skulle kunna fungera som ett komplement till lösningar byggda i linje med vår API-strategi.

(minus) Ytterst oklart om alla våra källsystem kan publicera event

(minus) Utveckling i OeP (event-lyssnare)

(minus) Oklart vem som faktiskt skall implementera och förvalta en sådan lösning (ett nytt “Eventarkitektur-team” kanske?!)

(minus) Integrationssäkerhetsfrågan måste utredas

(minus) Stor initial kostnad att få infrastrukturen på plats - väldigt tveksamt med nyttan i stort

(minus) Ej 100% rättssäkert - vi vet inte om det är rätt status som ligger i OeP

Kostnadsestimat

API-teamet: 0

OeP: SMALL/MEDIUM/LARGE?

API-teamet: SMALL

OeP: SMALL/MEDIUM/LARGE?

API-teamet: 0

OeP: 0

RPA-teamet: SMALL/MEDIUM/LARGE?

API-teamet:MEDIUM/LARGE

OeP: 0

API-teamet: 0

Eventarkitektur-team: LARGE

OeP: SMALL/MEDIUM/LARGE?

Actions

Outcome

  • No labels