In de discussie over softwareontwikkeling lijkt het vaak alsof je een religie moet kiezen. De ene groep zweert bij plannen van tachtig pagina’s. De andere groep wil morgen beginnen met bouwen zonder te weten waar de data landt. Beiden hebben ongelijk. De beste systemen ontstaan door een combinatie van twee werelden op het juiste moment.
In mijn ervaring als architect is er een groot verschil tussen de harde structuur van een systeem en de dagelijkse praktijk van de gebruiker. Om een bedrijf echt te laten schalen, heb je beide methodes nodig. Maar de volgorde is bepalend voor het succes.
De fundering: Waarom waterval nodig is bij de start
Een Minimum Viable Product (MVP) is pas levensvatbaar als de basis van de data op orde is. Als je de fundering van je systeem – de relatie tussen klanten, orders en voorraad – gaandeweg probeert uit te vinden via korte sprints, bouw je op drijfzand. Je creëert dan direct een technische schuld die de groei later zal afremmen.
In deze eerste fase heeft een strakke planning volgens de waterval methode grote waarde. Je moet namelijk eerst een Single Source of Truth definiëren voordat je gaat bouwen. Dit biedt drie cruciale voordelen:
- Data integriteit: Je dwingt jezelf om vooraf na te denken over hoe informatie stroomt. Een database halverwege aanpassen is een operatie aan een open hart.
- Voorkomen van chaos: Door de kern vooraf strak te trekken, zorg je dat alle latere aanpassingen landen op een solide fundament.
- Logica in de kern: Je voorkomt dat je na maanden ontdekt dat de gekozen data structuur simpelweg niet past bij je bedrijfsmodel.
De versnelling: Agile voor de operationele inrichting
Zodra de basis van de data en de belangrijkste stromen staan, moet je de strakke planning loslaten. De theorie van een architect is namelijk nooit zo slim als de praktijk van de gebruiker. De business weet pas echt wat zij nodig heeft als zij het systeem daadwerkelijk gebruikt.
Vanaf dat moment zijn de snelle feedbackloops van agile werken onmisbaar:
- Contact tussen business en IT: De werkvloer geeft direct aan waar een proces in de praktijk schuurt, zodat de techniek meteen kan worden bijgesteld.
- Directe waarde: Je levert elke twee weken verbeteringen op die de productiviteit van het team meteen verhogen.
- Bouwen wat nodig is: Je stopt met het ontwerpen van functies die in de praktijk niet worden gebruikt en focust op wat de groei echt ondersteunt.
De paradox: Een starre basis met een flexibele schil
Echt schalen gaat over het bouwen van een architectuur die aan de binnenkant onwrikbaar en logisch is, maar aan de buitenkant extreem wendbaar. Een goede architect zorgt dat de fundering vaststaat, zodat het team daarna de vrijheid heeft om in hoge snelheid te sprinten.
Conclusie
Vraag bij een nieuw project niet alleen of een team agile werkt. Vraag hoe zij zorgen dat de fundering en de Single Source of Truth eerst kloppen voordat zij gaan bouwen. De vraag is niet welke methode beter is. De vraag is: is jouw basis sterk genoeg om daarna flexibel te kunnen zijn?