Repareer het contract, niet de dashboards

Het ticket

“Sommige dashboards laten verkeerde cijfers zien — kun je dat fixen?”

Dat was het ticket. Standaard data-engineeringwerk in theorie: een middag besteden, de foute join vinden, een fix uitrollen, doorgaan.

Het ticket was een symptoom

Het werkelijke beeld, zodra je voorbij de verkeerde cijfers keek: het data-team van PVH was in twee helften gesplitst die elkaars code eigenlijk niet konden lezen —

• DA (analisten) maakten prototypes in notebooks — SQL waar het kon, Python waar dat niet kon.
• DE (engineers) implementeerden diezelfde logica opnieuw in PySpark, brachten het naar productie op Spark, scheduleden het via Airflow, en koppelden het aan BI.

Elk dashboard werd zo twee keer geschreven. Een discrepantie debuggen vroeg om een meeting. Een nieuw dashboard kostte ~2 weken DA-notebookwerk plus 1–2 sprints DE-herimplementatie.

DE werd de zichtbare bottleneck. Dus stopten DA’s stilletjes met het platform — ze draaiden notebooks met de hand rechtstreeks naar BI. Version control, tests, lineage, alerting, monitoring: weg. Alles wat DE had gebouwd om de cijfers kloppend te houden, zat nu upstream van het werkelijke leveringspad.

De “verkeerde cijfers” waren het meest zichtbare symptoom van die schaduw-pipeline, niet de oorzaak.

Het lastige was de goedkeuring

Het zien was niet het lastige deel. Ik had de rework-loop tijdens mijn eerste engagement bij PVH al aangekaart en geprobeerd verandering door te drukken. Daar kwam niks van — en dat was ook terecht. CRM was eigenaar van de dashboards, hun analisten van de notebooks. Hen vragen om hun manier van werken te veranderen op het woord van een contractor die was vertrokken en teruggekomen — dat was niet iets dat engineering eenzijdig kon afdwingen. Het vertrouwen was er nog niet.

Dus de eerste maanden van de tweede engagement deed ik gewoon dingen fixen. Tickets met verkeerde cijfers, Spark-performance-incidenten, IAM-chaos — ik pakte ze op en leverde. Dat leverde een ander soort krediet op dan argumenteren.

De opening kwam in de vorm van weer een “verkeerde cijfers”-ticket. In plaats van het alleen te patchen, trok ik een week uit en bouwde een parallelle omgeving die het nieuwe contract end-to-end draaide: één notebook geschreven als DA-stijl SQL, de commit-time lint, de YAML-catalog, de DQ-gate, hetzelfde dashboard opgehaald uit het nieuwe pad. Naast prod, dezelfde inputs, dezelfde outputs.

Dat was genoeg.

Wat we daadwerkelijk veranderden

Niet “fix de dashboards.” Niet “huur meer DE’s aan.” Verander het contract tussen DA en DE.

• DA schrijft alleen SQL — geen PySpark. De reden is mechanisch: statische analysetools zoals sqlfluff kunnen SQL ontleden tot op de IO-relaties, dus een lint-hook weet welke tabellen een notebook leest en schrijft, en kan daarop een gate plaatsen. PySpark is op het business-niveau niet op dezelfde manier hanteerbaar — om te weten wat het daadwerkelijk doet, moet een mens het lezen.
• Notebooks worden gelint bij commit. Inputs moeten uit door DE beheerde tabellen komen. Outputs moeten idempotent zijn. Overtredingen falen bij git commit — DA hoort het meteen, niet drie dagen later in de standup.
• Eén YAML catalogiseert alle notebooks. Tabellen in, tabellen uit, schedule, eventuele speciale runtime-vereisten. Die YAML is de single source of truth waaruit Airflow schedulet, en levert lineage en upstream-readiness-checks er gratis bij.
• DE neemt de boilerplate één keer voor zijn rekening. Upstream-checks, catalog-interactie, IAM, BI-levering, en de data-quality-gate die gevalideerde rijen uit DA’s self-service-tabel promoveert naar DE’s gelijknamige productietabel. DA is alleen verantwoordelijk voor de transformatielogica.

Vier dingen. Geen ervan is een dashboard.

De cijfers

Metric	Voor	Na
Nieuw-dashboard TTM	4–6 weken	1–2 uur
DE-tijd teruggewonnen	—	~5 mandagen / sprint
Dashboard-refresh klaar	10–11 AM	5–7 AM

DE besteedde de teruggewonnen dagen aan echt platformwerk — bronkwaliteit, performance-bottlenecks, lineage UI, compute/storage- efficiëntie. Dingen waarvoor ze tickets hadden geschreven en nooit aan toekwamen.

Wat ik hieruit meeneem

De meeste engineering-problemen zijn niet “we weten niet hoe we X moeten bouwen.” Ze zijn “we weten eigenlijk niet wat we aan het bouwen zijn, en we voegen complexiteit toe om dat te compenseren.” De dashboards waren niet kapot. De overdracht tussen twee teams was dat, en de organisatie had daar een parallelle schaduw-pipeline omheen gebouwd, alleen om te kunnen blijven leveren.

Elk systeem tendeert naar hogere entropie. De vraag die ertoe doet, is wat je verandert zodat het een tijdje de andere kant op gaat. Meestal is dat een contract, niet een stuk code.