Het principe ‘eenmalige opslag, meervoudig gebruik’ is vaak verspilling van middelen en hoort niet in architectuurdocumenten thuis. Het verordonneren dat informatie voortaan nog maar op één plek wordt opgeslagen en door alle mensen en systemen wordt gebruikt, klinkt simpel. Maar is buitengewoon complex.
In bijna ieder zichzelf respecterend architectuurdocument is een prominente plaats ingeruimd voor het principe ‘eenmalige opslag, meervoudig gebruik’. Een principe waar je bijna niet tegen kunt zijn: niemand wil dat een brandweerauto vaststaat voor een wegopbreking, terwijl de verantwoordelijke afdeling de opbreking toch echt had ingevoerd. Of dat post gestuurd wordt naar overleden personen, terwijl het overlijden wel degelijk netjes en tijdig was gemeld. Maar hoe haalbaar is het in de praktijk? En is het eigenlijk wel altijd nodig om ernaar te streven? Eenmalige opslag, meervoudig gebruik als algemeen principe nastreven is vaak verspilling van middelen en hoort – in deze algemene vorm – dus niet in architectuurdocumenten thuis. Eenmalige opslag van een bepaald soort gegeven voegt niet altijd voldoende waarde toe en is zeker niet altijd nodig. Het implementeren van maatregelen om de eenmalige opslag van informatie te garanderen vraagt vaak veel tijd en geld. De welbekende wirwar van met elkaar gekoppelde systemen binnen veel organisaties heeft meestal zijn weerslag op het gegevenslandschap: dezelfde soort informatie wordt, vaak onbewust, op meerdere plekken geregistreerd. De architectenoplossing – middels een principe verordonneren dat informatie voortaan nog maar op één plek wordt opgeslagen en dat die ene vastlegging vervolgens meervoudig, door alle mensen en systemen die de informatie nodig hebben, gebruikt wordt – klinkt simpel. Maar die ene opslag kiezen, geschikt maken voor gebruik door anderen, nieuwe koppelvlakken realiseren, de ongewenste registraties opruimen: dat vraagt veranderingen op allerlei niveaus.
MEER DAN IT ALLEEN
Integratietechnologie wordt slimmer en goedkoper. En iedereen kent buzzwords als Enterprise Service Bus (ESB). Voor je het weet verwordt het inrichten van eenmalige opslag dan ook tot een IT-aangelegenheid. Technologie is echter maar een van de vele relevante invalshoeken:
- ARCHITECTUUR
Welke gegevens beheert de organisatie en waar worden deze bijgehouden? Welke andere bronnen, zoals Excel-lijstjes, hobbymatig gebouwde databases en nog niet gedigitaliseerde of gestructureerde documenten, zijn er? Waar is uitwisseling met ketenpartners of basisregistraties nodig? Wat doen we met gegevens die niet in de eenmalige bron worden opgenomen, maar daar wel aan gerelateerd zijn?
- ORGANISATORISCHE INRICHTING
Wie is eigenaar van de gegevens en/of opslag? Wie neemt beslissingen over wat wel/niet in de opslag zit en stemt af met bijvoorbeeld de beheerders en afnemers van de gegevens? Wie maakt afspraken over kwaliteitsaspecten, zoals correctheid en tijdigheid?
- BEHEER EN BORGING
Wie is aanspreekpunt voor de gegevens en wie voor de opslagvoorziening? Waar en hoe kunnen gebruikers fouten in de gegevens terugmelden en wie herstelt – en hoe snel – die fouten? Wie borgt dat mensen en systemen inderdaad de eenmalige opslag bevragen en niet zelf gegevens vastleggen of uitvragen?
- SEMANTIEK
Wat betekenen gegevens precies? Heeft iedere gebruiker hetzelfde beeld bij die betekenis? Hoe wordt die betekenis vastgelegd en gedeeld met de gebruikers van de gegevens?
- META INFORMATIE
Als gebruik gemaakt moet worden van door anderen vastgelegde gegevens, is informatie dan beschikbaar over die vastlegging? Wie heeft de gegevens wanneer ingevoerd en onder welke omstandigheden zijn de gegevens vastgesteld of gemeten?
- TOEGANG EN PRIVACY
Hoe borg je dat informatie alleen kan worden ingezien door personen die daar recht op hebben? Of dat informatie alleen wordt gebruikt waarvoor die oorspronkelijk is vastgelegd? Welke (wettelijke) eisen en regels zijn van toepassing en hoe wordt daaraan voldaan?
Dat zijn dan ook serieus complexe trajecten, met impact dwars door de hele organisatie en het applicatielandschap heen. Prioritering is daarom van belang. Waar voor een ziekenhuis het op orde hebben van patiëntgegevens cruciaal is, is het voor een veiligheidsregio veel urgenter om geografische informatie goed te beheren. Nadenken over de vraag wat de gevolgen zijn van het hebben van verkeerde informatie kan helpen om te bepalen voor welke soorten informatie het streven naar eenmalige opslag écht relevant is. En dus om een veel concretere variant van het architectuurprincipe op te stellen waar een organisatie wél iets aan heeft.
Nauwelijks haalbaar
Haalbaarheid is een ander probleem. Op papier laat een landschap met unieke bronnen voor de verschillende soorten gegevens zich prima uittekenen. Eigen kernregistraties en landelijke basisregistraties vormen een vast onderdeel van het plan, net als koppelingen om gegevens door het landschap te verspreiden of API’s om de informatie live uit de bron op te halen. Maar dan de praktijk: veel organisaties maken gebruik van allerlei standaardpakketsoftware. Is het mogelijk zo’n pakket naar het gewenste gegevensmodel in te richten? Of om koppelvlakken te realiseren om gegevens te ontsluiten naar andere systemen, danwel gegevens uit andere systemen te gebruiken? Is er kennis en technologie voorhanden om al die koppelvlakken te realiseren en beheersbaar te houden? Door de noodzakelijke hoeveelheid maatwerk kan het middel erger worden dan de kwaal (zie kader). Echte eenmalige opslag is vaak nauwelijks haalbaar – en dat is helemaal niet erg. Kern van de zaak is dat informatie eenduidig en eenmalig geregistreerd of gemuteerd wordt. Dat er vervolgens gegevens nog (geautomatiseerd) gekopieerd worden naar andere applicaties – en dus feitelijk meervoudig in plaats van eenmalig worden opgeslagen – is in veel gevallen veel minder van belang. Als maar volkomen helder is wat in een bepaalde gebruikscontext de bron en actualiteit van de betreffende informatie zijn. Eenmalige vastlegging en van daaruit ontspringende beheerste informatiestromen is een ambitie die haalbaarder en vaak ook al ruim voldoende is. En die dus meer op zijn plaats is als architectuurprincipe.
“Architecten die het principe opnemen in documenten, leveren half werk.”
Halfbakken tussenresultaat
Architecten die eenmalige opslag, meervoudig gebruik als algemeen architectuurprincipe opnemen in architectuurdocumenten, leveren dus eigenlijk half werk. Zonder aan te geven voor welke soorten gegevens het de moeite loont om te streven naar correcte, actuele, eenduidige en consistente vastlegging, is het risico groot dat er veel tijd en geld worden besteed aan allerlei technische oplossingen. Terwijl soms überhaupt geen techniek nodig is om een voldoende effect te bereiken en het afdoende is om werkprocessen aan te scherpen. Of dat het risico op fouten door meervoudige opslag gewoon aanvaardbaar is. Is het bijvoorbeeld niet voldoende om elke wijziging in de personeelsgegevens handmatig door te geven aan de vakbekwaamheidsadministratie – loont het echt de moeite om daarvoor een koppelvlak te realiseren, te onderhouden en te beheren? Wanneer een technische oplossing wel voor de hand ligt, is het van groot belang om een realistisch ambitieniveau met betrekking tot de kwaliteitseisen aan de uit te wisselen informatie (actualiteit, eenduidigheid en consistentie) in het oog te houden. Daarbij bepaalt ook het huidige landschap in grote mate de mogelijkheden die men heeft om die kwaliteitseisen te realiseren. Op basis van die input moeten organisatie-eigen, concrete varianten van het principe van eenmalige opslag gedefinieerd worden die goed genoeg en wél haalbaar zijn. Een dagelijkse batchkopie van systeem A naar systeem B voldoet in veel gevallen prima en geeft voldoende invulling aan de kern van eenmalige opslag. Kortom, een algemeen principe zoals eenmalige opslag, meervoudig gebruik is hoogstens een startpunt voor architecten om na te denken over gegevens(stromen) in hun eigen organisatie en het daarbij behorende applicatielandschap. Het is een typisch voorbeeld van een principe dat ‘persoonlijk’ gemaakt moet worden, zoals het artikel Principeverslaving verzwakt architectuur stelt, omdat het anders meer kwaad dan goed doet. Een goed beheerd gegevenslandschap biedt de mogelijkheid in te spelen op veranderingen en tegelijkertijd te zorgen voor actuele, eenduidige en consistente informatie. Het principe helpt daarbij als denkrichting, maar moet geen doel op zich worden.
Terug naar het overzicht
.jpg)