Å gå fra utvikler til Azure Solutions Architect betyr å flytte målingen av fremdrift fra fungerende kode, pull requests og leveranser til valg som holder over tid på tvers av kostnad, sikkerhet, drift og forretningsbehov.
Det gjør rollen særlig relevant for erfarne utviklere som allerede forstår hvordan systemer bygges, men som ønsker større ansvar for hvordan de bør utformes. En Azure Solutions Architect lager ikke bare tekniske skisser; rollen handler om å omsette behov fra produktmiljøer, plattformteam, sikkerhet, drift og ledelse til løsninger som kan bygges, forvaltes og videreutvikles i Microsoft Azure.
Hvorfor utviklere har et godt utgangspunkt
Utviklere som har jobbet noen år med .NET, Java, JavaScript eller tilsvarende teknologistakker, har ofte en praktisk forståelse som er vanskelig å erstatte. De vet hvordan avhengigheter oppstår, hvor ytelsesproblemer vanligvis skjuler seg, hvordan små arkitekturvalg påvirker deployering, og hvorfor uklare grensesnitt mellom team kan skape teknisk gjeld.
Overgangen til arkitektrollen handler likevel mindre om å skrive mer kode og mer om å ta designvalg under begrensninger. En løsning kan være teknisk elegant, men for dyr å drifte, for komplisert å sikre eller for sårbar ved feil. Arkitektens arbeid ligger ofte i avveiningen: hva som bør standardiseres, hva som kan bygges enkelt, hvor risikoen er akseptabel, og hvilke beslutninger som må dokumenteres før teamene går videre.
Dette skiftet gjør produkt- og plattformtenkning viktig. En utvikler kan konsentrere seg om én applikasjon eller ett domene, mens en Azure Solutions Architect må forstå hvordan applikasjoner, identitet, nettverk, data, sikkerhet og driftsmodeller henger sammen. I mange norske virksomheter betyr det også å samarbeide tett med interne plattformteam, sikkerhetsmiljøer og leverandører som har ansvar for hybrid infrastruktur.
Hva rollen innebærer i praksis
En Azure Solutions Architect arbeider med å designe løsninger som bruker Azure på en kontrollert og hensiktsmessig måte. Det kan omfatte skymigrering, modernisering av applikasjoner, valg av dataplattformer, sikkerhetsarkitektur, integrasjon med eksisterende datasentre og etablering av driftsmodeller. Microsofts egen eksamensbeskrivelse for AZ-305 legger vekt på design av identitet, governance, overvåking, datalagring, kontinuitet og infrastruktur, noe som gir et godt bilde av bredden i rollen.
I en norsk kontekst dukker noen temaer ofte opp. Mange organisasjoner har hybride miljøer der Azure må fungere sammen med eksisterende nettverk, datasentre og identitetsløsninger. Microsoft Entra ID blir da mer enn en innloggingsmekanisme; det blir en del av organisasjonens sikkerhetsmodell. Tilsvarende blir landing zones, altså standardiserte grunnmurer for kontoer, nettverk, policyer og tilgangsstyring, viktige fordi de hindrer at hvert prosjekt lager sin egen skyplattform.
Et anonymisert eksempel kan være en offentlig virksomhet som skal flytte en eldre saksbehandlingsløsning til Azure. Utviklingsteamet ønsker rask modernisering med containere og administrerte databaser. Sikkerhetsteamet krever tydelig segmentering, logging og kontroll på tilgang. Økonomimiljøet ønsker forutsigbare kostnader, mens drift er opptatt av beredskap og gjenoppretting ved feil. Arkitektens bidrag er å samle disse hensynene i et løsningsdesign der nettverk, identitet, overvåking, backup, disaster recovery og koststyring vurderes før migreringen starter.
Fra kodeansvar til arkitekturansvar
Forskjellen mellom en erfaren utvikler og en Azure Solutions Architect ligger ikke i at den ene er teknisk og den andre er strategisk. Begge må forstå teknologi. Forskjellen er hvor beslutningene treffer. Utvikleren tar ofte detaljerte valg innenfor en definert løsning, mens arkitekten definerer rammene som flere team skal bygge innenfor.
Det betyr mer dialog med interessenter som ikke nødvendigvis leser kode. Arkitekten må kunne forklare hvorfor en bestemt dataløsning gir bedre robusthet, hvorfor et nettverksvalg påvirker leveransetempo, eller hvorfor en tilsynelatende billig løsning kan bli kostbar når overvåking, sikkerhet og drift tas med. Den faglige tyngden ligger i å gjøre komplekse valg forståelige uten å forenkle bort risiko.
En vanlig feil i overgangen er å over-engineere. Utviklere som er vant til å løse vanskelige problemer, kan bli fristet til å designe for alle tenkelige scenarioer. I praksis er gode Azure-arkitekturer ofte preget av klare standarder, færre spesialtilpasninger og bevisste begrensninger. Evnen til å forenkle og standardisere er derfor like viktig som kjennskap til mange Azure-tjenester.
Kompetansen som må bygges
Utviklingsbakgrunn gir et sterkt fundament, men arkitektrollen krever bredere kompetanse. Governance betyr styring av ressurser, policyer, abonnementer, navngivning, tilgang og etterlevelse. Koststyring handler om å forstå hvordan designvalg påvirker forbruk, skalering og økonomisk forutsigbarhet. Pålitelighet krever kunnskap om redundans, backup, gjenoppretting og feilhåndtering. Sikkerhet må være innebygd i arkitekturen, ikke lagt på mot slutten.
Observability er et område mange undervurderer. Det holder ikke at en løsning kan deployeres; den må kunne overvåkes, feilsøkes og forbedres når den er i produksjon. Logging, metrikker, alarmer og sporbarhet bør derfor vurderes som del av løsningsdesignet. Uten dette kan teamene ende med løsninger som fungerer i test, men som er vanskelige å drifte når reelle brukere, integrasjoner og feiltilstander kommer inn.
En annen tydelig utvikling er at plattformengineering og Infrastructure as Code har endret forventningene til arkitekter. Bicep, Terraform og automatiserte deployment-pipelines gjør at arkitektur i økende grad uttrykkes som kode. Det betyr ikke at arkitekten må være den som skriver alle modulene, men rollen må kunne lese, diskutere og kvalitetssikre infrastrukturdefinisjoner sammen med utviklere, plattformteam og SRE-miljøer.
AZ-305 som målestokk for overgangen
Microsoft Certified: Azure Solutions Architect Expert er knyttet til eksamen AZ-305: Designing Microsoft Azure Infrastructure Solutions. Det finnes ingen formell forutgående eksamen som må tas først, men erfaring med Azure-administrasjon, nettverk, sikkerhet og drift gjør forberedelsene langt mer realistiske. Mange bruker derfor kunnskap tilsvarende Azure Administrator-nivå som et praktisk fundament før de går dypt inn i løsningsdesign.
AZ-305 bør forstås som en målestokk, ikke bare som en test. Eksamenen dekker designvalg på tvers av identitet, styring, overvåking, dataplattformer, kontinuitet og infrastruktur. For en utvikler er verdien at pensum tvinger frem et bredere perspektiv enn applikasjonskode alene. Det blir tydelig hvorfor valg av region, nettverkstopologi, tilgangsmodell, datalagring og gjenopprettingsstrategi må vurderes samlet.
En god læringsrekkefølge er å starte med Azure-grunnmuren: abonnementer, ressursgrupper, RBAC, Microsoft Entra ID, virtuelle nettverk, private endepunkter og overvåking. Deretter bør læringen flyttes mot designscenarier: hvordan en organisasjon etablerer landing zones, hvordan en kritisk applikasjon bør sikres, og hvordan migrering påvirker data, integrasjoner og drift. Readynez omtaler AZ-305 i en sertifiseringskontekst, men selve læringsarbeidet bør alltid kobles til reelle arkitekturvalg i egen organisasjon eller et realistisk øvingsmiljø.
Fordeler for utviklere og arbeidsgivere
For utvikleren kan rollen gi mer innflytelse på tekniske veivalg. I stedet for å komme sent inn i et prosjekt der viktige rammer allerede er bestemt, kan en arkitekt bidra tidligere når krav, risiko og driftsmodell fortsatt kan påvirkes. Det gir en annen type faglig ansvar enn ren implementering, og det kan være attraktivt for utviklere som liker systemtenkning, teknisk ledelse og samarbeid på tvers av fagmiljøer.
For arbeidsgivere er verdien ofte knyttet til bedre sammenheng mellom utvikling og plattform. Når arkitekturkompetanse ligger nær utviklingsmiljøet, blir det lettere å lage standarder som faktisk kan brukes. Det kan redusere dobbeltarbeid, gjøre kostnader mer synlige og gi sikrere løsninger fra starten. Særlig i virksomheter som bygger mye selv, er kombinasjonen av å kunne bygge og designe praktisk verdifull.
Norske stillingsannonser varierer i ordbruk, men mange etterspør nettopp denne kombinasjonen: praktisk teknologiforståelse, evne til å designe løsninger og evne til å samarbeide med sikkerhet, drift og ledelse. Det er sjelden nødvendig å kunne alle Azure-tjenester i detalj. Det som ofte skiller sterke kandidater, er evnen til å velge bort, standardisere og forklare konsekvensene av tekniske valg.
Vanlige fallgruver i overgangen
Den første fallgruven er å behandle arkitektur som et dokumentasjonsarbeid. Diagrammer og beslutningsnotater er nyttige, men de skaper lite verdi hvis de ikke påvirker hvordan løsningen faktisk bygges. Arkitektur må være koblet til backlogg, plattformmoduler, sikkerhetskrav, kostoppfølging og driftsrutiner.
Den andre fallgruven er å ignorere governance og kost tidlig i prosjektet. Azure gjør det enkelt å opprette ressurser, men uten policyer, tagging, budsjettvarsler og eierskap blir miljøer raskt uoversiktlige. Dette er særlig relevant i organisasjoner der flere team eksperimenterer parallelt, eller der skybruken har vokst frem uten en felles plattformmodell.
Den tredje fallgruven er å undervurdere driftsevne. En arkitektur som mangler tydelig logging, alarmer, backup, tilgangsstyring og gjenopprettingsplaner, vil ofte koste mer senere. Det er derfor BCDR, altså business continuity and disaster recovery, bør vurderes som en del av designet og ikke som en oppgave som overlates til drift etter produksjonssetting.
Hvordan starte uten å vente på en ny stillingstittel
Utviklere trenger ikke nødvendigvis vente på en formell arkitektrolle før de begynner å bygge relevant erfaring. Et praktisk første steg er å ta ansvar for en intern referansearkitektur for én applikasjonstype, for eksempel en webapplikasjon med API, database, identitet, logging og deployment-pipeline. Målet bør være å vise hvordan team kan bygge tryggere og mer forutsigbart, ikke å lage et stort prinsippdokument.
Et annet godt steg er å ta en kostvakt-rolle i et team eller produktområde. Det innebærer å følge med på forbruk, tagging, ressursstørrelser, skaleringsvalg og ubrukt kapasitet. Denne typen ansvar gjør arkitekturens effekt konkret, fordi den viser hvordan tekniske valg påvirker økonomi og drift over tid.
Deretter kan utvikleren gradvis bygge en portefølje av arkitekturarbeid: beslutningslogger, løsningsskisser, risikovurderinger, migreringsplaner og forbedringer i observability. Slike artefakter viser modenhet fordi de dokumenterer vurderinger, ikke bare løsninger. De gir også bedre grunnlag for samtaler med ledere, plattformteam og sikkerhetsansvarlige.
Ofte stilte spørsmål
Må man være utvikler for å bli Azure Solutions Architect?
Nei. Rollen kan også vokse ut av drift, nettverk, sikkerhet eller plattformarbeid. Utviklere har likevel et godt utgangspunkt fordi de forstår applikasjonslivssyklusen og konsekvensene av tekniske valg i kode, deployment og produksjon.
Er AZ-104 et krav før AZ-305?
Nei, AZ-104 er ikke et formelt krav for AZ-305. Kunnskap på Azure Administrator-nivå er likevel ofte nyttig, fordi arkitektureksamenen forutsetter at kandidaten forstår Azure-ressurser, identitet, nettverk, overvåking og drift i praksis.
Hvor teknisk må en Azure Solutions Architect være?
Rollen er teknisk, men den handler ikke om å kunne implementere alle detaljer alene. En god arkitekt må forstå nok til å ta gode designvalg, utfordre antakelser, samarbeide med spesialister og forklare konsekvensene av ulike alternativer.
Å gjøre arkitekturansvar konkret
Steget fra utvikler til Azure Solutions Architect er mest verdifullt når det kobles til reelle problemer: en migrering som trenger tydeligere rammer, en plattform som trenger standardisering, en løsning som mangler observability, eller et produktområde som trenger bedre kostkontroll. Sertifisering kan gi struktur og språk, men erfaringen bygges gjennom beslutninger som tåler møte med sikkerhet, drift, budsjett og brukere.
En praktisk vei videre er å bruke AZ-305 som kart, velge ett internt arkitekturproblem som øvingsarena og dokumentere beslutningene underveis. Readynez kan være relevant for utviklere som ønsker et strukturert sertifiseringsløp, men den viktigste gevinsten kommer når læringen omsettes til enklere, sikrere og mer driftbare Azure-løsninger. For a deeper dive, see beste-pmp-forberedende-kurs-din-guide-til-aa-bli-en-sertifisert-prosjektleder" data-autoinject="link_injection">Beste PMP-forberedende kurs: Din guide til å bli en sertifisert.
