Security, performance, herstelbaarheid: waarom “later” altijd te laat is

Non functionals zien we later wel

Vrijwel wekelijks kom ik het tegen. Zinnen die lijken op deze: “We gebruiken het Cloud Adoption Framework van Microsoft.” Bij mij lopen dan de koude rillingen al over m’n rug. De verteller probeert me hiermee zonder uitzondering uit te leggen dat de security dus geregeld is. Niet dus. Je security is daarmee niet geregeld en het is zelfs erger dan dat.

Als jij dit ook weleens zegt of denkt, lees dan mee wat de reden is dat het daarmee niet geregeld is en wat wél te doen.

Kijk, functionele requirements krijgen alle aandacht: “de knop moet dit doen, het scherm moet dat tonen”. Non-functional requirements (NFR’s) verdwijnen daarmee naar het einde van de sprintplanning. Of nog erger: “dat testen we na de livegang wel”. Want er is altijd druk: MVP, deadline, demo.

En dan komt die livegang.
Niet met champagne, maar met brandjes:

• Een datalek omdat autorisaties “even later” zouden worden ingericht.
• Dataverlies omdat back-up en herstel nooit zijn geoefend.
• Een trage applicatie omdat performance geen acceptatiecriterium was.
• Boze gebruikers omdat het systeem onvoorspelbaar uitvalt.
• Een audit die je niet haalt omdat logging en traceability ontbreken.

Dat is geen technisch detail. Dat is risico op omzet, reputatie, continuïteit en compliance. Kortom: boardroom-territorium. Als je NFR’s uitstelt, schuif je niet “IT-werk” dóór; je schuift bestuurdersaansprakelijkheid, boetes en verstoring van de business naar vóren.

En het meest pijnlijke: “later” komt zelden. Tegen de tijd dat de problemen zichtbaar zijn, is het budget op en is de organisatie al afhankelijk.

Wat zijn non functionals/NFR’s eigenlijk?
Het zijn eisen aan hoe het systeem zich gedraagt onder druk, falen en misbruik. Niet wat het doet, maar of je erop kunt bouwen.

Belangrijke categorieën (die je minimaal gecheckt wil hebben):

• Security & privacy (auth, autorisatie, encryptie, dataretentie)
• Performance & schaalbaarheid (latency, throughput, piekbelasting)
• Beschikbaarheid & betrouwbaarheid (uptime, failover, degradatie)
• Herstelbaarheid (back-up, restore, RPO/RTO, disaster recovery)
• Observeerbaarheid (logging, metrics, tracing, alerting)
• Beheerbaarheid (patching, configuratie, deployment, rollback)
• Compliance & auditability (rechten, bewijs, rapportage)
• Usability & toegankelijkheid (frictie, fouten, WCAG)

In dit blog loop ik langs plekken waar het met non functionals vaak misgaat, waarom dat gebeurt, welke schade je pas ziet als het te laat is en hoe je ze vanaf dag één verplicht maakt: meetbaar, testbaar en bestuurbaar.

Security ‘ingebakken’? Dan heb je het ‘recept’ niet goed gelezen

“We gebruiken het Cloud Adoption Framework van Microsoft, dan is onze security toch geregeld?”

Ik schreef al, dit hoor ik vaak. Feitelijk zeg je dan: “We hebben een kookboek, dus het diner is klaar.” “Nou ja Hugo, doe eens niet zo flauw” denk je misschien. Het is niet flauw, het is weer eens een Microsoft truc om je te laten denken dat je het allemaal onder controle hebt. Helaas …

CAF (of welk vergelijkbaar framework dan ook) is geen beveiliging. Het is een set richtlijnen. Een checklist. Een manier om je werk te structureren. Handig, zeker. Maar het doet niets, bouwt niets, beschermt niets. Het zegt hooguit: hier moet je aan denken.

Security ontstaat pas wanneer je die richtlijnen concreet maakt. Met keuzes. Met grenzen. Met harde afspraken die je kunt testen.

Want security zit niet ingebakken in je cloudabonnement. Het zit ook niet ingebakken in je standaardproducten. Het zit al helemaal niet ingebakken in je organisatie.

Wat je wél moet ‘inbakken’ oftewel moet besluiten en implementeren:

• Identiteiten en toegang: wie is wie? Welke rollen bestaan er? Welke rechten horen daarbij? En waarom? Zonder autorisatiematrix is ‘least privilege’ een poster aan de muur.
• Aansluiting op applicaties: SSO, conditional access, service accounts, API-rechten. Elk koppelpunt is een nieuwe deur.
• Netwerk- en platformbeveiliging: segmentatie, firewallregels, hardening, patching, secrets management.
• Detectie en respons: logging, monitoring, alerting, triage. Niet “we hebben een SIEM”, maar: wie kijkt er, wanneer en wat is de eerste actie?
• Continuïteit: incident response, noodprocedures, back-up én restore, DR-testen. Een back-up die je nooit terugzet is een schijnveiligheid.

En dan nog het meest onderschatte deel: ownership. Wie is eindverantwoordelijk? Wie beslist dat iets live mag? Wie trekt aan de noodrem als risico’s oplopen?

De boardroom vraagt graag: “Is security geregeld?”
De betere vraag is: “Welk risico accepteren we en hoe weten we dat het werkt?”

Want als je security ‘ingebakken’ noemt, terwijl je de ingrediënten niet eens hebt gekozen… dan is het geen strategie. Dan is het hoop. Of, zoals ik dat noem, schijnzekerheid met de zekerheid van problemen die je veel geld gaan kosten.

Je upgrade is geslaagd… tot maandagochtend 09:00

Eind vorig jaar was het weer raak: SQL Server 2022.
Op papier een nette, noodzakelijke upgrade. In de praktijk: elke week - soms meerdere keren - een uur lang CPU tegen de 100%. En gebruikers die precies doen wat je niet wilt: refreshen, opnieuw proberen, escaleren. Niet omdat ze lastig zijn, maar omdat hun werk stilvalt.

Dit is geen SQL-only probleem. Oracle 12.1 liet het ook zien: niet ‘de applicatie’, maar de release zelf kan het performanceprobleem zijn. Nieuwe versies brengen structurele wijzigingen mee: andere query-planners, ander geheugen- en IO-gedrag, nieuwe defaults, extra background tasks. Soms is dat winst. Soms is het precies de verkeerde kant op - voor jóuw workload.

En daar zit de valkuil: supportdruk maakt upgrades tot paniekprojecten.
‘Uit support’ klinkt als een compliance-issue. Dus gaat de organisatie in de sprint: plannen, klikken, migreren, klaar. En de non functionals? Die komen later wel. Tot later ineens productie is.

Het probleem wordt groter als je software niet zelf bouwt. Je weet niet welke aannames erin zitten. De leverancier zegt: “Compatible met versie X.” Maar dat betekent zelden: “Getest met jouw data, jouw maatwerk, jouw piekbelasting, jouw keten.” Zij testen generiek. Jij draait specifiek.

En als je er pas achter komt na een halve dag productie op de nieuwe release, dan is ‘terug’ vaak geen optie. Of wel, maar tegen serieuze kosten: downtime, herstel, datafixes, extra consultancy, reputatieschade. De rollback is altijd duurder dan de test die je oversloeg.

Hetzelfde zag ik bij een recente Windows 10 → Windows 11 upgrade. Alles volgens de regels: minimale systeemeisen gecheckt, te oude werkplekken vervangen. Mooi. Alleen: niemand had getest wat er gebeurt als je échte werk start. Resultaat: machines die “Windows 11 prima draaien”, maar waar Word en Excel minuten nodig hebben. Teams? Vijf minuten opstarten en daarna nog een minuut om een call te openen. Een kale OS-check zegt niets als je productiviteit in de applicaties zit.

Haastige spoed is zelden goed.
Zeker niet bij upgrades.

Want zodra supportdruk de planning dicteert, sneuvelen de non functionals als eerste. En precies die bepalen of je bedrijf maandagochtend gewoon kan draaien.

Maak van “later” geen incidentrapport

Je kunt non functionals negeren… tot ze jou negeren.

De meeste ellende ontstaat niet door ‘een bug’.
Maar door wat níét is afgesproken en níét is getest: performance onder piekbelasting, autorisaties, logging, herstelbaarheid, failover, beheerbaarheid.

En dan is het altijd hetzelfde ritueel:
War room, escalaties, leveranciers die wijzen, users die vloeken, de boardroom die vraagt hoe dit kon gebeuren.

Dat wil je voor zijn.

Plan daarom een vrijblijvende afspraak van 30 minuten met mij. Dan lopen we samen langs jouw komende rollout of upgrade en bepalen we:

• Welke non functionals écht hard moeten zijn,
• Welke meetbaar/testbaar gemaakt moeten worden,
• En welke risico’s je nu onbewust accepteert.

Sciante helpt al meer dan 15 jaar organisaties om non functionals wél op orde te brengen - vóórdat het live gaat. Zodat uitrollen weer een keuze is, geen gok.

Maak die afspraak. Organisaties die dit vooraf doen, voorkomen achteraf escalaties, herstelkosten en bestuurlijke verrassingen.