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:
- Betekenisloze identiteitsaanduiding
- Ontkoppelpunten voor complexiteitsreductie en flexibiliteit, maximale onafhankelijkheid van delen
- Consistentie van taal
- Duidelijke verantwoordelijkheidsverdeling en functiescheiding voor de administratie
- Beslissingsbevoegdheid voor de uitvoering zo laag mogelijk beleggen
- Autorisatie loskoppelen van identificatie/authenticatie
- Enkelvoudige vastlegging van stamdata
- Data en metadata scheiden in opslag en verwerking
- Standaardpatronen toepassen zonder afwijkingen
- Applicatiefunctie en dataopslag scheiden
- Apparaat onafhankelijk ontwikkelen
- Kies een opslagstructuur op basis van de eisen
- Maak koppeling zichtbaar
