Boekjaar Data Warehouse

Context

Boekjaar verkoopt geautomatiseerde jaarrapportage. Dat werk begint als boekhouddata in het boekhoudsysteem dat de klant al gebruikt, en het moet eindigen als een boekjaarrapport dat iemand kan indienen. Ik werkte rechtstreeks met de medeoprichter, wat in een startup betekent dat de zakelijke vraag en het technische antwoord één gesprek zijn.

De uitdaging

Een rapport is pas automatisch als de data eronder al de juiste vorm heeft, en boekhouddata heeft dat niet. Die komt binnen per klant en per boekhoudsysteem, elk met een eigen idee van wat een grootboekregel is. Het lastigere probleem is het tweede rapport, niet het eerste. Een warehouse gemodelleerd rond de vragen van vandaag heeft een schemawijziging nodig voor die van morgen, en zo'n schemawijziging midden in een rapportageplatform is duur.

Wat ik deed

• De integraties met Exact Online en e-Boekhouden gebouwd, waar de boekhouddata daadwerkelijk leeft, en genormaliseerd wat elk daarvan aanlevert tot één vorm waar het platform mee kan werken.
• Het datawarehouse achter de geautomatiseerde jaarrapportage ontworpen, 25 MySQL-tabellen die de boekjaardata modelleren, gevoed door die integraties aan de ene kant en uitgelezen door de eigen API's van het platform aan de andere.
• Het zo gemodelleerd dat nieuwe analyses erop voortbouwen, in plaats van een schemawijziging te vereisen, en dat is het verschil tussen een warehouse dat meegroeit en een dat opnieuw wordt gebouwd.
• De autorisatie met OAuth 2.0 afgehandeld, omdat dit de financiële administratie van een klant is, en de toegang daartoe iets is wat die klant zelf moet kunnen verlenen en intrekken.
• Draaide het op AWS Serverless, zodat de kosten het werk volgen, wat voor rapportage die in pieken draait in plaats van continu precies de juiste vorm is.
• De flows afgedekt met Playwright, end to end, op de paden waar een verkeerd getal erger is dan een ontbrekende pagina.
• Rechtstreeks met de medeoprichter gewerkt, aan de vraag wat de rapportage moest beantwoorden, zodat het model op echte vragen is gebouwd in plaats van op aangenomen vragen.

Het resultaat

• Jaarrapportage die draait op gegevens die het platform al in de juiste vorm bevat.
• Boekjaaranalyses die gebruikers zelf samenstellen in plaats van aanvragen.
• Een model dat nieuwe analyses aankon zonder opnieuw te worden opengelegd, en dat is wat de automatisering houdbaar maakt.

Gebruikte technologieën

• Node.js: De integratieservices en de API's boven het warehouse.
• AWS Serverless: Hoe die services draaien, zodat de kosten het werk volgen.
• MySQL: Het warehouse zelf, zo gemodelleerd dat nieuwe analyses erop voortbouwen zonder schemawijziging.
• Data warehousing: Het boekjaarmodel achter de geautomatiseerde rapportage.
• OAuth 2.0: De autorisatie achter de integraties met Exact Online en e-Boekhouden.
• API-ontwikkeling: De API's waarmee het platform het warehouse uitleest.
• Playwright: End to end dekking van de rapportageflows.

Rapportage die mensen vertrouwen is eerst een datamodelleringsprobleem en pas daarna een rapportageprobleem, en ik praat liever over het model dan over het dashboard.