Arkitektur er en nødvendighet
For å designe komplekse systemer samt sikre at de faktisk fungerer når de er ferdige, er man i dag avhengig av en skikkelig arkitektur.
"Jeg har ingen komplekse systemer", sier du? Nei vel, så alle dine systemer er enkle systemer som kjøres isolert uten å utveksle informasjon? Jeg er redd for å måtte skuffe deg - dette er dessverre aldri tilfelle, noe som nødvendiggjør å tenke arkitektur.
En god arkitektur er som et ferdig puslespill: Et helhetsbilde nøye sammensatt i henhold til brikkenes form, farge og plass i totalsystemet. En IT-arkitektur fungerer på samme måte, bortsett fra at brikkenes form og farge er erstattet med forskjellige krav som teknologi, funksjonalitet, sikkerhet, drift, og økonomi. Har man gode prinsipper for arkitekturen, gir dette støtte for de riktige valgene, og sørger for at valgene samtidig bygger oppunder strategiske forretningsbehov.
Det er med it som i verden ellers ) arkitektur er ganske enkelt en beskrivelse av komponenter og hvordan de henger sammen. Imidlertid kan man ikke diskutere arkitektur uten samtidig å forklare i hvilken sammenheng det gjelder. Vanligvis snakker vi om fire aspektområder når det gjelder it-arkitektur (se figur). Forretningsarkitektur sier noe om forretningsprosesser og organisasjonen. Informasjonsarkitekturen beskriver informasjonsstrømmene i oppbyggingen, informasjonssystemer er de automatiserte forretningsprosessene mens den teknologiske arkitekturen er den underliggende teknologien som informasjonssystemene bruker.
I tillegg kan det være nødvendig å beskrive arkitekturen i form av risikonivå (sikkerhetsarkitektur) og kvalitetsnivå (driftsarkitektur).
Arkitekturen sikrer at en løsning er robust, vedlikeholdbar, adaptiv og framtidsrettet. Den reduserer risikoen betraktelig for at et prosjekt mislykkes fordi fokus rettes mot de viktigste og mest kritiske faktorene, og den henter erfaringer fra eksisterende løsninger. Bruk av løsningsmønstre sørger i tillegg for en god løsning på kort tid som også er gjennomprøvd og følger beste praksis fra industrien. Vi kan dele inn i fire faser:
Først er man avhengig av en kontekstuell fase. Her planlegges prosjektet, omfang og målsetning bestemmes, og overordnede forretningsprinsipper samles og defineres. Prinsippene er en del av arkitekturen, og det er nettopp de som skal drive alle beslutninger på et senere stadium. Samtidig må roller og ansvar i prosjektet bestemmes, samtidig som informasjon om nå-situasjonen og eksisterende arkitektur dokumenteres.
I den konseptuelle fasen identifiseres behov og krav til ny løsning samtidig som risikonivå og kvalitetsnivå defineres. Kravene kan være roller og tjenester, karakteristikker av disse eller krav til hvordan de må henge sammen.
I den logiske fasen designes den ideelle løsningen. Her beskrives de komponentene man vil bruke basert på kravene i forrige fase samtidig som de plasseres der de best løser behovene.
Den avsluttende fasen, også kalt den fysiske fase, innebefatter valg av løsning og produkter. I denne fasen beskriver man produkter, teknikker og standarder. Disse valgene må også være basert på de opprinnelige kravene i den konseptuelle fasen. Først da ender man opp med ikke bare en liste over produkter og hvordan de fysisk henger sammen, men like viktig - en detaljert konfigurasjonsinformasjon og beskrivelse av hvordan man skal implementere løsningen.
Og det er nettopp den ferdige listen og konfigurasjonsinformasjonen som får brikkene i puslespillet til å falle på plass. Har du fortsatt ingen komplekse systemer? Med den mangelen på suksess som it-bransjen historisk har hatt i utviklingen av programvareprosjekter, burde det ikke være nødvendig å si mer(
Lykke til med puslespillet!
Paul R. Carr,sjefskonsulent i Cap Gemini Ernst & Young, og sertifisert it-arkitekt med sikkerhet som spesialitet, prosjektleder og kursleder.
E-post: Paul-Richard.Carr@cgey.com
