Minst eller mest mulig it-arkitektur?

Minst eller mest mulig it-arkitektur?

KRONIKK: Hvis to tabletter er bra mot hodepine, må fem være bedre.

Aspirinteorien går ut på at hvis to tabletter er bra mot hodepine, må fem være enda bedre. Det stemmer selvfølgelig ikke, verken for hodepine eller it-arkitektur. Tvert imot: For mye arkitektur er verre enn for lite.

De fleste er enige i teorien om at bedrifter som bruker it behøver en it-arkitektur. Det er opplagt: Elementene skal henge sammen og utvikle seg koordinert. Ellers får endringer uante konsekvenser.

Det store spørsmålet er: Hvor mye arkitektur? Forretningsenhetene vil ha minst mulig fordi arkitekturbeslutninger binder dem. Det er makt i arkitektur, det er det samme som styring. It-avdelingene vil ha mye fordi det gir dem forutsigbarhet og stabilitet. Sannheten finnes et sted imellom.

Prosess, ikke produkt

Uten arkitektur skaper enhver større endring i forretningen en uoversiktlig mengde arbeid og risiko. Det er derfor Gartner har definert arkitektur slik: "Prosessen som på en effektiv måte omskaper forretningsmessige målsetninger til endringer i bedriften". Her ligger vekten på prosessen, ikke på produktet. De tre store utfordringer i arkitekturarbeidet har ikke med teknikken å gjøre, men med forretningsenhetene, menneskene og prosessene.

Her er noen utprøvde veier rett inn i fortapelsen:

Mange arkitekturprosjekter vender seg innover, mot it-faget. De som er interessert i faget flokker seg sammen. Maskiner, programmer, datalagring, det er hva saken dreier seg om for dem. Forankringen i forretningsenhetene er minimal, "de skjønner jo likevel ingenting!" Velger man denne veien er fiaskoen sikret. Folk som ikke er opptatt av it synes at å argumentere rundt det teknologiske fundamentet er nærmest irrelevant. De vil ha løst sine problemer. Teknologibaserte arkitekturer blir det aldri noe ut av fordi forretningsenhetene vet at ingen toppledere vil kreve at de blir etterlevd. Det verste er at arkitektene ikke skjønner hvorfor de ikke får gjennomslag, det er så opplagt riktig det de foreslår. For dem selv, altså.

Mange arkitekturprosjekter mislykkes fordi det er feil personer som jobber med dem. De har ikke påvirkningskraft i organisasjonen, de tenker teknisk og rir sine kjepphester. Hvis forretningsenhetene blir invitert til å være med, sender de folk som har lite å gjøre – hver eneste gang. Får ikke prosjektet tak i de tunge, sentrale personer (som alltid har masse å gjøre) er slaget tapt før det har startet.

Problemløsning, ikke papirarbeid

Så har vi dette med at "fem aspiriner er bedre enn to". Big Design Upfront er akkurat like feil her som i smidige prosjekter. Å spandere år på "å løse det hele" før det første konkrete problemet blir tatt tak i, er en sikker vei til bøtta. Rammeverk skaper papirarbeid, ikke problemløsning. Denne type arkitekter sitter i sine elfenbenstårn og kommer sjelden ut i frisk luft. "Just enough architecture, just in time" er derfor et godt Gartner-slagord. Det er best å begynne med en kort liste, fire til fem kritiske koordineringsproblemer, og lage et rammeverk som er godt nok for å løse dem. Går dette bra, har man lært en masse og er klar til å gå videre.

Overdrevent fokus på arkitekturprosessens dogmer og irrganger fører også lukt til helvete. Forretningsmessige utfordringer skal stå i fokus. Spesielt farlig er det hvis arkitekturprosjektet ikke forstår ordentlig hva disse utfordringene er. Da er det greiere å jobbe med det man vet noe om fra før – prosessen. Vi er skapt slik at vi helst vil jobbe med det vi allerede vet en del om, ikke hva vi burde lære oss mer om.

Arkitektur dreier seg om å velge standarder og standardløsninger. Det er mye lettere å velge en standard enn å begrunne hvorfor vi skal ha den. Å innføre standarder koster flesk. De begrenser valgmulighetene. Det krever tid og innsats å avgjøre om de foreslåtte løsninger oppfyller standardene. Ikke misforstå: Vi må ha noen standarder, men vi må klare å begrunne hvorfor vi skal ha dem. Det er best å vente med å velge en standard til vi tydelig ser at å ikke ha den har skapt problemer. Da er det mye lettere å argumentere.

Unntak

Og sist, men ikke minst: Håndtering av unntak. Har vi valgt en arkitektur og noen standarder, kan vi være sikre på at ønsker om fravik vil dukke opp ganske snart. Det er her "hjulet treffer asfalten".

Hvis unntakene blir innvilget hver gang, har arkitekturen ingen effekt. Men hvis et ønske om unntak skal avvises, må den som avviser det ha sterk støtte ovenfra.

Den som ønsker seg unntaket, vil appellere og argumentere oppover, og da blir det tydelig hvem som har ledelsens øre og tillit.

Les om: