Juni 2001: Document en Informatiearchitectuur

Deze maand een stelling over wat de informatie architectuur omvat. De stelling luidt:

---
“Een goed uitgewerkte informatie architectuur is essentieel voor goed document management.“
---

De information view van Tapscott en Caston wordt door hen geïntroduceerd als één van de 5 views op een IT-systeem. Hun view omvat het zogenaamde enterprise information model. Letterlijk stellen zij dat de information view het information engineering perspectief geeft op de IT architectuur (dit is de architectuur van het IT-systeem cq. van de IT-infrastructuur). Hun information view representeert de fundamentele resources in de vorm van een informatie model dat, zoals zij ongeveer 10 jaar geleden schreven, opgesteld wordt door informatie architecten.

Dit is een veel beperkter opvatting van het beroep van informatie architect (en van wat hij of zij kan en doet) dan tegenwoordig gangbaar is. Een informatie architect is iemand die zich bezighoudt met het steeds belangrijker wordende bedrijfsmiddel “informatie”. Met de organisatie zorgt de informatie architect ervoor dat duidelijk is welke gegevens informatie zijn voor een bepaalde organisatie en wel-ke eisen, wensen, uitgangspunten en randvoorwaarden die organisatie verbindt aan haar informatie. Met die kennis kan de informatie architect de organisatie aan de best passende informatie infrastruc-tuur helpen door delen daarvan door aanbesteding, uitbesteding, procurement enz. te laten verbete-ren. De informatie architect staat daarbij aan zijde van de organisatie bij de beslissingen die op dit gebied genomen worden en de onderhandelingen die zij moeten voeren. Hij/zij weet immers wat die organisatie wil en kan.

Een document is “een middel waarmee, ongeacht de vorm, het mogelijk is gegevens duurzaam vast te houden en te bewaren voor (her) gebruik (zoals foto, film (waaronder microfilm en –fiches) kaart, tabel, aantekenboek, calque, stencil, geluidsopnamen, telegram, telex, telefax en machineleesbare gegevensbestanden of reproducties, ongeacht de vorm, welke hiervoor in de plaats zijn gesteld)”. Met deze, vrij algemeen gebruikte, definitie van het begrip document kan elke combinatie van één of meer gegevens een document genoemd worden. Ongeacht of de gegevens in het document nu ge-acht worden informatie te zijn voor een betreffende organisatie of niet.

In het door Tapscott/Caston bedoelde (conceptuele) informatiemodel wordt de structuur van die gegevens uitgewerkt die voor de organisatie informatie zijn. Echter, lang niet alle informatie zal in gestructureerde vorm terug te vinden zijn in de informatie- of data-bases van de organisatie. Dat is ook logisch. Waarom zou een organisatie immers moeite doen om informatie in een gestructureerde base te zetten? Dat zouden zij alleen moeten doen als zij daar ook echt voordeel van hebben, dus er meer opbrengst dan kost van hebben, in welke vorm dan ook.

Het is bijvoorbeeld logisch dat een organisatie middelen inzet om gestructureerd informatie bij te houden over de eigen producten, diensten en klanten. Maar is het ook zo logisch voor een organisatie om moeite te doen om gestructureerd informatie over de producten, diensten en klanten van haar concurrenten te hebben? Of van concurrenten die vergelijkbare producten op een totaal andere markt leveren? Een organisatie moet wel hele goede redenen hebben als zij daar geld en energie in willen steken.

Niet alle informatie wordt in gestructureerde vorm vastgelegd. Sterker nog, tegenwoordig wordt steeds meer informatie in ongestructureerde vorm vastgehouden. Denk alleen al aan wat we uit de “open bron” internet halen en vasthouden. Giga-, tera-, ja zelfs peta-bytes aan gegevens halen we in documenten van het internet, de plaats waar, volgens kenners, alles te vinden wat je ooit zou willen vinden. Ongestructureerd, op een manier gestructureerd waar we weinig of niets mee kunnen, op een manier geformatteerd die we niet of nauwelijks kunnen gebruiken, om maar eens een paar vormen te noemen.

Informatie in ongestructureerde vorm op een zinvolle manier vasthouden lijkt steeds beter mogelijk. Textretrieval software in bijvoorbeeld search engines zijn tegenwoordig vaak goed genoeg om in gi-gantische hoeveelheden gegevens in documenten, vrijwel ongeacht de manier waarop ze vastgelegd zijn, veel te vinden van wat iemand zoekt. Deze documenten worden vaak gedownload en in de ei-gen infrastructuur opgeslagen. Dat worden er snel meer en meer en op die manier ontstaan de vele bytes die nodig zijn om al die gegevens vast te kunnen houden.

Steeds meer organisaties vertonen de symptomen van een gegevens infarct. Het is immers vaak niet geheel duidelijk welke gegevens nu informatie zijn. Daarmee is het dus ook niet mogelijk om te bepalen welke documenten nu echt in de eigen infrastructuur opgeslagen moeten worden, en welke niet. Met als gevolg dat men “op zeker” gaat en dan maar alles wat men kan vinden overneemt, met alle gevolgen van dien.

Een document management systeem (DMS) helpt hier alleen als het goed opgezet en ingericht wordt. Een teveel aan gegevens voor de gebruiker los je immers slechts tijdelijk op door een sneller of beter systeem te bieden. Een DMS kan alleen goed ingericht worden als er een goed afgestemd document informatie model ten grondslag ligt. In dat model tref je de elementen aan die je per document vast kan of moet leggen. Daarbij is het bijvoorbeeld sterk de vraag of je trefwoorden aan docu-menten moet toekennen. Zoals gezegd is de text retrieval software tegenwoordig tot heel veel in staat en het is de vraag of de sisyfusarbeid geïntroduceerd moet worden om trefwoorden per document te gaan toekennen. De praktijk wijst uit dat een beperkte dossiervorming, die overigens ook noodzakelijk is voor het registreren van documenten en voor archiefvorming, vaak voldoende is. En dan spreken we nog niet over de koppeling tussen informatie in databases en de informatie in documenten. Een goede opzet voorkomt een grote hoeveelheid werk, zowel van IT-ers maar vooral van de gebrui-kers.

Een ander punt is workflow management. Het is niet echt nuttig om documenten in een workflow te zetten als daar geen aanleiding voor is. Die aanleiding kan alleen zijn dat er informatie voor de organisatie in staat (of in zou staan). Alleen dan zullen documenten immers voor afhandeling in aanmerking komen. En ook hier is de relatie tussen informatie in documenten en informatie in databases van belang, want vaak zal dit in een workflow onderkend worden.

Samenvattend: in een informatie architectuur wordt vastgesteld welke gegevens informatie zijn voor de onderhanden organisatie(s). Tapscott en Caston zien hun information view als een informatie mo-del, de informatie architectuur is echter veel meer dan dat alleen. De informatie architectuur zal onder meer ook vaststellen welke documenten wel en welke niet in de eigen informatie infrastructuur vast-gelegd moeten worden op basis van hun inhoud. De informatie, dus. Het doel van een informatie architectuur zal steeds zijn, dat zoveel mogelijk informatie beschikbaar komt en zo min mogelijk gegevens. Zoals aangegeven is een gegevens infarct een groot probleem voor steeds meer organisaties, terwijl een informatie infarct in principe niet bestaat. Een informatie architectuur is dus heel erg belangrijk voor een goed document management.