Software architectuur, keuzes die je niet terugdraait

Software architectuur is het geheel van fundamentele keuzes over hoe een systeem is opgebouwd: welke onderdelen er zijn, hoe ze data uitwisselen en waar ze draaien. Die keuzes bepalen wat je software later kan, wat aanpassingen kosten en hoe afhankelijk je bent van je leverancier.

Het zijn ook de duurste beslissingen om terug te draaien. Een verkeerde kleur fix je in een uur. Een verkeerde architectuurkeuze merk je pas in jaar twee, als elke nieuwe wens dubbel zoveel tijd kost.

Dit artikel behandelt die keuzes vanuit jouw vraag als opdrachtgever: wat betekent dit voor mijn kosten, mijn snelheid en mijn afhankelijkheid over drie jaar.

Architectuur gaat niet over code schrijven. Het gaat over de indeling waarbinnen die code wordt geschreven. Vergelijk het met een gebouw: de metselaar bepaalt de kwaliteit van de muur, de architect bepaalt of je er later een verdieping op kunt zetten.

Concreet beantwoordt software architectuur vier vragen:

• Hoe knip je het systeem op in onderdelen? En hoe strak scheid je die van elkaar?
• Waar leeft de data en wie mag erbij? Eén database of meerdere, en op basis van welke rechten?
• Hoe praten onderdelen met elkaar en met de buitenwereld? Rechtstreeks of via een tussenlaag?
• Waar draait het en hoe groeit het mee? Eigen servers, Europese cloud, of iets ertussenin?

Het effect zie je pas bij de eerste wijziging na livegang. In een goed opgezet systeem kost een extra koppeling twee dagen. Zitten de bedrijfsregels verspreid door de codebase, dan kost dezelfde koppeling twee weken. Dat verschil betaal je bij elke wijziging opnieuw, jarenlang.

Architectuur is dus geen technisch detail dat je aan de bouwer overlaat. Het is een businessbeslissing die je zelf moet kunnen navertellen.

Een monoliet is één applicatie die je in één keer uitrolt. Microservices knippen datzelfde systeem op in losse diensten, elk met een eigen database en een eigen deployment. Op conferenties wint microservices altijd. In de praktijk van organisaties met 50 tot 250 medewerkers verliest het meestal.

De reden is organisatorisch, niet technisch. Elke microservice heeft eigen monitoring, logging, versiebeheer en uitrolproces nodig. Met vijftien diensten heb je vijftien keer dat werk. Dat loont alleen met genoeg teams om die diensten los van elkaar te ontwikkelen.

De verstandige middenweg heet een modulaire monoliet: één applicatie, maar intern strikt opgedeeld in modules met duidelijke grenzen. Je houdt de eenvoud van één systeem en je houdt de deur open om later een module los te trekken als dat echt nodig blijkt.

Voor de meeste maatwerkprojecten is dat de juiste startkeuze. Meer over hoe wij die afweging maken lees je bij maatwerk software laten maken.

Schaalbaar betekent dat je systeem meer werk aankan zonder dat je het opnieuw moet bouwen. Dat is de hele definitie. Het gaat niet om snelheid vandaag, maar om wat er gebeurt bij tien keer zoveel gebruikers, klanten of transacties.

Technisch schaal je op twee manieren. Verticaal betekent een grotere server: simpel, snel, en op een gegeven moment op. Horizontaal betekent meer servers naast elkaar: onbeperkt, maar alleen mogelijk als je applicatie daarop is ontworpen.

Drie dingen bepalen of schaalbare software echt schaalt:

1. De applicatielaag onthoudt niets. Elke server moet elk verzoek kunnen afhandelen. Zit de sessie van een gebruiker vast aan één machine, dan kun je niet uitbreiden.
2. De database is meestal de bottleneck. Niet de servers. Rapportages die rechtstreeks op de productiedatabase draaien, leggen bij groei het hele systeem plat.
3. Zware taken gaan uit het verzoek. Rapporten, exports en e-mails horen in een achtergrondproces. Anders wacht de gebruiker op werk dat hem niet aangaat.

Er is ook een organisatorische kant, en daar gaat het in de praktijk vaker mis. Kost het aansluiten van klant honderd net zoveel handwerk als dat van klant tien, dan is je software misschien schaalbaar maar je bedrijf niet. Dat is een architectuurvraag, geen personeelsvraag.

Eerst een verduidelijking, want de term wordt voor twee dingen gebruikt. In Microsoft 365 en Azure is een tenant jouw eigen afgeschermde omgeving binnen de dienst van Microsoft. Daar gaat deze sectie niet over. Hier gaat het over software architectuur: hoe je één applicatie bouwt die meerdere klantorganisaties tegelijk bedient, elk met strikt gescheiden data.

Dat is de standaardopzet voor elk SaaS-product. Je bouwt en onderhoudt één keer, en bedient er honderd klanten mee. Het alternatief, per klant een eigen kopie draaien, wordt onbetaalbaar zodra je een update moet uitrollen.

Er zijn drie varianten. Een gedeelde database is het goedkoopst per klant en één keer updaten, maar een fout in de scheiding raakt iedereen. Een database per klant geeft betere isolatie en makkelijker exporteren, tegen meer beheer. Een eigen omgeving per klant geeft maximale isolatie, maar is het duurst en schaalt niet mee.

Multi-tenant software kost vooraf 20 tot 30 procent extra ontwikkeltijd. Die investering verdient zich terug bij de vijfde of zesde klant. Belangrijker: dit is de keuze die je later het moeilijkst omdraait. Achteraf multi-tenant maken komt in de praktijk neer op herbouw.

Koppelingen zijn in platformprojecten zowel de grootste kostenpost als het grootste risico. In de trajecten die wij begeleiden zit doorgaans 30 tot 50 procent van het budget in de verbinding met andere systemen, niet in de applicatie zelf.

Dat komt doordat je afhankelijk bent van software die je niet beheert. De documentatie klopt niet helemaal. Er zit een limiet op het aantal verzoeken. De leverancier brengt een nieuwe API-versie uit met een half jaar overgangstermijn. Ligt hun systeem eruit, dan ligt jouw proces stil.

Er is één architectuurregel die dat risico echt verkleint: koppel nooit rechtstreeks. Bouw een eigen tussenlaag waar alle externe verbindingen doorheen lopen. Wisselt een leverancier, dan pas je die ene laag aan in plaats van je hele applicatie. Dat kost vooraf een paar dagen extra en bespaart later weken.

Stel voor elke koppeling drie vragen voordat je begint:

• Welk systeem is de bron van de waarheid als de gegevens uit elkaar lopen?
• Wie binnen de organisatie is eigenaar van dat systeem en van de API-toegang?
• Wat doet ons proces als deze koppeling een dag niet werkt?

Hoe wij koppelingen ontwerpen en waar AI daarin een rol speelt, lees je in AI koppelingen en integraties en op op maat AI-integraties.

Software kwaliteit meet je niet in de code. Je meet het in drie cijfers die iedere directeur begrijpt: hoe lang duurt een fix, hoe vaak gaat er iets stuk, en hoe snel is een nieuwe developer productief.

Code review betekent dat elke wijziging door een tweede persoon wordt bekeken voordat hij live gaat. Dat vangt fouten af voordat je klanten ze vinden. Het zorgt er ook voor dat kennis bij meer dan één persoon zit. Een continuïteitsmaatregel, geen luxe.

Feature flags zijn een schakelaar waarmee je een functie aan of uit zet zonder nieuwe software uit te rollen. Je zet hem eerst aan voor vijf procent van de gebruikers en draait terug met één klik als het misgaat. Livegangen worden een non-event.

Continuous delivery betekent wekelijks of dagelijks uitrollen in plaats van elk kwartaal. Kleine wijzigingen zijn makkelijker te testen en terug te draaien. Een gemelde fout is dezelfde dag opgelost.

Software refactoring is gepland opruimen van verrommelde code. Reserveer hier structureel 10 tot 20 procent van de ontwikkelcapaciteit voor. Doe je dat niet, dan betaal je het later terug met rente. Dat mechanisme heet technical debt.

Dit zijn de zes keuzes die op dag één logisch lijken en na twee jaar niet meer te repareren zijn zonder herbouw. Je hoeft niet alles vooraf perfect te doen. Deze zes maak je wel bewust.

1. Bedrijfsregels in de interface zetten. Zit de logica in het scherm in plaats van in een aparte laag, dan bouw je alles opnieuw zodra er een app, portaal of API bij komt.
2. Alles in één database, inclusief rapportage. Op het moment dat een zware rapportagequery het bestelproces vertraagt, is het te laat om nog iets te scheiden.
3. Geen API-laag. Elke nieuwe koppeling raakt dan de kern van je systeem. Dat maakt elke integratie duur en risicovol.
4. Hard-coded aannames. Eén land, één valuta, één btw-tarief, één taal. Elke uitbreiding naar België of Duitsland wordt daarmee een verbouwing in plaats van een instelling.
5. Vendor-specifieke afhankelijkheden. Bouw je diep op de eigen diensten van één cloudleverancier, dan is verhuizen later geen optie meer. Dat mechanisme beschrijven wij bij waarom vendor lock-in een reëel bedrijfsrisico is.
6. Geen scheiding tussen klantdata en configuratie. Zodra klantinstellingen verweven raken met klantgegevens, wordt elke migratie handwerk.

Wat deze zes gemeen hebben: ze besparen in de eerste maand tijd en kosten daarna elk jaar meer. Bredere achtergrond vind je in de kennisbank over platformen.