Versions Compared

Old Version 7

changes.mady.by.user Per Persson

Saved on

compared with

New Version 8

changes.mady.by.user Per Persson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Page Properties

Status

Status
colourYellowGreen
titleIn progressdecided

Impact

Status
colourYellow
titleMedium

Driver

Jakob Melander

Approver

Per Persson

Contributors

Adam Hedesand Stålhult (Unlicensed) Ronny Lundberg (Unlicensed)

Informed

Due date

Resources

...

Alternativ 1

Alternativ 2a

Alternativ 2b

Pros and cons

(plus) Korrekt funktionsallokering

(plus) Inga beroenden mellan olika team

(minus) Frågan om utökat driftansvar för BODIL-maskinen måste redan ut

(minus) Resursbrist i hos Datalagret (är väl bara Joel som är aktuell för utvecklingen just nu)

(plus) Resursfrågan mindre akut

(minus) Funktionsallokering/
ansvarsfördelning alls inte optimal

(minus) Dubbel utveckling för varje ny datamängd (skapa vy i Datalagret samt logik i mikrotjänst)

(plus) Resursfrågan minst akut

(minus) Funktionsallokering/
ansvarsfördelning alls inte optimal

Utvärdering

Data samt dess API hanteras inom samma objektförvaltning, vilket talar för detta alternativ

Detta alternativ går bort som standard-alternativ - att Att alltid behöva utveckla på två ställen när en ny datamängd skall exponeras är det sämsta dyraste alternativet. Ansvarsdelningen är inte optimal

Kompetens- och resursmässigt är detta den bästa lösningen - dock är ansvarsdelningen inte optimal och vi riskerar “blame-games”

✅ Action items

  •  

\uD83C\uDF1F Outcome

Alternativ 2a

Motivering:

  • Saknas kompetens inom Datalagret för API-utveckling i dag, och det är i dagsläget inte ekonomiskt rimligt att ta in nya resurser bara för detta

  • Alternativ 2b går bort ur säkerhetssynpunkt

Att diskutera vidare:

  • Livscykelhantering samt incidenthantering för dessa APIer måste redas ut då det blir ett delat ägande av funktionen som helhet.