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 欧洲杯在线买球_欧洲杯投注网站推荐@.
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.