- Ontwikkelaars die architect willen worden, moeten leren ontwerpen voor identiteit, governance, kosten, betrouwbaarheid en compliance, niet alleen voor werkende code.
- De actuele Microsoft-route naar Azure Solutions Architect Expert draait om Exam AZ-305; AZ-104 is nuttige basiskennis, maar geen formele vereiste.
- In België wegen aantoonbare architectuurbeslissingen, sectorcontext en meertalige communicatie vaak zwaarder dan een certificaat op zichzelf.
Een Azure-oplossingsarchitect is de rol die bedrijfsdoelen, risico’s en technische beperkingen vertaalt naar een Azure-ontwerp dat teams veilig kunnen bouwen, beheren en verbeteren. Voor ontwikkelaars is die stap logisch, maar niet automatisch: de aandacht verschuift van componenten en user stories naar platformkeuzes, niet-functionele eisen, besluitvorming en verantwoording tegenover meerdere stakeholders.
Die verschuiving is vooral zichtbaar in organisaties die Azure gebruiken voor migraties, dataplatformen, applicatiemodernisering of AI-initiatieven. De architect moet kunnen uitleggen waarom een bepaalde identity-opzet, netwerksegmentatie, landing zone, monitoringaanpak of kostenmodel past bij de context. De beste voorbereiding bestaat daarom uit meer dan examenstof: ze combineert Azure-kennis met ontwerpdiscipline, communicatie en bewijs van goede trade-offs.
Waarom deze stap logisch is voor ervaren ontwikkelaars
Veel ontwikkelaars hebben al een deel van het architectuurwerk in handen voordat de functietitel verandert. Ze kiezen integratiepatronen, beoordelen technische schuld, ondersteunen CI/CD, bespreken schaalbaarheid en vertalen requirements naar implementaties. Wat ontbreekt, is vaak het bredere kader waarin die keuzes aantoonbaar aansluiten op security, operations, governance en kosten.
De stap naar Azure-oplossingsarchitect wordt interessant wanneer een ontwikkelaar niet alleen wil bouwen, maar ook wil bepalen welke technische richting haalbaar, veilig en onderhoudbaar is. Dat vraagt meer aandacht voor afhankelijkheden buiten de codebase: Entra ID-rollen, netwerkgrenzen, Azure Policy, monitoring, backup, disaster recovery, budgetbewaking en compliance-eisen. Een oplossing die lokaal elegant lijkt, kan op organisatieniveau problematisch zijn als ze geen rekening houdt met beheer, audit of schaalbaarheid.
In Belgische organisaties komt daar extra context bij. Banken, verzekeraars, overheidsinstellingen, gezondheidszorg, logistiek en industriële bedrijven werken vaak met strikte eisen rond gegevensbescherming, outsourcing, auditability en operationele continuïteit. GDPR is daarbij de basis, terwijl NIS2 in meer sectoren de aandacht verschuift naar risicobeheer, incidentrespons en toeleveringsketens. Meertaligheid is geen formele architectuurskill, maar in Belgische teams helpt het wanneer een architect technische keuzes helder kan uitleggen aan Nederlandstalige, Franstalige en Engelstalige stakeholders.
Wat de rol werkelijk inhoudt
Een Azure-oplossingsarchitect schrijft doorgaans minder productiecode dan een senior developer, maar moet code en infrastructuur nog steeds voldoende begrijpen om haalbare ontwerpen te maken. De rol zit tussen business, development, platform engineering, security, operations en soms procurement. Daardoor is de kwaliteit van vragen vaak belangrijker dan de snelheid waarmee iemand een service kan selecteren.
Een architect onderzoekt bijvoorbeeld of een workload geschikt is voor App Service, Azure Kubernetes Service, Functions of een hybride patroon. Die keuze hangt niet alleen af van technische voorkeur, maar ook van deploymentcomplexiteit, teamvaardigheden, netwerkvereisten, observability, schaalgedrag, licentiekosten en supportmodel. Microsoft Learn behandelt in dit verband onderwerpen zoals Azure Well-Architected Framework, Azure Landing Zones en de domeinen van Exam AZ-305; die bronnen zijn nuttig omdat ze ontwerpkeuzes koppelen aan terugkerende kwaliteitscriteria.
De hiringrealiteit is daarbij nuchter. Een certificaat helpt om kennis te structureren en zichtbaarheid te geven, maar werkgevers zoeken vaak bewijs dat iemand architecturale beslissingen kan nemen en verdedigen. Voorbeelden zijn architecture decision records, referentiearchitecturen, migratievoorstellen, cost estimates, risicoanalyses en presentaties waarin alternatieven worden afgewogen. Wie vanuit development wil doorgroeien, doet er goed aan die artefacten bewust op te bouwen voordat de officiële titel op het cv verschijnt.
De actuele certificeringsroute: AZ-305 en de rol van AZ-104
Update: januari 2026. De vroegere AZ-303- en AZ-304-examens zijn vervangen. De huidige route naar Microsoft Certified: Azure Solutions Architect Expert loopt via Exam AZ-305: Design Azure Infrastructure Solutions. Een associate-certificaat zoals Azure Administrator Associate, gekoppeld aan AZ-104, is aanbevolen voor wie beheerfundamenten wil versterken, maar het is geen formele vereiste om AZ-305 af te leggen.
Dat onderscheid is belangrijk voor ontwikkelaars. Wie dagelijks met Azure resources, networking, identity en operations werkt, kan mogelijk rechtstreeks richting AZ-305 studeren. Wie vooral applicatiecode schrijft en weinig ervaring heeft met Azure-beheer, mist vaak de praktische basis rond subscriptions, RBAC, virtual networks, monitoring en governance. In dat geval is AZ-104-kennis een verstandige tussenstap, zelfs wanneer het examen zelf niet het einddoel is.
AZ-305 toetst ontwerpvaardigheid. De examendomeinen draaien rond identity, governance, monitoring, data storage, business continuity en infrastructuurontwerp. De vragen gaan niet alleen over welke service bestaat, maar over welke combinatie van services past bij requirements, beperkingen en risico’s. Een gestructureerde opleiding zoals Readynez AZ-305 training kan daarbij helpen wanneer theorie, scenario’s en examengerichte oefening samen moeten komen, maar de officiële Microsoft Learn-examenpagina blijft de bron voor actuele examendetails.
De grootste valkuil: services kiezen vóór de architectuurvragen duidelijk zijn
Ontwikkelaars die de overstap maken, focussen soms te snel op Azure-services: welke database, welk computeplatform, welke messagingoptie. Dat is begrijpelijk, omdat developers gewend zijn problemen concreet te maken. In architectuur leidt die volgorde echter geregeld tot herwerk, vooral wanneer identiteit, governance, netwerksegmentatie, kosten en compliance pas later besproken worden.
Een landing zone is hier een goed voorbeeld. Zonder vooraf bepaalde subscriptionstructuur, naming, RBAC, policy, logging, netwerkconnectiviteit en securitybaselines kan een migratie technisch starten, maar later vastlopen op audit, beheer of kostenallocatie. Platform engineering op Azure versterkt die trend: architecten ontwerpen steeds vaker guardrails waarmee teams zelfstandig kunnen leveren binnen afgesproken grenzen. Infrastructure as Code, policy-as-code, golden paths en self-service deployment zijn dan geen randzaken, maar onderdeel van het productdenken rond het platform.
Voor AI- en dataprojecten komt daar een extra laag bij. Bij diensten zoals Azure OpenAI en data-analyseplatformen moeten beslissingen over dataresidentie, netwerkisolatie, privileged access, logging en DLP vroeg in het ontwerp genomen worden. Een proof of concept zonder governance kan nuttig zijn om waarde te testen, maar is zelden voldoende als basis voor productie in een gereguleerde omgeving.
Praktijkcase: een migratiebeslissing vanuit architectuurdenken
Consider een Belgisch softwareteam dat een bestaande .NET-applicatie naar Azure wil migreren. De developer ziet al snel een technisch pad: containeriseren, deployen, database koppelen en CI/CD aanpassen. De architect stelt eerst andere vragen: welke data is gevoelig, welke afhankelijkheden blijven on-premises, welke beschikbaarheid is vereist, wie beheert secrets, hoe wordt logging gecentraliseerd en welk kostenprofiel is aanvaardbaar na de migratie?
In een eerste ontwerp zou Azure App Service voldoende kunnen zijn als het team eenvoudige deployment, ingebouwde schaalopties en beperkte platformcomplexiteit wil. AKS kan logisch worden wanneer er meerdere containerized workloads zijn, specifieke netwerkvereisten gelden of een platformteam Kubernetes als standaard aanbiedt. Azure SQL Managed Instance kan aantrekkelijk zijn voor compatibiliteit bij databasemigratie, terwijl Azure SQL Database eenvoudiger beheer kan bieden wanneer de applicatie minder afhankelijk is van instance-level functies.
De architect legt die afweging vast in een architecture decision record. Zo’n ADR beschrijft de context, de opties, de gekozen richting, de gevolgen en de open risico’s. Een kort voorbeeld: “Kies App Service voor de eerste migratiefase omdat het team beperkte Kubernetes-ervaring heeft, de workload voorspelbaar schaalt en operationele eenvoud zwaarder weegt dan clusterflexibiliteit. Herbekijk AKS wanneer meerdere services dezelfde runtime- en netwerkvereisten delen.” Dit soort bewijs is waardevol in sollicitaties en interne promoties omdat het laat zien hoe iemand tot een besluit komt.
Een realistisch 90-dagenplan voor de overgang
Een ontwikkelaar hoeft niet te wachten op een nieuwe functietitel om architectuurervaring op te bouwen. Een praktisch traject van negentig dagen kan genoeg zijn om hiaten zichtbaar te maken, gericht te oefenen en tastbaar bewijs te verzamelen. Het doel is niet om alle Azure-services uit het hoofd te kennen, maar om betrouwbaarder te worden in het ontwerpen, uitleggen en verdedigen van keuzes.
- Maand 1: versterk fundamenten rond Entra ID, RBAC, subscriptions, virtual networks, monitoring en Azure governance.
- Maand 2: ontwerp voor resilience, backup, disaster recovery, kostenbewaking, compliance en operationele overdracht.
- Maand 3: bouw een kleine referentiecase, schrijf drie ADR’s, laat het ontwerp reviewen en bereid interviewverhalen voor.
Die drie maanden worden sterker wanneer de ontwikkelaar een architect shadowt tijdens refinements, design reviews of architecture boards. Het observeren van vragen, bezwaren en compromissen is vaak leerzamer dan het bestuderen van servicevergelijkingen alleen. Daarnaast is het zinvol om voor een sandboxontwerp een kostenraming te maken met de Azure Pricing Calculator en expliciet te noteren welke aannames het bedrag beïnvloeden.
De drie ADR’s hoeven geen grote documenten te zijn. Eén kan gaan over identity en access management, één over hostingkeuze en één over dataopslag of business continuity. Belangrijk is dat elke beslissing een alternatief benoemt en uitlegt waarom een optie in de gegeven context beter past. Dat traint precies de denkstijl die in AZ-305-scenario’s, architectuurgesprekken en klantbesprekingen terugkomt.
Salaris en carrièrewaarde in Belgische context
De oorspronkelijke belofte rond salaris moet voorzichtig gelezen worden. Internationale bronnen zoals ZipRecruiter-salarisdata voor Azure Architect-rollen kunnen een indicatie geven van de marktwaarde in de Verenigde Staten, maar ze zijn niet rechtstreeks vertaalbaar naar Belgische loonpakketten. In België spelen statuut, sector, regio, anciënniteit, consultancy versus interne rol, extralegale voordelen en taalvereisten een grote rol.
De carrièrewaarde van de stap ligt daarom niet uitsluitend in brutoloon. Azure-oplossingsarchitecten krijgen vaker invloed op platformkeuzes, roadmapbeslissingen, securityprioriteiten en cloud governance. Voor sommige ontwikkelaars is dat aantrekkelijk omdat de rol dichter bij strategische besluitvorming staat. Voor anderen kan het nadeel zijn dat er minder tijd overblijft voor hands-on coding. Die afweging hoort bewust gemaakt te worden voordat iemand de stap zet.
Wanneer een ontwikkelaar klaar is voor de stap
Een goede indicator is niet het aantal jaren ervaring, maar de kwaliteit van technische besluitvorming. Een ontwikkelaar is dichter bij een architectenrol wanneer die kan uitleggen welke trade-offs horen bij schaalbaarheid, latency, security, beheerbaarheid en kosten. Ook het vermogen om onzekerheid zichtbaar te maken is belangrijk: een architect hoeft niet elk antwoord onmiddellijk te kennen, maar moet wel weten welke risico’s onderzocht moeten worden voordat een ontwerp productie raakt.
Hiring managers letten vaak op signalen die in gewone developerprofielen minder expliciet zijn. Kan de kandidaat praten met security zonder defensief te worden? Kan die een oplossing vereenvoudigen in plaats van complexer maken? Kan die een keuze documenteren zodat een ander team ze later begrijpt? Kan die een ontwerp aanpassen wanneer budget, compliance of operationele capaciteit verandert? Zulke vragen maken het verschil tussen technische senioriteit en architecturale volwassenheid.
De stap verstandig zetten
De overstap van ontwikkelaar naar Azure-oplossingsarchitect is geen breuk met development, maar een verbreding van verantwoordelijkheid. De technische basis blijft belangrijk, terwijl de waarde steeds meer komt uit het verbinden van requirements, risico’s, platformkeuzes en menselijke samenwerking. In België vraagt dat extra aandacht voor sectorregels, meertalige afstemming en aantoonbare besluitvorming.
Een praktisch vertrekpunt is om één echte of realistische Azure-case uit te werken alsof die naar een architecture board moet. Leg de requirements vast, maak een referentieontwerp, bereken kosten op basis van aannames, schrijf ADR’s en toets het ontwerp aan Microsoft Well-Architected-principes. Wie daarna AZ-305 wil voorbereiden in een begeleide setting, kan de bestaande Readynez-training voor Microsoft Certified Azure Solutions Architect gebruiken naast Microsoft Learn en praktijkervaring.
