
De overstap naar een Enterprise Service Bus (ESB)
In een ideale situatie worden binnen een gemeente dezelfde gegevens eenmalig geregistreerd en meervoudig gebruikt. Een Enterprise Service Bus (ESB) zorgt daarbij voor een koppeling tussen bron- en afnemende applicaties, via één vaste, organisatiebrede standaard. Wij adviseren een ESB stap voor stap te implementeren.
Datadistributie
Op dit moment gebruiken veel gemeenten een of meerdere datadistributiesystemen voor het uitwisselen van data tussen applicaties. Denk hierbij aan systemen als Key2Datadistributie of de Gegevensmakelaar. Zo’n systeem ontvangt mutaties, beoordeelt ze en zorgt ervoor dat de afnemende applicaties over deze mutaties beschikken. Vaak voert een dergelijk systeem ook bewerkingen uit op de data. De applicatiebeheerder van het datadistributiesysteem beheert de regels die hierbij horen. Nadeel hiervan is dat deze regels veel onderhoud vragen en je andere applicaties niet zomaar op een bepaald datadistributiesysteem kunt aansluiten.
Wat is een enterprise service bus (ESB)?
Een ESB zet berichten uit een bronapplicatie realtime, één-op-één, door naar alle andere applicaties die gegevens uit dat bericht nodig hebben. Daarvoor kijkt een ESB alleen naar de metadata, niet naar de inhoud van een bericht. Ook voert een ESB geen bewerkingen uit. Registraties en vakapplicaties kijken zelf welke data ze gebruiken. Groot voordeel is dat een ESB een vaste standaard voor berichten gebruikt, meestal StUF. Hierdoor is het mogelijk om, als een ESB eenmaal draait, er tegen een relatief geringe beheerlast allerlei applicaties en diensten aan te koppelen.
Big Bang?
De standaardisering van berichtenuitwisseling via een ESB kan voor gemeenten een belangrijke stap zijn richting eenmalige gegevensopslag en meervoudig gebruik. Maar hoe maak je de overstap van een structuur met een of meerdere datadistributiesystemen naar een centrale ESB? Je kunt kiezen voor een Big Bang, waarbij je van de ene op de andere dag overgaat. Dat vraagt echter veel voorbereiding, met enorme afstemmings- en testinspanningen. Dit scenario heeft niet onze voorkeur, omdat de kans op fouten dan groot is en de gevolgen daarvan enorm kunnen zijn.
Bron na bron
Een ander scenario is bron na bron overstappen. Je koppelt dan eerst één bronapplicatie aan de ESB. Die ESB koppel je, tijdelijk, aan je huidige distributiesysteem. Zo verandert er voor de daadwerkelijk afnemende applicaties nog niets, maar zet je al wel de eerste stap. Iedere keer nadat dit voor een bronapplicatie naar tevredenheid werkt, sluit je de volgende bronapplicatie aan. Na de bronapplicaties volgen de afnemende applicaties. Het klopt dat er dan tijdens het project zowel een ESB als een of meerdere distributiesystemen actief zijn. Dat is financieel weliswaar een extra kostenpost, maar daar staat een technisch en functioneel beter uitvoerbare operatie tegenover.
Met een ESB gebaseerd op standaard berichtformaten, creëer je een universele ‘stekker’ voor alle registraties en applicaties die informatie van elkaar nodig hebben. Als je de keus hebt, is bron na bron aansluiten zeker aan te raden. Daarmee houd je het proces het beste onder controle.”
André Zuidhof, Informatie adviseur
Verborgen functionaliteiten
Ook bij het koppelen van een bronapplicatie of afnemende applicatie aan de ESB is het verstandig belangrijke stappen na elkaar te zetten. Denk aan: voorbereiden, koppelen, testen, naar productie, evalueren. Hierbij kunnen ‘verborgen’ functionaliteiten van een datadistributiesysteem zichtbaar worden, bijvoorbeeld data die wordt bewerkt voordat deze wordt doorgegeven. Deze functionaliteiten moeten worden verplaatst naar de koppeling tussen de applicatie die de bewerking nodig heeft en de ESB. De ESB zelf moet zo standaard mogelijk blijven, zodat alle systemen binnen en buiten de organisatie er gebruik van kunnen maken.
Meer weten over een ESB?
Stel je vraag aan Jos. Of laat een bericht achter in de chat.