Van Systems Engineer naar Infrastructure Architect: leren denken vanuit de onderneming

Een server vervangen, een netwerk uitbreiden of een cloudmigratie uitvoeren. Voor een ervaren Systems Engineer zijn het vertrouwde opdrachten. Je onderzoekt de bestaande omgeving, bepaalt wat nodig is en zorgt ervoor dat de technische uitvoering correct verloopt.

Maar zodra je meer verantwoordelijkheid krijgt voor IT-beslissingen, verandert de vraag waarmee je begint.

Welke bedrijfsbehoefte moet deze infrastructuurinvestering invullen, en welke oplossing past daar het best bij?

Die vraag vormt voor mij een belangrijk onderdeel van de ontwikkeling van Systems Engineer naar Infrastructure Architect. Technische kennis blijft de basis. De volgende stap bestaat erin die kennis te gebruiken om de gevolgen van IT-beslissingen voor de onderneming te beoordelen.

Je kijkt naar de bedrijfsprocessen die van technologie afhankelijk zijn, de risico’s bij uitval, de kosten over de volledige levensduur en de inspanningen die nodig zijn om een omgeving te beheren.

Dat vraagt een bredere manier van denken. Je ontwerpt niet alleen een technische oplossing. Je helpt de onderneming bepalen welke oplossing verantwoord is.

Technische expertise blijft de basis

Een ervaren Systems Engineer begrijpt hoe servers, netwerken, opslag, besturingssystemen en applicaties samenwerken. Die kennis is nodig om storingen te onderzoeken, capaciteitsproblemen te herkennen en wijzigingen gecontroleerd uit te voeren.

Veel van die expertise ontstaat in de praktijk.

Een netwerkdiagram toont bijvoorbeeld hoe verbindingen volgens het ontwerp zouden moeten werken. De werkelijke omgeving kan ondertussen bestaan uit historische configuraties, tijdelijke oplossingen, verouderde apparatuur en applicaties met onverwachte afhankelijkheden.

Wie verantwoordelijk is voor het beheer, leert rekening te houden met die realiteit.

Die ervaring is bijzonder waardevol bij architectuurwerk. Je weet dat een wijziging aan één component gevolgen kan hebben voor andere systemen. Je begrijpt ook waarom een technisch correcte configuratie in de praktijk toch problemen kan veroorzaken.

Als Infrastructure Architect gebruik je die kennis om verder te kijken dan de afzonderlijke componenten. Je onderzoekt hoe de volledige omgeving functioneert en welke gevolgen een ontwerpkeuze heeft voor het beheer, de beveiliging en de continuïteit.

De technische basis blijft dus essentieel. Ze krijgt een bredere toepassing.

Begin bij het bedrijfsprobleem

Stel dat een onderneming een verouderde fysieke server wil vervangen. Op die server draait een applicatie waarop verschillende medewerkers dagelijks vertrouwen.

De technische analyse bepaalt hoeveel processorcapaciteit, geheugen en opslag nodig zijn. Daarmee ken je een deel van de vereisten, maar nog niet de volledige oplossing.

Je moet ook weten hoe belangrijk de applicatie is voor de onderneming.

Wat gebeurt er als de toepassing een halve dag niet beschikbaar is? Welke gegevens verwerkt ze? Zijn andere systemen ervan afhankelijk? Hoe lang moet de applicatie nog worden gebruikt? Wie is verantwoordelijk voor het onderhoud?

De antwoorden bepalen mee welke architectuur geschikt is.

Een nieuwe fysieke server kan de juiste keuze zijn. Virtualisatie kan interessant zijn wanneer verschillende toepassingen efficiënt op dezelfde infrastructuur kunnen draaien. Een cloudplatform kan geschikt zijn als de applicatie en haar afhankelijkheden dat toelaten en de kosten aanvaardbaar blijven.

Ook de vervanging van de applicatie zelf verdient soms onderzoek.

Als je uitsluitend naar de bestaande server kijkt, ligt een technische vervanging voor de hand. Zodra je de bedrijfsbehoefte onderzoekt, komen andere mogelijkheden in beeld.

De bedrijfsvereisten bepalen de criteria waarmee je technische oplossingen vergelijkt.

Dat betekent niet dat iedere infrastructuurvraag een groot strategisch project moet worden. De diepgang van de analyse moet aansluiten bij de impact, de complexiteit en de risico’s van de beslissing.

Beschikbaarheid afstemmen op de bedrijfsimpact

Hoge beschikbaarheid is een goed voorbeeld van de relatie tussen infrastructuur en bedrijfsvoering.

Een onderneming kan vragen om een omgeving die altijd beschikbaar is. Als architect moet je onderzoeken wat die eis concreet betekent. Welke onderbreking kan de organisatie aanvaarden? Hoe snel moeten diensten na een storing herstellen? Hoeveel wil de onderneming investeren om het risico op uitval te beperken?

Daarbij moet je drie begrippen uit elkaar houden.

Hoge beschikbaarheid (High Availability) gebruikt technische maatregelen om de impact van bepaalde storingen te beperken en diensten beschikbaar te houden of snel over te nemen.

Back-up maakt het mogelijk gegevens te herstellen na verlies, beschadiging of ongewenste wijzigingen. De bruikbaarheid hangt onder meer af van de kwaliteit van de back-ups en de mogelijkheid om ze daadwerkelijk terug te zetten.

Disaster recovery beschrijft hoe IT-diensten na een ernstige verstoring opnieuw beschikbaar worden gemaakt.

Deze maatregelen vullen elkaar aan, maar beantwoorden verschillende behoeften.

Een onderneming die administratieve software gebruikt, kan andere hersteldoelstellingen hebben dan een productiebedrijf waarvan de werking rechtstreeks afhankelijk is van een specifieke toepassing. Ook binnen dezelfde organisatie kunnen de vereisten sterk verschillen.

Daarom onderzoek ik eerst welke bedrijfsprocessen door een storing worden geraakt. Vervolgens kunnen de gewenste hersteltijd, het maximaal aanvaardbare gegevensverlies en de benodigde technische maatregelen worden bepaald.

Twee begrippen helpen daarbij: Recovery Time Objective (RTO), de beoogde maximale tijd om een dienst te herstellen, en Recovery Point Objective (RPO), het beoogde maximale verlies van gegevens uitgedrukt in tijd.

Die doelstellingen moeten aansluiten bij de werkelijke bedrijfsbehoefte en bij het beschikbare budget.

Een architect moet de gemaakte keuzes kunnen uitleggen aan zowel de technische verantwoordelijke als de bedrijfsleiding.

Ontwerp voor de volledige levenscyclus

Een infrastructuuroplossing moet gedurende haar volledige levensduur bruikbaar, beheersbaar en betaalbaar blijven. De aankoop en implementatie vormen slechts een deel van het werk.

Neem een migratie naar de cloud of naar Microsoft 365. De technische overdracht kan correct verlopen, terwijl de onderneming daarna te maken krijgt met onverwachte beheerkosten, gewijzigde toegangsrechten of extra werk voor medewerkers.

Daarom beoordeel je een migratie vanuit de volledige levenscyclus.

Bij een migratie van een bestandsserver naar SharePoint Online zijn bijvoorbeeld de bestaande mappenstructuur, toegangsrechten, synchronisatiebehoeften en afhankelijkheden tussen applicaties relevant. Ook de manier waarop medewerkers samenwerken, kan invloed hebben op het ontwerp.

Na de migratie blijven vragen bestaan.

Wie beheert de omgeving? Hoe worden toegangsrechten gecontroleerd? Welke back-upvoorziening is nodig? Hoe worden wijzigingen opgevolgd? Welke terugkerende kosten ontstaan? Hoe kan de onderneming haar gegevens exporteren of naar een andere oplossing verplaatsen?

Dezelfde redenering geldt voor lokale infrastructuur, virtualisatie en open-sourcesoftware.

Een oplossing kan technisch geschikt zijn en toch moeilijk te beheren worden wanneer ze gespecialiseerde kennis vereist die intern onvoldoende beschikbaar is. Ook ontbrekende documentatie of een sterke afhankelijkheid van één leverancier kan de toekomstige werking beïnvloeden.

Als architect beoordeel je daarom niet alleen of een oplossing vandaag werkt. Je onderzoekt ook wat nodig is om ze gedurende haar levensduur te onderhouden, te beveiligen en waar nodig aan te passen.

Documentatie beperkt operationele risico’s

In veel IT-omgevingen zit belangrijke kennis verspreid over configuraties, tickets, documenten en de ervaring van individuele medewerkers.

Dat wordt een risico wanneer slechts één persoon weet waarom een firewallregel bestaat, welke toepassing van een databaseserver afhankelijk is of hoe een bepaalde integratie functioneert.

Wanneer die kennis niet beschikbaar is, kunnen eenvoudige wijzigingen onverwacht complex worden. Ook een overdracht naar een collega of externe dienstverlener vraagt dan meer tijd.

Goede architectuurdocumentatie beschrijft daarom meer dan IP-adressen en servernamen.

Ze legt onder andere vast:

• Welke functie een systeem vervult en welke bedrijfsprocessen ervan afhankelijk zijn.
• Hoe infrastructuurcomponenten en applicaties met elkaar verbonden zijn.
• Welke ontwerpkeuzes zijn gemaakt en waarom.
• Hoe back-up, herstel, beveiliging en toegangsbeheer zijn geregeld.
• Wie verantwoordelijk is voor beheer, onderhoud en wijzigingen.

De documentatie moet voldoende actueel zijn om bruikbaar te blijven.

Ze helpt medewerkers de omgeving begrijpen en ondersteunt toekomstige beslissingen. Bij een vervanging, migratie of uitbreiding kan de onderneming vertrekken vanuit een duidelijk beeld van de bestaande situatie.

Voor mij hoort documentatie daarom bij het ontwerp zelf. Ze maakt de technische redenering overdraagbaar en helpt voorkomen dat essentiële kennis uitsluitend bij één medewerker blijft.

Beoordeel kosten en afhankelijkheden samen

Een technisch goede oplossing kan financieel ongeschikt zijn voor een onderneming. Een goedkope aankoop kan op haar beurt extra kosten veroorzaken wanneer beheer, onderhoud of toekomstige aanpassingen moeilijker blijken dan verwacht.

Daarom moet een infrastructuurbeslissing rekening houden met de Total Cost of Ownership (TCO), de totale eigendomskosten over een bepaalde periode.

Afhankelijk van de oplossing omvat die berekening onder meer:

• Aankoopkosten en licenties.
• Onderhoud, ondersteuning en energieverbruik.
• Tijd die medewerkers besteden aan beheer en incidenten.
• Beveiliging, monitoring en back-up.
• Toekomstige uitbreidingen, vervangingen en migraties.

Bij clouddiensten kunnen ook opslag, gegevensverkeer, aanvullende diensten en de gekozen capaciteitsmodellen de kosten beïnvloeden. De precieze impact hangt af van de dienst, het gebruik en de contractvoorwaarden.

Ook leveranciersafhankelijkheid hoort in de beoordeling. Een oplossing kan specifieke licenties, beheertools of gespecialiseerde vaardigheden vereisen. De beschikbare exportmogelijkheden en voorwaarden voor gegevensoverdracht kunnen eveneens invloed hebben op toekomstige keuzes.

Open source kan in bepaalde situaties een geschikt alternatief bieden. De afwezigheid van een klassieke softwarelicentie garandeert echter geen lagere totale kosten. Implementatie, ondersteuning, onderhoud en interne expertise blijven bepalend.

Ik vertrek daarom vanuit de concrete vereisten van de onderneming. De beste oplossing is de optie waarvan de functionaliteit, risico’s, beheerlast en totale kosten passen bij wat de organisatie nodig heeft.

Maak technische beslissingen begrijpelijk

Een Infrastructure Architect werkt met mensen die verschillende verantwoordelijkheden en kennisniveaus hebben.

Een systeembeheerder wil weten hoe een oplossing wordt geïmplementeerd en onderhouden. Een IT-manager wil inzicht in capaciteit, afhankelijkheden en risico’s. Een bedrijfsleider wil begrijpen welke gevolgen een investering heeft voor de dagelijkse werking en het budget.

De architect moet de technische inhoud kunnen vertalen naar elk van die perspectieven.

Neem de segmentatie van een bedrijfsnetwerk. Technisch gaat het bijvoorbeeld over VLAN’s, firewallregels en toegangsbeleid. Voor de bedrijfsleiding is vooral relevant welke systemen van elkaar worden afgeschermd, welke risico’s daarmee worden beperkt en welke operationele gevolgen de wijziging heeft.

Een goed voorstel maakt ook duidelijk welke aannames zijn gebruikt, welke beperkingen blijven bestaan en welke risico’s niet volledig kunnen worden weggenomen.

Geen enkel ontwerp biedt een absolute garantie tegen storingen of beveiligingsincidenten. De kwaliteit van een beslissing hangt mede af van de beschikbare informatie, de gekozen maatregelen en de manier waarop de omgeving wordt beheerd.

Duidelijke communicatie helpt de onderneming om de gevolgen van een beslissing te begrijpen en bewust akkoord te gaan met de gemaakte afwegingen.

Hoe groei je van Systems Engineer naar Infrastructure Architect?

Wie vanuit systeembeheer of engineering wil doorgroeien naar architectuur, kan gericht werken aan een aantal vaardigheden.

1. Begrijp de bedrijfsprocessen achter de technologie

Vraag waarvoor een toepassing wordt gebruikt, wie ervan afhankelijk is en wat er gebeurt wanneer ze uitvalt.

Probeer te begrijpen welke systemen de dienstverlening, productie, verkoop of administratie ondersteunen. Zo kun je de technische prioriteiten beter afstemmen op de gevolgen voor de onderneming.

2. Vergelijk alternatieven voordat je ontwerpt

Werk niet uitsluitend een voorkeursoplossing uit. Onderzoek relevante alternatieven en vergelijk ze op basis van prestaties, beveiliging, beheer, kosten en afhankelijkheden.

Leg vast waarom een bepaalde optie het best bij de vereisten past. Zo wordt de beslissing controleerbaar en kunnen anderen de redenering volgen.

3. Zoek de structurele oorzaak van terugkerende problemen

Wanneer hetzelfde incident regelmatig terugkomt, onderzoek dan of de oorzaak dieper ligt dan het zichtbare symptoom.

Monitoring, standaardisatie, automatisering of een aangepast ontwerp kunnen helpen om structurele problemen aan te pakken. De juiste maatregel hangt af van de vastgestelde oorzaak.

4. Denk in wijzigingen, risico’s en herstel

Een technisch correcte wijziging kan problemen veroorzaken wanneer afhankelijkheden ontbreken in de analyse of wanneer een terugvalplan ontbreekt.

Leer daarom werken met impactanalyses, implementatieplannen, validatiecriteria en herstelprocedures. Bepaal vooraf hoe je vaststelt dat een wijziging geslaagd is en wat er gebeurt wanneer de resultaten afwijken van de verwachtingen.

5. Maak ontwerpkeuzes overdraagbaar

Documenteer de vereisten, onderzochte alternatieven, gemaakte keuzes en resterende risico’s.

Een collega moet kunnen begrijpen waarom een oplossing werd gekozen zonder alle eerdere gesprekken opnieuw te moeten voeren.

Deze ontwikkeling verloopt niet volgens een vast tijdschema. De vereiste vaardigheden hangen af van de complexiteit van de infrastructuur, de grootte van de organisatie en de verantwoordelijkheden van de functie.

Moet iedere Systems Engineer Infrastructure Architect worden?

Nee. Technische specialisatie blijft waardevol.

Een engineer met diepgaande kennis van netwerken, Linux, virtualisatie, opslag of beveiliging levert expertise die nodig is om architectuurkeuzes correct te beoordelen en uit te voeren.

De architectuurrol past vooral bij IT-professionals die naast techniek ook belangstelling hebben voor bedrijfsprocessen, investeringsbeslissingen, risico’s en de toekomstige ontwikkeling van een organisatie.

In kleinere ondernemingen kunnen systeembeheer, engineering en architectuur bovendien door dezelfde persoon worden uitgevoerd. De functietitel vertelt daarom niet altijd het volledige verhaal. De werkelijke verantwoordelijkheden zijn bepalender.

Voor mij zit de groei vooral in de manier waarop je technische kennis toepast. Je leert niet alleen hoe een oplossing werkt, maar ook waarom ze nodig is, welke alternatieven bestaan en welke gevolgen de keuze heeft voor de onderneming.

Van technische kennis naar betere bedrijfsbeslissingen

Bij een infrastructuurinvestering, cloudmigratie, uitbreiding of beveiligingsproject moeten verschillende belangen samen worden beoordeeld. De technische mogelijkheden vormen daarbij één onderdeel van de beslissing.

De bedrijfsvereisten, continuïteit, beveiliging, beheerbaarheid en kosten bepalen mee welke oplossing geschikt is.

Dat is de manier waarop ik naar infrastructuurarchitectuur kijk. Als onafhankelijk ICT-adviseur bij Peritus Consult onderzoek ik hoe technische keuzes aansluiten bij de behoeften van een onderneming en welke gevolgen ze hebben op korte en lange termijn.

Voor Belgische kmo’s kan die aanpak helpen om investeringen beter te onderbouwen, afhankelijkheden zichtbaar te maken en IT-beslissingen te nemen op basis van duidelijke criteria.

Overweeg je een infrastructuurinvestering, een migratie of een andere richting voor de IT-omgeving van je onderneming? Peritus Consult kan helpen om de vereisten, technische mogelijkheden en zakelijke gevolgen in kaart te brengen.