Hoe een te brede entiteit elke integratie kapot trekt
Het patroon is altijd hetzelfde. In de eerste versie van de software is er één centraal object: de werkorder, de productieregel, de stuklijstregel. Dat object krijgt in de loop van de tijd steeds meer velden, want elk nieuw verzoek wordt erin geparkeerd in plaats van in een nieuw, gericht model. Na twee jaar heeft die ene tabel veertig kolommen, waarvan een derde in de meeste records leeg is. Op het moment dat je dan een koppeling bouwt naar een ERP-systeem, moet je uitleggen wat veld 27 betekent. Het ERP-systeem heeft geen idee. De ontwikkelaar schrijft een mapping, de mapping werkt, totdat iemand een nieuw veldtype toevoegt aan de werkorder. Dan breekt de mapping. Dit is geen incidentele bug. Dit is de structurele uitkomst van een datamodel dat niet bij de integratie betrokken was.
Relaties die later worden bijgebogen: de stille killer van API-stabiliteit
Erger dan brede entiteiten zijn relaties die achteraf worden bijgebogen. Stel: werkorder en klantorder beginnen als aparte concepten, maar ooit besluit iemand om de klantorder-ID direct in de werkorder te zetten, als snelkoppeling. Handig voor één scherm. Desastreus voor elke API die sindsdien op die relatie leunt. Want een klantorder kan meerdere werkorders aansturen, en een werkorder kan later worden gesplitst. Het datamodel zegt van niet, de werkelijkheid zegt van wel. De API geeft dan verouderde of dubbele data terug, afhankelijk van welk scherm er als eerste werd gebouwd. Koppelingen met klantportals of MES-systemen die op die API vertrouwen, geven verkeerde productiestatussen terug. Niet altijd, want dat zou makkelijk te spotten zijn. Af en toe, precies genoeg om het oplossen tijdrovend te maken.
Wanneer moet je het datamodel herontwerpen voor je verder integreert?
De eerlijke vraag is niet of je het model ooit moet herontwerpen, maar wanneer. Er zijn twee signalen die aangeven dat je er niet meer omheen kunt. Het eerste signaal: elke nieuwe integratie kost meer tijd dan de vorige, ook al lijkt ze op dezelfde koppeling. Dat betekent dat de mapping-logica toeneemt, niet de koppeling zelf. Het tweede signaal: bugs in de integratie zijn niet reproduceerbaar zonder kennis van de interne toestand van het systeem. Als een externe partij, een klant of een nieuw teamlid de output van je API niet kan begrijpen zonder uitleg over zes historische beslissingen, dan is het model de bottleneck. Op dat moment is het goedkoper om het model te herontwerpen dan om door te gaan met adapters. Niet goedkoper op de korte termijn, maar goedkoper over de eerste twaalf maanden na de beslissing.
Wanneer volstaat een tijdelijke adapter in maakindustrie software?
Er zijn situaties waar een adapter de juiste keuze is. Namelijk als het bestaande systeem stabiel is en de koppeling met een extern systeem beperkt is in scope: één richting, beperkt aantal veldtypen, weinig mutatiefrequentie. Een adapter is ook verdedigbaar als de organisatie midden in een grotere migratie zit en de koppeling overbruggend bedoeld is. Wat een adapter nooit is: een structurele oplossing voor een model dat te breed is. Adapters kopiëren het probleem naar een andere laag. Ze vertalen ruis naar ruis, alleen dan in een ander formaat. Na een jaar heb je twee complexe plekken in plaats van één.
Wat je concreet kunt doen als de koppelingen blijven breken
Begin met het in kaart brengen van de entiteiten die in meer dan twee integraties voorkomen. Dat zijn de kandidaten voor herontwerp. Kijk dan per entiteit hoeveel velden optioneel zijn, en of die optionele velden eigenlijk bij een subtype horen. Een werkorder voor revisie is iets anders dan een werkorder voor productie, ook al passen ze nu in dezelfde tabel. Scheiden is in het model weinig werk, in de bestaande koppelingen iets meer. Maar het is eindig werk, in tegenstelling tot het eindeloos herstellen van brekende API's. Als je op dit punt uitkomt en het systeem waarop de integraties draaien is ouder dan vijf jaar, is het ook het moment om te beoordelen of de software zelf aan vervanging toe is. Niet altijd het antwoord, maar een vraag die je op tafel moet durven leggen.