|
|
Referansarkitektur |
BTI001 Som innkjøper av fagsystemer trenger jeg et nettverk for å stille API-krav for tilgang til data slik at jeg kan trekke inn kompetanse til å spesifisere disse og få markedsmakt til å få leverandøren til å implementere dem. |
|
|
Referansarkitektur |
BTI007 Som konsument av data fra kommunene ønsker jeg at kommunene tilbyr felles API for den samme informasjonen, uavhengig av hvilket fagsystem/hvilke leverandører de bruker for å forvalte informasjonen, slik at integrasjonen jeg utvikler mot én kommune kan gjenbrukes mot de resterende ca 400 kommunene. |
|
|
Referansarkitektur |
BTI002 Som API-tilbyder som sammenstiller data på vegne av f.eks. kommuner ønsker jeg at de større systemene og registrene skal tilby API-er slik at jeg enkelt kan få tilgang til dataene for å gjennomføre mitt oppdrag. |
|
|
Referansarkitektur |
BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler] |
|
|
Referansarkitektur |
BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene. |
|
|
Referansarkitektur |
BAM05 - Som leverandør av API-management-verktøy ønsker jeg at den felles API-katalogen støtter beste praksis for API-er og de mest utbredte standardene, slik at det blir lett for meg å integrere mitt verktøy med den felles API-katalogen [gjetter jeg på …] |
|
|
Felles rammeverk |
Referansarkitektur |