Constructieprincipes voor de informaticus (13): Maak koppeling zichtbaar

Door: Rutger Gooszen

In deze serie van blogs sta ik stil bij de nog steeds geldige informatiekundige constructieprincipes die garant staan voor betere “informatiebouwwerken”. Deze 13^e en laatste blog in de reeks vervolgt met het vierde informatica principe (zie voor het onderscheid mijn startblog). Een principe voor de informatiekundige luidt “ontkoppelpunten voor complexiteitsreductie en flexibiliteit”. Maar een ontkoppelpunt is tegelijk een koppeling in het systeem als geheel! Alle koppelingen (ook vaak interfaces genoemd) moeten zichtbaar blijven, als je er één tegen komt moet je hem herkennen. Dit geldt overigens in dezelfde mate voor een bedrijfskundige; ook organisaties hebben koppelingen en afhankelijkheden en die moeten zichtbaar zijn.

Ontkoppelen = koppelen!

Koppelingen zijn onvermijdelijk en vaak zelfs gewenst om te kunnen ontkoppelen en complexe systemen op te delen in beheerbare componenten (“minimale koppeling, maximale samenhang”). Maar het moet altijd duidelijk zijn voor degene die een wijziging wil aanbrengen in component 1 wat die wijziging voor gevolgen heeft in de gekoppelde component 2 en verder. Dus er moet inzicht zijn in de aangebrachte koppelingen. Een goed aangebracht ontkoppelpunt zorgt juist voor onafhankelijke componenten die onafhankelijk van elkaar kunnen werken. De interne werking van de component is onzichtbaar voor de gekoppelde buitenwereld en kan worden gewijzigd zonder consequenties voor de omgeving zolang de functie naar buiten hetzelfde blijft. Maar of de wijziging impact heeft op de functie naar buiten moet inzichtelijk zijn. Dat kan door goede documentatie over de koppelingen in een systeem en/of testen en scenarioanalyse.

Onzichtbare koppelingen en modulariteit

In veel informatielandschappen zijn onzichtbare koppelingen aanwezig. Het stelsel van de basisadministraties is er één van. Realiseert iedere houder van een administratie zich de consequenties van het wijzigen van het gegevensmodel (een object, de betekenis, attributen of relaties) bij alle afnemers? De interne samenhang van de gegevens in het stelsel is niet onzichtbaar voor de buitenwereld omdat de verwevenheid zo groot is. Dat vereist minutieuze documentatie over aansluitvoorwaarden en een goed beheerst wijzigingsproces.

Door het veelvuldig toepassen van het modulariteitsprincipe in het applicatielandschap ontstaat tegelijk het vraagstuk van inzicht in de samenhang van het landschap als geheel. De samenhang van de domeinen (CRM, financieel, HRM, transactiesystemen) blijft immers bestaan als je domeinen modulair maakt. Het wijzigen van de CRM module kan impact hebben op de financiële module. De koppelingen moeten dus zichtbaar zijn!

Onzichtbare koppelingen en herleidbaarheid

Vanuit het perspectief van een audit moet het mogelijk zijn om vanuit de uitvoer de invoer op te sporen die tot die uitvoer heeft geleid. Dit is bij veel toepassingen voor het maken van rapportages en analyses ook uitgangspunt. Maar dat vergt veel van de vastlegging van metadata bij de registratie van de brondata en bewerkingen daar op. Met de huidige technieken voor Big- data-analyse en zeker AI-algoritmen wordt dit steeds lastiger. Feitelijk gaat gebruik van AI in tegen het principe van onzichtbare koppelingen vermijden want je hebt te maken met een probabilistisch verwerkingsproces in plaats van een deterministisch proces.

Bouw van code en regressietesten.

Het feit dat bij de bouw van (complexe) code nog steeds regressietesten nodig zijn onderstreept dat alleen documentatie niet voldoende is om onzichtbare koppelingen te vermijden. Testen blijft nodig om ze aan het licht te brengen in complexe systemen. Het blijkt toch steeds weer lastig om echt onafhankelijke componenten te ontwikkelen die blijven voldoen aan de interfacekarakteristiek zoals die was gedocumenteerd naar de buitenwereld. En dus vallen bij een nieuwe release bepaalde functies “om” omdat de impact van een wijziging elders in het landschap onvoldoende zichtbaar was.

Het belang van documentatie en afspraken

Documentatie maakt dingen zichtbaar door ze te beschrijven. Een koppeling moet gedocumenteerd zijn om de werking te weten en de impact van een wijziging in de component te kunnen beoordelen. Wie ooit in de buurt van een stopcontact of waterleiding in de muur heeft geboord weet wat de waarde is van kennis over waar die leidingen lopen. Muur en waterleiding zijn zelfstandige componenten maar ze zijn wel fysiek gekoppeld. Daarom staat bij waterwegen langs de kant een geel bord met de letter K er op. Zodat bij baggeren van het kanaal duidelijk is waar de koppeling met die kabel zich bevindt.

Het kan niet genoeg worden benadrukt; documenteer alle koppelingen en onderhoud deze documentatie!

Daarnaast zijn afspraken nodig over de wijzigbaarheid van de koppeling zelf als die eenmaal is gerealiseerd. Denk aan backward compatability, twee opvolgende versies naast elkaar kunnen draaien en dergelijke.

Conclusie

Als informaticus moet je alle interfaces zichtbaar maken en documenteren omdat je niet kunt voorzien hoe in de toekomst een koppeling kan worden beïnvloed door een nieuwe ontwikkeling. Om bij veranderingen de impact op het systeem als geheel te kunnen bepalen is inzicht in alle koppelingen essentieel.

Lees hier de andere constructieprincipes:

Gerelateerde Insights