Moderne og gammeldags programvare
Det viktigste først: Når man kjøper ferdig programvare, såkalt hyllevare, må man fall aldri for fristelsen for å kjøpe tjenester for å tilpasse programvaren til organisasjonen. Dette er alltid det dyreste valget. Disse tilpasningene vil medføre store merkostnader ved hver endring. Tilpass i stedet organisasjonens prosesser etter programvaren.
Når du som systemeier anskaffer programvare, så er det gjerne programvare en bruker, et menneske, skal sitte å jobbe i. Med integrasjonsøyne er det da i hovedsak fire forhold som må vurderes:
1. Provisjonering
At programvaren på forhånd får informasjon om sine brukere (eller andre ressurser, som rom). Nesten alle kjøpte webapplikasjoner med brukerinnlogging havner i denne kategorien, sammen med andre, som FS eller adgangskortsystemet. Vi er opptatt av om tjenesten kan oppdateres i sanntid eller ikke. Her snakker vi da om den kan få eller avgi informasjon fra/til andre IT-tjenester kontinuerlig eller periodisk. Periodisk (typisk oppdatering en gang i døgnet) kaller vi for batch. Provisjonering kan også skje manuelt ved at man taster inn navn, adresse eller lignende
Les mer om provisjonering her.
Programvare som bygger en brukerkonto/-profil under første innlogging kalles gjerne "just in time provisjonering" (JIT). For moderne tjenester benyttes gjerne teknologier som billetteknologier som OpenID Connect (OIDC) og SAML. Informasjonen programvaren trenger for bygge brukerprofilen ligger i billetten (adgangstegnet) fra innloggingstjenesten (som FEIDE), eller informasjon i billetten brukes for å finne mer informasjon om identiteten/entiteten i et oppslagsverk, f.eks. en web service. Til dette kan tjenesten f.eks. benytte teknologien Oauth.
Integrasjonsmessig kan JIT synes fordelsaktig, men også her er det fallgruver. For eksempel er det ikke sjelden at JIT-tjenester bare bygger en veldig tynn profil, og at brukeren manuelt må registrere resten av sine data. Det er ofte svært begrenset med informasjon som ligger i en billett. Det er ikke sjelden at flere provisjoneringsmetoder benyttes i samme IT-tjeneste, som at rapportdata synkroniseres batch, mens brukerdata (som adresse eller telefonnummer) oppdateres umiddelbart (når det skiftes i en tjeneste til alle affekterte tjenester). For eldre typer teknologi, det vi gjerne kaller legacy-teknologier, benyttes gjerne katalogtjenester som AD eller LDAP i stedet.
2. Integrasjonsteknologi
Filoverføringer og databasespørringer vil hovedsak alltid regnes som gammeldags ("legacy"), men web service er ikke nok i seg selv. Helt kort kan det sies at UiO foretrekker en retning innen web services som kalles RESTful. Denne retning har sin styrke i å være intuitiv, men kan lete seg frem til data man trenger, og behøver liten eller ingen kunnskap om kommandoord eller argumenter.
Les mer om integrasjonsteknologi
3. Galvanisk skille
Et tredje kriterie man kan rette seg etter for å bedømme hvor moderne en IT-tjeneste/programvare er, er om man gjør en innlogging i operativsystemet, eller i applikasjonen. Det om operativsystemet vet hvem du er eller ikke, kaller vi et galvanisk skille.
4. Trelagsarkitektur
Trelagsarkitektur innbærer at man kan benytte (helst valgfri) funksjonalitet fra en IT-tjeneste i en annen, f.eks. For Ansatte eller Mine Studier.
Oppsummert så gir dette en matrise med noen stikkord som kan si oss noe om hvor moderne en applikasjon er, spesielt med henhold til om den er tenkt for store brukermasser med homogene behov. De fleste applikasjoner har trekk fra både raden 'Moderne' og raden 'Gammeldags'
| Provisjonert | API | Autentisering |
Applikasjons- oppbygning |
|
|---|---|---|---|---|
| Moderne | Sanntidsoppdatering | RESTful WS og meldingskø | SAML / OIDC / Oauth | Løst koblet trelagsarkitektur (med hendelser) |
| Gammeldags | Batch (eller manuell) | SOAP, filoverføring, systembruker, SQL, RSS, "REST-rpc" | Benytter katalogtjenester som AD og LDAP til autentisering og/eller autorisasjon | To lagsarkitektur, eller programvare med tette koblinger |
Web Service for Dummies
Web Services (WS) er en type API (integrasjonsgrensesnitt). Det er noe programvare benytter for å sende informasjon mellom seg (og ikke direkte mellom bruker og programvare). Vi som driver med integrasjonsarkitektur liker altså WS. WS er de facto standard for utveksling av informasjon på internett i dag, og tilbyr det nyeste innen sikkerhet og funksjonalitet.
Som nevnt er web service en sekkebetegnelse. Så når man vurderer programvare er det ikke nok at leverandøren forsikrer at programvaren har web services. Det kan ennå være mange hindringer i veien: Lisenser, dokumentasjon, spesialkompetanse, proprietære formater osv. Vi ser stadig WS-er utformet i politisk øyemed. Selgeren reklamerer med WS, men den viser seg å bare være pynt for å sikre et salg.
Sanntidsoppdatering
Hvis du ikke allerede har sett dette demonstrert, og du er UiO ansatt, anbefaler vi deg å prøve det selv.
Demonstrasjon av sanntidsoppdatering
Gå inn på brukerinfo.uio.no. Velg fanen Person. Se hva som står i 'Kontaktinfo PRIVATEMOBILE registrert i SAP'. Gå inn i hr-portalen.uio.no. Trykk på snarveien til Personlig profil. Bytt Mobilnummer, privat til et gyldig nummer (f.eks. 99999999). Skift fane i nettleser tilbake til brukerinfo.uio.no og trykk refresh. Se at mobilnummeret har endret seg. Bytt tilbake i hr-portalen og sett tilbake ditt egentlige nummer. Bytt tilbake til brukerinfo og se at nummeret har endret seg igjen. Dette er sanntidsoppdatering.Det finnes flere sanntidsteknologier, men den UiO har valgt å gå for heter Meldingskø (MQ). Illustrasjonen under viser informasjonsflyten. Teknisk implementasjon krever langt flere komponenter.
Med meldingskø kan mange konsumenter få den samme meldingen. Alle som har en meldingskø kan få oppdatert sine data umiddelbart, når data endres i datakilden. Meldingskøen holder (for hver kø) på meldingen til køens konsument har hentet meldingen. Verdien til meldingskøer er altså lett å se: Alle IT-tjenester (som benytter tjenesten) vil ha konsistente data umiddelbart.
Les mer om sanntidsoppdatering
Masterdata, delte data og verdikjeder
Et spørsmål som reiser seg når man forteller om meldingskø er om ikke da man kan skifte sine data i et hvilket som helst system, og så skal dette reflekteres i alle. Svaret på dette er at denne kompleksiteten klarer vi ikke håndtere. Derimot kan man gjøre det fra et hvilket som helst presentasjonslag (som mobil-app eller nettleser) så lenge de benytter samme datalager i bakkant. For å klare håndtere kompleksiteten må en IT-tjeneste være autoritativ. Det er en bestemmelse som gjøres utenfor IT. Man bestemmer at dersom data ikke er like i to datakilder, er det den ene kilden som gjelder (uavhengig av hvor data var endret sist).
Hvilke datakilder som er autoritative for hvilke data kan variere, men det må være bestemt på forhånd. De data en IT-tjeneste er autoritative for, kalles masterdata. Man skal helst hente data fra autoritativ kilde, men dersom dette ikke er hensiktsmessig, skal dataene ikke endres på veien. Typiske eksempler er programvare som henter data fra katalogtjenester som AD og LDAP, eller at FS eller SAP data hentes fra Cerebrum.
Ved anskaffelser må det være tydelig på forhånd hvilke data tjenesten som anskaffes skal være autoritativ for, og hvilke data som skal hentes fra andre kilder. De fleste IT-tjenester har langt mer masterdata (data tjenesten produserer) enn det andre IT-tjenester har behov for. Ofte benyttes derfor termen masterdata om de data tjenesten er autoritativ for og deler med andre tjenester. Men hva man deler fra dag én, og hva som skal deles i fremtiden, er ikke alltid så lett å forutsi.
Les mer om masterdata og verdikjeder
RETROFIT
Hva om min foretrukne skytjeneste eller programvare ikke har MQ og RESTful services? Hva om den snakker SOAP og RSS? Benytter systembruker? I en del tilfelle kan vi hjelpe deg med dette, ved å lage en mikrotjeneste som oversetter. Vi gjør iblant grep for å få gammel teknologi til å fungere med ny teknologi. Et slikt grep kalles en retrofit.