Hvordan begrepene innen IT kan være problematiske – hva er egentlig en tjeneste?

Som IT-konsulent har jeg jobbet med «tjenesteutvikling» og studiene mine var proppfulle av forskjellige bruk av ordet «tjeneste» eller engelsk «service». Senere meldte jeg meg en kort tid på en masterutdanning et annet sted enn der hvor jeg endte opp med å ta mastergrad og jeg havnet i en konflikt med noen medstudenter rundt hva en «tjeneste» var. Jeg har også sett på med interesse fordi en jeg møtte og kjente litt for lenge siden har vært involvert i noe som heter «tjenestedesign».

Men «tjenestedesign» og «tjenesteutvikling» er to helt forskjellige ting. Tjenestedesign ser på tjenester som noe en bruker av et slag interagerer mot. «Tjenesteutvikling» er egentlig semantiske tekniske tjenester. Om du bruker en app på mobilen for å sjekke været kan det være man som bruker tenker på dette som en værtjeneste. Men en tjenesteutvikler vil tenke på det som ligger bak – en semantisk tjeneste som mottar kommandoer og returnerer data.

Sjekker du været i en app for vær vil du kanskje klikke på stedet ditt og langtidsvarsel og du vil få opp en visuell representasjon av langtidsvarselet der hvor du ønsker et langtidsvarsel. Men en teknisk tjeneste benyttes gjerne i bakgrunnen. Denne tjenesten kaller man et API eller et Application Programming Interface. Det er gjerne en server som tar i mot et «kall» som du på et eller annet vis sender en forespørsel til som noe som «gi meg langtidsvarselet for Bergen fra i dag» og som returnerer strukturerte data på en eller annen form semantisk.

Det kan være en ide å utvide begrepet «tjenesteutvikler», som også kalles «back end utvikler» om man søker folk (da får man ikke misforståelsen) som «semantisk tjenesteutvikler» og å fortelle at man utvikler en semantisk tjeneste heller enn å si at man utvikler en tjeneste fra et teknisk perspektiv.

Et eksempel på en semantisk tjeneste for vær kan se slik ut om det er HTTP som er grensesnittet og dataformatet er JSON:

HTTP forespørsel kan se sånn ut: GET http://www.perandersen.no/vaer/langtid/bergen

Svaret som kommer fra den kan være litt pseudokodet og med masse rom for diskusjon avhengig av hva som skal vises til sluttbruker:

{

[{day:»monday», temperature: 16, condition: «sunny», wind: «moderate»},

{day:»tuesday», temperature:18, condition:»partly cloudy», wind:»still»]

…(og så videre)

}

Og så kan man tenke seg at en app som man gjerne også kan kalle en tjeneste men da med en brukersentrisk bruk av begrepet brukte dette til å til å hente inn rett bilde om det er en sky eller en sol og vise temperaturen og eventuelle andre ting til en sluttbruker.

Det er en utfordring for tverrfaglighet at begrepene gjerne i hvert fall for meg gjerne var en selvfølge ut fra at jeg hadde en teknisk bakgrunn mens jeg opplevde gjerne at andre parter jeg møtte hadde en sneverhet fra sin side, i hvert fall den gang jeg havnet i konflikt med noen på dette masterstudiet rundt begrepsbruken av ordet «tjeneste». Det er uansett et problem at man har semantiske tjenester som danner grunnlag for sluttbrukertjenester og derfor er det viktig å spesifisere dette. «Service design» kunne man kanskje ha kalt «end user service design» og «service development» kanskje «semantic service development» men vi må bare leve med at språket går i sine egne veier.

Blogglistenhits

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *