I dette dokumentet er de fire termene tjenesteportef?lje, tjenestekatalog, tjenesteoversikt og tjenesteregister definert som f?lger:
- En tjenesteportef?lje er et forvaltningsverkt?y for flere tjenester under samme forvaltning. Dette gj?res fordi tjenestene har et avhengighetsforhold til hverandre. Dette avhengighetsforholdet kan medf?re at optimalisering av en tjeneste medf?rer uplanlagt merarbeid hos andre, slik at totalen g?r i minus. Form?let med en tjenesteportef?lje er alts? ? f? forutsigbarhet mht. kostnader, leveringstider og ressursbruk for tjenestene i portef?ljen under ett. Bruksomr?det er internt.
- En tjenestekatalog er den delen av tjenesteportef?ljen som virksomheten viser sine (potensielle) konsumenter. Essensiell informasjon i en tjenestekatalog er tjenestens innhold, kontaktpunkter og regler for bruk. En tjenestekatalog kan sy sammen informasjon fra flere tjenesteportef?ljer, men en tjenesteportef?lje kan ogs? ha flere tjenestekataloger. Dette avhenger av hvordan virksomheten opplever det mest hensiktsmessig ? formidle informasjon om sine tjenester.
- En tjenesteoversikt er en opplisting av tjenester i en eller flere tjenestekataloger. Tjenestene er beskrevet sv?rt overfladisk og normalt lenker tjenesteoversikten til den mer informasjonsrike tjenestekatalogen.
- Et tjenesteregister er en samling av dokumenterte integrasjonsgrensesnitt. Tjenesteregisteret er en del av tjenestekatalogen. Da informasjonen i registeret er detaljert og bare av interesse for utviklere, er denne delen av tjenestekatalogen trukket ut i en egen tjeneste. Et tjenesteregister kan igjen sy sammen eller segregere informasjon fra en eller flere tjenestekataloger.
Husk at dette er skrevet med fokus p? integrasjonsgrensesnitt (API). Det er p? ingen m?te noen opplisting over generelle felter i en tjenesteportef?lje/-katalog.
Felter til bruk i tjenesteportef?lje
Tjenesteportef?ljen trenger informasjon om API innen tre overordnede kategorier: forankring, forvaltning og validering.Detaljniv? kan variere mht. hva interessentene opplever som hensiktsmessig. Ofte vil hensikt og m?l begrunnes p? et h?yere niv? for tjenesten.
Innen forankring b?r det sies noe om hva hensikten med API er. Dette inkluderer kort- og langsiktige m?l og m?lekriterier. I vurdering av hensikt b?r det ogs? inng? vurderinger som er gjort mht. legalitet/konfidensialitet, intendert m?lgruppe og API-kategori. API-kategori vil si om API er ment for offentligheten eller internt, om det har en betalingsmodell, om det krever en registerering, er underlagt lovgivning eller annet. Om API er for strengt begrenset bruk (produsentens egne utviklere) er det ikke n?dvendig for integrasjonsarkitekturen at det er oppf?rt i tjenesteportef?ljen. Systemeier kan allikevel ?nske oppf?ring mht. dokumentasjon, budsjettering eller m?ling av ressursbruk.
Under forvaltning b?r det v?re:
- Lenker til dokumentasjon rundt tekniske implementasjon. I det tekniske designet b?r det v?re gjort vurdering mht. gjenbruk, hvordan delte data holdes konsistente p? tvers av tjenester, samt i hvilken grad man det vil p?virke konsumentene om man skiller ut funksjonalitet fra kildesystemet eller bytter kildesystem.
- Det b?r v?re beskrevet hvilke delegeringer som er gjort. F.eks. kan utviklere v?re delegert rettighet til selv ? utvikle mer funksjonalitet eller andre grupperinger kan v?re delegert muligheten til ? gi tilganger til systemeierens data. Sistnevnte skjer typisk i situasjoner hvor det er laget uttrekk sammensatt fra forskjellige kildesystemer og som er lagt under sentral forvaltning.
- Det b?r beskrives eventuell juridiske forhold, f.eks. hvorvidt det kreves en databehandleravtale og hvorvidt denne er standardisert og elektronisk
Validering av en tjeneste b?r foreg? p? et tidspunkt planlagt da tjenesten sist ble validert. Vi skal ikke her gi noen fasit p? validering, men kan kort nevne at m?loppn?else, ROS-analyse, compliance med lovverk og interne f?ringer, samt brukerunders?kelser er vanlig tiltak i et valideringsprogram. Integrasjonsarkitekturen tilf?rer et krav om validering av kvaliteten p? egne data. (Som oftest finner man at kvaliteten p? dataene er lavere enn antatt).
Felter til bruk i tjenestekatalog
Husk: All informasjon i tjenestekatalogen skal v?re hentet fra tjenesteportef?ljen. Det skal alts? ikke dukke opp nye informasjonsomr?der; tjenestekatalogen skal tilrettelegge den informasjon som er relevant for konsumenten. Grovt sett kan API-informasjonen i tjenestekatalogen deles i overordnede forretningsmessige forhold og deres praktiske implikasjoner. Overgangen har en tendens til ? v?re gradvis. I tabellen under er dette illustrert:
| Forretningsmessige forhold | Beskrivelse |
|---|---|
| Masterdata | Beskrivelse av hvilke overordnede typer data kan man forvente ? finne og hvordan dataene henger sammen med relevante data i andre tjenester |
| Kategori | Dette feltet b?r besvare sp?rsm?l som: Er API tilgjenglig for alle? Krever det registrering? Er det begrenset ved lovgivning? Er det en betalingstjeneste? |
| Praktiske implikasjoner | |
| Tilgang til API | Informasjon om hvor API er ? finne og hvordan man f?r tilgang. Lenker til standardisert avtaleverk. |
| Informasjon om kontraktsforhold | Dette er b?de overordnet informasjon om hvilke lover og regler som gjelder. Det er ogs? informasjon av annen art, som l?fter om ytelse og oppetid (SLA) eller i hvilken grad produsent forplikter seg til versjonering av sine API. |
| Dokumentasjon | Lenker til tekniske dokumentasjon eller annen informasjon som tjenestens forvaltningssyklus og valideringskriteria. |
Felter til bruk i tjenesteregister
I tjenesteregister m? det v?re lenker til tjenestekatalog/-portef?lje avhengig av APIs kategori eller utviklers rolle. (En tjenesteportef?lje/-katalog er ofte samme programvare hvor tilgangen til informasjon er segregert p? rolle). Det b?r ogs? v?re lenker til utvidet teknisk informasjon. Videre kan det v?re felt for egne kontaktpunkt for utviklere.