- Utvecklaren börjar påverka lösningens riktning, inte bara implementationen.
- Arkitektrollen kräver tydligare beslut kring säkerhet, kostnad, drift och styrning.
- AZ-305 kan vara relevant när arbetet redan rör designval i Azure snarare än enbart kod.
En azure-fundamentals-hur-du-klarar-az-900-examen-och-oekar-din-karriaer" data-autoinject="link_injection">Azure Solutions Architect-roll innebär för många seniora utvecklare att kodbasen fortfarande är viktig, samtidigt som besluten flyttas till större frågor: vilken identitetsmodell ska användas, hur ska miljöer separeras, vilka beroenden är kritiska, och hur mycket driftkomplexitet är rimlig för teamet?
Rollen Azure Solutions Architect handlar om att designa Azure-lösningar som fungerar tekniskt, operativt och affärsmässigt. Den passar särskilt väl för utvecklare som redan samarbetar med DevOps, säkerhet, nätverk och produktägare, och som vill ta ansvar för de val som formar en plattform eller arbetslast över tid.
Från utvecklare till arkitekt: vad förändras i vardagen?
En utvecklare bedöms ofta på hur väl en funktion byggs, testas och levereras. En Azure Solutions Architect bedöms i högre grad på om hela lösningen kan bära verksamhetens krav över tid: tillgänglighet, säkerhet, skalbarhet, kostnad, dataskydd, observability och återställning vid fel. Skillnaden märks inte bara i möten, utan i hur beslut dokumenteras och motiveras.
Det vanligaste övergångsgapet är att fortsätta tänka i lokala implementationer när frågan egentligen kräver arkitekturtrade-offs. En containerplattform kan ge flexibilitet, men också mer driftansvar än en PaaS-tjänst. En snabb nätverkslösning kan få ett projekt över mållinjen, men skapa svag segmentering och svår governance i flera prenumerationer. En arkitekt behöver kunna säga varför ett alternativ väljs, vilka risker som accepteras och vilka kontroller som ska finnas på plats.
I praktiken innebär det att icke-funktionella krav måste behandlas lika konkret som funktionskrav. Svarstider, RTO och RPO, loggning, åtkomstmodeller, dataresidens inom EU, budgetgränser och kvotbegränsningar i regioner behöver komma in tidigt. När de frågorna skjuts upp blir Azure-projekt ofta dyrare att ändra, särskilt när identitet, nätverk och prenumerationsstruktur redan har etablerats.
Varför utvecklarbakgrunden är en fördel
Utvecklare har ofta en stark känsla för hur designbeslut påverkar teamets leveransförmåga. De förstår beroenden mellan tjänster, deployment-flöden, API-kontrakt, testbarhet och felhantering på ett sätt som gör arkitektur mer praktisk. Det är en viktig motvikt till arkitektur som ser bra ut i en presentation men blir svår att drifta i en verklig produktmiljö.
Den tekniska bredden behöver däremot kompletteras med styrning. Azure-arkitektur handlar sällan om en isolerad applikation. Den rör prenumerationsmodell, Microsoft Entra ID, rollbaserad åtkomst, nätverkszoner, private endpoints, policy-as-code, backup, övervakning och kostnadsstyrning. Därför blir arkitektens värde tydligt när utvecklingsteam, plattformsteam och säkerhetsfunktioner behöver en gemensam riktning.
Branschens rörelse mot plattformsengineering och GitOps förstärker detta. Arkitekter förväntas i många organisationer inte bara rita målbilden, utan bidra till återanvändbara mallar, pipelines, policyer och referensarkitekturer. Den som kan översätta en princip till Bicep- eller Terraform-moduler, Azure Policy och tydliga deployment-flöden får lättare att göra arkitekturen användbar för teamen.
När AZ-305 blir rätt steg
Certifieringen Azure Solutions Architect Expert är kopplad till provet AZ-305, Designing Microsoft Azure Infrastructure Solutions. Enligt Microsoft Learn täcker provet design av identitet, styrning och övervakning, datalagring, affärskontinuitet och infrastruktur. Det speglar många av de beslut som uppstår i Azure-projekt: landing zones, nätverk, backup och disaster recovery, lagringsval, behörighetsmodeller och övervakningsstrategier.
För en utvecklare som fortfarande främst vill fördjupa sig i att bygga Azure-applikationer kan Azure Developer Associate och AZ-204 ligga närmare vardagen. När arbetet däremot börjar handla om att välja lösningsmönster, väga PaaS mot containrar, definiera governance eller designa för flera miljöer är AZ-305 ofta mer relevant. Det finns inga formella förkunskapskrav för AZ-305, men praktisk Azure-erfarenhet gör innehållet betydligt mer meningsfullt.
Certifieringen bör ses som en struktur för att täcka bredden, inte som hela beviset på arkitektförmåga. Vid rekrytering och interna rollbyten värderas ofta demonstrerad förmåga högt: architecture decision records, referensarkitekturer, infrastructure-as-code-repon, Well-Architected-granskningar och tydliga kostnadsantaganden visar hur en kandidat tänker. Ett certifikat kan öppna samtalet, men konkreta artefakter gör resonemanget granskningsbart.
Ett Azure-beslut i praktiken
Anta att ett produktteam ska modernisera en kundportal som hanterar personuppgifter för användare inom EU. Teamet vill minska driftbördan, förbättra releaseflödet och uppfylla krav på säker åtkomst, loggning och återställning. Ett rent utvecklarperspektiv kan börja i ramverk, API-design och CI/CD. Ett arkitektperspektiv börjar bredare: identitet, nätverk, dataflöden, sekretess, driftsäkerhet och kostnadsprofil.
I ett sådant scenario kan Azure App Service eller Azure Container Apps vara mer ändamålsenligt än Azure Kubernetes Service om teamet saknar behov av avancerad klusterkontroll. AKS kan vara rätt vid komplex orkestrering, men det innebär också större ansvar för nätverk, patchning, observability och plattformsdrift. Om kravet är snabbare leverans med kontrollerad komplexitet kan en mer hanterad plattform ge bättre balans.
Databasen kan placeras i en region som stödjer organisationens krav på dataresidens, med private endpoint, begränsad nätverksexponering och central loggning. Azure Policy kan användas för att förhindra publika lagringskonton, kräva taggar för kostnadsuppföljning och styra vilka regioner som får användas. Budgetar och alerts bör skapas redan i sandlåda och testmiljö, eftersom kostnadsstyrning som införs efter produktionssättning ofta blir reaktiv.
Arkitektens beslut blir då inte bara ”vilken tjänst är modernast”, utan vilken kombination som uppfyller säkerhet, driftsäkerhet, kostnad och teamets faktiska kapacitet. Ett kort ADR-dokument kan beskriva varför en hanterad applikationsplattform valdes, varför AKS avvaktas, vilka risker som finns och vilka mätvärden som ska följas efter lansering. Det är den typen av dokumentation som gör arkitekturbeslut möjliga att granska och ändra.
En praktisk 60–90-dagars övergångsplan
En bra övergång till arkitektrollen bör blanda teori med konkret designarbete. Ren provläsning ger ofta för svag koppling till vardagen, medan enbart praktiskt arbete kan lämna luckor inom områden som affärskontinuitet, governance och lagringsdesign. Den mest robusta vägen är att välja en verklig eller realistisk arbetslast och granska den systematiskt.
Under de första veckorna bör fokus ligga på nulägesbild. Utvecklaren kan kartlägga en befintlig Azure-lösning: prenumerationer, resursgrupper, identiteter, nätverk, dataflöden, beroenden, backup, loggar och kostnader. Målet är inte att rita en perfekt målarkitektur, utan att förstå vilka designbeslut som redan har fattats och vilka som saknar tydlig motivering.
Nästa fas bör handla om att formulera beslut. Det kan innebära att skriva korta ADR:er för tre till fem arkitekturval, till exempel nätverkssegmentering, datalagring, autentisering, miljöstrategi och återställning. Varje ADR bör innehålla alternativ som förkastades, konsekvenser, antaganden och hur beslutet ska valideras. Här tränas den förmåga som skiljer arkitektur från allmän teknisk senioritet.
Mot slutet av perioden bör arbetet omsättas i repeterbara artefakter. En enkel landing zone i en sandlåda, byggd med Bicep eller Terraform, kan innehålla prenumerationsstruktur, policyer, budgetar, loggning och grundläggande nätverksmönster. Genom att lägga till alerts, återställningstest och en Well-Architected-inspirerad granskning blir träningen mer lik det ansvar en arkitekt faktiskt har.
Den som använder AZ-305 som ramverk kan samtidigt läsa mot provets områden och koppla varje område till den egna labbmiljön. Identitet och governance blir då inte ett abstrakt kapitel, utan konkreta beslut om åtkomst och policy. Affärskontinuitet blir inte en definition, utan testade backup- och återställningsantaganden. Readynez kan vara ett stöd för strukturerad AZ-305-förberedelse, men den praktiska portföljen bör byggas parallellt.
Färdigheter som gör skillnad i rollen
Den tekniska kärnan börjar med Azure-identitet, nätverk och governance. Många projekt får problem när dessa områden behandlas som efterhandsarbete, eftersom de påverkar nästan varje senare beslut. En arkitekt behöver förstå hur Microsoft Entra ID, RBAC, management groups, Azure Policy, hub-spoke-nätverk, private connectivity och central loggning samspelar.
Därefter kommer förmågan att designa för drift. Det innebär att välja rätt nivå av tillgänglighet, definiera backup och disaster recovery, förstå beroenden mellan regioner och tjänster, samt testa återställning innan produktion. Business impact analysis, kvoter och regionsbegränsningar låter administrativa, men de kan avgöra om en lösning går att återställa när den verkligen behöver fungera.
Kostnad är också en arkitekturfråga. FinOps börjar inte när fakturan blir hög, utan när lösningen designas. Rätt SKU, autoskalning, reservationsstrategi, loggnivå, datalagring och miljöpolicy påverkar kostnaden löpande. En utvecklare som kan koppla tekniska val till kostnadsdrivare får ett starkare beslutsunderlag i dialog med produktägare och ledning.
Att ta steget med rätt bevis på förmåga
Vägen mot Azure Solutions Architect är mest övertygande när den visar hur personen tänker under osäkerhet. En portfolio behöver inte vara stor, men den bör visa tydliga trade-offs: varför en tjänst valdes, hur risker hanterades, vilka kontroller som infördes och hur lösningen kan följas upp. Det är ofta mer användbart än att enbart beskriva vilka Azure-tjänster som har använts.
Den praktiska nästa åtgärden är att välja en arbetslast och behandla den som ett arkitekturuppdrag. Dokumentera nuläget, genomför en Well-Architected-granskning, skriv ADR:er, bygg en liten IaC-baserad miljö med policy och budget, och koppla sedan studierna för AZ-305 till de beslut som redan har testats. Readynez nämns bäst i det sammanhanget som ett möjligt stöd för att strukturera certifieringsdelen, medan den verkliga utvecklingen sker när teori, design och drift möts i samma arbetsyta.
