Neem voorraadbeheer. Het ene systeem houdt bij hoeveel koffie, thee en melk er op kantoor staat en stuurt een melding als er besteld moet worden. Het andere stuurt de aanvoer van onderdelen naar een productielijn. Daar moet het juiste onderdeel binnen de takttijd aan de lijn liggen. En het systeem moet blijven werken als de koppeling met het MES (Manufacturing Execution System) of het magazijn even wegvalt.
Beide beheren voorraad. Dat ze een totaal ander ontwerp nodig hebben, voel je op je klompen aan.
Functie is niet genoeg
Toch gaat het in architectuurdiscussies hier regelmatig mis. We benoemen systemen naar hun functie: een voorraadsysteem, een CRM, een planningssysteem. En wat dezelfde naam heeft, krijgt al snel dezelfde technische oplossing.
De functie zegt alleen wat een systeem doet. Hoe het dat moet doen, wordt bepaald door de omgeving waarin het draait. Als een kantoorbestelling een dag later wordt verwerkt, merkt niemand het. Als een onderdeel niet op tijd aan de lijn ligt, staat de lijn stil. Eén uur stilstand kan dan meer kosten dan het hele kantoorsysteem ooit heeft gekost.
Hetzelfde systeem, een andere wereld
Dat dit geen theorie is, zag ik bij een financieel adviessysteem. Het was gebouwd als hulpmiddel voor adviseurs: eerst voor eigen medewerkers, later ook voor partners. Toen de klant het systeem ook op de eigen website aanbood, aan iedereen, kwamen ze bij ons.
Aan het systeem was niets veranderd. Het rekende nog steeds uitstekend. Toch liep het vast. Getrainde adviseurs maakten plaats voor gebruikers zonder training. Die maken meer fouten en gebruiken het systeem anders dan bedoeld. Ze zijn met veel meer, en ze komen ook 's nachts en in het weekend. Het systeem dreigde te bezwijken onder zijn eigen succes.
We hebben eerst het bestaande systeem overeind gehouden:
- beveiligingsproblemen opgelost;
- de zwaarste berekeningen in de database herschreven;
- capaciteit actief gestuurd: opschalen waar het moest, afschalen waar het kon, om kosten te besparen;
- met onze teams in Vietnam en Nederland productie 18 uur per dag bewaakt;
- een acceptatieomgeving opgezet om probleemgevallen na te bootsen en op te lossen, zonder dat productie er last van had.
Tegelijk hebben we met de klant een stappenplan gemaakt om weer grip te krijgen. De klant kon direct verder, en eindklanten hebben er niets van gemerkt.
Het systeem deed nog precies wat het altijd deed. Alleen de context was veranderd, en niemand had de vragen opnieuw gesteld die bij die nieuwe context hoorden.
Kwaliteitseisen: bekend, maar zelden concreet
Die vragen gaan over kwaliteitseisen, of non-functionals: beschikbaarheid, latency, consistentie, herstelbaarheid, integratie. ISO 25010 zet ze netjes op een rij. Onbekend zijn ze dus niet.
Het probleem is dat ze worden opgeschreven als "het systeem moet snel en betrouwbaar zijn". Zonder getal, zonder context, zonder consequentie. Zo'n eis past op elk systeem en stuurt daarom geen enkel ontwerp.
Mijn werk begint bij een zin als: "maximaal 30 seconden niet-beschikbaar" en "zonder dat de lijn stopt." Dan weet je wat je moet bouwen. En minstens zo belangrijk: wat je niet hoeft te bouwen.
Het verschil zit in wat er op het spel staat
Het kantoorsysteem mag concessies doen. Een standaard cloudplatform, een eenvoudige database en een simpele interface zijn prima. Ligt het een uur plat, dan drinkt iemand thee in plaats van koffie.
Het productiesysteem moet ontworpen zijn op falen. Wat doet het als de verbinding met de machine wegvalt? Mag de lijn doordraaien op de laatst bekende voorraad, of moet hij stoppen? Hoe herstel je na een storing zonder dubbele of verloren boekingen (idempotentie)? Hoe zie je dat er iets misgaat voordat de operator het ziet?
Dat zijn geen implementatiedetails. Het zijn ontwerpbeslissingen, en ze kosten geld. Dat geld is goed besteed als de gevolgen van een fout groot zijn. Zijn ze klein, dan is het weggegooid.
De vragen die ik stel
Een goed ontwerp begint bij de werkelijkheid waarin het systeem moet functioneren. Dit zijn de vragen die ik stel voordat er een technologiekeuze op tafel komt:
- Gebruikers - Wie gebruikt het systeem, met welke kennis, en wanneer?
- Beschikbaarheid - Wat gebeurt er als het systeem een minuut niet beschikbaar is? En een uur?
- Kosten van stilstand - Wat kost een uur stilstand, en wie betaalt dat?
- Volume - Hoeveel gebruikers, transacties of gebeurtenissen moeten we verwerken, ook op piekmomenten?
- Latency - Hoe snel moet een verandering zichtbaar zijn, en voor wie?
- Integratie - Wat gebeurt er als een koppeling met een ander systeem wegvalt?
- Impact van fouten - Wat zijn de gevolgen als het systeem een verkeerde beslissing neemt?
Pas als die antwoorden er zijn, met getallen, kun je bepalen welke architectuur past. En als de context verandert, stel je ze opnieuw.
Met een AI-assistent heb je in een middag een werkend voorraadsysteem. Maar deze vragen krijg je (nog) niet van een AI als je aan het vibecoden bent.
Standaardiseer op kritikaliteit, niet op functie
Standaardisatie is waardevol. Het beperkt complexiteit, maakt beheer eenvoudiger en bespaart tijd en geld. Ik ben er een voorstander van.
Het risico zit in een vraag die ik regelmatig hoor: "We hebben al een voorraadsysteem. Waarom gebruiken we dat hier niet gewoon?" Of, zoals bij het adviessysteem: "Het werkt toch al? Zet het gewoon online."
Een redelijke vraag. Maar dat een systeem een functie al ondersteunt, bewijst nog niet dat het geschikt is voor elke context waarin die functie nodig is. Wie standaardiseert op functie, legt het productiesysteem de concessies van het kantoorsysteem op. Of andersom: het kantoorsysteem de kosten van het productiesysteem.
Daarom deel ik systemen liever in naar wat er op het spel staat, bijvoorbeeld in drie kritikaliteitsklassen. Per klasse standaardiseer je platform, monitoring, herstelprocedures en testdiepte. Twee systemen in dezelfde klasse kunnen prima een platform delen, ongeacht wat ze doen. Twee voorraadsystemen in verschillende klassen meestal niet.
Context eerst
Kort gezegd:
Een systeem kan precies blijven doen wat het altijd deed, en toch niet meer kunnen wat nodig is.
Twijfel je of een bestaand systeem past bij de context waarin je het wilt inzetten, of sta je voor een standaardisatieslag? Laten we praten. Met een kop koffie, uiteraard.
