Om

Arkitekturportalen for Trondheim kommune er en samling med ressurser for alle med interesse for IT-forvaltning. Portalen brukes som arkitekturstyringsverktøy i Trondheim kommune, men vi synes det er viktig at andre kommuner kan nyttiggjøre seg ressursene som ligger her. 

Portalen henter inspirasjon fra blant annet TOGAF og OIO (Offentlig Information Online). Innholdet blir oppdatert av arkitektressurser i Trondheim kommune. Om du har innspill eller spørsmål ta kontakt med Tor.Erlend.Fagri@trondheim.kommune.no 

Ofte stilte spørsmål

Alle IT-systemer har en iboende struktur bestående av komponenter/moduler, relasjoner mellom dem og noen prinsipper som ligger til grunn for innledende utvikling og den videre forvaltningen av systemet. Denne strukturen inngår i systemets arkitektur. Arkitektur gir oss mulighet til å resonere omkring systemets evne til å oppfylle visse forventninger -- såkalte kvalitetsegenskaper. Et eksempel kan være vedlikeholdbarhet. En gitt oppdeling i komponenter/moduler gjør at vi kan resonere oss fram til hvordan IT-systemet kan innfri fremtidige behov for å videreutvikle systemet.

En IT-arkitekt er en ressurs som tar arkitekturbeslutninger og utarbeider arkitekturleveranser (skisser, kataloger, matriser.) IT-arkitekten har også en viktig formidlingsrolle. En IT-arkitekt fanger opp tekniske behov og utfordringer fra de som skal bruke løsningen og sammenstiller og formidler dem ledere. En IT-arkitekt kan også formidle strategiske meldinger fra ledelsen til det operative nivået -- for eksempel de som skal anskaffe en IT-løsning.

Viktig å merke seg: En IT-arkitekt er verken en teknisk koordinator, prosjektleder, utvikler eller tester, selv om hun bistår de nevnte roller.

“You don’t need architecture to build a dog kennel, but you’d better have some for a skyscraper.”

Så svaret kommer an på system størrelese, heterogenitet, kritikalitet, fordeling, forandringshastighet og organisasjon hierarki og forretningsmodell. F.eks. arkitektur er mye mer viktig og kritisk i MinSide kontektsten i en stor kommune enn en app for pizza bestilling! Siden fleste av virksomhtssystemer er stor, kompleks og avhengig av andre systemer, er arkitektur veldig viktig i store virksomheter som TK.

I tillegg til systemer og deres struktur, bør vi merke Conway's Law for å forstå hvor viktig og kritisk er å ta vare på arkitektur i store virksomheter: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". Figuren nedenfor viser gevinster av satsing på virksomhetsarkitektur i NAV (kilde: Lauvrak og Michaelsen).

Begrepet arkitektur er kastet rundt veldig enkelt i IT-avdelinger i disse dager. Selv om er det allerede vanskelig nok til å forklare for noen utenfor IT at hva arkitektrolle innebærer, forstår mange mennesker innen IT-avdelinger ikke forskjellige typer arkitektroller som kan eksistere i store virksomheter.

Moderne IT systemer er så stor, kompleks og distribuert at arkitekturen skal brytte ned til ulike "domener" og handles ved spesifike roller. Arkitekturdomener er bl.a. forretning, informasjon (data), applikasjon og integrasjon, sikkerhet og teknologi. F.eks. forretningsarkitekter kartlegger forretningsprosesser og kategoriserer forretningstjenester, sikkerhetsarkitekter kartlegger sikkerhetsutfordringer og utformer sikkerhetsløsninger, og infrastruktur arkitekter utformer nettverk og IKT infrastruktur.

I tillegg til "domenet", er andre aspekter som gjør forskjellge arkitektroller "omfanget" og "detaljnivå" av arkitekturen. Virksomhets- og løsningsarkitekt er resultat av disse aspekter. Begge roller bør fokusere og ha kunnskap til både IT og forretning domener, men omfanget og detaljnivået gjør forskjellen. Mens løsningsarkitekter handler om utforming av en bestemt løsning i detaljer, fokuserer virksomhetsarkitekter på arkitekturaktiviteter i hele organisasjonen i høy nivået og utarbeider arkitekturleveranser på tvers av ulike IT prosjekter. F.eks. etablering referanse kvalitetskrav for utvikling av IT systemer er et ansvar for virksomhetsarkitekt, mens utarbeide kvalitetskrav til et spesifik prosjekt basert på referanse krav er plikten til en løsningsarkitekt. Figuren nedenfor viser ulike arkitekturroller på domene og detaljnivå aspekter (inspirert av denne nettside).

Det kan være en hybrid kombinasjon av "domene" og "omfang" også. F.eks. en kan være sikkerhetsarkitekt bare for et spesifik prosjekt og jobber ved autentiseringsmekanismer for en spesifik løsning mens annen kan være sikkerhetsarkitekt for hele organisasjonen og etablerer sikkerhetsprinsipper på tvers av alle IT-prosjekter.

Hva om IT-arkitekt? Som generelle begrep, brukes IT-arkitekt for å differensiere rollen med arkitekt i byggningsverden. Men innen IT-verden er det et forvirrende ord og brukes i ulike organisasjoner på forskjellige måter! Noen mener infrastrakturarkitekt når bruker IT-arkitekt, noen mener integrasjonsarkitekt og osv. Rollen skal være klart definert i organisasjoner som bruker ordet da. 

Mange tenker at arkitekturskisser er bare noen boxes-and.arrows! Jo skissene ofte ser ut noen boxes-and-arrows men ulike arkitekturelemeneter og deres relasjoner har ulike meninger og de skal visualiseres på en riktig og konsistent måte. Av denne grunnen har noen standardorganisasjoner utviklet modelleringspråk for dokumentere arkitekturskisser. De kjente språk er Archimate og UML. 

Selv om unødvendig arkitekturarbeid kan være mot smidighet, nok og klok arkitekturarbeid kan faktiskt hjelpe prosjekter og organisasjoner å være mer smidig! Gjennbruk av kunnskaper og tjenester på tvers av prosjekter og enheter øker smidighet og gjennbruk er ikke mulig uten bevist arkitekturarbeid og leveranse. I tillegg, finnes mange filosofier som gifter arkitektur og smidighet. Noen er beskrevet nedenfor!