Vi vet ikke hvilke tjenester vi trenger i fremtiden, men vi ser at endringstakten ?ker, og IT-tjenester blir stadig mer integrert. Det er derfor viktig ? tenke p? fremtidige kostnader, dvs. at i ROS- og kost/nytte-analyser b?r man legge inn et godt sikringsmonn for at IT-tjenesten skal ha endringsevne. Man skal kunne endre, s?gar skifte ut, programvaren uten at dette utl?ser store kostnader, heller ikke i andre deler av virksomheten.
Tidligere har vi gjort programvarevalg som har gjort bytte av programvare veldig kostbart, f.eks. programvare for arkiv, l?nn, regnskap, integrasjon, og studentsystem. I noen IT-tjenester med mange integrasjoner knyttet til seg, har vi v?rt i en lock in situasjon, som gj?r at i praksis kan ikke programvaren skiftes ut. Kostnadene ved skifte er for store. Illustrasjonen under viser hvordan programvaren BAS leverer data til 8 forskjellige konsumenter (mottagere av data). Hvis man byttet ut programvaren BAS, ville det utl?se endringer (og dermed kostnader) i alle disse konsumentene. Og alle m?tte skifte til samme tid.
For Cerebrum i dag har vi ikke 8 konsumenter, som i tegningen, men 50+. Alle disse f?r (har f?tt) sine egne spesialtilpassende uttrekk (datasett). Ingenting kan gjenbrukes. Hvis det derimot hadde v?rt et API mellom BAS og konsumentene, kunne hver konsument hentet de data det trengte, og selv tilpasset det sitt format, kunne man endret skiftet ut hele BAS uten at dette bet?d endinger for noen av konsumentene.
Det er ikke alltid leverand?rens WS tilbyr de data man ?nsker seg (det har vi fersk erfaring med), og opp mot store skyleverand?rer kan det v?re umulig ? f? dette implementert som en liten kunde. Derfor er det mange vurderinger som m? gj?res mht. API n?r IT-tjenester anskaffes. Den aller viktigste er: Skal man bygge, eller ha muligheten til ? bygge, en egen WS? N? virker dette kanskje som en uoverkommelig stor oppgave, men det finnes mange rammeverk i dag som gj?r dette arbeidet veldig overkommelig. Det avhenger naturligvis om man bare skal tilby data, eller hvor rik funksjonalitet man ?nsker tilby. Man kan kombinere: Lage en selvutviklet WS for dataene mange konsumenter benytter, og benytte leverand?rens for f? konsumenter med spesielle behov. Dette er vist i illustrasjonen under.
Videre: Dersom IT-tjenesten kommer fra leverand?r med et WS API som tilfredsstiller de ?nsker vi har til utforming, kan man vurdere noen andre muligheter:
- Kan man lisens og utviklingsmessig beholde (og endre) leverand?rens API, selv om man bytter ut leverand?rens bakenforliggende programvare?
- Skal man vente med ? bygge en egen WS til man er i en situasjon hvor man skal skifte bakenforliggende programvare, og da bygge den selvlagde slik at det p? den hvite siden ser ut som leverand?rens? Alts? slik at konsumentene ikke merker at man legger skifter API?