Bijna elk bedrijf heeft er één: een systeem dat al vijftien jaar draait, waar de hele administratie in zit, en waar niemand meer aan durft te komen. De leverancier bestaat niet meer of rekent per koppeling een bedrag waar je van achteroverslaat. Toch is zo’n systeem vrijwel altijd te ontsluiten, en meestal zonder het te vervangen.
Eerst kijken, dan koppelen
Voor je iets bouwt wil je drie dingen weten. Waar staat de data fysiek, in welk formaat, en hoe vaak verandert hij? Een systeem waarvan de database op een server in de meterkast draait vraagt een andere aanpak dan een gehost pakket waar je alleen via het scherm bij kunt.
Even belangrijk: wat mag je contractueel? Sommige leveranciers verbieden directe databasetoegang expliciet, en daarvan afwijken kost je je support. Dat uitzoeken kost een middag en voorkomt dat je een koppeling bouwt die je niet mag gebruiken.
Route 1: een API-schil eromheen
Je bouwt een aparte laag die met het oude systeem praat op de manier die het begrijpt, en naar buiten een moderne API aanbiedt. Al je nieuwe software praat alleen nog met die schil.
Dit is de duurste route om te bouwen en veruit de beste om mee te leven. Het oude systeem wordt vervangbaar zonder dat er iets anders hoeft te veranderen, want alles eromheen kent alleen de schil. Vervang je later de kern, dan pas je de schil aan en merkt de rest het niet.
Kies dit als het legacy-systeem op termijn weg moet, of als er meerdere applicaties aan gaan hangen.
Route 2: rechtstreeks op de database, alleen lezen
Veel oudere systemen hebben een gewone relationele database eronder. Een gebruiker met uitsluitend leesrechten, het liefst op een replica, geeft je toegang zonder dat je iets kunt breken.
Snel en goedkoop, met twee nadelen. Je omzeilt de bedrijfsregels van de applicatie, dus je moet zelf snappen wat de data betekent: welke statuscode geannuleerd betekent, welke records zachte verwijderingen zijn. En bij elke update van het pakket kan het schema wijzigen, waardoor je koppeling stilvalt.
- Doe dit nooit schrijvend: rechtstreeks wegschrijven in de database van een pakket omzeilt validaties en triggers. Dat gaat lang goed en dan een keer heel hard mis.
- Werk op een replica: dan raakt een zware query nooit het productiesysteem waar mensen op zitten te wachten.
- Leg het schema vast: documenteer waar je van afhankelijk bent, zodat een update van het pakket een gerichte controle wordt in plaats van een zoektocht.
Route 3: bestandsuitwisseling op een vast ritme
Vrijwel elk systeem kan exporteren, al is het maar een CSV naar een map. Een geplande export, opgehaald via SFTP en ingelezen door een verwerkingsstap, is een volstrekt legitieme koppeling.
Onderschat dit niet omdat het onmodern klinkt. Het is robuust, goed te controleren en je kunt elk bestand bewaren, zodat je bij een fout precies ziet wat er binnenkwam. Het nadeel is de vertraging: je werkt met de stand van het laatste uur of de laatste nacht, niet met realtime gegevens.
Voor rapportage, facturatie en voorraadstanden is dat prima. Voor iets waar een klant op zit te wachten niet.
En als geen van drieën kan
Dan rest schermautomatisering: software die het systeem bedient zoals een medewerker dat doet. Het werkt, maar het breekt bij elke schermwijziging en het is traag. Beschouw het als tijdelijke overbrugging, niet als oplossing.
In de praktijk komen we daar zelden aan toe. Wij beginnen een koppeltraject altijd met een inventarisatie van wat er technisch en contractueel mogelijk is; daar rolt bijna altijd een van de drie routes hierboven uit. Wil je weten wat er in jouw situatie kan? Vraag een gratis analyse aan.