Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Morgen zijn alle gegevens nog hetzelfde

 

Computable Expert

ir. Reinoud Kaasschieter
Sr. Consultant, Capgemini. Expert van Computable voor het topic Datamanagement.

Toen ik 25 jaar geleden als trainee mijn loopbaan in de it begon, werd me gevraagd het verschil tussen tekst en data te onderzoeken. Ik zal je mijn bespiegelingen besparen, maar de conclusie van de trainer zal ik je niet onthouden: tekst is gewoon een vorm van data. Toch hebben we de afgelopen decennia in het vakgebieden bi en ecm steeds gesproken over het verschil tussen ongestructureerde data en gestructureerde data.

Binnen enterprise information management (eim) wordt geen principieel onderscheid gemaakt tussen gestructureerd en ongestructureerd, tussen business intelligence (bi) en enterprise content management (ecm). Op technisch niveau is er meestal nog wel sprake van aparte informatiesilo’s voor gestructureerd en ongestructureerd. Omdat beide soorten data hun eigen systemen vereisten en eigen business cases hadden, is lange tijd een duidelijke scheidslijn getrokken. Maar in deze tijd van big data is alles data geworden. Tijd om te kijken of hoe we nu tegen dat verschil tussen gestructureerd en ongestructureerd kunnen aankijken.

Ik zal proberen dit te verduidelijken aan de hand van data-archivering. Data-archivering is het gecontroleerd opslaan van data buiten het bronsysteem. Dit kan gebeuren om allerlei redenen: wet- en regelgeving, ‘compliancy’, het ontlasten van productiesysteem van weinig gebruikte gegevens of het bewaren van gegevens uit uitgefaseerde processen en systemen. Data-archivering kan worden gedaan door een traditioneel ecm-systeem, een datawarehouse (dwh) of - dat is het beste - in een speciaal data-archiveringssysteem.

Hieronder worden puntsgewijs enkele verschillen tussen gestructureerde en ongestructureerde gegevens besproken. Ik gebruik databasetabellen als voorbeeld voor gestructureerde gegevens en documenten voor ongestructureerde gegevens. Ik ben me ervan bewust dat de variëteit in data veel groter is, maar voor de eenvoud neem ik deze twee voorbeelden. De vraag die ik me stel is: moet ik een onderscheid blijven maken tussen gestructureerde en ongestructureerde gegevens?

1.   Opslagruimte
In de begindagen van elektronisch archiveren was opslagruimte een issue die aandacht nodig had. Om bijvoorbeeld 1 TB aan documenten op te slaan in een ecm-systeem, was speciale hardware nodig. Maar tegenwoordig is 1 TB niets meer. De grote datasystemen kunnen vele Petabytes aan data opslaan. Opslag is geen uitdaging meer. Wat dat betreft is er geen onderscheid meer tussen gestructureerd en ongestructureerd.

2.   Semantiek
In de tijd dat ongestructureerde gegevens voornamelijk uit gescande documenten bestond, was het voor computersystemen moeilijk om de inhoud van die documenten te interpreteren. De inhoudelijke kenmerken van een document moesten handmatig als metadata aan de documenten worden toegevoegd. Tegenwoordig zijn documentinvoerstraten zo ver ontwikkeld dat het mogelijk is de inhoud van een document door een machine te lezen, te interpreteren en te classificeren. Hierdoor weten systemen wat er in documenten staat en kunnen we contextueel zoeken op de inhoud van de documenten.

Maar wat belangrijker is: tegenwoordig zijn de meeste ongestructureerde documenten helemaal niet meer zo ongestructureerd. De meeste ongestructureerde documenten zijn elektronisch ontstaan: Office-documenten, Twitter-berichten, e-mails… Content-analysetools kunnen met statistische technieken de inhoud interpreteren en de betekenis van de tekst bepalen. Teksten zijn op dit moment geen ‘gesloten’ objecten meer.

Ook bij gestructureerde gegevens is het niet altijd duidelijk wat bepaalde gegevenselementen betekenen. Maar dat is een datakwaliteitsprobleem, geen verschilpunt tussen gestructureerd en ongestructureerd.

3.   Retentiemanagement
Retentiemanagement, methoden om oude of verouderde data te verwijderen, is intrinsiek onderdeel van big data oplossingen. Al is opslag geen probleem, is het toch verstandig de wildgroei van de dataverzameling te bepreken door niet meer gebruikte gegevens te verwijderen. In de ecm-wereld is al lang gebruikelijk. Retentiemanagement is al aanwezig in een records management application (rma) voor documenten. Ook hier zijn er weinig verschillen: ook gestructureerde gegevens zijn onderhevig aan wet- en regelgeving, ‘compliancy’, bewaartermijnen et cetera.

Een rma beperkt zich formeel tot documenten en biedt daarom geen volledig retentiemanagement. Aan de andere kant heeft records management de processen rondom bewaren en vernietigen beter uitgewerkt. Bij records management moet eerst een voorgeschreven procedure worden doorlopen voordat documenten mogen worden vernietigd. Momenteel zijn de grote leveranciers druk bezig overkoepelende retentiemanagement te ontwikkelen voor alle data in een organisatie. Wat dat betreft zullen ook hier de verschillen verdwijnen.

4.   Levenscycli
Retentie is de laatste stap in de levenscyclus van een gegevenselement. Ieder gegeven is onderhevig aan een levenscyclus. In de loop van de levensduur van een gegevenselement - een databaseregel, een document - neemt het aantal opvragingen en mutaties op het element af. Ook kan het beveiligingsniveau veranderen: documenten kunnen vrijgegeven worden, klantrecords moeten geanonimiseerd worden. De betere ecm-systemen hebben ondersteuning voor levenscycli, zoals document life cycles. Hierbij worden de rechten, processen enz. behorende bij een fase in die levenscyclus automatisch gezet of gestart. In de gestructureerde wereld heet dit data life cycle management (dlm). En eigenlijk maakt het niet uit of het gestructureerde of ongestructureerde gegevens betreft, het is allemaal onderdeel van het bredere begrip information life cycle management (ilm).

Bij ilm is de vraag of deze systemen de juiste granulariteit van data aankunnen. Kunnen ze de levenscyclus van individuele regels in een database sturen? Want iedere regel kan bijvoorbeeld over een andere, individuele klant gaan. En iedere individuele klant kan besluiten geen klant meer te zijn, zodat zijn individuele gegevens na een periode - bijvoorbeeld zeven jaar - vernietigd of geanonimiseerd moeten worden in de databasetabel met klantgegevens.

Maar ook binnen documenten kunnen meerdere gegevenselementen staan: tekstblokken met verschillende betekenis of context. Vooral bij beveiliging kan dit een rol spelen. Zo kennen we bij een gedeclassificeerd geheim document de zwart gemaakte tekstregels. De ene regel is wel vrijgegeven, de andere niet. Nu ken ik geen grote rcm-systemen die op dat niveau autorisaties kunnen leggen (dit niveau gaat dieper dan ‘compound’-documenten), maar het maakt wel inzichtelijk dat bij ongestructureerde gegevens, zoals documenten, dezelfde zaken rond granulariteit spelen als bij gestructureerde gegevens.

5.   Autorisaties
Zoals we de levenscyclus voor individuele data-elementen apart willen inregelen, zullen we ook de rechten op individuele gegevenselementen apart willen bepalen. Binnen databases is het mogelijk om op bijvoorbeeld regel- en kolomniveau rechten te zetten: row-level permissions en column-level permissions. Diezelfde soort mogelijkheden zou ik graag zien binnen ongestructureerde data, bijvoorbeeld op regels of alinea’s. In de vorige alinea heb ik beschreven waarom dit wenselijk kan zijn. Dat betekent dat wij ongestructureerde tekst moeten gaan structureren in tekstelementen. Met bestaande tooling is dat goed te doen, door bijvoorbeeld door documenten op te slaan in xml-formaat.

6.   Versiebeheer
Versiebeheer is typisch ecm. In de loop van de tijd worden meerdere versies van een document gemaakt die als één geheel kunnen worden benaderd. Ook kunnen van een documentversie meerdere representaties worden gemaakt. Zoals het oorspronkelijke Office-formaat en een pdf-versie, de laatste bijvoorbeeld voor publicatiedoeleinden. Ook bij gestructureerde data is er de behoefte om de wordingsgeschiedenis vast te houden. Ook is er de behoefte om meerdere representaties te maken, bijvoorbeeld om de geschiedenis van de klantrelatie te kunnen reconstrueren en dat over een langere tijd te kunnen doen, zonder dat de oorspronkelijke bronapplicaties nog beschikbaar zijn. Beide vormen van versiebeheer komen nog weinig voor bij data-archiveringssystemen. Hier is zeker ruimte voor verbeteringen.

Mijn conclusie
Bovenstaande zes vergelijkpunten laten zien dat er steeds minder verschillen zijn in de behandeling van gestructureerde data en ongestructureerde data. Aan beide soorten gegevens worden dezelfde functionele eisen gesteld, zeker in een archiefsysteem. Maar de verschillen worden kleiner zodat op dit moment eigenlijk al alle soorten data op dezelfde manier kunnen worden opgeslagen en kunnen worden beheerd. Ik weet dat er ongestructureerde gegevens zijn waarvan de inhoud minder gemakkelijk te bepalen is, zoals filmpjes, geluidsfragmenten en foto’s. Hier heeft image processing veel voortgang geboekt, zodat ook hier de inhoud automatisch geïnterpreteerd kan worden. Vandaag kan onderscheid maken tussen gestructureerde en ongestructureerde gegevens nog zinvol zijn om, dat beide soorten data hun eigen systemen vereisen. Maar morgen zijn de systemen naar elkaar toe gegroeid en kunnen we het oude onderscheid laten varen. Dat is goed nieuws, omdat we op deze wijze de datakwaliteit en de levenscycli van gegevens vanuit één systematiek kunnen beheren.

Foto: Wikimedia Commons (Creative Commons CC0 1.0 Universal Public Domain Dedication).

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5051076). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Reinoud,

Ik wil even kort terug komen op onderstaande alinea:

"Opslagruimte
In de begindagen van elektronisch archiveren was opslagruimte een issue die aandacht nodig had. Om bijvoorbeeld 1 TB aan documenten op te slaan in een ecm-systeem, was speciale hardware nodig. Maar tegenwoordig is 1 TB niets meer. De grote datasystemen kunnen vele Petabytes aan data opslaan. Opslag is geen uitdaging meer. Wat dat betreft is er geen onderscheid meer tussen gestructureerd en ongestructureerd"

Eens, de opslagcapaciteit is flink toegenomen. Maar een ECM omgeving verlangt toch nog enige vorm van redundantie, mogelijke replicatie naar een 2e locatie en schaalbaarheid. Dus het is wel nog van groot belang om hier de juiste keuzes te maken. Te klein instappen levert veel teleurstellingen en uitdagingen op. En te groot instappen een desinvestering. Classificatie van de data op basis van bewaartermijnen, wetgeving en performance geeft je beter inzicht voor welk systeem je moet kiezen.

Wat ik mis, is het probleem van de leesbaarheid van proprietary-formaten waar geen software meer voor bestaat.
Ik loop regelmatig aan tegen documenten die met software gemaakt zijn die niet meer bestaat of niet meer op moderne platformen functioneert.

Beste Reinoud,

Een zeer interessant artikel die zeker op een goede wijze de vervagende scheidslijnen laat zien tussen ecm/rms/dms systemen en databasesystemen.

@Jan van Leeuwen: de onleesbaarheid van gegevens wordt steeds meer een issue in de verregaande digitalisering en digitale archivering. Het nadien leesbaar maken kan een hels karwei zijn en vaak onmogelijk. Het is hierbij van belang dat organisaties zich steeds meer bewust van worden dat ze een digitale duurzaamheidsbeleid moeten gaan voeren. Als organisatie moet je o.a. van te voren nadenken over de gegevensdragers die je gebruikt, het uitvoeren van controles op de leesbaarheid van je gegevens en ook het op tijd omzetten van gearchiveerde gegevens naar leesbare gegevensdragers en formaten. Er zijn dus een paar zaken die organisaties van te voren kunnen inregelen als ze er ook van te voren over nadenken.

Leuk artikel !
Ik ben het trouwens wel met Jan van Leeuwen eens.
een open formaat is weinig open als het enkel op MicroSoft bagger valt te implementeren.

Ongeveer 15 tot 20 jaar geleden had ik documenten gemaakt met het grafisch programma van Wordperfect (.wpg) die heb ik enkele jaren niet kunnen gebruiken, tot er uit de FOSS omgeving een addon voor open-office ter beschikking kwam.
Dat probleem heb ik niet meer sinds ik open document format (odf) gebruik.
Open source met open standaards zijn volgens mij de juiste weg.

Uit het artikel:
"Tegenwoordig zijn documentinvoerstraten zo ver ontwikkeld dat het mogelijk is de inhoud van een document door een machine te lezen, te interpreteren en te classificeren. Hierdoor weten systemen wat er in documenten staat en kunnen we contextueel zoeken op de inhoud van de documenten."

En in feite is daarmee het hele artikel samengevat in twee zinnen. De reden dat ongestructureerde data en gestructureerde data hetzelfde behandeld worden is simpelweg omdat er geen ongestructureerde data meer bestaat. Alle data krijgt structuur mee voordat het opgeslagen wordt en dus bestaat het onderscheid niet meer.

@Jan van Leeuwen: het onleesbaar worden van documenten omdat de bronapplicaties niet meer bestaan of viewers de formaten niet meer ondersteunen, is een bekend probleem. Binnen de archiefwereld noemen we dit 'digitale duurzaamheid'. Willen we documenten decennia (of eeuwen) later nog kunnen inkijken, zullen ze opgeslagen moeten worden in een beschreven formaat. Dat kan een 'open' formaat zijn, bijv. ODF. Of een genormeerd (gestandaardiseerd) formaat, zoals varianten van PDF. Essentieel is dat het formaat beschreven is, zodat latere gebruikers aan de hand van die beschrijving het document kunnen interpreteren. Dit klinkt omslachtig maar is wel de 'koninklijke weg'. In de praktijk wordt verwacht dat de ondersteuning voor open en genormeerde formaten gewoon langer blijft bestaan, in vergelijking tot allerlei 'proprietary' formaten.

Wie hiermee rekening moet houden, zal er meestal niet aan ontkomen documenten ergens in de documentlevenscyclus te converteren naar een duurzaam, of beter: duurzamer, formaat.

Top! Helder artikel dat gestructureerd duidelijk maakt dat, zoals Koen het samenvat, alle data tegenwoordig is te structureren. Om het enthousiasme ietwat te temperen vrees ik wel dat er nog een flinke slag is te maken om wat er mogelijk is in praktijk toe te passen. En dan heb ik het niet eens over aspecten als het genoemde op elementniveau kunnen autoriseren, maar over platvloerse zaken als het slimmer opslaan van (tekst)documenten dan met alleen wat handmatig toegekende metakenmerken. Of om het uberhaupt gaan archiveren van allerlei belangrijke data die in databases aanwezig is.

@Reinoud Kaasschieter
ik kan alleen maar zeggen dat ik blij ben dat ik ooit van proprietary naar open source overgestapt ben. Ook al vindt je daar verschillende tekort komingen, je kunt in ieder geval je data lezen.

Uit zuiver nieuwsgierigheid, vroeger werden in het ziekenhuis de gegevens naar microfilm gezet, vanwege de houdbaarheid. Hoe is dat vandaaag de dag, digitaal kan zich mijns inziens nog steeds niet meten met film, die 50 jaar of meer mee gaat. Wie heeft er bijvoorbeeld nog een 8 inch floppydrive?

@Jan van Leeuwen
Sorry voor de late reactie. Inderdaad is de houdbaarheid van allerlei dragers nogal beperkt. Ten eerste kan er veroudering plaatsvinden, ten tweede kunnen ze niet meer leesbaar zijn met de beschikbare technische middelen. Dat betekent dat in veel gevallen computerbestenden niet alleen geconverteerd moeten worden naar een ander formaat, maar ook overgezet moet worden naar een andere drager.
Op 8-inch diskettes zal niet zoveel gegevens staan. Maar het aantal CD-ROMs of CD-RW's met te bewaren gegevens is veel groter. Ook hier is de houdbaarheid van de drager beperkt. Veel archieven moeten er niet aan denken wanneer deze schijfjes niet meer leesbaar zijn door veroudering.

Een aanvulling op het artikel; Het proces (governance en compliancy) is zeer belangrijk. Bepaalde gegevens worden bewaard omdat da van rechtswege moet. Na die verplichte tijd kunnen ze worden vernietigd. Regelmatige extractie van data naar externe opslag zorgt voor een continue verloop van de opslagbehoefte.

De enige manier om dat te doen zonder risico's en zonder hoge kosten voor personeel dat deze processen moet uitvoeren en controleren is Process Automation. In combinatie met jouw betoog een perfecte oplossing!

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×