Integrasjonsarkitektur

Transkript

1 Integrasjonsarkitektur Integrasjonsarkitektur har arbeidsgruppen definert til å være hvordan dataene kommer inn i et system fra et annet system, altså fra maskin til maskin Arbeidet med integrasjonsarkitektur handler om endringsdyktighet Unngå fremtidige kostnader og risiko ved bytte av programvare Raske leveranser av nye tjenester Kontroll over kostnader og konsekvenser Operative løsninger på strategiske føringer

2 Oppdrag Arbeidsgruppens oppgave har i hovedtrekk vært å kartlegge hvordan UiO gjør integrasjon i dag og hvilke alternativer som finnes til dagens løsning Arbeidet med integrasjonsarkitektur er forankret i IHR-tiltaket Arkitektur- og integrasjonsrammeverk

3 Dagens situasjon Dagens integrasjonsarkitektur understøtter ikke korte leveringstider, og den er lite solid når det gjelder standardisering, gjenbruk og endringer. Mangelen på en enhetlig integrasjonsarkitektur gjør integrasjon både dyrt og tidkrevende, det oppstår køer og flaskehalser, og mye kompetanse finnes kun hos enkeltpersoner Fortsetter man på samme måte, uten en overordnet og enhetlig arkitektur, vil man se en kontinuerlig økning i kompleksiteten i systemer, grunnet et stadig økende antall spesialtilpasninger. Dette vil resultere i at integrasjon vil bli stadig mer tidkrevende og kostbart. Dagens mangel på integrasjonsarkitektur er heller ikke i tråd med statlige retningslinjer (DIFIs arkitekturprinsipper) UiO allerede i en situasjon der noe programvare vanskelig kan skiftes ut, da integrasjon rundt programvaren er omfattende og egenartet. Mye av dagens integrasjonsarbeid er sentrert rundt USIT-gruppene UAV/UAIT og SUN/INT. Begge er bemannet med 11 årsverk hver. Totalt bruker UiO årsverk på integrasjonsarbeid.

4 Begynnelsen på en teknisk løsning Bygge teknisk løsning på incentiv løsningen skal være ønsket Represalier finnes ikke Presenterer to modeller: Distribuert Modell og Sentralisert Modell Felles for begge modellene: Access Manager (tilgangsstyring) Service Portfolio (tjenesteportefølje) Webservice Meldingsbasert og hendelsesdreven kommunikasjon Modulerte, gjenbrukbare uttrekk

5 Tilgangsstyring Sentralt system for tilgang Holde rede på alle koblinger Gir styring og etterrettelighet

6 Modulert uttrekk Uavhengig av alternativene vil begge fordre endringer som vil være like for begge. Dette skyldes at i dag er dataens konfidensialitet og autorisasjon ivaretatt av de skreddersydde løsningene. I en ny modell som baserer seg på gjenbruk må standardiserte metoder og teknologier overta og ivareta hvem som kan benytte hvilke data. Begge modellene vil fordre omlegging til eksplisitt autorisasjon, hvilket vil si at autorisasjon sjekkes for hver oppkopling og ikke bare da integrasjonen opprettes. Det er autorisasjonen som avgjør hvilke data som kan nås, med «alle rettigheter» vil man kunne nå alle data. Grå felter illustrerer data konsument ikke kan lese, da den ikke er autorisert

7 Tjenesteportefølje Tjenesteporteføljen sier noe om tjenestenes fortid, nåtid og fremtid, og for øvrig dokumentasjon av tjenestens API og integrasjonspartnere Arbeidsgruppa mener en tjenesteportefølje også bør benyttes operativt, eksempelvis: Tjenesteporteføljen kan tenkes som et operativt verktøy for et styringsrammeverk. I dette styringsrammeverket kan administrativ-it inngå. Dette styringsrammeverket vil, om det eksisterer, ikke behandle systemer som «øyer», men kartlegge, beslutte og prioritere i saker som går på tvers av systemer og tjenester. Et annet potensielt bruksområde for tjenesteporteføljen kan være i underkant av det Administrativ-IT definerer; porteføljen kan konkretisere drift-/utviklingsoppgaver, timeverkskvoter, tjenesteavtale(r) og forvaltningsoppgaver, som igjen bør reflekteres i budsjetter, bemanningsplaner og annen ressursplanlegging. Tjenesteporteføljen kan være sentral i arbeid med applikasjonsarkitektur, som lenker hvilken programvare som er i bruk av hvilke prosesser

8 Hendelsesdrevet oppdatering Eksempelet viser (forenklet) hvordan systemene abonnerer på meldinger og responderer mht. behov. Eksempelet viser hvordan systemene UA, SAP og AD abonnerer på hendelser fra Cerebrum. UA responderer på meldingen med å spørre SAP om brukers personnummer. AD responderer med å spørre Cerebrum om brukerens gruppemedlemskap

9 Webservice (kobling) Felles kommunikasjonsplattform for alle Berike API-er kontra egne uttrekk Industristandard Kan skjule siloer

10 Distribuert modell All kommunikasjon en-til-en Konsument ansvarlig for å finne og hente relevante data Lav inngangsterskel Klart definert eierskap til data

11 Sentralisert modell Ett holdepunkt for integrasjon Forretningsregler og unioner sentralt styrt Mindre behov for forståelse av forretningsregler Bedre kontroll av data, flyt og tilganger

12 Modellene sammenlignet med dagens situasjon: Distribuert modell Sentralisert modell Inngangsterskel Lav Høy Dagens situasjon Grad av standardisering Lav Høy Ingen Sentralt ressursbehov Lav Høy Høy Effektiv utnyttelse av ressurser Best Bra Lav Fremtidig leveransetid for ny integrasjon (TTM) Bra Bra Dårlig Behov for koordinering på tvers av organisasjonen Høy Lav Lav Risiko knyttet til innføring av arkitekturen Lav Høy Kompetanse Distribuert Sentralisert Sentralisert Kompetanseredundanse Lav Høy Lav Kvalitetssikring Ujevn Høy Ingen, eller unntaksvis

13 Disclaimer Ny integrasjonsarkitektur blir ikke altomfattende man må hele veien vurdere hensiktsmessighet, primært de store systemene som har mange integrasjoner Det er ikke og blir ikke noen «one size fits all». Det er ikke bra nok støtte i konsumentene til at det er mulig. Man må snarere tenke på ny integrasjonsarkitektur som en verktøykasse med «Best pratice» og «Good practice», antatt også noe «Next practice» (men vi skal forfekte en sunn konservatisme) Integrasjons- og arkitekturarbeid slutter ikke det har ingen sluttdato. Integrasjons- og arkitekturarbeid er kontinuerlige prosesser. Formålet er å løse problemer, ikke lage strikte regler for integrasjon for sin egen del; standardisering, etterrettelighet og fleksibilitet er verktøy for måloppnåelse, ikke mål i seg selv.

14 Teknisk fremdrift For begge modeller virker en gradvis innføring mest hensiktsmessig. Arbeidsgruppen foreslår at det i første fase utvikles et åpent API for Cerebrum. Deretter foreslås det å ta i bruk et eksisterende (eller lage et eget) API for SAP. I tillegg bør de nye integrasjonstjenestene til sektortjenesten Felles Studentsystem (FS) tas i bruk der UiO allerede har integrert mot denne tjenesten. For å få FS' tjenester modne nok til at de kan tas i bruk, bør flere FS-partnere gå sammen om å lage en kravspesifikasjon. Ved å starte med tjenester som står sentralt i dagens integrasjon, vil man forholdsvis raskt kunne se resultater av den nye integrasjonsarkitekturen. Hvilke systemer som skal prioriteres videre, avhenger av hvilke oppgaver UiOs systemeiere ønsker løst. Disse oppgavene må defineres og prioriteres.

15 Veien videre? Workshop Forankring, kartlegging og innspill Valg av modell Mene noe om viktighet og investeringsvilje Workshop legger grunnlag for rapport som overleveres IT-direktør IT-direktør kommer med anbefaling til Universitetsdirektør

16 Vite mer? Arbeidsgruppas websider: Arbeidsgruppas kontaktadresse: