De Architectuur Review Checklist
Een software systeem overnemen is een uitdaging.
Misschien ben je net begonnen als CTO of nieuwe developer. Misschien heeft je bedrijf software overgenomen. Misschien zijn de oprichters of het oude team vertrokken en is het nu aan jou. De documentatie is karig. De git-historie vertelt verhalen waar je niet bij was. Het systeem draait, meestal, maar je weet niet precies waarom. Laat staan wanneer het gaat omvallen.
Dit artikel geeft je vragen. Vragen die problemen blootleggen voordat ze zichzelf aankondigen. Je leert meer van de vragen die je niet kunt beantwoorden dan van de vragen die je wel kunt beantwoorden. Elke keer dat je “geen idee” moet zeggen, weet je waar je op kunt focussen.
Drie gebieden zijn belangrijk: beveiliging, operations en aanpasbaarheid. Elk gebied legt andere risico’s bloot, en samen vertellen ze je wat voor software je in huis hebt.
Beveiliging
Beveiliging in dit soort systemen is speurwerk. Beslissingen genomen door mensen die er niet meer zijn, gebaseerd op aannames die misschien niet meer kloppen. Jouw taak: uitpluizen.
Kun je het volledige pad volgen van gebruikersinvoer naar de database? Authenticatie zit in de ene service, autorisatie ergens anders, inputvalidatie verspreid over drie microservices. Waar componenten elkaar raken, daar vind je de zwakke plekken.
Wat is de schade als één component wordt gehackt? Kijk naar gedeelde database-credentials, service accounts met onbeperkte toegang, secrets in environment variables die elke service kan lezen. Dit was logisch toen het systeem nog klein was met 3 ontwikkelaars met één server. Nu betekent het dat één hack overal doorwerkt. De Target-hack van 2013 begon met de credentials van een airco-leverancier en eindigde met 40 miljoen gestolen creditcards. Eenmaal binnen konden aanvallers overal bij.
Wat als authenticatie niet meer werkt? Als de authenticatieservice down gaat, falen requests dan of gaan ze door? Onder druk falen veel systemen open: de “tijdelijke bypass” die nooit is verwijderd, de fallback die validatie overslaat of minder goed beveiligd is. Dit zit in bijna elke codebase. Vind het voordat een aanvaller het vindt.
Welke beveiligingskeuzes passen niet meer bij hoe het systeem nu wordt gebruikt? Het single-tenant systeem dat multi-tenant werd, de interne tool die naar klanten ging. Beveiligingsfouten kunnen meerdere productreleases overleven, vooral als ze uit dependencies komen. Vraag wanneer de laatste security review was. Vraag dan wat er sindsdien is veranderd.
Beveiligingslekken kunnen kostbaar worden. Probeer een goed beeld te vinden van waar de risico’s zich bevinden.
Operationele Paraatheid
Je ontdekt hoe software faalt door ernaar te kijken, niet door te wachten tot het daadwerkelijk gebeurt. Operationele paraatheid betekent dat je bugs kunt oplossen voordat je klanten erover beginnen te posten op social media.
Wat gebeurt er als het systeem ‘s nachts down gaat? Als er iets faalt, wordt dan de juiste persoon genotificeert, en heeft deze genoeg informatie om het probleem te kunnen oplossen? Veel van dit soort systemen sturen alerts naar Slack-kanalen die niemand bekijkt, en zeker niet na kantooruren. Dat is schijnveiligheid, geen werkende monitoring. Check wie er echt on-call is, welke informatie ze krijgen, en of ze er iets mee kunnen.
Op welke manier heeft dit systeem nog nooit gefaald? Als het systeem nooit een database-failover heeft meegemaakt, of een externe service die wegviel, nooit echte productiebelasting heeft doorstaan, dan weet je niet hoe het zich gedraagt in die scenario’s. Geen incidenten kan betekenen dat het systeem robuust is, maar het kan ook betekenen dat dit nog kan komen.
Welke alerts worden door iedereen genegeerd? Te veel valse meldingen creëren een gevaarlijk patroon: teams leren alerts negeren, waardoor echte problemen onzichtbaar worden. Analyseer: hoeveel alerts kwamen binnen en hoeveel waren terecht? Minder dan de helft bruikbaar? Dan verstoort je monitoring meer dan het beschermt.
Hoe lang duurt herstel echt, en heb je het ooit getest? De meeste van dit soort systemen hebben backups die nooit zijn teruggezet, failover-procedures die nooit zijn uitgevoerd, en runbooks van mensen die jaren geleden vertrokken. Je ‘theoretische’ hersteltijd betekent niets tot je het onder druk hebt doorlopen. GitLab leerde dit op de harde manier in 2017 toen ze tijdens een incident ontdekten dat hun backups niet werkten. Ter referentie: DORA-onderzoek laat zien dat topteams binnen een uur herstellen. Zwakke teams doen er een week tot een maand over.
Wie weet echt hoe het systeem werkt? Als het antwoord ‘één persoon’ is, heb je een single point of failure. Onderzoekers noemen dit de “busfactor,” het aantal mensen dat kan vertrekken voordat een project vastloopt. Een studie bij JetBrains toonde aan dat bestanden die niet meer door hun oorspronkelijke ontwikkelaars worden aangeraakt, verlaten blijven. Permanente blinde vlekken in de codebase. Als ‘het vertrokken team’ je antwoord is, vertrouw je op kennis die al begint te verdwijnen.
Aanpasbaarheid
Als ontwikkelaars niet durven te refactoren, worden kleine aanpassingen opgespaard tot gevaarlijke mega-releases. Bugfixes blijven liggen uit angst voor onverwachte bijwerkingen. De technische schuld groeit omdat iedereen de risicovolle modules mijdt. Enquêteonderzoek in de software-industrie toont aan dat teams 23% van hun ontwikkeltijd verspillen aan technical debt. Tijdsdruk is de belangrijkste oorzaak.
Angst is een valide maatstaf voor architectuurkwaliteit.
Waar weigeren developers aan te werken in het systeem? Elk systeem heeft dit soort black boxez: de facturatiecode die niemand helemaal snapt, de koppeling met dat legacy-systeem bij elkaar gehouden door WD-40 en duct tape. Dit worden permanente blinde vlekken en zijn risicovol.
Wat is het ergste dat kan gebeuren door een typfout? Kan één verkeerd teken productie platleggen? Een gezond systeem kan omgaan met kleine fouten, terwijl een gevoelig systeem kleine fouten keihard afstraft.
Vinden je tests echt bugs? Een groene testsuite die niet alles test zorgt voor vals vertrouwen. Teams deployen omdat de tests slaagden, terwijl de tests niet testten wat belangrijk was. Kijk naar de laatste bugs die productie bereikten. Hadden de tests die bugs moeten voorkomen?
Hoe lang duurt het voor een nieuwe engineer code kan deployen? Dit is een productiviteitsmetric die wrijving meet. Als het maanden kost om het systeem goed genoeg te begrijpen om veilig code bij te dragen, zal ontwikkeling aan het systeem altijd traag zijn. De codebase werkt tegen. Bij Etsy deployen nieuwe engineers op hun eerste dag.
Kun je een foute deploy binnen minuten terugdraaien? De snelheid waarmee je kunt herstellen bepaalt je bereidheid om te deployen. Als rollback een nachtmerrie is, durf je niet meer te deployen. Teams nemen geen risico’s meer en productiviteit en innovatie stopt.
Wat Nu Met Deze Antwoorden
Begin met de vragen die je niet kon beantwoorden. Dat zijn je blinde vlekken, en blinde vlekken blijven niet voor altijd verborgen.
De antwoorden die je zorgen baren: schrijf ze nu op. Volgende week is de urgentie weg, en het systeem blijft draaien terwijl je jezelf vertelt dat het waarschijnlijk wel goed zit. Leg de zorgen vast en pak dit aan.
Deze vragen geven je geen compleet beeld, het is een beginpunt. Ze vertellen je waar de gaten kunnen zitten, en daar begin je met oplossen.
Lumia Labs werkt samen met organisaties met legacy systemen. Heb je behoefte aan een frisse blik op je systeem? Laten we praten.
