1
En analyse av i hvilken grad en ny integrasjonsarkitektur påvirker UiOs
endringsevne
Einar Gordon Jerpseth
Masteroppgave UNIVERSITETET I OSLO
27 januar 2016
2 Sammendrag
Temaet for oppgaven er IT-arkitektur og organisasjonsmessig endringsevne (agilitet), og problemstillingen er å vurdere i hvilken grad ny integrasjonsarkitektur ved Universitetet i Oslo påvirker universitetets endringsevne. For å vurdere dette bygger oppgaven på teori om organisasjonsmessig endringsevne og IT-arkitektur, om governance, samt om kompleksitet.
Dataene er hentet fra intervjuer av forskjellig ekspertise som på hver sin måte kjenner historien og løsningene, samt fra rapporter og observasjoner.
Tilnærmingen er å sammenligne gammel og ny integrasjonsarkitektur. De vurderes hver for seg mot teori og datamaterialet, før de sammenlignes mht. arkitektur, styring og
kompleksitet. Mht. arkitektur måles det i hvilken grad løsningene hver for seg legger til rette for tjenesteorientering, skytjenester, og brukermobilitet. For governance måles det 3
aspekter: 1) I hvilken grad det er definert beslutningstagere og –domener, 2) hvilke koordinerende grep som er gjort for de forskjellige delene av virksomheten skal velge løsninger som ivaretar en helhet i UiOs systemlandskap mht. organisasjonenes
endringsevne, samt 3) i hvilken grad det finnes mekanismer som fanger opp endringer i brukernes behov og effekten av styrings- og arkitekturtiltak. Om kompleksitet benyttes teorien om kompleksitetskrysset som forsøker å forutsi noe om kostnadseffektiviteten i et nettverk/system. Dette gjennom analyse av hvordan systemet er satt sammen av små og store komponenter. Teorien beskriver også grep som kan gjøres for å bedre kostnads- effektiviteten.
Mine funn viser at designet av gammel og ny arkitektur hadde mange likheter på det tidspunkt løsningene ble foreslått, men implementasjon av gammel arkitektur skiller seg sterkt fra hvordan løsningen var planlagt. Det er forsøkt å forklare hvordan denne
utglidningen kan ha skjedd. Mht. styring ser vi at tidene har forandret seg, og at IT i dag er langt mer gjennomgripende i alle deler av organisasjonen. Det innebærer at større deler av organisasjonen må involveres, hvilket medfører et økt behov for koordinering. Mht.
kompleksitet ser vi at ny og gammel løsning skiller seg vesentlig fra hverandre og at det gir potensial for en vesentlig forbedring av kostnadseffektivitet og agilitet.
Konklusjonen er at den foreslåtte integrasjonsarkitekturen i høy grad samsvarer med ny forskning innen IT-arkitektur, styring og kompleksitet. Den gir et godt grunnlag for å bedre organisasjonens endringsevne, fordi den er mer fleksibel, men samtidig mindre kompleks, og det tas i bruk riktigere styringsmekanismer. Forutsetningen for å lykkes er at
implementeringen gjennomføres på en god og konsistent måte. Dette er avhengig av flere faktorer som er utenfor rammen av denne oppgaven, for eksempel ledelse og
organisasjonskultur.
3 Innhold
Sammendrag ... 2
1. Innledning ... 5
1.1 Bakgrunn ... 5
1.2 Problemstilling og avgrensninger ... 6
1.2.1 Begrepene arkitektur og styring, samt begrepet integrasjonsarkitektur ... 9
2. Teoretiske perspektiver ... 11
2.1 Arkitektur ... 11
2.1.1 Agilitet og fleksibilitet ... 12
2.1.2 Hva er tjenesteorientert arkitektur (SOA)? ... 12
2.1.3 Styrker og svakheter ved Bloombergs bok og teori ... 14
2.2 Governance ... 15
2.3 Kompleksitet ... 19
2.4 Teori oppsummert ... 21
3. Metode ... 23
3.1 Om valg av metode ... 23
3.2 Datainnsamling ... 23
3.3 Dataanalyse ... 25
3.4 Vurdering av forskningskvalitet ... 27
4. Funn ... 28
4.1 Bakgrunn ... 28
4.2 Dagens situasjon ... 30
4.2.1 Arkitektur ... 30
4.2.2 Governance ... 32
4.2.3 Kompleksitet ... 34
4.3 Beskrivelse av ny integrasjonsarkitektur ... 34
4.3.1 Arkitektur ... 35
4.3.2 Sammenligning av gammel og ny integrasjonsarkitektur ... 39
4.4 Governance ... 39
4.4.1 Sammenligning av ny og gammel styring ... 42
4.5 Kompleksitet ... 43
4.5.1 Sammenligning av kompleksitet i ny og gammel løsning ... 44
4.6 Kostnadseffektivitet, endringsevne, og sikkerhet ... 44
4.7 Oppsummering av funn ... 46
4
5. Diskusjon ... 48
5.1 Vurdering og funn ... 48
5.1.1 Arkitektur ... 48
5.1.2 Governance ... 56
5.1.3 Kompleksitet ... 61
5.1.4 Sikkerhet, kostnadseffektivitet, og endringsevne ... 64
5.2 Sammendrag av diskusjon ... 68
5.3 Tiltak ... 69
6. Konklusjon ... 71
Referanseliste ... 72
Vedlegg skriftlige rapporter benyttet som datakilder ... 74
En ny integrasjonsarkitektur for UiO ... 75
Arbeidsgruppas rapport tillegg - Konseptuell og praktisk tilnærming ... 82
Arbeidsgruppas rapport tillegg - Tekniske konsekvenser og løsningsforslag ... 90
Forklaring av prinsipper for integrasjonsarkitektur ... 106
Prosjektmandat for UiO integrasjonsarkitektur ... 111
Forprosjekt UiO-integrasjonsarkitektur - Prinsipper for integrasjonsarkitektur – Kortversjon ... 119
Visjonsnotat Cerebrum... 122
Visjonsnotat ESB ... 128
Utdrag fra Brukerundersøkelse LOS 2015 ... 136
Referat fra SKAIT møte 23. november 2015 ... 141
Universitetsdirektørens disponeringsskriv 2015 ... 147
Appendix A: Bloombergs illustrasjon ... 151
Appendix B: Overordnede føringer for integrasjonsarkitekturen ... 152
Appendix C: Intervjuguide ... 155
Appendix D: Intervjureferater ... 157
Appendix E: VETRO-funksjonalitet – karakteristika ved buss-programvare ... 175
Appendix F: Cerebrum integrasjoner ... 176
Appendix G: Governance Arrangements Matrix ... 177
5 1. Innledning
Forfatteren har brukt rundt 60% av sin arbeidstid i de to siste år på arbeidet med å endre integrasjonsarkitekturen ved Universitetet i Oslo(UiO) og har i samme periode deltatt i deltidsprogrammet “Erfaringsbasert master” ved Institutt for informatikk(IFI) ved UiO. Det innebærer at en del av tankegodset i undervisningen er tatt med tilbake til arbeids-
situasjonen. Således forventes et sammenfall mellom “liv og lære”.
1.1 Bakgrunn
Universitetsstyret vedtok 23.oktober.2012 «Standardisering og organisering av
Universitetets IT-virksomhet», som var en del av hovedprosjektet Internt Handlingsrom (IHR). IHR er forankret i UiOs Strategi2020, Mål4: `Universitetet i Oslo skal forvalte sine samlede ressurser offensivt, slik at de bidrar til å understøtte kjerneaktivitetene.’
Strategi2020 fastslår at UiOs kjerneaktiviteter er forskning, utdanning, formidling og innovasjon. Hovedformålet med IHR var: «[..]å skape en effektiv og profesjonell administrasjon som bidrar til å øke det økonomiske handlingsrommet for forskning og utdanning. Målet er å oppnå en gevinst på 10-30% målt i kroner og/eller kvalitet»
(Universitetsstyrets møte 23.oktober 2012, V-SAK 6 Saksnr. 2012/7588). I dette arbeidet er endringsevne sett på essensielt, jfr. følgende utdrag fra Strategi2020:
“For at Strategi 2020 skal ha virkning og skape endring, må den være relevant for den enkelte ansatte og student. Målene UiO nå har satt seg, kan ikke nås uten at
strategien skaper endringer der forskningen og undervisningen skjer til daglig”
“Universitetet i Oslo må øke evnen til å gjennomføre endringer i fagportefølje, undervisningsformer og administrative systemer.”
“Bruken av IKT i læringen skal være fleksibel og fremtidsrettet.”
Et av tiltakene er «Arkitektur og integrasjonsrammeverk», og der er arbeidet med ny integrasjonsarkitektur forankret. Det ble nedsatt en arbeidsgruppe og arbeidsgruppas rapport beskriver nå-situasjonen (anno november 2013):
«Integrasjon ved UiO skjer i dag nesten utelukkende i forbindelse med innføring eller oppgradering av et system. Den blir ikke vedlikeholdt eller forvaltet enhetlig, og den er særegen for hvert produkt. Dette gjør at integrasjon blir stadig mer tidkrevende og kostbart, fordi vi opplever en kontinuerlig økning av spesialtilpasninger. Dagens integrasjonsmetodikk er ikke i tråd med statlige retningslinjer (Se DIFIs arkitekturprinsipper). UiO er allerede i en situasjon der noe programvare vanskelig kan skiftes ut, da integrasjon rundt programvaren er omfattende og egenartet.»
Arbeidsgruppen kartla dagens situasjon og lagde et overordnet forslag til ny integrasjonsarkitektur. Dette arbeidet er nå ført videre i «Forprosjekt UiO
integrasjonsarkitektur», som ble avsluttet 01.oktober 2015. Forprosjektet skal følges opp av
6
et hovedprosjekt. Endelig mandat og oppstartdato for hovedprosjekt er ennå ikke besluttet.
Denne oppgaven tar for seg:
Situasjonen UiO var i og skissert fremtidsbilde. (Ny integrasjonsarkitektur er planlagt.
Den er ikke implementert eller endelig vedtatt)1
Hvilke grep som gjøres og hvorvidt disse vil bedre UiOs endringsevne o Hvilke grep som gjøres teknologisk
o Hvilke grep som gjøres mht. styring av prosesser
1.2 Problemstilling og avgrensninger
Hovedtanke: Når man leser «Stortingsmelding nr. 19 (2008–2009) - Ei forvaltning for
demokrati og fellesskap», «Samordning og styring av IKT-relaterte investeringer i staten», og UiOs «Strategi2020», har de alle til felles at to hovedmål brukerorientering og
kostnadseffektivitet. Brukerorientering er å tilby kontinuerlig attraktive tjenester (altså som endrer seg i takt med brukernes behov) til sine borgere, innbyggere, studenter, ansatte, eller andre. Kostnadseffektivitet skal ivaretas gjennom å velge løsninger som kan endres over tid, samt at løsningene enkelt kan utveksle informasjon.
(En mer utfyllende redegjørelse finnes i Appendix B).
Virkemidlene for å oppnå effektmålene, brukerorientering og kostnadseffektivitet, er arkitektur og styring. ´Styring´ er vanlig brukt på norsk som oversettelse for den engelske termen ´governance´. I dsenne oppgaven brukes termene styring og governance om hverandre med identisk betydning. Disse virkemidlene skal gjøre UiO mer agil. I artikkelen
´Business agility and diffusion of information technology´, av Lars Mathiassen og Jan Pries- Heje i European Journal of Information Systems, (2006 15, s116–119) beskriver forfatterne agile organisasjoner slik: “[..]agile organizations respond quickly, they are resourceful, and they are able to adapt to their environment.” Videre beskrives brukerorientering som evnen til hurtig å kunne reagere på endringer i kunders behov: “Quickness is about the speed with which the organization can respond to customer requests, market dynamics, and emerging technology options. This includes the time to sense relevant events, the time to interpret what is happening and assess the consequences for the organization, the time to explore options and decide on which actions to take, and the time to implement appropriate responses (Haeckel, 1999)”. For å kunne respondere raskt må organisasjonen ha et gitt sett med ressurser: “Resources are about the capabilities that are available within the
organization including people, technology, processes, and knowledge. Resources can be both tangible and intangible and they provide the basis for doing business and for
1 SKAIT ga 23.november 2015 sin anbefaling til Universitetsdirektøren for vedtak av deler av arkitekturen.
Bakgrunnsnotat og SKAITs behandling og anbefaling ligger i oppgavens vedlegg
7
instantiating change (Haeckel, 1999). Adaptability is about how well the organization
responds to changing demands, threats, or opportunities. This requires the ability to learn as well as flexible processes and products that can be reconfigured without extensive
additional costs (Haeckel, 1999; Dove, 2001)”. I denne oppgaven er termen `endringsevne`
brukt for å beskrive i hvilken grad organisasjonen utvikler evner og ressurser til å kunne respondere hurtigere på endringer i brukeres behov og endringer i markedet eller på teknologifronten. Dette uten å utløse betydelige kostnadsøkninger.
I arbeidet med å vise at endringsevne er essensielt for brukerorientering, presenterte jeg illustrasjonen i Figur 1 for USITs ledelse (30.juni 2015) for å få bekreftet oppgavens påstand rundt sammenheng mellom effektmål og virkemidler var i samsvar med ledelsens oppfatning og arbeid.
Figur 1
Figur 1 leses slik at bokser lenger ned i illustrasjonen bygger opp om bokser høyere opp. Dvs.
at for å ha «Fornøyde brukere» må man ha endringsevne, og endringsevne fordrer
tilstrekkelige kosteffektive og sikre tjenester. Sikker(het) gjenspeiler her innbruddsikker, så vel som stabilitet, og etterrettelig. Integrasjonsarkitekturen må understøtte minst en av de strategiske evnene, helst alle tre. Ledelsen sa seg enig i illustrasjonen, men påpekte at dette bare vars et lite subsett av mål og evner USITs ledelse arbeider med. Illustrasjonen i Figur 2 under utdyper hvilke taktiske virkemidler som gjemmer seg innenfor boksen
`integrasjonsarkitektur` i Figur 1.
I undersøkelse av integrasjonsarkitekturen står bruk av virkemidlene arkitektur, governance og kompleksitetshåndtering i sentrum av oppgaven. Boksen ´Kompleksitetshåndtering´ er i Figur 2 plassert litt nærmere strategiske evner, da arkitektur og governance begge er
virkemidler for å håndtere kompleksitet. Og uten kompleksitet ville man hverken hatt behov for arkitektur eller styring; de er begge verktøy for å håndtere samspill mellom entiteter.
8
Samspillet kan foregå mellom mennesker, som individ eller gruppering og organisasjon, mellom programvareløsninger, eller mellom menneske og deres bruk av programvare- løsninger. Om kompleksitetshåndtering er en strategisk evne eller et taktisk virkemiddel kan diskuteres; jeg har valgt å behandle kompleksitetshåndtering som et taktisk virkemiddel som følge av oppgavens litteraturvalg rundt emnet.
Figur 2
Ytterligere avgrensning: I arbeidet med å beskrive dagens situasjon er hovedvekt lagt på det integrasjonsarbeidet USIT er ansvarlig for. Dette er i hovedsak konsentrert rundt systemet Cerebrum. Utenfor USITs domene og virke finnes det andre systemer med mange
integrasjoner knyttet til seg som ligger utenfor oppgavens avgrensning. Dette er systemer som lønns- og personalsystemet SAP, studieadministrative systemer som de nasjonale systemene Christin, Nora, og Felles Studentsystem (FS), og UiOs økonomisystem (Oracle Applications, OA). UiOs nye integrasjonsarkitektur vil derimot også berøre nevnte i varierende grad.
Oppgaven vil benytte teori om arkitektur, styring og kompleksitet. Innen arkitektur benyttes boken «The Agile Architecture Revolution» av Jason Bloomberg, gjennom oppgaven referert til som AAR eller Bloomberg. Bloombergs bok er ikke en vitenskapelig lærebok. Den bygger snarere på hans egne erfaringer. Selv om Bloomberg tidvis presenterer vitenskapelige undersøkelser, synes disse snarere å være valgt for å understøtte påstander fremfor å invitere til deskriptiv diskusjon. Som følge av nevnte svakheter er det tidvis benyttet teori fra
«Applied SOA» ifm. tjenesteorientering og oppgavens teori om governance er hentet boken IT Governance (IT-G) av MIT forskerne Peter Weill og Jeanne Ross (W&R). Noen forklaring og utfyllinger er hentet fra boken «Enterprise Architecture as Strategy» (EEaS), av Jeanne Ross, Peter Weill, og David C. Robertson(RWR). Mht. kompleksitet legges til grunn artikkelen:
TAKTISKE VIRKEMIDLER STRATEGISKE EVNER
Arkitektur Endringsevne
Governance
Kompleksitetshåndtering
9
Schneberger, S. L., and McLean, E. R. (2003). “The Complexity Cross: Implications for Practice,” Communications of the ACM (46:9):216-225. Artikkelen tar for seg forholdet mellom kompleksitet og kostnadseffektivitet, og presenterer grep man kan gjøre for å håndtere kompleksitet med lavest mulig kostnad. Oppgaven tar for seg i hvilken grad teorien kan si noe om kostnadseffektiviteten i ny vs. gammel integrasjonsarkitektur.
1.2.1 Begrepene arkitektur og styring, samt begrepet integrasjonsarkitektur
Som vi vil komme tilbake til, er arkitektur og styring nødvendig for å binde sammen de forskjellige deler av virksomheten under ett. Bloomberg (AAR, s12) definerer arkitektur, ganske i tråd med IEEE2, som «den fundamentale organiseringen av systemer i form av sine respektive komponenter, deres forhold til hverandre og til omgivelsene, og prinsippene som veileder deres utforming og utvikling». RWR (EAaS, s9) definerer virksomhetsarkitektur med ordene: «Virksomhetsarkitektur er logikken som bestemmer organiseringen av forretnings- prosesser og IT-infrastruktur, og reflekterer de krav virksomheten opererer etter mht.
standardisering og integrasjon». Disse definisjonene gir et ganske entydig bilde på hva som i denne kontekst ligger i termen arkitektur. Allikevel ligger det en forskjell i at AAR (og SOA generelt) behandler governance som en del av arkitekturen, mens IT-G og EAaS behandler styring og arkitektur mer adskilte emner. Selv om IT-G og EAaS behandler emnene separat er de tydelige på at de har konsekvenser for hverandre. IT Governance er (fritt etter IT-G, s8)
«et rammeverk som gir incentiv til ønsket utvikling gjennom å spesifisere (og delegere deretter) beslutningsansvar». I denne oppgaven vil vi behandle arkitektur og styring som adskilte aspekter, hvor arkitektur går på teknologiske grep, mens styring går på
organisatorisk koordinering. Det er ikke strengere definert enn det.
I arbeidet med UiOs Integrasjonsarkitektur er den governance som er spesiell for integrasjonsarkitekturen, regnet som en del av integrasjonsarkitekturen. Andre førende regelsett, som Nærhetsmodellen (se Appendix B), Strategi2020 og Sikkerhetshåndboka, ligger til grunn, men er ikke regnet som en del av integrasjonsarkitekturen. Sikkerhets- håndboka er et sett prinsipper og prosedyrer som skal ivaretas for å sikre elektronisk informasjon ved UiO. Sikkerhetshåndboka er eiet og vedtatt av Universitetsdirektøren på vegne av Universitetsstyret. Integrasjonsarkitekturen er altså formet av styringsregler
utledet på høyere nivå. Videre er integrasjonsarkitektur i UiOs arbeid definert som «hvordan systemer skal utveksle informasjon», mens informasjonsutveksling mellom bruker og system er definert som “tjenestearkitektur” og dermed utenfor integrasjonsarkitekturarbeidet. En del informasjonsutveksling mellom systemer innebærer at brukere gjør en handling, gjerne innlogging, som starter informasjonsutvekslingen. Grensen mellom tjenestearkitektur og integrasjonsarkitektur er derfor utydelig. Integrasjonsarkitekturen skiller seg fra SOA. I SOA
2 IEEE er Institute of Electrical and Electronic Engineers. Iht. Wikipedia er: «IEEE er en ledende autoritet på en rekke tekniske områder, som blant annet datateknikk, biomedisin, telekommunikasjon, elektroteknikk og elkraftteknikk og romfarts- og forbrukselektronikk. IEEE er en av de ledende standard-lagende organisasjonene i verden. Data/overførings-teknologi har gjerne en IEEE-kode”
10
er informasjonsutveksling mellom bruker og programvare essensiell. Vi kommer tilbake til dette i teorikapittelet, men følgende er sentralt for problemstillingen: Bloomberg, i sin visjon, lager en illustrasjon (Se Figur 14, Appendix A) som i midten viser målet: Oppnåelse av
«Continous Business Transformation», hvilket altså fordrer endringsevne. Rundt målet finnes virkemidlene: Skytjenester, SOA, og mobilteknologi, altså teknologi som gjør oss i stand til å jobbe hvor som helst fra, uavhengig om det er fra pc, mobiltelefon, nettbrett eller annet. Og Bloomberg tenker virkemidlene i den rekkefølgen, men mht. en organisasjon som UiOs med all sin IT-arv og alle sine brukere, synes ikke Bloombergs illustrasjon å være komplett. Før UiO kan ta i bruk skytjenester for tjenester av signifikant størrelse, må disse kunne integreres med UiO sine data. Det fordrer at man har en integrasjonsarkitektur. Integrasjons-
arkitekturen kan sees på som et grunnleggende subsett av SOA, og SOA-teori kan benyttes for å forklare i hvilken grad UiOs integrasjonsarkitektur bidrar til å bedre virksomhetens endringsevne, f.eks. ved å muliggjøre bruk av skytjenester og mobilteknologi. Og da må først integrasjonsmulighetene foreligge.
Problemstillingen er: En komparativ analyse om hvorvidt grep brukt i om omleggingen fra gammel til ny integrasjonsarkitektur vil sannsynliggjøre en bedring av UiOs endringsevne.
Ny integrasjonsarkitektur er ennå ikke bygget. Derfor er en del av oppgaven å drøfte
sannsynligheten for at den operasjonelt kan gjennomføres (og bedre endringsevnen) i lys av erfaringer med gammel integrasjonsarkitektur.
11 2. Teoretiske perspektiver
I dette kapittelet vil agil arkitektur, styring og kompleksitet bli redegjort for i hvert sitt delkapittel. Til slutt er det skrevet en oppsummering av hovedpunktene.
2.1 Arkitektur
“Fundamentally, flexibility is the key to every organization’s profitability, longevity, and success”, (Jason Bloomberg, The Agile Architecture Revolution, s6)
Bloombergs resonnement er at bruk av IT har gjort virksomheter mer styrt av ytre faktorer (spesielt mht. konsumenter og kommende arbeidstagere), hvilket igjen medfører at
virksomheter må øke sin evne til å endre seg mht. endringer i omgivelsene. Avhengigheten til ytre faktorer gjør virksomheten mer komplekse. Virksomhetens endringsevne er avhengig av i hvilken grad de er kapable til å håndtere kompleksiteten. Dette innebærer at
virksomheter må være bevisste at feil kommer til å skje og at feil er en naturlig del av det å utvikle seg og en effektiv måte å lære på. Tilsvarende må virksomheten er designet til å tåle feil og å lære av feil, samt av hva som har virket.
Innovasjonstakten innen IT gjør igjen at den generelle endringstakten i virksomheten øker.
Bloomberg nevner i første instans tjenesteorientering, skytjenester og teknologi som muliggjør mobilitet som de faktorer som bidrar til endringsevne, kosteffektivitet og å opprettholde et attraktivt tjenestetilbud for kunder, partnere og ansatte. Det er essensielt hos Bloomberg at skytjenester og SOA muliggjør bruk av mobilteknologi. I denne sammen- heng vektlegges at skytjenester er designet for å kunne nås fra hvor som helst i verden på en sikker måte. Dessuten muliggjør SOA at den samme applikasjonen kan benyttes av flere brukergrensesnitt. Slik kan tjenesten være tilgjengelig og brukertilpasset uavhengig om man benytter mobiltelefon, nettbrett, eller PC.
Bak krav om endringsevne og mobilitet ligger 5 underliggende drivere, supertrender (AAR s109-110), som igjen avspeiler krav/ønsker fra menneskene som skal benytte løsningene:
• Lokasjonsuavhengighet (Location Independence): Her mht. tjenesteabstraksjon, som vil si at tjenesten kan endre bakenforliggende kildesystemer uten at dette påvirker
konsumenter av tjenesten
• Global avlukke/arbeidsplass (Global Cubicle): Hvilke som helst to personer i verden kan arbeide sammen, kommunisere og sosialisere som om de var i samme rom. Kommende generasjon arbeidstagere forventer og krever dette.
• Demokratiseringen av IT: Arbeidstagere vil i stor grad selv kunne velge programvare fra skytjenester og app-stores
• Dyp interoperabilitet: Det forventes at alle systemer kan utveksle informasjon på en enkel måte, typisk gjennom at det forventes tilgjengelige, standardiserte integrasjonsgrensesnitt og åpne, standardiserte utvekslingsformater
• Kompleks systemhåndtering (Complex Systems Engineering): Leverandøruavhengighet i hele systemporteføljen og fokus på informasjonsbehandling/-flyt fremfor valg knyttet til IT systemer, (leverandør)plattformer, og infrastruktur
12
Nettopp dette samspillet mellom IT-løsninger og menneskene som benytter IT-systemene skaper kompleksiteten som gjør endringsevne så essensielt. Hvordan IT knytter menneskene og verktøyene de benytter sammen på tvers av alle grenser, utgjør et (eller snarere en rekke) nettverk som påvirker hverandre på måter som er så komplekse at ingen kan forutsi hvilke følger dette får. Dette gjør at man må være beredt på hurtig reaktivt å kunne omstille seg når en endring i behov hos kunde/ansatt/partner oppstår. Dette fordrer en proaktiv strategi for å ha en endringsevne i alle deler av virksomheten, både teknologisk, organisatorisk og kulturelt. Hos Bloomberg er en bevisst holdning til å se på feil som noe naturlig, uunngåelig og nødvendig, en metode for å håndtere kompleksitet. Læring og omstillingsevne som følge av feil, er sentrale elementer i virksomhetens konkurransekraft og overlevelsesevne.
Implisitt i Bloombergs resonnement for å oppnå suksess ligger kompetanse. Det vil si kompetanse i teknologi og organisasjon og samspillet mellom disse, i kommunikasjon og koordinering, samt i planlegging og gjennomføringsevne.
2.1.1 Agilitet og fleksibilitet
Bloomberg (AAR s6) skiller agilitet fra fleksibilitet3. Når man snakker om at virksomheten ønsker å oppnå agilitet, mener man (AAR, s6) «evnen til å kunne respondere hurtig og effektivt på endringer i omgivelsene og kunne utnytte disse endringer til en fordel i
konkurranseøyemed». Bloomberg (AAR, s83) mener fleksibilitet er en egenskap ved agilitet:
«Flexibility is another word frequently used to describe one of the desired benefits of
agility». Agilitet er mer enn fleksibilitet, f.eks. elastisitet. (AAR, s83-86). AS behandler agilitet og fleksibilitet under ett uten å skille begrepene (AS, s16) og utelukkende i strikt SOA
kontekst. Altså fort å kunne tilpasse seg endringer gjennom å kombinere eksisterende (programvare)tjenester til nye tjenester. I denne oppgaven vil jeg innlemme agilitet og fleksibilitet inn i begrepet `endringsevne`.
2.1.2 Hva er tjenesteorientert arkitektur (SOA)?
Strengt teoretisk er SOA en arkitektur som baserer seg på services (AAR, s21/22; AS, s33).
Services er en type programvare som hver utgjør en bit av en digitalisert prosess, slik som tilgangskontroll, en utregning, en kredittsjekk, forespørsel om ledig sete på fly, tog etc. I denne oppgaven er ikke SOA-begrepet brukt som et strikt regelsett for hva som teknisk sett er SOA-kompatibel designet programvare, men som i hvilken grad man benytter SOA- virkemidler for å oppnå tjenesteorientering. SOA er således et kontinuum. Man er i en gradstilstand av SOA, mer eller mindre tjenesteorientert. Man beveger seg på en skala til eller fra en ideell SOA tilstand. Servicene er integrasjonsgrensesnitt som hindrer at
konsumenter interagerer direkte med kildesystemet. Dette innebærer at man ideelt sett kan
3 Bloomberg synes ikke konsekvent i sin ordbruk, jfr. kapittelets innledende sitat, der termen flexibility benyttes, mens agility virker å være mer i tråd med Bloombergs teori
13
endre kildesystem (produsent) uten at dette er merkbart for konsument, altså den som henter eller mottar data, og vice verca. DIFI definerer `tjeneste` som funksjonalitet ved et dataprogram, altså kan et dataprogram eller -system ha mange tjenester, altså ulike
funksjoner. I SOA er det essensielt at man kan endre/flytte noen av tjenestene/funksjonene til en annen programvare, uten å skifte ut hele datasystemet eller også måtte gjøre
(omfattende) endringer i de funksjonene som ikke flyttes/endres. Hvis funksjonene kan flyttes er løsningen preget av løse koblinger. Løse koblinger er et grunnleggende SOA- verktøy for å skape endringsevne. De følgende sitater viser hvordan lærebøkene definerer løse koblinger:
AS (s64): “Koblinger refererer til graden av avhengighet mellom moduler, komponenter, eller tjenestekonsumenter og -produsenter. Løst koblede tjenester ([..]) har få og velkjente
avhengigheter, mens tett koblede tjenester har mange kjente og, viktigere, ukjente
avhengigheter. Et systems koblingsgrad affekterer direkte dets generelle fleksibilitet. Jo mer tett koblet et system er, jo mer vil en endring i en tjeneste fordre endringer i andre
tjenesteprodusenter eller -konsumenter”,
AAR (s32-33): “Vi sier at en tjeneste er løst koblet om endringer i tjenesten ikke knekker eksisterende konsumenter av tjenesten, og videre, at tjenesten kan imøtekomme behov fra forskjellige konsumenter - selv om disse varierer. [..] Løse koblinger [..] betyr mer enn å være i stand til å supportere forskjellige konsumenter med forskjellige behov. Det betyr også at noe er bygget med tanke på å kunne endres (building for change)”.
Både Bloomberg og AS forholder seg til løse koblinger i SOA-forstand (altså i det begrensede aspektet av å levere prosesser og produkter som digitaliserte tjenester). I en større
tjenesteorientert kontekst kan løse koblinger også assosieres med forhold med mennesker og kode/system, mellom to organisatoriske grupperinger osv. I så måte ønsker jeg å utvide nevnte definisjoner og forklaringer for løse koblinger. Begrepet vil brukt slik i denne
oppgaven:
At to entiteter er løst koblet betyr at entitetene samhandler, men man kan endre den ene entiteten uten at dette medfører at man må gjøre endringer i den andre. Det omvendte av løse koblinger er tette (eller harde) koblinger. Tette koblinger fordrer at det gjøres endringer i begge entiteter, ofte må begge byttes om den ene byttes. Løse og tette koblinger er ideelle tilstander. I praksis snakker vi ofte om i hvilken grad entiteter er løst koblet.
Datakonsistens er en form for gjenbruk. Det handler om hvordan virksomheten behandler redundante data slik at disse er like på tvers av systemer og tjenester. AS (s14):
«How many enterprises suffer redundant data or applications? (All of them probably.) What is the result? Users get different results depending on how they are about doing something.
When the users are customers, this results in dissatisfaction and lost customers»
Inkonsistente data påvirker tjenestekvalitet i negativ retning. For å opprettholde konsistente data skal man ha en felles informasjonsmodell for tjenestene som definerer hvilke data
14
tjenestene deler på og hva deres delte betydning er (AS s16 og s19-20). Tjenester og
systemer kan oversette mellom sin egen betydning av dataene og betydningen dataene har som delte data. Delte data er data som systemer har felles og som skal være konsistente på tvers av systemer. Ofte er det godtatt at dataene er forskjellige i en gitt periode som noen timer eller et døgn. Hvis man umiddelbart synkroniserer (delte) data på tvers av systemer med små meldinger kalles integrasjonen «meldingsbasert» eller «hendelsesdrevne oppdateringer». Dette står i kontrast til «batch» som er at man synkroniserer en rekke oppdateringer periodisk, f.eks. i en nattlig jobb.
2.1.3 Styrker og svakheter ved Bloombergs bok og teori
AAR har styrker og svakheter. Den primære styrken ligger i at boken er temmelig ny. Dette medfører at boken har fått med seg nye trender innen teknologi og tjenester, slik som skytjenester, mobiltelefon/nettbrett og annen teknologi. Dette skiller Bloomberg fra
tradisjonell SOA litteratur blant annet ved at boken tar innover seg lærdommer fra en rekke feilslåtte forsøk på å bygge SOA arkitektur. Bloomberg har også større fokus på kompleksitet enn tradisjonell SOA litteratur. Hos Bloomberg behandles SOA som «en arkitektur», ikke
«Arkitekturen». Tradisjonell SOA litteratur fokuserer på å presentere og forklare SOA.
Dermed ignoreres ofte det faktum at man vanligvis alltid har en mengde parallelle
arkitekturer. Dette tar Bloomberg i større grad høyde for. Bloomberg tar også høyde for at endringsdyktighet er avhengig av mer enn styring og arkitektur og at elementer som
bedriftskultur, incentivprogrammer og finansielle muskler også er sterkt medvirkende både mht. endringsevne og derunder kompleksitet.
Bloombergs supertrender og forhold til skytjenester synes å være preget av en amerikansk kultur. AAR ser lite legalitetsutfordringer med bruk av skytjenester i motsetning til f.eks. EU, Russland og Kina. Heller ikke tar behandler boka at skytjenester reiser nye utfordringer, som at hver leverandør ofte har særegne løsninger for utskrift, lagring, søk og metadata. Også punktet om fremtidige ansattes krav til arbeidsgiver er snevert. Slike krav kan bare stilles i en situasjon hvor en besitter en kompetanse som er spesielt etterspurt. Dette kan endre seg mht. resesjon og nedgangstider eller flere sikkerhetslekkasjer som f.eks. Snowden-saken. At ansatte kan stille den type krav til arbeidsgiver synes mer sannsynlig i Europa og USA og mindre sannsynlig i land som India, Bulgaria, Ukraina, Tyrkia, og Malaysia. Disse har til felles at de har mange innbyggere med god IT-utdannelse. Videre vil teknologi som skytjenester, kunstig intelligens og robotikk gjøre mye av dagens spesialistkompetanse overflødig. F.eks.
har mange virksomheter i dag spesialister på infrastruktur og konfigurasjon av operativ systemer og programvare. Tenk på det som forskjellen på å kunne bruke en TV og å kunne bygge en TV. Med skytjenester kan man kjøpe infrastruktur og programvare. Virksomheten behøver ikke lenger vite hvordan man den virker, bare hvordan den brukes. Dette medfører et lavere kompetansebehov som igjen medfører at mange arbeidstagere med
15
spesialistkompetanse innenfor arbeidsområder som kan kjøpes som varer vil miste forhandlingsmakts.
Boka diskuterer ikke farer ved risikosamfunnet og at utvikling mot skytjenester og
skygiganter kan øke risikoen ytterligere. De store skyleverandørene som Amazon, Microsoft og Google, investerer i skytjenester med en stor grad av risiko. Dataanleggene som bygges, er enorme. Microsoft har per oktober 2014 19 regioner, hver region har minst to og opptil 16 datasentre. Hvert datasenter kan romme to Boing 7474. Dette ut fra prinsipp om å kunne drive ned pris gjennom mengde. I teorien om kompleksitetskrysset (som presenteres i delkapittel 2.3) blir det hevdet at systemer hvor det er ekstrem forskjell på størrelsen på komponentene er mindre endringsdyktige, og man kan trekke en parallell til nevnte giga- strukturer. Man kan f.eks. forestille at terrorister eller kriminelle klarer å bryte seg gjennom sikkerhetsforanstaltningene. Gigantenes haller bygges mht. antagelser om fremtidig behov som ikke skyldes pc og mobil, men «tingens internett». Tingens internett baserer seg igjen på at mennesker ønsker seg «smarte ting». Det kan tenkes folk går lei av «smarte ting», resesjon gjør at man ikke har kjøpekraft eller det kommer skandaler, f.eks. at en
skyleverandør går konkurs eller saboteres med det resultat at kundene mister sine data. Det kan altså skje endringer og disse endringer kan rive bort hele grunnlaget for investeringene i giga-strukturene. Til slutt kan nevnes at Bloomberg heller ikke tar høyde for disruptive aktører. Ingen forutså Microsoft, Facebook eller Google.
Historien bølger mellom perioder med sentralisering og desentralisering, f.eks. er vi nå inne i periode hvor produksjon av elektrisitet igjen, i hvert fall delvis, desentraliseres. Innen IT er det ikke helt usannsynlig at en helt ny aktør løser behovene på en måte som igjen gjør det attraktivt med små lokale eller distribuerte løsninger.
2.2 Governance
“IT Governance Simultaneously Empowers and Controls”, (IT Governance, s1)
I boken IT Governance presenteres en studie forfatterne har utført i trehundre virksomheter, fordelt over 20 land og over en periode på 4 år. Gjennomgående for casestudiene presentert i boken er at de som gjør det best, har kommet seg gjennom faser med store endringer.
Altså er god governance essensielt for endringsevne. I W&Rs undersøkelse hadde de som var bedre enn gjennomsnittet 20% bedre verdiavkastning («return on asset, ROA», IT-G, s14) enn aktørene som hadde lav score på målte governanceferdigheter. Metoden for å måle grad av god IT-styringen var ved å sjekke hvor mange ledere som kan beskrive IT-styringen.
Foruten lønnsomhet vektlegger W&R flere andre argumenter for viktigheten av god IT- styring:
4 http://www.digi.no/bedriftsteknologi/2014/10/21/-microsoft-elsker-linux
16
a) Minimere risiko: IT er dyrt. Når man skal investere i IT er det viktig at systemet leverer den forventede verdiskapingen.
b) IT er gjennomgripende. Det finnes nå i alle deler av forretningsvirksomheten og samfunnet ellers. Det er ikke lenger isolert til fagmiljøer. Mange IT utgifter, opp til 20% i W&R tallmaterialet, er ført på andre budsjettposter enn IT og i mange virksomheter er ikke lenger IT som én sentral ressurs verken ønsket eller mulig.
c) IT utvikler seg hurtig. Mange virksomheter er avhengig av å kunne omstille seg raskt, den må være beslutningsdyktig. IT styring kan medvirke til at beslutningsmyndighet og ansvar er delegert slik at dette er mulig.
d) For at organisasjonen skal kunne lære seg verdien av IT er IT styring nødvendig. IT er vanskelig å regne på. Man kan ikke bruke tradisjonelle metoder som diskontert kontantstrøm analyse alene. IT-styring sørger for mekanismer som griper gjennom hele virksomheten og sørger for at all potensiell verdi av et IT-tiltak kan debatteres og læringen formaliseres. Videre skjer mye av en virksomhets læring gjennom unntak og IT-styring kan formalisere unntakshåndteringen.
e) Når IT-prosjekter feiler skyldes det langt oftere at virksomheten ikke klarer å tilpasse seg nye prosesser enn tekniske mangler. IT-styring hjelper IT til å bli en integrert del av forretningsprosessen. Begge parter, både IT og forretningssiden, har samme målbilde og virkelighetsoppfatning.
f) Toppledere har begrenset kapasitet. Toppledere har ofte hverken kompetanse eller kapasitet til å kunne ta de riktige beslutningene om IT-systemer. At «alt» skal gjennom toppledelsen vil være en flaskehals som gjør virksomheten lite smidig.
Virksomheten vil bli sårbar fordi den ikke kan respondere hurtig. Beslutningsansvar bør delegeres og et IT-styringsrammeverk kan sikre at beslutningene er konsistente med de visjoner toppledelsen har laget og dra i den retningen toppledelse har staket ut.
g) Kjenn deg selv! De ledende, de som står for de beste prestasjonene, lager sine egne IT-styringsrammeverk.
(Denne gjenfortellingen av W&R er temmelig fri og lite ordrett. Dette er gjort for å få et bedre norsk språk enn en mer direkte oversettelse ville gitt. I dette ligger en fare for at noe av W&Rs meningsinnhold kan ha blitt endret. Originalteksten finnes på sidene 14-18 i IT-G.
Disse oversettelsene er også gjenreferert senere i oppgaven)
W&Rs arbeid bygger på noen grunnleggende forutsetninger. 1) Virksomheten har en strategi og organisasjon, og det skal være mekanismer som sørger for at IT organisering og
virksomhetsadferd harmoniserer med den overordnede strategien og organisasjonen.
Organisasjonen er gjerne bygget rundt forretningsprosessene, altså det verdiskapende
17
arbeidet (den prosess) virksomheten gjør med noe som kommer inn (input) for å gi kunden en leveranse(output). En leveranse kan være en vare, en tjeneste, en beslutning osv.
2) Virksomheten har forretningsmål, den skal oppnå resultater. Man skal ha mekanismer som gjør at man kan måle virksomhetens ytelse, dvs. i hvilken grad den er god til å oppnå forretningsmål, gjerne iht. konkurrentene. 3) Mellom strategi/organisasjon og
forretningsmål, altså selve prosessene som skaper resultatene, ligger det W&R kaller forvaltning av aktiva/ressurser. IT er et av 6 aktivum hos W&R. Det abstrakte laget i IT- forvaltning kaller W&R IT styringsordninger, mens det praktiske/operasjonelle planet har mekanismer for hvordan styringsstrategien omsettes i praksis, som manuelle og
automatiserte rutiner for mennesker og maskiner. I senter for nevnte rutiner står de beslutninger som IT-styringsordningene har kommet frem til. W&R kaller
prosessene/mekanismene for hvordan et «abstrakt» lag som strategi, organisasjon, aktivum og forretningsmål manifesterer seg i operasjonelle gjøremål, for en «harmonize how». Det vil si hvordan det abstrakte idéplanet harmoniserer med de operasjonelle gjøremålene.
Dette kan vi kalle de loddrette mekanismene, fordi de går fra det abstrakte til det
operasjonelle i en loddrett linje, innenfor sitt virksomhetsnivå. De vannrette mekanismene, de som flytter input gjennom organisasjon og til output, som igjen ligger til grunn for forretningsmål, kaller W&R for «harmonize what». Det vil si hvilke input, hvilke steg en forretningsprosess skal ha, samt hvordan prosessen skal forvaltes og forvaltningen skal resultere i et forretningsmål, og dette skal stå i henhold til hverandre; altså hvordan «hva»
flyter mest effektivt gjennom forretningsprosessen.
W&R kaller det beskrevne rammeverket for «IT Governance Design Framework» og visualiserer det slik det er vist i Figur 3.
Figur 3
18
I det store bildet kommer IT-styring inn der den røde sirkelen er i illustrasjonen, men må altså harmonere med det store bildet, med alt det omkringliggende. (Harmonisere er i denne oppgaven identisk med termen ´alignment´). Dette innebærer f.eks. at prosjekter og
organisatoriske enheter har styringsregler, komiteer, kontaktpunkter, definert vokabular etc.
som bedrar til tydelig kommunikasjon og valg av løsninger som passer inn i system-
landskapet sett under ett. Det vil si at programvareløsningene lar seg integrere og skiftes ut sikkert og kostnadseffektivt. Videre gjør governance at beslutninger tas på riktig sted. En enhet skal ikke ta beslutninger som ligger utenfor deres definerte beslutningsdomene.
Eksempelvis kan dårlig styring medføre at man har to til forveksling like programvare- tjenester, styrt av to grupperinger og med data i hvert sitt datalager. Dette kan medføre forvirring for kunde/klient (f.eks. mht. inkonsistente data), doble utgifter til bemanning, lisenser, og manglende kontroll og etterrettelighet. Alt i alt økte kostnader og lavere verdiavkastning.
Hvis vi så ser nærmere på og forsøker oss på en konkretisering av IT-styring. Hva konkret gjør vi? I følge W&R bør man ta utgangspunkt i de 3 følgende spørsmålene:
1. Hvilke beslutninger må tas?
(For å sikre effektiv ledelse og bruk av IT) 2. Hvem bør ta disse beslutningene?
3. Hvordan skal disse beslutningene tas og hvordan skal de måles/overvåkes?
Til hjelp med utarbeidelse av svarene på disse spørsmålene har W&R kommet opp med en matrise W&R kaller «Governance Arrangements Matrix» (vedlagt Appendix G). Denne matrisen synes mindre relevant mht. arbeidet med integrasjonsarkitektur. Mht. denne oppgaven er det undersøkt i hvilken grad det er definerte beslutningstagere og –domener for integrasjonsarkitekturen samt i hvilken grad integrasjonsarkitekturen er harmonisert mht. forretningsprosesser og forretningsmål. Det er også undersøkt i hvilken grad det er til stede mekanismer for sansing, læring og måling.
Det er andre aspekter ved W&Rs forskning som kunne være interessante å forske videre på.
F.eks. ser man ofte lignende tall på `Top performers` hvor det er målt på andre faktorer, som merkevareforvaltning eller psykososiale arbeidsforhold. Det kan f.eks. tenkes at styring ikke medfører økt ROA av seg selv, men at styring medfører bedre trivsel på arbeidsplassen som igjen medfører økt ROA. Et annet alternativ er at de som har et veldig bevisst forhold til styring, også har et bevisst forhold til merkevareforvaltning. Man kan også trekke dette videre med andre forskningsspørsmål, som eksempelvis: Er det slik at enhver styringsmodell gir bedre ROA, eller er det slik at bare fungerende, gode styringsmodeller overlever i praksis?
Og i så fall, er dette modeller som fremmer trivsel på arbeidsplassen?
For videre forskning kan også forskes på i hvilken grad dreiningen i endringsarbeid fra fossefallsmetodikk til agile metoder vil medføre nye funn mht. suksessfulle virksomheters
19
koordineringsmekanismer. Agile metoder, som Scrum og Kanban, har vokst voldsomt (AAR, s4-5) i utbredelse siden W&R gjorde sine undersøkelser. I IT-organisasjoner er det også blitt mer vanlig med prosessorientert organisasjonsstruktur, som et alternativ de tradisjonelle funksjons- eller markedsbaserte organisasjonsstrukturene (Hvordan organisasjonen
fungerer, s102-104). Det kan være interessant å sammenligne organisasjonsstruktur og om det er sammenheng mellom organisasjonsstruktur og forskjeller for grad av suksess med henhold til organisasjoners valg og anvendelse av styrings- og harmoniseringsmetoder.
2.3 Kompleksitet
«How can computer system designers and managers simplify computer systems?»
I artikkelen «The Complexity Cross: Implications for Practice» definerer forfatterne kompleksitet som avhengig av en rekke faktorer: antall komponenter, komponentenes heterogenitet, antall interaksjoner, interaksjonens heterogenitet, komponentens
avhengighet til hverandre (løse vs. harde koblinger) og systemets endringstakt. Dette er vist i Figur 4.
Figur 4
Altså øker kompleksiteten i en situasjon hvor antall komponenter er likt, men
komponentene er ulike. På den andre siden minker kompleksiteten om komponentene, til tross for at de er ulike, interagerer på samme måte. Et gitt eksempel er internett, der sterk standardisering rundt TCP/IP, HTML og nettlesere, samt ekstremt løse koblinger mellom komponentene, gjør det mulig for nettverket å fungere til tross for ekstrem variasjon i komponentene.
Grunnsteinene er altså at
enkle komponenter i utgangspunktet er enklere (og gir dermed mindre kostnad å endre), enn sammensatte komponenter
for at en komponent skal kunne agere må den ha et grensesnitt (interface) og jo flere komponenter, dess flere interaksjoner, og jo flere interaksjoner, dess mer kostnader knytter det seg til endinger
der hvor det er få store moduler er systemene mer sentralisert og det er mange sentraliserte grensesnitt
20
der hvor det er mange små moduler er systemet distribuert. Modulene er enkle, men kompleksiteten i systemet dras opp av at interaksjonene også er distribuerte
Dette er illustrert i Figur 5.
Figur 5
Så både kostnadene med et helt sentralisert system, så vel som for et helt distribuert system, er høye. Kostnadene ved endring (som følge av kompleksitetshåndtering) er lavest når man klarer å avbalansere antall (ulike) komponenter opp mot antall (ulike) grensesnitt, som vist i Figur 6.
Figur 6
Implisitt betyr dette at en sentralisert løsning har få, store moduler, har høye kostnader med endre modulene, men lite kostnader med integrasjon. Distribuerte løsninger har lite
kostnader knyttet til endring av modul (liten, enkel å endre), men store kostnader knyttet til
21
integrasjon. Avhengig av om man har uhensiktsmessig mye kostnader med henholdsvis integrasjon eller modulendring, er det grep man kan gjøre:
Man kan senke komponentkompleksitetskurven gjennom å bruke verktøy og teknologi for å forenkle modulene, eller gjennom å kombinere flere enkle moduler, slik at de for
integrasjonspartnere opptrer som de var bare en.
Man kan senke systemkompleksitetskurven gjennom å redusere antall heterogene
komponenter og standardisere komponenter og integrasjoner i størst mulig grad. Dessuten ved å redusere komponentens avhengighet av hverandre (benytte løse koblinger) eller senke endringstakten gjennom større og sjeldnere oppdateringer.
Man kan forskyve skjæringspunktet mellom kurvene. Om systemet er sentralisert bør man gjøre grep for å gjøre det mer distribuert. Dersom systemet er veldig distribuert kan man sentralisere noen komponenter som datalager og integrasjonsgrensesnitt.
Mht. teorien om kompleksitetskrysset tar denne oppgaven for seg i hvilken grad ny integrasjonsarkitektur teoretisk sett er mer eller mindre kostnadseffektiv enn gammel integrasjonsarkitektur. Dette gjøres gjennom å analysere besvare spørsmålene: Er systemet sentralisert vs. distribuert? Er komponentene og integrasjonsgrensesnittene standardiserte eller heterogene? Er koblingene løse eller tette? Er antall interaksjoner flere eller færre? Det vil også bli diskutert i hvilken grad skjæringspunktet forskyves i ny vs. gammel løsning.
2.4 Teori oppsummert
Organisasjonen oppnår endringsevne gjennom å bygge og benytte IT-tjenester som er løst koblet til hverandre og som utveksler informasjon gjennom åpne formater og standardiserte integrasjonsgrensesnitt. Skyleverandører klarer gjennom spesialisering å tilby enhetspris på standardiserte varer som det skal mye til å konkurrere med. Og organisasjoner vil tjene på å bygge sine IT-tjenester så de kan benyttes av skytjenester eller på standardiserte enheter skyleverandører tilbyr. Skytjenester, enten egne eller tredjeparts, er enkle å portere til forskjellige plattform som pc, nettbrett og mobil. Dette er viktig mht. brukermobilitet og brukervalg. Mobilteknologi er enkel å distribuere og vedlikeholde gjennom app-stores.
Endringsevne oppnås gjennom å delegere beslutningsmyndighet i organisasjonen. Dette forutsatt at helheten er i varetatt gjennom retningslinjer og koordineringsmekanismer for samhandling vertikalt og horisontalt i linjeorganisasjonen (harmonisering). For å gjøre de riktige endringene kreves også sansingsmekanismer som oppdager endringer i behov i omgivelsene. Dessuten fordres kriterier og mekanismer for måling om endring medførte ønsket resultat og læringsmekanismer for å justere de grep som gjøres for å imøtekomme endringer i omgivelsenes behov.
22
Et nettverk består av forskjellige entiteter som utgjør systemets kompleksitet. Kostnads- effektivitet oppnås gjennom riktig balansering av sentrale og distribuerte entiteter. De sentraliserte komponentene er større enn de distribuerte. Det er denne egenskapen som gjør entitetene sentraliserte, men størrelsesforskjellen bør ikke bli for stor. Jo mer man kan standardisere like komponenter og like integrasjonsgrensesnitt, dess mer synker
kompleksiteten. Kompleksiteten blir også mindre gjennom å redusere antall utvekslinger.
23 3. Metode
3.1 Om valg av metode
I denne oppgaven undersøkes om UiO bedrer sin endringsevne primært gjennom analyse av gitte karakteristika i ny arkitektur sammenlignet med gammel arkitektur. Casestudie og komparativt design er metodikk som vil passe oppgaven. En case er unik og i casestudier ser en på det unike fremfor det generelle. Typisk i slike studier er at de er kvalitative og har få personer/case. Primært tester casestudier en teori gjennom innhenting av data, men studiet kan i noen grad også bidra til også å forklare en case (Ringdal, s151). Ringdal (s149) foreslår en definisjon av casestudie: «[..] casestudier som intensive undersøkelser av et lite antall case(analyseenheter) som kan være individer, familier, bedrifter, organisasjoner, eller land, men også hendelser og beslutninger. Dataene kan være samlet inn på ulike måter: historiske kilder, registerdata, samtaleintervjuer, feltarbeid, eller bruk av spørreundersøkelser». Med henhold til komparativ design sier Ringdal (s150, etter Ragin 1987): «Kjernen i enhver komparativ design er å finne teoretisk interessante egenskaper ved analyseenhetene som kan brukes til å forklare det fenomen, eller det utfall som studeres». I denne case vil primær fokus legges på om det er sannsynlig at de grep som gjøres, bidrar til å løse det konkrete problemet (øke UiOs endringsevne), men det vil også være et bidrag tilbake for å se i hvilken grad funn understøtter teori.
Organisasjonen som studeres er UiO innen et begrenset omfang over noen karakteristika knyttet til teori om endringsevne, målt i aspekter av agil arkitektur, governance, og
kompleksitet. Begrensningen i omfang gjør oppgaven mer gjennomførbar, samt setter fokus på årsak til eventuell endring. Endringen i karakteristika kan måles og fremstilles komparativt mht. situasjon før og etter et endringsarbeid, altså endringsarbeid gjort med ny integrasjons- arkitektur. I arbeidet med å presentere de funn som utgjør en forskjell i ny vs. gammel integrasjonsarkitektur er det benyttet tabeller. Hensikten med disse er å gjøre det enkelt for leseren å se hvor løsningene er like, og hvor de differensierer seg fra hverandre.
3.2 Datainnsamling
Datamaterialet består av dokumenter, intervjuer og observasjoner, altså både primærdata og sekundærdata. Dataene er i hovedsak vedlagt eller og offentlige tilgjengelige dokumenter er referert til med internettadresse. Unntaket er Brukerundersøkelse LOS 2015 som er kuttet ned til den delen som angår USIT. Dette som følge av utfordringer med tekstbehandlings- programmet og formatkonvertering. Intervju er primært mht. datainnsamling for bruk mht.
bruk av Bloombergs og W&Rs teorimateriale, mens biten om kompleksitet er bygd på dokumenter. Dette da problemstillingen krever mer inngående analyse enn det er mulig for et intervjuobjekt å svare grundig på uten først å gjøre et tidkrevende arbeid med å sette seg inn i teori og analysere på grunnlag av denne. Tabell 1 viser hvilke datakilder som er i bruk i hvilke deler av oppgaven.
24
Tabell 1
Oppgavedel Datakilder
Beskrivelse av gammel integrasjonsarkitektur
Intervjuer
Visjonsnotat Cerebrum Arbeidsgruppas rapport Beskrivelse av ny
integrasjonsarkitektur
Intervjuer
Integrasjonsarkitekturprinsippene Visjonsnotat ESB
Arbeidsgruppas rapport
Arbeidsgruppas rapport teknisk dokument
Observasjoner (Intervjumateriale fra arbeid med ny integrasjonsarkitektur)
Dokumenter som gir overordnede føringer for ny integrasjonsarkitektur
Stortingsmeldingene:
«Stortingsmelding nr. 19 (2008–2009) - Ei forvaltning for demokrati og fellesskap»
«Samordning og styring av IKT-relaterte investeringer i staten»
DIFI-prinsippene UiOs strategi2020
Administrativ-IT (Universitetsstyrets behandling og vedtak) Organisering og standardisering av universitetets IT-virksomhet (Universitetsstyrets behandling og vedtak)
Dokumenter benyttet under drøftelse
Kilder benyttet under drøftelse er særskilt presisert underveis
Når det gjelder intervju er det gjennomført intervjuer som skiller seg fra hverandre på forskjellige karakteristika: a) Noen intervju er gjort med interessenter i forbindelse med arbeidet med integrasjonsarkitektur. Det var laget miniguide til disse intervjuene, men det var svært åpne intervjuer som i stor grad fulgte de emner interessenten ønsket å følge opp.
Utsagn fra to av disse er tatt med ettersom det ble funnet relevant og interessant
informasjon, men et eget intervju for hovedfaget syntes unødvendig. Intervjuer i kategori a) ansees og henvises til som observasjoner. Intervjuene er gjort med egen referent til stede, men det er ikke gjort opptak. b) Noen intervjuer er gjort for hovedfaget. De varierer mht.
intervjuobjektets kompetanseområde. Intervjuene er noe strengere i formen. Man sørger mer for å få noen svar relevante for hovedfaget enn for intervjuene for integrasjons-
arkitekturarbeidet. Til disse intervjuene foreligger en mer generell miniguide, men ikke hele miniguiden er lagt til grunn for hver av de intervjuede, det er gjort begrensning mht.
kompetanseområde. Dette er spesifisert i Appendix D for hvert intervju.
I kategori b) er intervjuspørsmål som er merket med tall, spørsmål som er blitt stilt.
Intervjuspørsmål/stikkord merket med bokstav er emner man har forsøkt å følge opp med
25
tilleggsspørsmål om ikke personen har svart på dette av seg selv. Kategori a) har ikke noe slikt system, men ord i firkant parentes viser at personen ble vist en illustrasjon, eller fikk et stikkord til oppfølging.
Ettersom oppgaveforfatter kjenner dokumentene oppgaven bygger på godt, delvis fordi de ligger til grunn for arbeidet med ny arkitektur, delvis som medforfatter, ble det først lett etter funn i dokumenter. Intervjuene er utformet basert på behov for utdypning av
problemstillinger, derunder spørsmål mer direkte knyttet opp mot teoribiten av oppgaven.
Oppgaven er primært bygd på et semi-strukturerert intervju, intervjuguide finnes i Appendix C. Intervjuer i kategori b) har en ganske høy grad av standardisering, men i noen grad
tilpasset intervjuobjektet, både før besøk og underveis. Intervjuene er utført ved besøk, med fysisk ansikt til ansikt intervju. Intervjuprosess for intervjuer i kategori b) er bygget etter Brinkman&Kvale 7 stegs prosess. For kategori a) er det mye felles i de syv stegene, men stegene er mindre systematisk gjennomarbeidet. Intervju kategori b) er delt i 3 temabolker:
1. Arkitektur, spørsmålene tar utgangspunkt i Bloombergs supertrender og spørsmålene skal avdekke om ny arkitektur i større grad enn gammel arkitektur støtter opp under supertrendene. Om så vil ny arkitektur, iht. Bloomberg, bidra til å bedre UiOs
endringsevne?
2. Governance, spørsmålene tar for koordineringsmekanismer i både gammel og ny arkitektur innen fokusområdene beslutningstagere og -domener, horisontale og vertikale harmoniseringsmekanismer i organisasjonen, samt mekanismer for sansing, læring, og måling
3. Spørsmål som går direkte på sikkerhet og kostnadseffektivitet, og som kan utfylle ting som har falt mellom to stoler eller ellers er blitt glemt eller utelatt i forhold til de to tidligere punktene
Under planlegging av intervjuene ble det valgt ut hvilke personer som skulle intervjues. Det ble foretrukket intervjuobjekter som er nåværende eller tidligere teknikere og ledere som kjenner ny og/eller gammel integrasjonsarkitektur godt. Der intervjuobjekt kun innehar spesiell domenekunnskap (som sikkerhet eller gml. arkitektur) er personen bare stilt et relevant subsett av spørsmål. Det er laget en intervju-guide, se Appendix C. Intervjuene starter med åpne spørsmål (tall i intervjuguide) og guiden har så spesifiseringer (bokstaver i intervjuguide) som intervjuer kan gå inn på, om objektet ikke selv kommer inn på temaet.
3.3 Dataanalyse
Dokumentene er analysert mht. kategorier i oppgavens litteraturpensum. Disse kategorier og (evt. mangel på) funn utgjorde så grunnlag for utvikling av intervju-miniguide. Slik
intervjuet er strukturert, er det lett å finne ut i hvilken grad de intervjuede er enige eller om det er uoverensstemmelser. Intervjuet er også utformet slik at det er enkelt å lete etter
26
nøkkelord og sortere etter kategorier. Materialet er undersøkt spesielt etter uttalelser og innfallsvinkler som avslører andre innganger til, eller aspekter ved casen, enn det som kommer frem av dokumentene i datamaterialet.
I arbeidet med analyse og formidling av funn til leserne er det utformet kategorier og
tabeller. Kategoriene, som er gjenkjennelige fra teori og intervjuskjema, finnes både i delene om ny og gammel (altså dagens) arkitektur. Kategoriene gjenspeiler kriterier i teorikapittelet, slik at funnene kan vurderes og drøftes opp mot teorimaterialet. Det er ikke bare en
sammenligning av ny og gammel arkitektur alene.
I arbeidet ble data først analysert for hvert virkemiddel i ny og gammel arkitektur hver for seg. Det er så gjort en konsolidering av de viktigste funnene som så blir presentert
komparativt. Tabell 2 viser en oversikt analysepressen og hvor resultatene er å finne.
Tabell 2
Trinn Aktivitet Resultat
1 Analyse av gammel arkitektur Tabell 3
1 Analyse av gammel styring Tabell 4
1 Analyse av kompleksitet i gammel løsning Tabell 5
2 Analyse av ny arkitektur Tabell 6
2 Analyse av ny styring Tabell 8
2 Analyse av kompleksitet i ny løsning Tabell 10
3 Sammenligning av gammel og ny arkitektur Tabell 7
3 Sammenligning av gammel og ny styring Tabell 9
3 Sammenligning av kompleksitet i gammel og ny løsning Tabell 11 4 Funn konsolidert i enkle kategorier som lav og høy for å frem
likheter og kontraster mellom løsningene
Tabell 13 5 Drøftingspunkter av ny og gammel arkitektur mht. å prøves
opp mot teori om agil arkitektur
Tabell 14 5 Drøftingspunkter av ny og gammel arkitektur mht. å prøves
opp mot teori om governance
Tabell 15 5 Drøftingspunkter av ny og gammel arkitektur mht. å prøves
opp mot teori om kompleksitetskrysset
Tabell 16
Ifm. analysen er det også laget en tabell, Tabell 12. Der trekkes det frem utsagn som har direkte fokus på strategiske evner som sikkerhet og kostnadseffektivt. Dette er et supplement, en annen og mer direkte inngang siden mange aspekter av de strategiske evnene endringsevne, sikkerhet og kostnadseffektivitet ellers behandles mer indirekte gjennom de taktiske virkemidlene. Det å ha en annen inngang er en kvalitetssikringsprosess mht. i hvilken grad analyse av taktiske virkemidler virkning for strategiske evner er
konsistent med funn i intervjumaterialet.
Helt til slutt i funnkapittelet (4.7), i Tabell 13, er alle funn trukket inn i en presentasjon.
Hensikten er å samle alle forskjellene i en tydelig oversikt. I Tabell 13 er gammel og ny
27
arkitektur analysert og satt der opp mot hverandre og forskjell beskrives med begreper som
`høy`, `middels`, og `lav`. Dette for å få frem kontrast. Analysen fortsetter inn i
diskusjonskapittelet, der det er analysert hvilke funn som er relevante mht. drøfting opp mot teorimaterialet. Disse drøftingspunktene er presentert i tabeller.
3.4 Vurdering av forskningskvalitet
Dokumentene er produsert med tanke på publisering og dokumentene er gjennom- gått/godkjent av ledere. Dokumentene er av ny dato og (større) endringer lite trolig. Slike data karakteriseres (av Ringdal) som «prosessdata med høy struktur». Også intervjudataene er av høy kvalitet. De er førstehåndsdata, hvor innsamleren har hatt innsikt i hvilken
kontekst uttalelsene ble gitt. De har dermed hatt tilgang til tonefall, mimikk eller annet som avslører bruk av humor, ironi, sarkasme eller annet. Slik er viktig for å forstå dataens
innhold. Under intervjuene og etter samtykke er det gjort lydopptak av intervjuene. Ingen intervju-objekt hadde innsigelser mht. bruk av opptak. Fra lydopptakene er det kun transkribert de deler som er vitale for funn, derunder motstridene funn. Transkribert
sammendrag av intervju er tilbake til intervjuobjekt, slik at denne har hatt mulighet til å rette eller presisere på tolkningen utsagn er gitt i sammendraget. Både intervju og dokumenter kan behandles som et intervju/(en narrativ). Kvale og Brinkmann presenterer (kap11 s 202- 203) en intervjuanalyse i seks trinn. Viktig i denne sammenheng er spesielt trinn fire hvor det understrekes at forskeren må ha en forståelse for hvilken mening utsagn er tiltenkt fra intervjuobjektet for å kunne analysere datamaterialet. Det er forsøkt å ivareta dette ved å sende transkribert sammendrag av intervju tilbake til intervjuobjektet, slik at dette har hatt mulighet til å rette på eller presisere tolkningen utsagn er gitt i sammendraget. Dette er også tilfellet for de intervjuer som er benyttet som observasjoner. Det vil si at dataene er av høy kvalitet. De er valide. En korrekt analyse av materialet vil kunne måle det som er tiltenkt å skulle måles.
I innsamlingsarbeidet er det gjennomgående benyttet personer med dyptgående domene- kunnskap. Et mer tilfeldig utvalg av intervjuobjekter ville kunnet gi et annet resultat. Det er verdt å merke seg at mange av intervjuobjektene har arbeidet tett sammen og at dette har gitt en ganske lik faglig oppfatning av grep og konsekvens som kan være et resultat av gruppetenkning.
28 4. Funn
I dette kapitelet vil gammel og ny løsning presenteres hver for seg. For Cerebrum er det lagt inn en tekst om bakgrunn, for å få rett kontekst for forståelse av case og tolkning av funn.
For ny arkitektur er bakgrunnen allerede beskrevet i oppgavens introduksjonskapittel. Ut over det er delene likt bygd opp: Først beskrives løsningen, deretter kommer en bit om funn knyttet til hvert av virkemidlene som undersøkes. Når funn rundt et gitt virkemiddel er beskrevet for både gammel og ny løsning, kommer et lite sammendrag med funnene satt opp mot hverandre. Når det er redegjort for virkemidlene følger et delkapittel som går direkte på funn knyttet til strategiske mål. Til slutt kommer en oppsummering. I hvilken grad de taktiske virkemidlene bygger opp om de ønskede strategiske evner blir diskutert i neste kapittel.
4.1 Bakgrunn
Universitets Senter for Informasjonsteknologi (USIT) sendte på tidlig 90-tall en delegasjon til MIT for å studere og få en innføring i deres `Project Athena`. Lærdommen og inspirasjonen derfra bidro sterkt til USIT/UiOs arkitektur og tenkning om sentraliserte IT-tjenester og ganske tynne klienter. Når trenden med desentralisering kom med PC-ene, førte dette ikke til noen sterk desentralisering på UiO, til forskjell fra f.eks. NTNU eller Universitet i
København. Dette ga et fortrinn når trenden så snudde tilbake til sentraliserte tjenester i en klient – tjener arkitektur. UiO var allerede der. Denne tankegangen medførte også at UiO var tidlig ute med et felles brukerregister, UREG. Dette medførte bl.a. at brukere hadde samme brukernavn og passord, samt samme tilganger, uavhengig av hvilken maskin de logget inn på. Tilgangsstyringen var spesielt viktig mht. Lønns- og personsystemet, senere Lønns- og trekksystemet, (LP/LT). Dette var egenutviklet ved UiO.
IT var altså primært for ansatte, enten som forskere eller som følge av behov for tilgang til LP. Unntaket var Det matematisk-naturvitenskapelige fakultet, og der var særlig Institutt for Informatikk(IFI) i en særstilling. IFI var tidlig ute med elektronisk emnepåmelding.
Emnepåmeldingen ble integrert med UREG, som besørget automatisk brukerbygging, epost- og tilgangsstyring mm. Det var IFIs emnepåmeldingsløsning som lå til grunn både teknisk og idémessig for Felles Studentsystem(FS). I praksis var IT (ganske snart) for langt flere enn ansatte. Mange kjente noen og skaffet seg tilgang på den måten. Det var totalt 14000 brukere (av dem kanskje 30% ansatte) på det tidspunkt (rundt `96) Universitetsstyret vedtok at alle studenter skulle få tilbud om å kunne benytte UiOs IT ressurser. Vedtaket medførte et behov for en automatisk løsning for brukerbygging: UREG2000. Fremveksten av UREG2000 skjedde i nær integrasjon med FS-data, altså emner studentene var påmeldt. På dette tidspunktet var IT tilgang for studenter ennå dyrt for enhetene da det krevde opplæring.
Opplæringskursene lå i FS og eleven fikk en temporær bruker om man meldte seg på IT opplæringskurs (gjennom FS). Brukeren ble permanent dersom man møtte opp på kurset.
Kostandene og det at alle studenter hadde krav på IT tilgang medførte et stort press fra
29
fakultetene for en billig løsning. Så tvungen kursing ble avviklet. Styrevedtaket ble fulgt opp med store krav til måling av ressursbruk. IT var primært en forskerressurs, f.eks. skulle studenter bare kunne utnytte 20% av UiOs båndbredde.
Tungregning avdekket tidlig behov for nasjonalt samarbeid og det ble tenkt sektorbrukere og/eller føderering (altså at man kunne benytte den brukeren man benyttet i det vanlige til innlogging på felles sektortjenester). Behov for samarbeid betød behov for felles IT-regler, kompatible IT reglement, og mekanismer som gjorde at man kunne dele tjenester: en felles elektronisk identitet. Felles Elektronisk Identitet (FEIDE) var et IT tiltak gjennom Uninett for en sentral autentiseringstjeneste for hele UH-sektoren. Utviklingen av FEIDE foregikk utenfor UiOs Universitetsdirektørs og IT-direktørs kontroll og viten. Finansiering foregikk gjennom Uninett med midler de var tildelt fra departementet. Første versjon av FEIDE var i hovedsak utviklet ved USIT. Foruten kompatible IT-reglement var det krav om at for å kunne knytte seg til FEIDE føderasjonen måtte virksomheten ha et identitets-håndteringssystem(BAS).
UREG2000, som altså var en BAS, var i en særposisjon og langt foran andre samtidige løsninger. (NTNU hadde sitt eget system, BB, men det var i liten grad automatisert).
UREG2000 hadde for mye UiO-spesifikt til å kunne rulles ut på andre institusjoner. Systemet var også blitt klattet og lappet på, slik at løsningen allerede hadde en del teknisk gjeld.
Utvikling av Cerebrum skjedde med det for øye å lage en organisasjonsuavhengig BAS- løsning som alle skolene i sektoren kunne implementere sin replika av. Gjennom det ville de oppfylle kravene for å kunne knytte seg til FEIDE. I utrulling av Cerebrum på andre
institusjoner enn UiO møtte man utfordringer mht. FS integrasjon da det fantes lokale forskjeller i FS, primært mht. semantisk bruk av felter. Selgerne av FS ikke bare godtok, men oppfordret til nevnte praksis. Det var også andre utfordringer. Cerebrum kom med svak dokumentasjon og var vanskelig å implementere. Det var bare de mest ressurssterke institusjonene som hadde mulighet til å sette opp sin egen instans. UiO/USIT laget et tilbud om å implementere og drifte for de som hadde interesse av å sette bort oppgaven, et tilbud et dusin institusjoner har takket ja til. Videre viste det seg at Cerebrum også hadde
ytelsesproblemer, og for å løse dette lagde man løsninger som ikke var iht. intensjon, forretningsmodell og initielt design. Løsningene innebar også harde koblinger. Epost-
informasjon var jo integrert allerede i UREG/UREG2000. Og i Cerebrum kom nye moduler til:
Hjemmeområde hang tett med personinformasjon, og kvoter/diskbruk, senere utskrift, var tett knyttet til personobjektet. Det virket naturlig å utvide funksjonalitet i eksisterende løsning. I fm. initielt arbeid, altså allerede tilbake i LP/LT verden, ble det laget et rammeverk for tilgangsstyring, som muliggjorde distribuert arbeidsflyt. Dette rammeverket er sentralt mht. at ny funksjonalitet er lagt til Cerebrum, da gjenbruk av tilgangsstyringsrammeverket har vært regnet som kostnadseffektivitet og sikkert. De nye modulene var ofte mindre relevante mht. personinformasjon. F.eks. er det moduler som holder orden på
nettverkssegmenter (VLAN) og internett-adresser (DNS). Totalt finnes et dusin-talls moduler for ymse formål. Modulene har relativt få knytninger til hverandre, men er hardt koblet mot Cerebrums kjernefunksjonalitet, spesielt komponenten for tilgangsstyring.