Blog

Muisarm, theaterknie of kloppelkoot?

Het zal je maar gebeuren. Ben je net hersteld van je muisarm, gaat het wat beter met je theaterknie, krijg je last van je vingers na een dagje koppelvlakken implementeren… Je gaat naar de dokter en die stelt vast dat je een kloppelkoot hebt opgelopen. Overbelasting van je vingerkootjes door het vele handmatige inklopwerk wat je moet uitvoeren om koppelingen tussen applicaties tot stand te brengen. Deze ‘kloppelingen’ zorgen voor veel kopzorgen. Ze zijn complex, lastig te beheren, foutgevoelig en vooral erg kostbaar. Beste overheid, dat moet toch anders kunnen?

 

Van point-to-point koppelingen naar een wendbare architectuur

De eerste belangrijke overweging is hoe de architectuur wordt opgezet. Nog maar al te vaak zie ik bij overheidsinstanties dat allerlei applicaties rechtstreeks aan elkaar gekoppeld worden. Dit model zorgt uiteindelijk voor een spaghetti aan koppelingen waarbij niemand nog kan overzien hoe de informatiestromen precies lopen, laat staan dat een dergelijke architectuur nog kan meebewegen met de behoeften van de organisatie.

Gelukkig constateer ik ook dat bij de organisaties waarbij een dergelijke ‘architectuur’ bestaat, de betreffende informatiearchitecten zich bewust zijn van de noodzaak hier iets aan te moeten doen, meestal door een Enterprise Service Bus (ESB) te implementeren.  De ESB biedt de mogelijkheid om applicaties op basis van “loose coupling” met elkaar te kunnen laten communiceren. De zendende applicatie communiceert met de ESB, en de ESB zorgt voor de communicatie met de ontvangende applicatie(s). Op deze manier wordt een duidelijke scheiding gerealiseerd tussen een (functioneel georiënteerde) applicatie enerzijds, en de communicatie-infrastructuur anderzijds. De applicatie is verantwoordelijk voor het domein specifieke deel van het bericht (de inhoud). De ESB is verantwoordelijk voor de aflevering van deze inhoud bij de bestemming. Indien noodzakelijk zorgt de ESB voor de vertaling van het berichtformaat alsook het communicatieprotocol, mocht dit voor de betreffende bestemming nodig zijn.

Enterprise Service Bus voor veel organisaties te hoog gegrepen?

Is het niet vreemd dat een architectuurmodel dat al zo lang bestaat nog maar zo weinig wordt ingezet? Eigenlijk niet. De gemiddelde ICT afdeling van een overheidsorganisatie beschikt niet over de juiste capaciteit om dit soort complexe en langdurige transitietrajecten zelf uit te voeren. Het is niet triviaal om een ESB-gebaseerde architectuur organisatie breed uit te rollen terwijl de winkel open moet blijven.

ESB’s zijn over het algemeen generiek inzetbare producten. De protocollen en processen die erin ondersteund worden zijn niet specifiek tot een bepaald business domein afgebakend. Dit is natuurlijk erg flexibel, maar het heeft ook een keerzijde. Het daadwerkelijk implementeren van koppelvlakken moet nog gebeuren. Probeer eens een StUF sectormodel in de gemiddelde ESB te implementeren en je begrijpt wat ik bedoel. Dit is bepaald geen sinecure. Je hebt kennis nodig van technische protocollen, beveiliging, domein-specifieke standaarden en uiteraard van de ESB zelf. En niet zelden moet je een heleboel configuratie aanleggen in technische XML bestanden om het aan de praat te krijgen.

ESB’s bieden een grote variëteit aan mogelijkheden, en kennen daardoor een steile leercurve. Je hebt eerder maanden dan weken nodig om je thuis te gaan voelen in het product en er effectief mee te kunnen werken.

 

Domein-specifieke Service Bus

Door de vergaande mate van standaardisatie binnen de overheidsmarkt op het gebied van gegevensuitwisseling, wordt het steeds beter mogelijk om oplossingen te maken die ‘plug & play’ in te zetten zijn. Standaardproducten waar praktisch alle benodigde koppelvlakken en protocollen zoals Digikoppeling vooraf geconfigureerd in opgenomen zijn. Het gros van het technische configuratiewerk is dan al voor je gedaan en getest met bijvoorbeeld landelijke voorzieningen uit het Stelsel van Basisregistraties.

Zit je daarmee vast aan de betreffende leverancier? Nee, dat hoeft beslist niet het geval te zijn. De betreffende ESB kan ook flexibel uitgebreid worden voor koppelvlakken die nog niet standaard vooraf gedefinieerd waren.

 

Bij gemeenten wordt al heel vaak gebruik gemaakt van een ‘Gemeentelijke servicebus’. Ik ben van mening dat deze ‘best practice’ ook door andere onderdelen van de overheid nagestreefd zou moeten worden. De Nederlandse Overheids Referentie-Architectuur en de verschillende daarvan afgeleide referentiearchitecturen kunnen daar een belangrijke rol in spelen.

Wat mij namelijk opvalt is dat alleen de referentie-architectuur voor gemeenten (GEMMA) een referentiecomponent ‘Gemeentelijke servicebus’ bevat, en dat alle andere referentiearchitecturen (WILMA, PETRA, CORA, VeRa…) het op een generieke ESB houden. Dat is een gemiste kans.

Het lijkt mij een goede zaak als vanuit de NORA-architectuur meer sturing gegeven wordt aan het inzetten van een Domein-specifieke Service Bus.

 

Dit kan de organisaties die hun architectuur baseren op deze referentiearchitecturen veel klopwerk, kopzorgen en kosten besparen! En uiteraard een kloppelkoot voorkomen…

 

Rolf van Deursen

Architect Makelaarsuite bij PinkRoccade Local Government

Deze blog is geschreven door Rolf van Deursen. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van rolfvandeursen
Rolf van Deursen
PinkRoccade - ICT Architect

Rolf van Deursen is als Lead Architect / Business Consultant werkzaam bij PinkRoccade. Met ruim 19 jaar ervaring in het centrale en lokale overheidsdomein heeft hij een realistische blik op ICT in brede zin, en op integratie technologie in het bijzonder.
In zijn huidige functie is hij verantwoordelijk voor de architectuur van het product Makelaarsuite (gericht op integraal gegevensmanagement en informatievoorziening) en vormt hij een belangrijke schakel tussen business en product development. Makelaarsuite ondersteunt zo’n 200 overheidsorganisaties bij het op orde krijgen en houden van hun interne gegevenshuishouding en stelt ze in staat om aan te kunnen sluiten op het landelijke stelsel van basisregistraties.
Daarnaast is hij als expert betrokken bij diverse landelijke overleggen van KING en Logius.

 
Reacties
Geert Wester op woensdag 17 december 2014 11:48

Beste Rolf,
Ik kan je verhaal goed volgen. Hartstikke mooi dat er een servicebus is die je veel zorgen uit handen kan nemen. Ik heb overigens niet altijd gemerkt dat daardoor de stromen echt inzichtelijker werden, maar ja.
Alleen aan het einde snap ik niet dat je de 'gemeentelijke servicebus' (toevallig ook de naam van een product van het bedrijf waar jij aan bent verbonden), en waarvan je gezegd hebt dat dat gewoon een vorm van ESB is, wilt gaan vergelijken met de ESB die in andere architecturen wordt genoemd. Ik zie dan toch eigenijk geen verschillen.

Als we dan toch verbeteringen willen aanbrengen in de architectuur, laten we het dan eens over sectorale gegevensknooppunten hebben (waarmee ik niet het gebruik voor het sociaal domein bedoel, maar meer die van de provincies). Dat lijkt me beter dan nu voor elke gemeente (omdat die nu eenmaal aan StUF vastzitten) een vertaling te willen maken van het HR-model (nee, geen human relations, of human resources, maar Handelsregister).

adgerrits op donderdag 18 december 2014 10:26

De "gemeentelijke servicebus" wordt (voorzover ik weet) voor het eerst gebruikt in paragraaf 5.6 ("Verbinden") in de GEMMA Informatiearchitectuur. Daarmee werden "de binnen een gemeente aanwezige generieke verbindingsvoorzieningen" bedoeld (geen fysieke ICT-oplossing). Dat je daarbij een product gebruikt dat ook de sticker "servicebus" heeft ligt voor de hand, maar zou dus niet eens hoeven.
Ik heb het stuk zelf geschreven in 2009 en weet dus aardig wat ermee beoogd werd. Reden om blij te zijn met wat hierboven door Rolf wordt geadviseerd. Want "verbinden" is qua informatievoorziening misschien wel de belangrijkste (en grootste?) uitdaging voor veel organisaties, waaronder gemeenten. En ja, daarbij horen goede producten en goede mensen. Die er bij veel organisaties nu nog in onvoldoende mate zijn.
De vraag of een generieke of meer specifiek ESB product het beste voldoet is wel een interessante en zal (zoals vaker) mede bepaald worden door wat je wilt bereiken en wat je mogelijkheden zijn. Beide hebben voor- en nadelen en bij grotere organisaties kunnen ze zelfs prima naast elkaar bestaansrecht hebben.
Je opmerking dat het zo veel werk is om "een StUF sectormodel in de gemiddelde ESB te implementeren" zou trouwens ook aanleiding kunnen zijn om na te denken over vereenvoudiging van zo'n sectormodel (maar dat is weer een andere discussie).

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.