In deze serie van blogs sta ik stil bij de nog steeds geldige informatiekundige constructieprincipes die garant staan voor betere “informatiebouwwerken”. Ze zijn soms, in de vaart van de voortschrijdende technologie, vergeten. Met als gevolg wankele of slecht onderhoudbare en uitbreidbare “informatiebouwwerken”. In deze tweede blog sta ik stil bij de kunst van het ontkoppelen.
Een goed ontwerp kent zogenaamde ontkoppelpunten. Denkbeeldige knippen in de complexiteit van het geheel die zorgen dat de delen, zo onafhankelijk als mogelijk, los van elkaar kunnen worden ontwikkeld, geïmplementeerd en (op termijn) vervangen. Interoperabiliteit dus, zonder centrale sturing. In zijn ultieme vorm is dit de “service oriented architecture (SOA)” maar die is in allerlei verschijningsvormen ontwikkeld.
Op organisatieniveau is dit te realiseren door te denken in diensten. Denk bijvoorbeeld aan de dienst die PostNL levert aan BOL.com in de logistieke keten. Via dienst-oriëntatie kun je de processen en bedrijfsfuncties die een eindproduct leveren in een voortbrengingsketen of netwerk ontkoppelen. De interne voortbrenging van de dienst zelf is een “black box” voor de afnemer van de dienst en je kunt zo als afnemer of keten diensten combineren tot ketens van diensten mits de koppelvlakken of aansluitvoorwaarden eenduidig zijn gespecificeerd. Vaak in de vorm van een contract. In de strafrechtketen doelarchitectuur is dit principe van ontkoppeling door dienst-oriëntatie toegepast omdat daar de onafhankelijkheid van de ketenpartijen een groot goed is terwijl er een gemeenschappelijk doel moet worden bereikt. (hiervoor is onder andere gebruik maakt van het gedachtegoed van Jan Dietz genaamd DEMO[1]).
De architect moet hier vooral letten op het vermijden van bottle necks of single points of failure. Welke alternatieven zijn er voor een dienst (flexibiliteit)? En zijn de contracten bindend genoeg om de voortbrengingsketen te laten draaien (denk ook aan de unhappy flow en uitzonderingen)?
Een voorbeeld van een keten waar dit nu moeizaam lijkt te gaan is de vreemdelingenketen. Is er wel voldoende ontkoppeling tussen de diensten van KMAR, IND, COA en gemeenten om het gezamenlijke doel te kunnen bereiken?
Op het niveau van informatie en communicatie en betekenis (semantiek) is het gebruikelijk om interoperabiliteit te bereiken met vertalingen tussen de verschillende domeinen of organisaties om te vermijden dat iedereen dezelfde “taal” moet spreken (wat vaak een grote inspanning vraagt). Informatie bestaat in een bepaalde context en die bepaalt de betekenis. Zonder context is informatie slechts data en die is dan meestal niet eenduidig voor iedereen te interpreteren. Zo kent het domein van financiële verantwoording XBRL als taal terwijl in het zorgdomein de standaard HL7 zorgt voor eenduidige betekenis. Toch is het afstemmen van semantiek een tijdrovend proces. Een alternatief is daarom Linked data als een oplossing om informatie in context te kunnen duiden, ongeacht het domein[2]. Linked data ontkoppelt feitelijk het gegeven van het domein.
Op technologie niveau zien je hier het ontkoppelen van de lagen (presentatie, applicatie, dataopslag) en ontstaan van technische koppelvlakken, API’s, waarop iedereen zonder verdere afstemming kan aansluiten en waarmee allerlei gegevensdiensten technisch kunnen worden ontkoppeld. Microservices zijn hier een implementatie van het SOA idee. Technisch ontkoppelen voorkomt ook vendor lock in door afspraken te maken over open standaarden en migratiemogelijkheden van data.
Omdat we tegenwoordig steeds meer in netwerken en ketens samenwerken is de kunst van het ontkoppelen belangrijker geworden om afhankelijkheden en complexiteit te reduceren. Het ontwerp van een oplossing moet daarom worden getoetst op deze afhankelijkheden en voorzien in logische ontkoppelpunten en alternatieve “leveranciers” om ze te verkleinen.
[1] https://en.wikipedia.org/wiki/Jan_Dietz
[2] Zie SKOS https://www.w3.org/TR/skos-reference/#L895
Andere blogs uit deze serie:
De 1ste blog, over betekenisloze identiteitsaanduiding, lees je hier.
De 3de blog gaat over eenduidige en consistente taal: link.
De 4de blog gaat over verantwoordelijkheidsverdeling en functiescheiding: link.
De 5de blog gaat over dat de verantwoordelijkheid voor besluiten zo laag mogelijk in de organisatie moet liggen: link.
De 6de blog gaat over aantonen “wie je bent” loskoppelen van “wat je mag”: link.
De 7de blog gaat over enkelvoudige registratie van stamgegevens: link.
De 8de blog gaat over data en metadata scheiden in opslag en verwerking: link.