Om arkitektur og hvordan den blir til

I mitt tidligere innlegg “Om arkitektur” forsøkte jeg å si noe om hva arkitektur innen informasjonsteknologi betyr og hvilket fokus arkitekturarbeidet bør ha. Jeg forsøkte å analysere hva ordet arkitektur kommer av og hvordan den klassiske tolkningen av ordet gikk ut på. Videre forsøkte jeg å trekke paralleller til hvordan arkitektur bør tolkes innen informasjonsteknologi. Minst like viktig er det å se på hvordan en arkitektur blir til, og ikke minst hvilke oppgaver en arkitekt bør ha i så henseende. I dette innlegget forsøker jeg å komme med noen tanker rundt dette.

“Jeg har sett mange gode arkitekturer som aldri ble noe av”

Dette sitatet (fritt etter hukommelsen) hørte jeg fra en foreleser på en konferanse for en tid tilbake. Min første tanke var: “var arkitekturen god hvis den ikke ble noe av”? Hvis vi igjen skal se på gode, gamle Vitruvius som jeg nevnte i mitt forrige innlegg; oppfyller arkitekturen som ikke ble noe av ikke prinsippene firmitatis utilitatis venustatis? Ikke var den robust, ikke var den nyttig for brukerne og den fikk aldri sjansen til å vise sin skjønnhet. Vel. Mer fruktbart er det kanskje å spørre seg hvorfor en arkitekturplan aldri ble noe av. Det kunne være at den ble for dyr, det kunne være at den ikke løste utfordringene den skulle eller det kunne være at den ikke hadde tilstrekkelig forankring i organisasjonen. Like viktig som hva en arkitektur består av, er hvordan den ble til.

Arkitektur ikke bare en arkitekts anliggende

Arkitektur er et tverrfaglig område. Det omhandler forretningen (hvilken funksjonalitet er ønsket, og hvilken verdi gir den?), økonomi/finans (hva er kostnadene? Oppstartskostnader vs. operasjonelle kostnader, osv.) og ikke minst teknologi (modenhet, tilgjengelighet, osv.). En god arkitekturprosess krever forankring og involvering fra ulike deler av organisasjonen og jo mer eierskap de involverte føler, jo større er sjansen for å lykkes. Et eksempel på dette er smidige utviklingsprosjekter, der arkitekturspørsmål bør kunne diskuteres og løses i utviklingsteamet. I den grad man har arkitekturprinsipper som går på tvers av prosjekter, bør man sikre tilstrekkelig involvering på tvers av prosjekter, f.eks. gjennom at arkitekter dedikeres til prosjektene og kan jobbe tett med utviklingsteamene.

Arkitektur og “Big Design Up Front” – BDUF

I mitt tidligere innlegg pekte jeg på at arkitektur er en delmengde av design i den forstand at design kan skje på alle granularitetsnivåer og kan gjerne omhandle en moduls eller applikasjons interne organisering, mens arkitektur fokuserer på helheten og eksterne kvaliteter. I smidige prosjekter ønsker man å unngå det man kaller “big design up front“, altså at design skjer før utviklingen eller implementasjonen starter. Dette er et prinsipp som brukes uavhengig av hvilke smidige metoder som benyttes, men jeg syns Lean Software Development er nærmest å forankre prinsippet teoretisk. I mine øyne er fravær av BDUF en følge av tre Lean-prinsipper: 1) vektlegge læring, 2) ta avgjørelser så sent som mulig og 3) mindre avfall, “eliminate waste”. Ved å kjøre designprosessen som en del av utviklingsprosessen kan man ta med seg læring inn i designprosessen. Videre kan man utsette designavgjørelser lengre slik at man har mer informasjon og kunnskap tilgjengelig som beslutningsgrunnlag og dermed forhåpentligvis ta en bedre avgjørelse enn man kunne gjort tidligere. Til sist, hvis design gjøres samtidig som implementasjonen, sparer man unødig ressursbruk til dokumentasjon i og med at de involverte har informasjonen i mente allerede. Mer om dokumentasjon senere…

Spørsmålet er om regelen om å unngå “big design up front” også gjelder for arkitektur? Ja og nei. Noen arkitekturavgjørelser må ofte tas før man starter implementasjon. Dette kan for eksempel være hvilken implementasjonsplattform man ønsker å bruke (Java EE eller .NET, for eksempel). Det som er viktig i slike sammenhenger, er som jeg nevnte i forrige avsnitt at man utsetter avgjørelser som er vanskelig å omgjøre så lenge som mulig. Spesielt viktig er det også å utsette avgjørelser som introduserer mye kompleksitet så lenge som mulig fordi kompleksitet ofte introduserer avhengigheter. Disse bidrar så til å krympe mulighetsrommet for arkitekturen. Med andre ord får man mindre frihetsgrader. I den grad man kan gjøre det, bør man fatte avgjørelser som kan omgjøres for å unngå å male seg inn i et hjørne. Et godt innlegg om det å utsette avgjørelser finner du her.

Et dokument er ikke arkitektur

“Leveransen fra arkitekturprosessen er et arkitekturdokument”. “I følge rammeverk X skal leveransen fra arkitekturprosessen være et Y-diagram, en Z-modell, … , samt en forretningmodell”. Lyder kjent? Å ha noe håndfast (i den grad man kan omtale et elektronisk dokument som håndfast, man kan i det minste skrive det ut for å få noe håndfast) å vise til som resultat av en investering gir en god og varm følelse. I klassisk transaksjonstankegang er dette viktig fordi det er et synlig bevis for hva man har fått igjen, og et sett arkitekturprinsipper som eksisterer inni hodene på folk ikke gir den samme følelsen av å ha fått noe tilbake.

Å benytte et rammeverk for arkitektur som definerer et sett av dokumenter som skal produseres gir også troverdighet som det er behagelig å lene seg på. Dette er selvfølgelig vissvass. Et arkitekturrammeverk er et tomt skall uten innhold, og det er innholdet som er viktig.

Arkitektur består av en del fokusområder / kvaliteter (eksempelvis firmitatis utilitatis venustatis). Disse er i stor grad ideer eller prinsipper, og det er veldig vanskelig å formidle ideer og prinsipper i dokumenter. Enklere er det derimot å overføre ideer muntlig, og enda bedre; hvis man selv har vært med på å komme frem til disse har man en enda bedre forståelse (og ikke minst et større eierskap). Dokumenter er den dårligste kommunikasjonsformen, og burde brukes når andre former ikke er tilgjengelige. Dette kan være tilfelle på grunn av avstand til brukere; både organisatorisk, geografisk og i tid. Som jeg nevnte i forrige avsnitt; den organisatoriske avstanden bør minimeres gjennom involvering, og som jeg nevnte i avsnittet om BDUF, avstanden i tid bør minimeres ved å utsette arkitekturavgjørelsene så lenge som mulig.

Oppsummering

Gjennom disse to innleggene om arkitektur har jeg vært innom flere aspekter som kan oppsummeres som følger:

Arkitektur fokuserer på helheten og på eksterne kvaliteter (hva som er eksternt varierer dog avhengig av perspektivet)
Arkitektur består av en del kvalitetsområder eller prinsipper, eksempelvis firmitatis utilitatis venustatis
Arkitekturarbeid er en tverrfaglig prosess der involvering fra ulike deler av organisasjonen er viktig
Arkitektur bør utvikles gradvis, parallelt med implementasjon der man underveis nyttiggjør seg lærdom man opparbeider seg
Leveransen fra arkitekturarbeid bør ikke defineres i form av dokumenter. Kommunikasjonsformen bør tilpasses situasjonen.

Hansen

Interessante artikler om arkitektur, ikke ofte man ser etymologi og gamle greske skrifter tatt med i betraktning av IT systemer. Sjekk også etymologien bak logikk, teknologi, tekst, teori, tekstur og ikke minst ‘informasjon’, med de konnotasjoner det har fra gamle Hellas.

En kort slutning er dog at etymologisk, så er arkitektur resultatet av at mesteren sitt geni designet sin informasjon fra noumenenes (formene og tankenes) verden og ut i fenomenenes objektivt sanselige verden, og materialiserte der det perfekte. Design, de-sign, å markere ut eller tenkte ut, med vekt på ‘ut’ (fra det indre, til modeller og diagrammer). Innen IT-terminologi blir arkitektur rent metaforiske, men design holder den originale betydningen godt.

Arkitektur blir da design vi ikke kan endre på, som er gitt eller satt, som hardware, OS og programmeringsspråk. Videre ut i prosjektene blir avgjørelser som er tatt, og ikke kan endres på, en del av arkitekturen, sammen med arbeid som er gjort og som er for dyrt å endre på. Det vi sitter igjen med av fleksibilitet er bygget inn i arkitekturen, med eller uten hensikt. Og som du også erfaringsmessig peker på, har også prosjektestyring og organisasjonskultur på samme måte sin arkitektur: Alt kan bygges, rives og modifiseres, men det koster.

En liten digresjon det her, det er IT vi fokuserer på, ikke filosofi, selv om filosofi etymologisk har mer med IT å gjøre enn dagens dilettantisk universitetsfag med samme navn…

http://www.kongsli.net/nblog/ Vidar Kongsli

Jeg tror at det å sette fokus på hva ordene vi bruker betyr, hva vi mener med dem, sammenligne det med hvordan andre bruker dem osv. (kall det gjerne filosofi) bidrar mye mer til å fange essensen (eng. ‘gist’) i det vi jobber med enn det å søke løsningen i rammeverk gjør.

Hansen

Jeg er helt enig med deg. Uten samme konsepter bak termene blir det mye rot, spesielt hvis misforståelsen ikke oppdages før et stykke ut i diskusjonen.

Etymologi synes jeg sådan er en veldig belærende innfallsvinkel på hva ord betyr; ofte mer så enn moderne definisjoner, fordi paradigmene forsvinner, men den essensen forblir og konseptene blir gjerne klarere. Jeg stirret ganske tomt på skjermen da jeg skjønte hva etymologien til ordet teknologi bærer i seg, og hvor gammelt dette konseptet er. Www er ikke noe nytt tankemønster, bare skalaen og maskinene er nye =)

Hva rammeverkene angår, har jeg på følelsen at vi fremdeles ikke er i nærheten av optimaliserte konsepter for å forstå et ‘perfekte rammeverk’. Dog synes jeg personlig at utviklingen av IT systemene våre minner veldig om naturlig evolusjon, og at det vi egentlig gjør er å ‘teste’ oss frem til systemer som allerede finnes (kvalitetssikret) i naturen i from av øko- og biologi systemer. -Kanskje det vi ender opp med er et IT-system som forteller oss mer om samspillet i naturen og vår rolle i den? -Dersom vi klarer å se IT-systemer som mer generiske systemer og ikke bare spesifikt anvendbart innenfor gitt område.

PS! ‘Paradigme’ har også etymologisk en bredere mening en den sammenhengen vi ofte bruker det i, og har røtter i ‘pattern’, som videre går tilbake til samme røtter som ‘architect’ (via ‘patron’). Det er en farlig vei å begynne på, dette med etymologi; alle ords mening blir snudd litt bak frem, og da blir det enda viktigere, som du sier, å avklare hva vi og andre legger i ordene… men da er i det minste alle parter klar over problemstillingen. Etymologi: win-win eller loose-loose =)