Maak de integratie-archeoloog overbodig: breng een bezoek aan de autodealer!

De oude Grieken en Romeinen staan onder meer bekend om hun robuuste bouwwerken. Die bouwden echt voor de toekomst en daarom kunnen we tot op de dag van vandaag nog vele mooie amphitheaters, aquaducten en tempels van weleer bezoeken.

Indrukwekkend hierbij zijn ook vaak de, met name bij tempels, toegepaste zuilen. Ooit lang geleden heb ik nog geleerd dat er Dorische, Ionische en Korinthische zuilen zijn, elk met hun eigen stijlkenmerken.

Maar wat heeft dit met integratie te maken?

Nou - ook in de integratiewereld doe ik nog regelmatig archeologische vondsten. Ook bij integratie blijken de oude technieken na tijden nog overeind te staan: de database-integraties! Ongeveer het begin van de integratiebeschaving(Verwijst naar een externe website).

Je herkent ze in integratie-landschappen aan de cilinder/zuil-vormige icoontjes. Net zoals de zuilen van de oude Grieken en Romeinen staan ze vaak nog fier overeind in het landschap, maar kun je je ook afvragen of het verstandig is om hier nog belangrijke constructies op te baseren.

Databasekoppelingen resulteren regelmatig in één of meer van de volgende anti-patronen:

• Een complexe query (al dan niet met business logica) die vanuit de interface wordt gedraaid. Hiermee creëer je een harde koppeling tussen de interface en de database: bij aanpassingen in de database wordt de integratie ook geraakt.
• Bij het aanroepen van de database (bijvoorbeeld een stored procedure) kan een cache-mechanisme in werking treden. Hierdoor kan het zijn dat je bij iedere databasewijziging de interface moet herstarten (ook al wordt de interface er zelf níet door geraakt).
• Constructies waarbij er periodiek complete tabellen worden overgenomen en vergeleken met de vorige keer, om op basis van 'zoek de verschillen' deze als wijzigingen door te sturen. Dit is verre van efficiënt en snel.
• Het ophalen van één record per keer uit een wijzigingen-tabel. Hier kun je in de knel komen qua verwerkingssnelheid, want je kunt de tijd tussen twee keer een record ophalen niet oneindig klein maken. En als je maximaal 1 x per 5 seconden iets kunt ophalen, zit je toch echt met een probleem als er meer updates per dag zijn dan je kunt verwerken (12 per minuut x 60 minuten x 24 uur = 17k updates).
• Als je gegevens rechtstreeks in een tabel/database wegschrijft omzeil je de validaties die normaliter plaatsvinden als je de gegevens via de applicatie invoert. En ook worden andere processen mogelijk niet getriggerd.
• En het kan complex worden om de status van verwerking goed bij te houden. Je kunt een update pas écht uit de tabel/database afstrepen als deze helemaal aan het einde is aangekomen. Dus daar dien je rekening mee te houden met je foutafhandeling.

In deze moderne tijden werken we liever met API's en Events, in plaats van met databasekoppelingen.

En dat is dan ook meteen een oproep aan applicatie- en solution-architecten: Betrek 'integratie' tijdig in wijzigings- en vernieuwingstrajecten. Neem al in een vroeg stadium contact op met je integratie-architect. Check de huidige architectuurprincipes. Moderniseer waar mogelijk - ga bij nieuwe applicaties uit van de nieuwste richtlijnen, en bij het vervangen van applicaties eigenlijk ook. Blijf niet hangen in een 'as-is' of '1-op-1' mantra. Je kunt niet iets willen wijzigen of vernieuwen, zonder iets te veranderen.

Als je een nieuwe auto koopt doe je dat ook niet. Ja... hij moet je nog steeds van A naar B brengen, maar tegenwoordig kijken er meer en meer mensen naar hybride of elektrische auto's, verwacht je dat er een navigatiesysteem in zit, en dat-ie zuiniger is dan de auto die je 10-20 jaar geleden had. Waarom zie ik dat bij interfaces niet gebeuren?

Training ‘360° blik op integratie’

Wil je meer weten over dit onderwerp, dan is wellicht onze integratie training interessant voor je. In 2 dagen geven we je een 360° blik op integratie. We kijken naar de basisbegrippen, architectuur, implementatie en organisatie & beheer van integratie en interfaces. We behandelen integratie op het niveau van architecten, project managers, product owners, team leads, afdelingshoofden. Er zit géén programmeer-werk in deze training. Dit najaar staat er weer een sessie gepland op donderdagen 24 en 31 oktober 2024.