Van Systems Engineer naar Infrastructure Architect: wanneer verandert je manier van denken?

Een goede Systems Engineer kent zijn infrastructuur. Hij weet hoe servers werken, hoe netwerken zijn opgebouwd, waar problemen ontstaan en hoe ze opgelost moeten worden. Hij zorgt ervoor dat gebruikers kunnen werken en dat systemen beschikbaar blijven.

Toch komt er in een technische carrière vaak een moment waarop een andere vraag belangrijk wordt:

Wil ik vooral de infrastructuur beheren, of wil ik mee bepalen welke infrastructuur een bedrijf nodig heeft?

Voor mij ligt daar het verschil tussen een Systems Engineer en een Infrastructure Architect.

De ervaring van een goede Systems Engineer of Systems Administrator vormt een sterke basis voor architectuurwerk. De technische kennis moet daarvoor worden aangevuld met inzicht in bedrijfsprocessen, bedrijfsdoelstellingen, projecten, risico’s, communicatie, documentatie en kosten.

De stap naar Infrastructure Architect is daardoor vooral een verandering in manier van denken.

Wat is het verschil tussen een Systems Engineer en een Infrastructure Architect?

Een Systems Engineer richt zich in belangrijke mate op de werking van technologie.

Een Infrastructure Architect kijkt naar de vraag waarom die technologie nodig is, welke bedrijfsfunctie ze ondersteunt en welke gevolgen een technische keuze heeft.

Een Systems Engineer kan bijvoorbeeld de vraag krijgen:

“Hoe kunnen we deze server vervangen?”

Een Infrastructure Architect stelt eerst andere vragen:

“Waarom hebben we deze server nodig?”

“Welke bedrijfsfunctie ondersteunt deze server?”

“Welke eisen stelt die functie aan beschikbaarheid, beveiliging en prestaties?”

“Welke alternatieven zijn er?”

“Wat betekent elke keuze voor beheer, risico en kosten?”

Misschien moet de server inderdaad worden vervangen.

Misschien kan de applicatie naar een cloudplatform.

Misschien kan de applicatie worden geconsolideerd.

Misschien is de applicatie zelf verouderd en moet eerst worden onderzocht of ze nog past binnen de bedrijfsstrategie.

De architect kijkt daardoor verder dan het technische component.

Systems Engineer: de technische basis

Een Systems Engineer werkt dicht bij de technologie.

Servers moeten functioneren. Netwerken moeten beschikbaar zijn. Storage moet voldoende capaciteit en prestaties leveren. Back-ups moeten werken. Gebruikers moeten toegang krijgen tot hun applicaties en gegevens.

Dat werk vraagt technische kennis en probleemoplossend vermogen.

Je leert bovendien iets wat moeilijk uit boeken te halen is: hoe een IT-omgeving zich in de praktijk gedraagt.

Een theoretisch ontwerp kan er perfect uitzien. De praktijk kan ondertussen bestaan uit oude servers, uitzonderingen, historische configuraties, applicaties met specifieke afhankelijkheden en gebruikers die anders werken dan oorspronkelijk was voorzien.

Die praktijkervaring is bijzonder waardevol.

Een Systems Engineer die jarenlang infrastructuur beheert, ontwikkelt daardoor inzicht in wat technisch haalbaar is en waar ontwerpen in de praktijk kunnen mislopen.

Dat vormt een stevige basis voor architectuurwerk.

De stap naar architectuur begint bij de business

De grootste verandering richting Infrastructure Architect zit voor mij niet in een nieuwe technologie.

Ze zit in de vraag die je stelt.

Een architect moet eerst begrijpen welke bedrijfsfunctie door de technologie wordt ondersteund.

Daarvoor moet je weten:

• welke processen bedrijfskritisch zijn;
• waar omzet wordt gegenereerd;
• welke systemen medewerkers nodig hebben;
• welke applicaties tijdelijk mogen uitvallen;
• welke gegevens kritisch zijn;
• welke wettelijke of contractuele verplichtingen gelden;
• welke groei de organisatie verwacht.

Zonder die informatie blijft infrastructuurarchitectuur vooral een technische oefening.

Een server, firewall, storageplatform of cloudomgeving heeft voor een bedrijf immers geen waarde op zichzelf. De waarde ontstaat doordat die technologie een bedrijfsproces ondersteunt.

Van technologie naar bedrijfsprocessen

Een Infrastructure Architect moet daarom begrijpen hoe een organisatie werkt.

Stel dat een productiebedrijf een bepaalde applicatie gebruikt voor een essentieel productieproces.

De technische vraag kan zijn:

“Welke server hebben we nodig?”

De architectuurvraag wordt:

“Welke beschikbaarheid heeft dit productieproces nodig en welke infrastructuur past daarbij?”

Dat leidt tot andere keuzes.

Misschien is hoge beschikbaarheid noodzakelijk. Misschien volstaat een goede back-up met een herstelprocedure. Misschien is de applicatie zelf de grootste afhankelijkheid. Misschien vormt de netwerkverbinding een groter risico dan de server.

De technische oplossing volgt uit de bedrijfsvereisten.

Dat is voor mij een belangrijk verschil tussen technisch beheer en architectuur.

Documentatie wordt onderdeel van architectuur

Een technische specialist kan veel kennis in zijn hoofd hebben.

Voor een architect wordt documentatie veel belangrijker.

Architectuurbeslissingen moeten uitlegbaar zijn. Andere mensen moeten kunnen begrijpen waarom een bepaalde technologie werd gekozen. Een beheerder moet kunnen achterhalen hoe een omgeving is opgebouwd. Een projectteam moet weten welke afhankelijkheden bestaan.

Documentatie is daarom onderdeel van architectuur.

Een infrastructuur die alleen begrijpelijk is voor degene die ze heeft gebouwd, vormt een bedrijfsrisico.

Wanneer die persoon vertrekt, ziek wordt of tijdelijk niet beschikbaar is, verdwijnt een deel van de kennis uit de organisatie.

Goede documentatie maakt technische kennis overdraagbaar.

Projecten veranderen je perspectief

Projectwerk dwingt je bovendien om verder te kijken dan één technische handeling.

Een Systems Engineer kan uitstekend zijn in het oplossen van een technisch probleem. Een Infrastructure Architect moet daarnaast rekening houden met planning, afhankelijkheden, risico’s, impact en communicatie.

Neem een cloudmigratie.

Technisch kan het kopiëren van bestanden naar een cloudplatform relatief eenvoudig lijken. Tijdens een migratie moet je echter ook rekening houden met bestandsnamen, paden, toegangsrechten, synchronisatie, wijzigingen in brondata en de gekozen migratiemethode.

Bij een concrete migratie naar SharePoint moesten bestands- en foldernamen eerst geschikt worden gemaakt voor Microsoft 365. Microsoft documenteert hiervoor onder andere beperkingen op bepaalde tekens en een maximale lengte van 400 tekens voor het volledige gedecodeerde bestandspad.

Ook wijzigingen in de brondata tijdens een migratie kunnen gevolgen hebben voor het migratieproces. Microsoft beschrijft bijvoorbeeld hoe incrementele migraties omgaan met gewijzigde, verplaatste en hernoemde bestanden.

Dat is architectuurdenken.

Je kijkt naar de volledige keten en niet alleen naar de technische handeling.

Een Infrastructure Architect denkt in gevolgen

Elke infrastructuurbeslissing heeft gevolgen.

Een keuze voor een bepaalde servertechnologie heeft gevolgen voor:

• licenties;
• beheer;
• hardware;
• back-up;
• monitoring;
• beveiliging;
• toekomstige migraties.

Een keuze voor cloud heeft gevolgen voor:

• maandelijkse kosten;
• afhankelijkheid van een leverancier;
• beveiliging;
• netwerkverbindingen;
• beheer;
• schaalbaarheid.

Een keuze voor standaardisatie kan het aantal technologieën verminderen. Daardoor kan ook de beheerlast veranderen.

Dat betekent dat een architect niet alleen vraagt of iets technisch mogelijk is.

De relevante vraag is:

“Wat zijn de gevolgen van deze keuze over de volledige levensduur van de oplossing?”

Daarbij horen bedrijfsstrategie, continuïteit, efficiëntie, beveiliging en Total Cost of Ownership.

Wanneer ontstaat architectuurdenken?

Er komt vaak een moment in de carrière waarop een Systems Engineer tijdens een probleem niet meer alleen denkt:

“Hoe los ik dit op?”

Maar ook:

“Waarom hebben we dit eigenlijk zo gebouwd?”

Dat is een belangrijk kantelpunt.

Je begint patronen te herkennen.

Je ziet terugkerende incidenten die door een bepaalde architectuurkeuze worden veroorzaakt. Je merkt dat verschillende systemen hetzelfde probleem op verschillende manieren oplossen. Je ziet dat een organisatie meerdere technologieën gebruikt voor een functie waarvoor misschien één standaard zou kunnen volstaan.

Daar ontstaat architectuurdenken.

Je verschuift van het oplossen van individuele problemen naar het onderzoeken van de oorzaak achter terugkerende problemen.

Automatisering is een belangrijke stap

Wie voortdurend dezelfde handeling uitvoert, moet zich afvragen waarom die handeling steeds opnieuw nodig is.

Een eenvoudige vraag kan veel opleveren:

“Waarom doe ik dit iedere week opnieuw?”

Misschien kan een script de taak uitvoeren.

Misschien is een configuratiestandaard mogelijk.

Misschien kan monitoring een probleem eerder signaleren.

Misschien moet het proces zelf worden aangepast.

Automatisering is daardoor niet alleen een technische oefening. Het kan ook een manier zijn om terugkerend werk zichtbaar te maken.

Een Infrastructure Architect moet daarom niet alleen weten hoe een handeling technisch kan worden uitgevoerd. Hij moet ook beoordelen welke werkzaamheden structureel nodig zijn en welke anders georganiseerd kunnen worden.

Kosten horen bij architectuur

Een architect die alleen naar technische kwaliteit kijkt, neemt maar een deel van de beslissing.

Een oplossing moet passen bij de financiële realiteit van de organisatie.

Daarbij kunnen onder meer deze kosten relevant zijn:

• aankoop;
• licenties;
• onderhoud;
• beheer;
• hardware en energie;
• personeelsinzet;
• beveiliging;
• back-up;
• schaalbaarheid;
• toekomstige migraties.

Serverconsolidatie is daar een voorbeeld van. Wanneer verschillende servers vergelijkbare functies of capaciteit leveren, kan standaardisatie mogelijk leiden tot een eenvoudiger infrastructuur.

De goedkoopste aankoopprijs vertelt daarbij weinig over de volledige kost.

De relevante vraag is:

“Welke oplossing geeft het bedrijf over de volledige levensduur de beste verhouding tussen risico, functionaliteit, beheer en kosten?”

Dat is een architectuurvraag.

De architect wordt een gesprekspartner van het management

Dit is misschien de grootste verandering in het groeitraject.

Een Systems Engineer praat voornamelijk over systemen.

Een Infrastructure Architect moet kunnen praten over bedrijfsimpact.

Een directie hoeft niet te weten hoeveel IOPS een storageplatform levert. Ze moet begrijpen wat er gebeurt wanneer een bedrijfskritische applicatie vier uur niet beschikbaar is.

Een CEO hoeft niet te weten hoe een VLAN technisch wordt geconfigureerd. Die persoon moet begrijpen waarom netwerksegmentatie relevant kan zijn voor beveiliging en continuïteit.

Een financieel verantwoordelijke hoeft niet alle technische details van een cloudplatform te kennen. Die persoon moet kunnen begrijpen waarom de maandelijkse kosten veranderen en welke technische keuzes daaraan ten grondslag liggen.

Dat vraagt communicatie.

Voor een architect is communicatie daarom onderdeel van het technische vak.

Niet iedere Systems Engineer moet architect worden

Het groeitraject naar Infrastructure Architect is geen verplichte promotie.

Sommige IT-professionals halen veel voldoening uit technisch beheer, troubleshooting en diepgaande specialisatie.

Dat is waardevol.

Een goede Systems Engineer kan bovendien technisch sterker zijn dan een Infrastructure Architect binnen een specifiek domein.

Architectuur vraagt een ander interessegebied.

Je moet nieuwsgierig zijn naar bedrijfsprocessen, financiële gevolgen, risico’s, projecten en de toekomstige ontwikkeling van een organisatie.

Mijn visie is dat technische kennis de fundering vormt. De architectuurrol ontstaat wanneer die kennis wordt verbonden met de bedrijfsstrategie.

Een mogelijk groeimodel

Ik zie het groeitraject ongeveer als volgt.

Systems Administrator

Je zorgt dat systemen werken.

Je beheert systemen, voert wijzigingen uit en lost dagelijkse problemen op.

Systems Engineer

Je begrijpt hoe systemen samenwerken en lost complexe technische problemen op.

Je kijkt verder dan één systeem en begrijpt afhankelijkheden tussen servers, netwerken, storage, applicaties en gebruikers.

Infrastructure Architect

Je bepaalt welke infrastructuur het bedrijf nodig heeft, waarom die nodig is en welke gevolgen de keuzes hebben.

Je verbindt technologie met bedrijfsprocessen, risico’s, kosten en strategie.

Infrastructure Manager

Je neemt verantwoordelijkheid voor mensen, processen, leveranciers, budgetten en de verdere ontwikkeling van de infrastructuur.

De rol verschuift daarmee verder richting organisatorische verantwoordelijkheid.

Deze functies zijn geen strikt afgebakende niveaus. In kleinere organisaties kunnen meerdere verantwoordelijkheden bij één persoon liggen.

De echte stap zit in je manier van denken

Voor mij is de overgang van Systems Engineer naar Infrastructure Architect daarom vooral een verandering in perspectief.

Je gaat van systemen naar bedrijfsprocessen.

Van incidenten naar structurele oplossingen.

Van uitvoeren naar ontwerpen.

Van technologie naar bedrijfsimpact.

Van individuele componenten naar het volledige ecosysteem.

En vooral: je leert technische beslissingen beoordelen vanuit de vraag wat ze betekenen voor het bedrijf.

Dat is precies het soort architectuuradvies dat voor een groeiende KMO waardevol wordt wanneer technologiekeuzes te belangrijk, complex of risicovol worden om uitsluitend vanuit operationeel IT-beheer te bekijken.

Een goede Infrastructure Architect blijft daarom technisch nieuwsgierig.

Maar hij kijkt ondertussen verder dan de server, firewall, cloudomgeving of applicatie.

Hij probeert te begrijpen waarom het bedrijf die technologie nodig heeft, welk probleem ermee moet worden opgelost en wat de beslissing op langere termijn betekent.