Page Properties | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
\uD83D\uDCD8 Bakgrund
Vi behöver besluta om hur vi exponerar APIer för Datalagret.
...
Alternativ 1 | Alternativ 2a | Alternativ 2b | |
---|---|---|---|
Pros and cons | Korrekt funktionsallokering Inga beroenden mellan olika team Frågan om utökat driftansvar för BODIL-maskinen måste redan ut Resursbrist i hos Datalagret (är väl bara Joel som är aktuell för utvecklingen just nu) | Resursfrågan mindre akut Funktionsallokering/ Dubbel utveckling för varje ny datamängd (skapa vy i Datalagret samt logik i mikrotjänst) | Resursfrågan minst akut Funktionsallokering/ |
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.