I arbeider med ny integrasjonsarkitektur var det viktig for oss ? p?peke at det er mennesker som skal bruke arkitekturen. Det ble gjennomf?rt workshops med systemeiere og utviklere der de viktigste og mest samstemte tilbakemeldingene fra samlingene var at forutsigbarhet, handlingsrom og autonomi var sterkt ?nsket. De ville ogs? ha ett punkt man kunne henvende seg til for ? f? veiledning og hjelp. Menneskets produktivitet motiveres av autonomi, f?lelsen av tilh?righet og at man har rett kompetanse.[1]
[1] Ref: A general theory of human motivation applicable to leadership. Deci and Ryan (1989) Self-Determination Theory (SDT).
Organisatorisk springer arbeidet med integrasjonsarkitektur ut av, og er forankret i, Universitetsstyrets vedtak om “Organisering og standardisering av universitetets IT-virksomhet”:
“Universitetsdirektøren skal i 欧洲杯在线买球_欧洲杯投注网站推荐@ med ledelsen ved fakulteter og institutter utarbeide forslag til arkitektur og integrasjonsrammeverk.”
Horisontal og vertikal koordinering
For ? ivareta helheten i tjenestelandskapet, samtidig med ? tilby systemeiere et handlingsrom, er det laget prinsipper og best-practices. Ved ? f?lge praksis kan for eksempel SV og HF lage hver sine IT-l?sninger uten ? snakke sammen, men l?sningene deres kan fortsatt utveksle informasjon. De er interoperatible. Vi kaller dette horisontal koordinering. Dette i kontrast til vertikal koordinering, som omhandler eskalering og beslutningskjeder. For integrasjonsarkitekturen er det besluttet at eskalering og beslutningskjeden er:
Systemeier -> Prioriteringsr?d -> SKAIT
Det er i skrivende stund noen forbehold:
- Beslutningskjeden gjelder bare administrative IT-systemer. Hvordan det blir for IT i 欧洲杯在线买球_欧洲杯投注网站推荐@ og IT i Utdanning, er enn? ikke avgjort.
- Systemgruppeforum er tildelt ansvaret som prioriteringsr?d.
Prioriteringsr?dets oppgave er ? ta forretningsbeslutninger rundt integrasjon. Det har en proaktiv rolle med tanke p? hva som kommer av oppdrag samt organisasjonens endringskapasitet og gjennomf?ringsevne. Eksempelvis er det i det p?g?ende ERP-anbudet langt flere systemer som er planlagt utskiftet enn vi kan h?ndtere samtidig. Hvordan UiO gj?r IT, ligger enn? til IT-Direkt?r iht. Universitetsdirekt?rens delegering. Systemeier l?fter typisk en sak til prioriteringsr?d hvis det reises uenighet. Hvis saken er utenfor mandat, eller det ikke oppn?s en enighet, kan saken l?ftes til SKAIT.
Integrasjonsarkitekturens hovedprinsipp er kost/nytte. Kost/nytte skal vurderes for hele virksomhetens systemlandskap under ett med et langsiktig perspektiv. Integrasjonsarbeidet ved UiO skal med andre ord gi en helhetlig verdi for virksomheten, der prioriteringsr?dets oppgave er ? og anbefale rekkef?lge og bemidling der det er interesse- eller ressurskonflikter.
Scenario 1: Flere har behov for de samme ressursene. Behov m? prioriteres opp mot hverandre og planlegges for ? f? komplekse integrasjoner p? plass, eller det m? vurderes ? kj?pe ekstern arbeidskraft. Prioriteringsr?det kan anbefale prioritering av ressurs-s?knader til SKAIT.
Scenario 2: System-/dataeiere ?nsker ? integrere, men har ikke mulighet til ? finansiere (hele) integrasjonen over egne budsjetter. Det m? fremskaffes midler og behovet m? vurderes i lys av andre integrasjonsbehov.
Scenario 3: En systemeiere har tilbyr ikke sine data i tr?d med integrasjonsarkitekturen, og uenighet med andre systemeiere medf?rer en eskalering.
N?rhetsmodellen
Det viktigste beslutningen og leveransen som kom ut av “Organisering og standardisering av universitetets IT-virksomhet” var N?rhetsmodellen. N?rhetsmodellen var den sterkeste f?ringen vi hadde da vi skulle tilpasse arkitekturen til organisasjonen.
N?rhetsmodellen sl?r fast at:
"Organiseringen av de administrative tjenester skal følge en desentral modell som innebærer økt ansvar og myndighet på lokalt nivå."
I v?rt arbeid bruker vi ordet "distribuert" i stedet for "desentral". I all hovedsak betyr det det samme, med unntak av at en distribuert l?sning best?r av komponenter som utveksler informasjon. En desentral l?sning har ikke dette kravet. En distribuert l?sning kan illustreres slik:
Internettmodellen – ansvarliggj?ring av systemeier
? ansvarliggj?re systemeier er ogs? en f?ring integrasjonsarkitekturen har arvet fra f?ringer p? h?yere niv?:
"Når det gjelder administrativ IT er det bestemt at denne skal fullfinansieres over systemeiernes budsjetter. Sammen med veikartene vil dette gi langt bedre oversikt over kostnadene knyttet til denne virksomheten og gi tilsvarende bedre grunnlag for styring og prioritering."
(fra Organisering og styring av IT)
Modellen med autonome akt?rer kalles ofte "Internettmodellen", da det er slik internettet er bygget: Alle holder kontroll p? seg selv. Det er ingen kontrollmekanismer (sentralt) i nettverket som godkjenner hvem som snakker med hvem.
De vanlige fordelene med modellen er at:
- den er innovasjonsdrivende
- det er kort vei til beslutningsmyndighet, beslutninger tas lokalt
- ansvaret er tydelig
- eventuelle flaskehalser lager bare forsinkelser for de involverte, ikke for nettverket som s?dan
De vanlige ulempene er at:
- den er uoversiktlig, vanskelig ? finne frem
- det er ingen kontrollmekanismer i nettverket, svak etterrettelighet
- den fordrer redundant kompetanse
- det kan kreve h?y kompetanse ? sette sammen data fra flere kilder
"Internettmodellen" ligger til grunn for UiOs integrasjonsarkitektur. I virkeligheten fungerer internettet p? grunn av ekstrem standardisering, for eksempel rundt internettadresser, protokoller (som http) og spr?k (som html). P? samme m?te har integrasjonsarkitekturen standardisert p? bransjestandard mekanismer og format. Dette gj?r at man ikke lenger er avhengig av spesialister p? USIT for ? integrere. Man kan gj?re det selv, eller kj?pe hjelp fra en valgfri tredjepart.
Internettet byr ogs? p? sentraliserte komponenter, enten de er per design (som DNS/SSL) eller de facto (som s?ketjenesten Google). Dette gir brukervennlighet, oversikt og sikkerhet. Derfor har UiOs integrasjonsarkitektur sentralisert tjenester som tilbyr nettopp dette. Vi har standardisert rundt noen felles komponenter for at informasjonsutveksling skal skje brukervennlig, effektivt og for ? bedre kontroll og etterrettelighet, herunder oppfylle lovgivning og forskrifter.
Telefonsentralmodellen
Det diamentrale arketypen til Internettmodellen kalles gjerne 'Telefonsentralmodellen'. Dette da all trafikk g?r gjennom en sentral f?r den n?r mottager, slik illustrasjonen under viser.
Dette er modellen vi har g?tt bort fra.
Tidligere m?tte man kontakte en gruppe spesialister og data ble fraktet gjennom store komponenter som FS, SAP, OA og Cerebrum. Kompleksiteten i disse sentralene gjorde det vanskelig og dyrt ? hente hjelp fra tredjepart. Gruppene sto ofte selv for ? prioritere oppdrag og diktere l?sninger. Dette var en modell som passet bedre da IT kun var for de innvidde og ikke skjedde overalt i organisasjonen. Modellen har ogs? gode sider. Sentralen tilbyr funksjonalitet som hjelper akt?rene i nettverket. For eksempel kan den, ut fra hvilken informasjon som sendes, vite hvilken akt?r som skal ha pakken, eller den kan sette sammen data fra forskjellige akt?rer f?r den sender den samlede informasjonen til mottager p? det foretrukne formatet.
Modellens kjerneegenskaper er:
- innovasjon skjer i sentralen, innovasjonshemmende p? enkeltakt?rer
- kompleksitet flyttes fra akt?r til sentral, krever mindre redundant spesialkompetanse
- fordrer mer ressurser sentralt i nettverket
- gir kontroll og etterrettelighet
- kan ved ressursmangel fungere som en flaskehals for hele nettverket
- effektive beslutninger fordrer tydelig mandat og delegasjon
N?rhetsmodellen tilsier at denne modellen skal benyttes under gitte omstendigheter:
"Ved stordriftsfordeler, eller der oppgavene krever særlig kompetanse, skal det velges sentraliserte løsninger."
Det burde kanskje v?rt tilf?yd: N?r behovene er statiske og endres sjelden.
Gode kombinasjonsmodeller
Til tross for modellene er diamentralt motsatte, kan de to metodene med hell benyttes i kombinasjon: De er to forskjellige verkt?y, som kniv og gaffel. Teknisk og administrativt kan alts? UiOs integrasjonsarkitektur illustreres slik:
Tegningen viser arkitekturen suppleres med st?ttetjenester. Disse st?ttetjenestene er:
- et felles tjenesteregister, som viser hvilke data som tilbys og hvor de er ? finne
- tjenesten Sikker Datadeling for sikker datautveksling mellom IT-tjenester
- en meldingsk?, hvilket er en tjeneste for umiddelbar datasynkronisering mellom tjenester som st?tter og trenger det. Det vil si tjenester som benytter seg av ? selv ? lagre replikerte data om rom, brukere, grupper eller annet, s?kalt provisjonering
- et felles kontaktpunkt. Dette har prim?rt til hensikt ? m?le resultatene av arkitekturen. Dette for ? kunne l?re og videreutvikle arkitekturen. For ? kunne gj?re denne l?ringen, m? kontaktpunktet vite hvem som har integrert hvordan, og erfaringen de har trukket av dette. Kontaktpunktet kan ogs? ta seg av andre henvendelser, som fra de som ?nsker st?tte til ? integrere eller til ? lage et godt design
- sentraliserte uttrekk og kontrollmekanismer
- eskalering- og beslutningskjeden som g?r fra systemeier, gjennom prioriteringsr?det, til SKAIT