Lånekassen har brukt Collibra siden 2017 som metadatakatalog. I tillegg har vi deltatt i utprøving av Azure Purview som datakatalog siden 2019. Den er fremdeles i public preview.

Det er noe ulike perspektiver på disse tjenestene.

Collibra har en fordel av å ha en godt fungerende meta-meta-modell i bunn. Det gjør at vi kan lage en godt tilpasset logisk representasjon av den kunnskapen vi forvalter i Lånekassen og hvordan relasjoner mellom ulike informasjonsverdier har. Den har også rik og fleksibel støtte for å gjennomføre prosesser i organisasjonen, men vi har så langt ikke benyttet det i stor grad.

Fordelen med en godt integrert datakatalog er at den til enhver tid har kontroll på fysisk data. Dette hjelper inn mot operativ dataforvaltning, flyt og sikkerhet.

Tidligere har vi benyttet oss av løsninger som har vært svært teknisk, men som i hovedsak har tatt utgangspunkt i DBA og informasjonsarkitektens behov. Slike løsninger har det ikke vært grunnlag for å gjøre tilgjengelig for virksomheten som helhet.

En tilnærming til en slik anskaffelse bør være med utgangspunkt i hva en COTS-løsning kan tilby, og hvor skillet mellom standardfunksjonalitet og egne særbehov går. En fullskala katalogløsning for informasjonsforvaltning bør muligens ikke være ambisjonen.

Det vil sannsynligvis være behov for å tilpasse organisasjon til ny arbeidsform, og også vurdere mengde utvikling for å integrere og kostnader tilknyttet teknisk forvaltning.

Standarder er krevende.. Det å få et internasjonalt produkt til å tilpasse seg en norsk applikasjonsprofil er lite realistisk. Men så lenge produktet har et API vil du kunne utvikle alene eller sammen med andre muligheter for å kjøre import/eksport til ønsket format.

Tilkobling til fysiske datakilder er krevende. Derav også aktive metadata. Det stiller krav til sikkerhet, men også at datastrukturer er utviklet på en standard måte. Det kan her være at det første krave om gode import-api er tilstrekkelig, og at en her også må kunne se på mulighet for å utvikle et uttrekk fra et lokalt format til en standardisert form.

Det å få tilgang til fysisk data er krevende. Vi ser at vi i Lånekassen må integrere med minst 2 andre løsninger for å realisere dette, og vi har så langt ikke prioritert dette behovet. Må denne prosessen være automatisert, eller er det tilstrekkelig at den er forutsigbar og at det med utgangspunkt i å oppdage hva som finnes kan settes i gang manuelle prosesser for å få tilgang?. Kan man beskrive den manuelle prosessen godt er det et bra utgangspunkt for å automatisere, men det det er en kostnad med dette som bør vurderes.

Språkstøtte på feltnivå er krevende for denne typen løsninger, og det kan være at kravet kan nyanseres til at en skal kunne legge inn flere beskrivelser.

Ser vi på brukergrensesnitt utover UU-krav så kommer vi igjen tilbake til det med API. Det å trekke ut informasjon fra en katalog og tilby denne andre steder krever spesialutvikling, og da er egentlig bare et godt API det som er nødvendig.

Poenget mitt her er at jeg tror ikke at vi kan kjøpe den perfekte løsningen, men at det er mulig å designe den med å se på kombinasjonen av ferdigprodukter og hvordan disse er designet med tanke på maskinlesbarhet og fleksibilitet i uttrykksrom

Ser at epost om at bruker blir slettet etter inaktivitet i 12 mnd ikke har noen CTA.

Det kan være verdt å se på en forbedring med lenke til Datalandsbyen for pålogging.