Webapps
Waarom ik eerst de data modelleer
De meeste mensen denken dat een webapp begint bij een scherm. Het mooie ontwerp, de knoppen, de kleuren. Ik begin liever bij iets wat je nooit ziet: de data.
Dat klinkt saai, en dat is het ook een beetje. Maar de structuur van je data bepaalt alles wat daarna komt. Wat de app kan, wat hij nooit zal kunnen zonder verbouwing, en hoeveel een latere wijziging gaat kosten.
Wat een datamodel eigenlijk is
Een datamodel is gewoon een eerlijke beschrijving van waar je app over gaat. Welke dingen bestaan er, en hoe horen ze bij elkaar?
Neem een offertetool. De dingen zijn: een klant, een offerte, een regel op die offerte, misschien een product. De relaties zijn: een klant heeft meerdere offertes, een offerte heeft meerdere regels, een regel verwijst naar een product. Dat is het. Geen scherm, geen knop, alleen de waarheid over hoe het werk in elkaar zit.
Als die waarheid klopt, voelt de app later vanzelf logisch. Als die waarheid niet klopt, ga je dat in elke knop merken.
Waarom de volgorde ertoe doet
Begin je bij het scherm, dan boetseer je je data naar wat toevallig op dat ene scherm past. Werkt prima, tot het tweede scherm iets vraagt wat je eerste keuze niet aankan.
Ik heb een planningstool gebouwd waar de klant in het begin zei: één medewerker per klus, simpel. We hadden het zo kunnen bouwen, een klus heeft een medewerker, klaar. Maar in het gesprek bleek dat ze bij grotere klussen soms met z'n drieën gingen. Dat ene zinnetje veranderde het hele model: een klus heeft meerdere mensen, met een rol erbij.
Hadden we dat na de bouw ontdekt, dan was het geen klein klusje geweest. Dan zit zo'n aanname verweven in het scherm, in de planning, in de uren-export. Nu kostte het een gesprek van tien minuten.
Verkeerd model, late pijn
Het vervelende aan een fout datamodel is dat je het niet meteen voelt. De eerste versie werkt. De pijn komt later, als je iets wilt toevoegen wat eigenlijk nooit had gepast.
Dan hoor je mij zeggen dat een ogenschijnlijk kleine wens een week werk is. Niet omdat ik traag ben, maar omdat de fundering verbouwd moet worden terwijl het huis er al op staat. Die week had niet gehoeven als we de relatie vooraf goed hadden gelegd.
Hoe ik het in de praktijk doe
Voor de bouw teken ik de entiteiten en hun relaties uit, vaak op één A4. Klant, offerte, regel, met pijlen ertussen. Dan loop ik dat met je na met echte voorbeelden. Wat als deze klant twee bedrijven heeft? Wat als een offerte wordt herzien, is dat een nieuwe of dezelfde?
Die vragen zijn niet technisch, ze gaan over jouw werk. Jij weet de antwoorden beter dan ik. En elk antwoord dat we vooraf vinden, is een verbouwing die we onszelf besparen.
Een goed datamodel is grotendeels onzichtbaar. Je merkt het alleen als het ontbreekt.
Zie ook: Begin met het lelijkste scherm en Waarom de eerste versie van je webapp maar één ding moet doen. Een idee dat je scherp wilt krijgen? Bekijk hoe ik webapps bouw.