Een architectuuraudit is geen mening over je stack. Het is een kaart van waar het systeem breekt onder het plan dat je werkelijk hebt.
Architectuurreviews hebben een slechte naam omdat veel ervan smaakoefeningen zijn — een consultant die uitlegt dat hij anders gekozen zou hebben. Een nuttige audit beantwoordt een smallere en veel waardevoller vraag: gegeven waar dit bedrijf over achttien maanden wil staan, wat breekt er, wanneer, en wat kost het om dat te repareren?
Signalen dat je er nu een nodig hebt
- De prestaties verslechteren merkbaar naarmate het gebruik groeit, en niemand kan precies zeggen waarom
- Infrastructuurkosten stijgen sneller dan de omzet
- Eén component valt uit en trekt ongerelateerde functies mee
- Een kleine feature uitbrengen vereist ingrepen in veel delen van het systeem
- Je staat op het punt het verkeer te vertienvoudigen — een launch, een partnerschap, een ronde
- Een investeerder heeft gevraagd of de architectuur schaalt, en het eerlijke antwoord is dat niemand het weet
Wat de audit onderzoekt
De datalaag, als eerste en het moeilijkst
In de meeste systemen is de database het echte plafond, en het duurste om later te veranderen. Wat telt: scheiding van lezen en schrijven, indexering tegen de werkelijke querypatronen, onbegrensde queries die met de tabel meegroeien, of één schrijf-master de limiet is, en of het schema kan evolueren zonder downtime.
Faalisolatie
- Wat er gebeurt als een externe afhankelijkheid traag is in plaats van plat — timeouts en circuit breakers, of cascaderende threaduitputting
- Of één tenant of één zware klant de dienst voor iedereen kan degraderen
- Of achtergrondtaken het requestpad kunnen uithongeren
Wijzigingssnelheid
Architectuur gaat niet alleen over belasting. Een systeem dat niet veilig te wijzigen is, faalt in zijn taak, ook al gaat het nooit plat. We zoeken koppeling die wijzigingen over meerdere modules afdwingt, ontbrekende naden om te testen, en gedeelde staat die lokaal redeneren onmogelijk maakt.
Passendheid bij de teamgrootte
Hoe de oplevering eruit hoort te zien
| Slechte auditoplevering | Nuttige oplevering |
|---|---|
| «Overweeg microservices» | «De Orders-tabel bereikt schrijfverzadiging rond 4× het huidige volume; sharding per tenant is ~3 engineer-weken» |
| «De testdekking is laag» | «Betalingsreconciliatie heeft geen tests; een regressie hier is stil en financieel» |
| «De technische schuld is aanzienlijk» | «Drie punten blokkeren de Q4-roadmap; de rest kan wachten en dit is waarom» |
| Een rapport van 60 pagina's | Een samenvatting van één pagina, een gerangschikte lijst en een gefaseerd plan |
Het doel van een architectuuraudit is vage angst over schalen omzetten in een klein aantal gedateerde, geprijsde beslissingen.
Toets één concrete groeiaanname
Een diagram bewijst geen werkelijke capaciteitsgrens. Verbind gebruiksverandering met afhankelijkheden, capaciteit en herstelbewijs.
- Volg een belangrijk verzoek door diensten, wachtrijen en opslag.
- Benoem gedeelde faalpunten en onbeproefde capaciteitsaannames.
- Vergelijk gerichte wijzigingen op effect en verificatiekosten.
Veelgestelde vragen
Hoe lang duurt een systeemarchitectuuraudit?
Eén tot drie weken voor de meeste systemen. Het werk bestaat uit het lezen van code en infrastructuur, het onderzoeken van echte productiemetrieken en querypatronen, en het interviewen van de engineers. Langere trajecten betekenen meestal dat de scope is afgedreven naar implementatie.
Gaan jullie ons vertellen alles opnieuw te bouwen?
Zeer zelden, en wees sceptisch bij iedereen wiens standaardadvies een herbouw is. De meeste schaalplafonds worden opgehoogd met gerichte wijzigingen — een index, een queue, een cache, een shardsleutel — en niet met een nieuwe architectuur.
Hebben we een architectuuraudit nodig vóór een ronde?
Het is de moeite waard als investeerders technische due diligence doen, wat standaard is vanaf Series A. De problemen zelf vinden is veel goedkoper dan ze door de tegenpartij tijdens de onderhandeling laten vinden.
Is altijd een belastingtest nodig?
Alleen bij een belangrijke open capaciteitsvraag en afgesproken testscope. Bestaande telemetrie kan een deel beantwoorden; leg ontbrekende metingen vast.
Bezorgd over wat breekt bij 10×?
Wij brengen de plafonds in kaart, prijzen de fixes en zetten ze op volgorde — meestal binnen drie weken.
Verder lezen
Technische schuld bij startups: hoeveel is te veel?
Elke startup heeft technische schuld, en het meeste ervan was de juiste keuze. De vraag is niet hoe je die wegwerkt — het is welke delen rente vragen die je je niet meer kunt veroorloven.
Technische MVP-audit: wat we in de eerste 48 uur controleren
De meeste MVP-audits leveren een document op. Een nuttige levert beslissingen op: wat brandt, wat kan wachten en wat het kost om het te herstellen.