Home Architectuur Wat is moderne informatie-architectuur?

Wat is moderne informatie-architectuur?

770
Overheid

Op mijn blog ‘Huidige tekortkomingen bij Digitale Architectuur’ is massaal gereageerd, met name op de constatering dat ‘informatie-architectuur’ nogal onderbelicht is. Het is verheugend te zien dat veel architecten mijn mening delen. Op de tweede dag van het Landelijk Architectuurcongres, 29 november, wordt een workshop gehouden over moderne informatie-architectuur. Na drie 10-minuten speeches van Jan Truijens, Hans Goedvolk en Steven van ’t Veld (drie professionals die hun sporen hebben verdiend in de informatie-architectuur) zal een discussie met de zaal worden gevoerd over de vraag ‘waar wij met informatie-architectuur naar toe zouden moeten’.
Om alvast langs digitale weg die discussie op te starten, staan hieronder enkele meningen waar jullie op kunnen reageren.

De informatie-architectuur gaat over de inrichting van het informatiegebeuren, inclusief kennis en intermenselijke communicatie. Laatst hoorde ik een Amerikaan onderscheid maken tussen ‘data at move’ en ‘data at rest’. Het eerste behoort tot het informatieverkeer; het tweede zijn de databases en die behoren tot de applicatielaag.
Lord Kelvin stelde ‘meten is weten’. Daar kunnen wij in dit dynamische tijdperk aan toevoegen ‘informeren is functioneren’. Informatie is de lijm, de smeerolie in een organisatie. Informatie verbindt mensen met mensen, mensen met processen en vice versa. Zonder goed ingericht informatieverkeer leeft een organisatie niet echt.
Centraal in de informatiearchitectuur staat een ‘common operational picture’, een overzichtelijk informatiebeeld voor alle partijen in de leveringsketens. Dit zorgt voor een optimale ‘situational awareness’ voor de individuele partijen in de keten op basis waarvan zij de juiste acties kunnen ondernemen.

Afgaande op de visitekaartjes van de architecten en de vaak creatieve benamingen op ‘LinkedIn’, zien wij dat de volgende professionals zich bezig houden met het formuleren van een of andere vorm van informatie-architectuur: informatie-architect, informatiestrateeg, senior informatiemanager, beleidsadviseur bedrijfsinformatie, BI-architect (inclusief dashboards), GIS-architect/GEO-architect, kennisarchitect, document-architect, DIV-architect, website architect, portaal architect, data architect/gegevensarchitect, masterdata architect, metadata architect, DBA-architect, dataware house architect, SAS-architect, ECM-architect en nog veel meer benamingen. Kortom, een bonte verzameling van hoogwaardige professionals. Het wordt de hoogste tijd dat er één informatie-architect wordt gedefinieerd die alle relevante aspecten van deze professionals in de vingers heeft.

De informatiearchitect zou zich moeten bezig houden met:
–       De inhoud van de informatie/kennis die interne en externe actoren gebruiken bij de bedrijfsprocessen die deze actoren uitvoeren. Dit betreft de bedrijfsprocessen voor het leveren van de diensten en producten in de leveringsketens zoals beschreven in de businessarchitectuur.
–       De wijze van aanbieden van bovengenoemde informatie/kennis aan de interne en externe actoren. Dit betreft ook keuzes als op papier, digitaal, via social media of via websites. In feite is zelfs de inrichting van de persoonlijke digitale ‘werkruimte’ hierbij van belang.
–       Leveringsketens van gegevens resp. kennisdelen waaruit de informatie of kennis is opgebouwd met aandacht voor externe leveranciers van gegevens of kennis, ook wel aangeduid met informatielogistiek.

Veel organisaties ‘zitten’ op een berg aan informatie, maar op het ‘moment suprême’ kunnen ze extern gevraagde informatie niet snel genoeg vinden.
Bij veel organisaties blijkt informatie-architectuur het stiefkindje van het architectuurgebeuren. In een tijd waarin steeds meer wordt aangedrongen op transparantie en het afleggen van verantwoordelijkheid zou er veel meer aan informatie-architectuur moeten worden gedaan.

Daan Rijsenbrij, www.Rijsenbrij-Academy.nl

32 REACTIES

  1. Heel herkenbaar! Wat mij betreft zou de Informatie Architect (IA) de verbindende schakel moeten zijn tussen de Business Architectuur(BA) en de Technische Architectuur (TA). Door het ontbreken hiervan gaat vaak de samenhang en integraliteit verloren en wordt vooral gestuurd op basis van “puntoplossingen”. Dit is al moeilijk genoeg binnen 1 Enterprise Architectuur (EA), nog moeilijker bij een SOA (next gen outsourcing) want dan heb je in feite te maken met 2 EA’en, dus alles dubbel (BA, IA en TA bij de klant en BA, IA en TA bij de leverancier(s))

  2. Ik mis hierbij nog de governance over de informatie: het zorgen dat de informatie goed wordt gedefinieerd, gebruikt en bewaakt wordt. Zorgdragen dat er een owner wordt aangewezen en dat de informatie herbruikbaar is in andere processen

  3. Informatie als zelfstandige laag lijkt mij in een interoperabele wereld van groot belang. Wat ik daarin ook zou willen beandrukken is dat de informatiemanager zich met de semantiek bezig houdt: wat noemen we wat wanneer en voor wie? En dat deze semantiek helder wordt doorgevoerd en de erg moeilijke taak om hierin (internationale) standaarden te bevorderen. Daarmee is informatielogistiek wel een belangrijke kunde voor de informatiearchitect.

  4. Zoals een collega van mij net zei na het lezen van dit stuk: dit heeft wel weer een erg hoog “wij van WC-eend adviseren WC-eend” gehalte. Waarom hoor bestuurders, politici en andere bobo’s ik hier nooit over. Om een uitspraak van LvG nog maar eens te verbroddelen: zijn wij (architecten) nou zo slim of zij zo dom?

  5. De verbindende schakel tussen business en techniek – eens! Maar in de discussies en ook in het verhaal hierboven bespeur ik een traditionele kijk op business (nl. bedrijfsprocessen) en techniek (nl. data en applicaties). Die tweedeling is overal aan het verdwijnen. Het gaat meer en meer over het bereiken van doelen, het kunnen bewegen in een wereld waarin alles beweegt. Daarbij kun je beter misschien spreken over “optimale” informatievoorziening, wat in de praktijk vaak neerkomt om “minder” in plaats van “meer”. En informatievoorziening die niet ten dienste staat van processen (“ik heb daar en op dat moment die-en-die informatie nodig”) maar die meedenkt en een actieve rol speelt.

  6. Henk,

    Je hebt helemaal gelijk. Een architect dient een systeem te beschouwen in samenhang met het beheer en de onderhoudsorganisatie. Dus naast informatie ook de borging op de kwaliteit van zowel de informatie als van de veranderingen van die informatie.
    Voorts hoort ook de archivering erbij.

    Zoals jij terecht benadrukt dient elk informatie-item een eigenaar te hebben.

    Groet,
    Daan.

  7. Door de invloed van mobiele communicatie, social media, Big Data, wordt net gedaan alsof traditionele informatica (Informatica architectuur, etc…) niet meer relevant zou zijn. Het is “en-en”. Een wereld zonder gestructureerde data gaat echt niet werken hoor, hoe “sexy” al die nieuwe media ook lijken.

  8. Bart,

    De business spreekt niet over architectuur, maar ergert zich aan het feit dat ze aanwezige informatie niet snel kan terugvinden. Zij verwondert zich over het gebrek aan orde en samenhang in de informatie. Dat zijn allemaal zaken die aangeven dat er een zwakke informatiearchitectuur is.

    Ik sprak laatst een businessmedewerker van een van de grotere provincies. Zoals je wellicht weet voert een provincie, in tegenstelling tot een gemeente, veel infrequente activiteiten uit. De klacht van die medewerker was dat hij elke keer weer moest nadenken hoe hij de activiteit de vorige keer had gedaan en welke informatie hij daarvoor nodig had. Dus dom herinnerwerk, en ‘herinneren’ kan een computer vele malen beter dan mensen. Oftewel maak een informatiearchitectuur zodat de computer maximaal het domme werk kan overnemen.

    In mijn CIO-gesprekken over architectuur met enkele uitvoeringsorganisaties bleek dat zij zich voorbereiden om onverwachte vragen van derden te kunnen beantwoorden. Dat vergt een geavanceerde informatiearchitectuur.
    En de mondige klant is helemaal niet geïnteresseerd in architectuur maar wel in een overheid die transparant is en verantwoording kan afleggen.

    Groet,
    Daan.

  9. Rob,

    Ik ben het helemaal met jou eens. De klant bepaalt welke informatie hij nodig heeft, en dat is vaak niet wat het bedrijf of de overheidsorganisatie wil leveren.

    Een klant wil geen volledig uittreksel van de Kamer van Koophandel. Hij wil antwoord op zijn simpele vraag: ‘Die mijnheer tot hoeveel mag hij tekenen?’. En dat korte antwoord wil hij op zijn smart Phone ontvangen.

    Groet,
    Daan.

  10. Atilla,

    Helemaal mee eens, voor het informatiegebeuren heb je aan stabiele, ordelijk ontworpen ‘binnenkant’ nodig. Aan de buitenkant kan je allerlei leuke devices hangen om het belevingseffect te verhogen.

    Als je die ‘degelijke’ binnenkant overslaat krijg je een losse verzameling ‘spiegeltjes en kraaltjes’.

    Groet,
    Daan.

  11. Daan,
    “Er zou veel meer aan informatie-architectuur moeten worden gedaan” zo sluit je af. Ik ben het daar helemaal mee eens. Die business medewerker vraagt inderdaad niet om architectuur, dat is niet mijn punt, maar die CIO zou dat wel moeten doen, anders is en blijft het een ondergeschoven kindje.

  12. Bart,

    CIO betekent Chief Information Officer. Dus je hebt gelijk hij/zij zou zich primair bezig moeten houden met informatie, informatiestromen, informatiebehoeften en informatiestromen. Jammer genoeg komen veel CIO’s uit de techniek.
    Er ligt een schone taak voor de seniore informatiearchitect om het cruciale belang van informatie (zie het negenvlak van de Universiteit van Amsterdam) weer onder de aandacht van de CIO te brengen.

    Groet,
    Daan.

  13. Daan,

    Gegevens zonder doel zijn zinloos, maar wel een van de belangrijkste assets van een organisatie (zelfs een enkel persoon). Gegevens vormen de inhoud van een proces, sturen het en rapporteren erover. 3 aspecten zijn over het algemeen net behapbaar voor de mens. Dit inzicht is al erg oud en de presentatie mag veranderen, maar blijkbaar is het nog steeds erg moeilijk om er mee om te gaan. Misschien kun je het in een nieuw plaatje tekenen dat dan weer een poosje actueel is. Ik ben benieuwd naar de discussie en de uitkomst ervan.

    Dank en Vriendelijke groet,

    Klaas Z

  14. Informatie-architectuur zou moeten gaan over ordening van informatie tot situationeel heldere betekenis. M.a.w. een stelselmatige ordening van informatie waaruit iedereen – afhankelijk van zijn/haar specifieke situatie – de contextueel relevante combinaties kan putten. Wie tijd heeft/neemt: zie http://www.information-roundabout.eu .

    Velen hebben de mond vol over zgn. Business-IT alignment… en hoe belangrijk die alignment is. Heeft iemand een idee hoe je daar concreet invulling aan geeft? Het is m.i. precies die stelsematige ordening van informatie die de concrete invulling-tot-alignment tussen die beide vormt. Het is a.h.w. de scharnierpen die de beide scharnierbladen in één-en-dezelfde beweging zowel koppelt als ook ontkoppelt – tot optimale vrijheid voor elk van de scharnierbladen.

    Zelf heb ik niet het idee dat informatie-architectuur (al) een stiefkindje is. Was het maar een stiefkindje! Dan zou je het bijvoorbeeld uit huis kunnen plaatsen of iets dergelijks. Nu heeft het zoveel meer weg van een ongeborene waarbij niemand zich bewust is van zwangerschap. En zo lijdt ongeborende een (weg)kwijnend bestaan terwijl het vanuit baarmoederlijke realiteit steeds meer mensen hoort roepen om zijn conceptie.

  15. Jan,

    Die systematische ordening waar jij het over hebt, dient te geschieden op basis van architectuurprincipes die worden afgeleid uit strategische uitgangspunten op het gebied van informatie en informatiegebruik.

    Ik zou graag zien dat de lezers van deze blog mij helpen aan een opsomming van de soorten bronnen waaruit dergelijke uitgangspunten kunnen worden geformuleerd.
    Ook zou ik graag voorbeelden willen zien van architectuurprincipes voor het informatiegebeuren.
    Bij voldoende interesse en voldoende materiaal kunnen wij wellicht lente volgend jaar eens een NAF-workshop houden over informatiearchitectuur.

    Zoals ik reeds eerder opmerkte in een van mijn reacties, de zogenaamde alignment tussen business en IT gebeurt middels de informatielaag, althans volgens het negenvlak van de Universiteit van Amsterdam. Wat jij noemt de ‘schanierpen’.

    Groet,
    Daan.

  16. Daan,

    Je reactie geeft mij de indruk dat je de route richting informatie-architectuur al hebt bepaald. Je lijkt nog slechts een handvol ingrediënten te missen. Dat verbaast me. Zover ben ik in ieder geval nog niet.

    Ik wil graag nog een stapje of wat terug. Om te voorkomen dat we opnieuw de muzikale plank volkomen misslaan. Wat is eigenlijk de crux van informatie-architectuur? Is er een crux? Dat zijn, lijkt mij, wezenlijke vragen.

    Vroeger… heel vroeger al… gaven mensen elkaar allerhande tekens. Via articulatie. Via gesticulatie. Enzovoort. Rooksignalen. Muurschilderingen. Allerhande bouwsels. Teveel om op te noemen. Op die manier be-teken-den zij en leefden zij al heel gevarieerd samen.

    En daaraan is vandaag geen sikkepit veranderd. Nog altijd be-teken-en wij elkaar tekens… op basis waarvan wij weer nieuwe tekens be-teken-en enzovoort enzovoort. Wel zijn onze hulpmiddelen ‘wat’ geavanceerder dan vroeger. Wel draait de wereld ‘wat’ sneller dan vroeger. Alsmaar toenemende dynamiek enzo.

    En dat zou ons er meer dan ooit toe moeten brengen ernst en haast te maken met zoiets als informatie-architectuur. Geruststellend daarbij is, zoals opgemerkt, dat aan ons tekenverkeer geen sikkepit is veranderd. Maar wat is dan de crux van dat onderlinge tekenverkeer? Hoe bedenken wij onze tekens? Hoe produceren be-teken-aars die tekens en waarom? Wat omvat optimale teken-productie zoal? Welke be-teken-is geven teken-waarnemers eraan en waarom? Wat doen teken-waarnemers vervolgens op basis van de door hen aan teken gegeven be-teken-is?

    Tekens. Tekenverkeer. Betekenis. Gedrag. Gedrag in de vorm van (weer nieuwe) tekens; tekens dus. Tekenverkeer. Betekenis. Enzovoort. Enzovoort. Ronduit intrigerend daarbij is hoe een teken aan z’n be-teken-is komt. Anders gezegd: hoe komt be-teken-is van teken tot stand? Een cruciale en allesbepalende vraag voor een informatie-architect. Toch? Want het draait niet zozeer om het teken, maar veeleer om de be-teken-is die een teken-waarnemer eraan geeft – betekenis stuurt immers gedrag. En informatie (teken) is bedoeld om het gewenste gedrag te bewerkstelligen. Het draait m.a.w. om pragmatische interoperabiliteit. Pragmatische interoperabiliteit die leunt op semantische interoperabiliteit. Hoe komt be-teken-is van teken in een mens tot stand. Statisch? Dynamisch? Anders?

    En als de antwoorden op dergelijke vragen zijn gevonden… als samenhang teken-betekenis-gedrag diep is begrepen… welke consequenties dienen informatie-architecten daar dan aan te verbinden m.b.t. de organisatie van informatie (tekens) met het oog op pragmatische interoperabiliteit?

    Kun je wat aanvangen met deze grondwerk-stappen? Heb jij dergelijk stappen mogelijk al doorlopen? Van gefundeerde antwoorden voorzien? Denk je dat je ze straffeloos kunt overslaan? Nog anders?

  17. Als Enterprise Search consultant heb ik dagelijks te maken met het concept “Informatie-Architectuur”. De relatie zit hem in het verhogen van de vindbaarheid (findability) van informatie. Informatie-Architectuur is onder deel van Information Governance. Ik ga hier verder niet in op de doelstellingen daarvan.

    Wat ik wel wil bijdragen aan dit artikel / deze discussie het verwijzen naar een leuke toelichting van het concept “Information Architecture”: http://prezi.com/aafmvya6bk7t/understanding-information-architecture/

    Peter Morville (http://semanticstudios.com/) houdt zich al jaren bezig met het onderwerp informatie-architectuur en ziet zichzelf als een founder en evangelist van dit onderwerp.

  18. Wat ik merk is dat veel mensen “in de Business” (besluitnemers/vormers) helemaal niet geïnteresseerd zijn in “elke vorm van architectuur”. Door al nieuwe trends als de Cloud, apps en Big Data word de indruk gewekt dat alles in een kwartier in elkaar geflanst kan worden.
    Zoals ik al aangaf in een eerdere reactie (en dank Daan dat je het zo omschrijft) de “binnenkant” moet je wel aan de “buitenkant” proberen aan te sluiten. Dat kost tijd en moeite (wat zo elegant zijn alle technische interfaces niet).
    Overigens echte toevoegde waarde krijgt ICT pas als het (bedrijfs)proces kwantitatief (sneller, goedkoper) of kwalitatief (betere, nieuwe functionaliteiten) er beter op wordt.
    De echte waarde van informatie-architectuur (buiten het feit dat je koppelvlakken beter kan bouwen) zit hem dan ook om inzichtelijk te maken aan “besluitnemers/vormers” waar die toegevoegde waarde hem dan precies in zit. Maar ook wat het kost om dat te bereiken. Het maken van architectuur an sich levert natuurlijk geen ene fluit op, maar het is een noodzakelijke randvoorwaarde om daadwerkelijk verder te komen.

  19. @ Jan van Til,

    Je reactie is helder.

    Je gaat echter wel uit van het teken in de basis. Syntax, dus, de codering, het lexicale. Ik geloof niet dat dat een handige basis is voor een informatiearchitectuur. Mijn uitgangspunt is het feit, vooral het gegeven feit (in de IT-wereld vaak het gegeven genoemd) zelf. Je kunt `tekens` gebruiken om een gegeven feit te coderen zodat er iets mee gedaan kan worden. Dat laat het feit zelf, het niet-lexicale, echter onverlet. Daarbij geef ik je dat een feit al of niet waar kan zijn, al of niet van waarde enz. Logisch, want de waarde van een feit ligt bij degene, organisatie of mens, die het feit heeft/kent, en die al of geen waarde aan dat feit toekent.

    Als je naar de ISO definitie (1983) van informatie kijkt zie je dat die zich baseert op (gegeven) feiten, waarbij de omgeving (ISO noemt dat de Universe of Discourse) neergezet wordt waarvoor het feit al of geen waarde, geen betekenis heeft. Indien een gegeven feit betekenis heeft wordt het informatie genoemd. Ongeacht waar het vandaan komt, ongeacht hoe het samengesteld is enz.

    Een informatiearchitectuur is dan een relatief simpel begrip, waarbij het om de informatie van een Universe of Discourse (gekozen omgeving) gaat. En dat kan een mens zijn, een groep mensen, een organisatie, een groep organisatie, een combinatie van delen van organisaties en ga zo maar door. De crux van een informatiearchitectuur ligt dan in het punt dat je kunt aangeven welke (soorten) feiten informatie zijn, en wat je met die informatie wil, kan, moet enz. Zo kan je een visie op de informatie van, bijvoorbeeld, een organisatie (dus = Universe of Discourse) neerzetten die onder meer sterk bepalend is voor de inrichting van de informatievoorziening van die organisatie. Dus bijvoorbeeld voor regie daarover.

    Uitgaan van het lexicale en die niet terugvertalen naar het non-lexicale levert problemen op omdat je dan te vaak niet de werkelijke achtergrond, de werkelijke basis van een feit cq. van informatie kunt achterhalen. Met grote gevolgen voor bijvoorbeeld het samenstel van oplossingen dat de informatievoorziening genoemd wordt, omdat je de daarvoor nodige integratie van delen anders niet meer kunt regelen.

    Taal is juist verzameling afspraken op basis waarvan we kunnen communiceren met elkaar. Die afspraken `vertalen` zich in wat jij tekens noemt (in al de door jou gegeven breedte), waarbij je wel de afspraken moet blijven handhaven om niet in grote communicatieproblemen terecht te komen omdat men elkaar mbv een bepaalde taal niet meer of niet goed meer kan begrijpen. Zeker als je het gebruik van tekens bij degene die de tekens heeft laat.

    Dat is de reden waarom situationele analyses van informatie alleen mondjesmaat kunnen werken, want iedere niet in die situatie betrokken partij heeft dan immers nog steeds moeite met wat in die situatie afgesproken kan zijn. Daar regent het vaak hele of halve synoniemen en, veel erger, homoniemen die niet meer uit elkaar te trekken zijn.

    Als je vanuit de tekens zou werken kom je, in jouw termen, in feite alleen uit op syntactisch interoperabiliteit, en niet veel verder. Als je teruggaat voor de betekenis, en daar kom je dus sterk in de buurt van standaarden en andere gemaakte afspraken, kan je elkaar ook gaan begrijpen. Jij noemt dat semantische interoperabiliteit. Pragmatische interoperabiliteit, dus het toepassen van wat je weet in een praktijk, is sterk gebaat bij goede semantische afspraken. Daan noemt dat de lijm, de smeerolie om verder te kunnen komen in waar je mee bezig bent als mens, groep mensen, organisatie enz.

    De praktische neerslag van dit alles kan je trouwens in mijn artikel in het nieuwe lustrumboek van NAF (deel 4.2) vinden. In het verlengde daarvan zie je dat je, als het over de primaire soorten informatie van organisaties gaat, het allemaal niet al te moeilijk is. Al sinds jaar en dag weten we dat bijvoorbeeld banken primair voldoende hebben aan 3 soorten informatie. Als je die drie soorten informatie als basis onder je informatiearchitectuur legt zie je ook dat je sterk richting (`regie`) kunt geven aan bijvoorbeeld de verdere ontwikkeling van een informatievoorziening van een organisatie, en de integratie van de componenten daarvan. Zelfs situationele analyses zouden daarmee een goede plaats krijgen, waarbij een topdown richtlijn tot een bottom-up validatie leidt.

    In mijn ervaring is dit het grondwerk, waarbij de keuze voor tekens een vertaling voor gebruik is. En zeker: je kunt niet zonder echt grondwerk als je hier aan werkt. Maar dat grondwerk is al zeer grondig in de jaren 70 en 80 van de vorige eeuw beschikbaar gelegd. Dat werk wordt tegenwoordig echter veel en veel te weinig gebruikt.

    Steven van ´t Veld
    Steven.van.t.Veld@aim.nl

  20. Edwin,

    Ik vind jouw bijdrage aan deze blog interessant en verfrissend.

    Een degelijke informatiearchitectuur is nodig voor het eenvoudig opslaan en vinden van informatie. Ik had laatst een gesprek bij een bedrijf dat problemen had met de gigantische hoeveelheid informatie. De IT-manager die er ook bijzat, vroeg zich af waar wij ons druk over maakten er is immers Google Search!
    Ik denk dat intelligent search heel belangrijk is, maar ik zie niet in hoe je daarmee concepten als ‘integraal klantbeeld’, ‘basisregistratie’ of ‘de ordening in het zaakgericht werken’ kan omzeilen.

    Ook het etalage-effect van de websites van een organisatie, zoals jij suggereert, heeft architectuur nodig. Alle drie de (Vitruvius) architectuuraspecten: orde & samenhang, slimme constructies en een interessante beleving.

    Groet,
    Daan.

  21. Atilla,

    Ik houd van moderne technologie, maar die dient wel beheerst te worden ingezet in het bedrijfsgebeuren. Dat zou een verdienste kunnen zijn van een architectuur.
    Op mijn lezingen waarschuw ik altijd: ‘Maak van je organisatie geen Efteling door lukraak nieuwe technologieën als interessante attracties neer te zetten’.

    Goed dat je nog even benadrukt waar de echte waarde van architectuur ligt. In mijn gesprekken met topmanagement en CIO’s hoor ik steeds vaker dat een architect wordt afgerekend op zijn/haar bijdrage aan de verbetering van de performance van de organisatie en haar individuele werknemers. Er is nauwelijks een weldenkende businessmanager die vraagt heb je TOGAF wel gebruikt of is dit conform NORA.

    Groet,
    Daan.

  22. Steven, dank je wel voor je uitvoerige reactie. In deze context zou ik ook kunnen zeggen: dank je wel voor je uitgebreide teken. Of, nog een stapje verder: lees-teken – hier als samenhangend geheel van tekens.

    Mijn reactie nam je waar (1) en vatte je op als een teken (2). En daar bleef het niet bij. Je kwam – heel intrigerend! – op de één of andere manier tot interpretatie; tot betekenisgeving (3). En via betekenisgeving kwam ook je tot gedrag (4), waaronder het produceren en publiceren van jouw lees-teken.

    Jouw lees-teken roept bij mij echter wel vraag-tekens op. Die vraag-tekens verpak ik in dit lees-teken; deze reactie die de reactie vormt op jouw lees-teken.

    Zo was mijn lees-teken gericht aan Daan; niet aan jou. Mijn lees-teken bevatte gerichte vragen aan Daan; niet aan jou. Antwoord jij nu los van Daan? Namens Daan? Wellicht nog weer anders?

    Je reactie geeft mij de indruk dat ook jij de route naar informatie-architectuur al(lang) hebt uitgestippeld/gevonden. Je reactie geeft mij bovendien de indruk dat jij eigenlijk niet eens ingredienten mist; het grondwerk is wat jou betreft al jaren geleden volbracht en behoeft geenszins heroverweging.

    Aan Daan stelde ik voor: “Ik wil graag nog een stapje of wat terug.” Van Daan weet ik het (nog) niet, maar jij lijkt dat volkomen overbodig te vinden. Jij lijkt geheel en al naar (eigen) tevredenheid je vaste uitgangspunt te hebben gekozen/gevonden in/met de keiharde feiten zoals de IT-wereld daar al sinds jaar en dag mee werkt. Vaste feiten in vaste relatie tot vaste zuilen. Zo denk jij, als ik je goed begrijp, hedendaagse en alsmaar toenemende dynamiek tot in lengte van jaren duurzaam in informatie-architectuur (op) te kunnen vangen.

    Ik niet.

    Want alsmaar toenemende dynamiek maakt alles wat nu nog vast is (of, beter: vast lijkt) uiteindelijk los, beweeglijk en variabel. Daar kunnen we dan maar beter direct (lees: nu al) rekening mee gaan houden. En daarom stelde ik Daan voor: “Ik wil graag nog een stapje of wat terug.” Het huiswerk overdoen dat we naar mijn idee “in de jaren 70 en 80 van de vorige eeuw” met de kennis van vandaag onvoldoende grondig hebben gedaan. Waarom zou mijn vorige bijdrage eigenlijk zo vol met vragen staan? “Je reactie is helder”, schreef je. Is dat echt zo? Die indruk heb ik niet gekregen.

    Van jou begrijp ik dat je geen huiswerk over wenst te doen; het is wat jou betreft immers al voldoende grondig gedaan. Met jou lijk ik dan ook geen kans te maken op een stapje terug. Dat is dan helder; dank; kost ook geen nodeloze energie.

    Wel ben ik benieuwd wat Daan (zelf) ervan vindt; of hij bereid is “een stapje of wat terug” te doen om informatie-architectuur van een grondiger fundament te voorzien dan waar, naar ik begrijp, Steven al ruimschoots tevreden mee zegt te zijn. Daan?

  23. Jaap van Till merkte op dat “de discussie” zich hier afspeelde. Alhoewel ik niet de indruk heeft dat het zin heeft om mijn opmerking elders te herhalen doe ik het toch maar:

    “Het verbaast me dat sommige mensen nog steeds niet beseffen dat in-formeren een persoons- dus contextgebonden fenomeen is.

    Hiermee bedoel ik dat in-formatie pas formeert als er binnen in de “ontvanger” al iets aanwezig is waar het op kan aansluiten.

    Dit heeft allemaal te maken met het verschil tussen de z.g. conduit-metaphor en de toolmaker-metaphor zoals bescheven in het baanbrekende artikel van Reddy (http://en.wikipedia.org/wiki/Conduit_metaphor) in 1979 (!!!) dat het begin was van de z.g. embodiment beweging in de cognitietheorie”

  24. Beste Daan,

    De problemen die jij aankaart zijn zeer herkenbaar voor Rijkswaterstaat. Ondanks (of dankzij?) de enorme hoeveelheid applicaties en bestanden kunnen wij geen eenduidig antwoord geven op vragen als ‘hoeveel asfalt heeft Rijkswaterstaat in beheer?’. Jammer, want bij het vaststellen van de benodigde financiering zijn antwoorden op dit soort vragen essentieel. Informatiearchitectuur is binnen mijn organisatie opgedeeld in data-architectuur en applicatie-architectuur. Vooral de data-architectuur staat nog in de kinderschoenen.

    Waar moeten we naartoe? Ook hier sluit ik me aan bij jouw stellingen. Inzicht in processen, actoren en leveringsketens (businessarchitectuur) en leveringsketens van gegevens is volgens mij onontbeerlijk voor een degelijke informatie-architectuur. Maar hoe komen wij tot dit inzicht?

    Daan, ik vrees dat hier onze wegen zich scheiden. Uit jouw eerdere stukken begrijp ik dat je een strikte scheiding aanbrengt tussen architecten en engineers. Ook architecten die steunen op een methodiek kunnen niet op jouw bijval rekenen. Toch wil ik hier pleiten voor de methodiek van Jan Dietz, Enterprise Engineering (Demo). Deze methodiek is bij uitstek geschikt om een overzicht te krijgen van actoren en leveringsketens en kan o.a. helpen bij consolidatie en uitbestedingstrajecten. Natuurlijk is alleen het toepassen van Demo onvoldoende voor een complete informatie-architectuur. Naast inzicht in koppelvlakken moet je bijvoorbeeld ook weten hoe je met deze koppelvlakken omgaat. Jan’s theorie vertelt niet hoe (ver)taalproblemen tussen partijen en systemen kunnen worden opgelost of hoe wet en regelgeving naar een specifiek informatievraagstuk kan worden vertaald.

    Demo kent in de toepassing binnen Rijkswaterstaat ook een aantal praktische problemen. Niet alle architecten delen mijn enthousiasme. Demo wordt door veel collega’s ervaren als academisch, moeilijk, omslachtig en slecht verkoopbaar aan het management. Academisch is deze methodiek zeker, er ligt een zeer grondige en logisch consistente gedachtegang aan ten grondslag. Met Demo werken is ook een behoorlijk karwei dat grondig onderzoek en veel contact met werkvloer en proceseigenaren vereist. Demo diagrammen vallen zeker niet in de smaak bij het management. Dit komt gedeeltelijk doordat architecten vaak te veel in 1 diagram willen verwerken waardoor deze soms monsterlijke vormen aannemen. Desondanks geef ik toe dat zelfs het perfecte Demo product niet zonder goede toelichting kan worden gelezen. Maar waarom zou je een directeur of HID lastig vallen met deze producten? Conclusies en adviezen op basis van Demo kunnen toch op een klantvriendelijke manier worden gepresenteerd? Wat mij betreft kan Demo dus zeker een belangrijke bijdrage leveren aan een (betere) informatie-architectuur.

    Hartelijke groet,
    Mieke van Nierop
    Rijkswaterstaat

  25. @ Jan van Til

    Weet je, ik ben gewezen op je reactie en heb de mijne daar aan toegevoegd. Als je alleen een discussie met Daan zoekt en met niemand anders raad ik je aan hem offline te benaderen.

    Je reactie is m.i. te ge-teken-d, om in je termen te blijven. Aan de ene kant grijp je terug naar het verre verleden om je ideeën neer te zetten en waarheid te geven, aan de andere kant lijk je een ander verleden te ontkennen terwijl daar heel veel basiswerk in is verricht waar we tegenwoordig geen kennis meer van schijnen te hebben.

    Een probleem dat ik wel eens heb met het heden is dat regelmatig ontkend wordt dat wat we al weten, of wisten, nog steeds van waarde is cq. kan zijn. Iets anders noemen dan voorheen betekent nog niet dat je iets nieuws hebt gevonden. Dat probleem zie ik niet alleen in vele presentaties, maar ook in bachelor/master-scripties en zelfs in proefschriften.

    In de vele jaren dat ik nu in en rond informatie werk, nationaal, internationaal en in de wereld van standaardisatie, blijken steeds weer dezelfde concepten terug te komen onder een andere naam en in een andere vorm. Niets staat voor altijd vast, maar als je er wat mee wilt kan je beter met je kennis en ervaring aan de slag en niet weer met yet-another aanpak die ook wel leuk zou kunnen zijn. Met natuurlijk een continue poging om wat je al hebt te falsificeren. Rond informatie bestaat al jaren een relatief simpele basis die al zo vaak onder vuur heeft gelegen en nog steeds de tand des tijds blijkt te kunnen doorstaan. Daarom gebruik ik daar de essenties dan ook van.

    Mijn reactie op je reactie is dan heel simpel: laat me zien dat je ideeën rond tekens toevoegen of veranderen en ik ben de eerste die ze zal overnemen. Op dit moment zie ik de toevoeging cq. verandering niet, zie ook mijn vorige reactie, maar misschien begrijp ik wat je zegt verkeerd. Mogelijk dat onze resp. achtergronden toch niet voldoende zijn om elkaars tekens echt goed te kunnen begrijpen.

    @ Hans (17-11-2012),

    Het begrip Universe of Discourse dat ISO hanteert is de context die je bedoelt.

    Steven van ´t Veld
    Steven.van.t.Veld@aim.nl

  26. Weet je, Steven, ik ben zo ver-schrik-ke-lijk blij met je reactie… je bevestigt er Zo Luid en Zo Duidelijk al mijn in mijn vorige reactie uitgesproken vermoedens mee. Dank je wel! Verder praten heeft om die reden dan ook niet of nauwelijks zin. Dat zou je reinste energieverspilling zijn – zoals ik je in mijn vorige bericht ook al aangaf.

    Jan van Til
    http://www.information-roundabout.eu

  27. Mieke,

    Waarom is er geen echte urgentie bij RWS om haar gegevensinfrastructuur op orde te brengen? Eist het kerndepartement dan geen transparantie en verantwoording van RWS? Hoe stuurt dat kerndepartement eigenlijk zonder die benodigde informatie?

    Hoe draagt DEMO bij aan het noodzakelijke inzicht? De waardevolle delen van DEMO bestonden al lang voor DEMO en de nieuwe zaken maken het gebruik van DEMO nodeloos complex. Ik kom graag eens een keer langs om jullie gebruik van DEMO tegen het licht te houden.
    Ik krijg een ‘déjà vu’ bij het lezen van DEMO. Je weet wel de rollen & bollen van prof. Sjir Nijssen (NIAM). Die methode leverde zo veel platen op, dat je door de bomen het bos niet meer zag. Dat effect levert DEMO ook, toch?

    Groetjes,
    Daan.

  28. Beste Daan,

    Natuurlijk kan Rijkswaterstaat d.m.v. handmatige koppeling en/of het opnieuw inwinnen van gegevens wel verantwoording afleggen. Dit is echter een tijdrovende en dure aangelegenheid. Er wordt daarom hard gewerkt aan de verbetering van het gegevensmanagement.

    Natuurlijk ben ik geïnteresseerd in een aanpak waarbij met minder platen het benodigde inzicht wordt gegeven. Misschien kan je hierover meer vertellen tijdens de workshop op het LAC?

    Hartelijke groet,
    Mieke van Nierop

    Ik ben benieuwd naar jouw ideeen

  29. Mieke,

    Ik ben zeer geïnteresseerd welke strategische uitgangspunten RWS kiest bij het verbeteren van haar gegevensmanagement. En welke architectuurprincipes daaruit worden afgeleid voor de informatiearchitectuur.
    Kan jij een tipje van de sluier oplichten?

    Hebben jullie ook architectuurconcepten op gegevensgebied zoals bijvoorbeeld een integraal klantbeeld of kernregistraties?

    Groet,
    Daan.

  30. Beste Daan,

    Ik wil hier best iets meer zeggen over onze plannen om het huidige informatielandschap te verbeteren. Een van de belangrijkste problemen is dat we vergelijkbare gegevens in verschillende bestanden met verschillende kwaliteit hebben. Ook is het vaak moeilijk om bestanden te koppelen. Zo is het belangrijk om netwerk gegevens uit (scheepvaart)verkeersnetwerken te kunnen koppelen aan areaalgegevens. Deze koppeling is belangrijk om te kunnen bepalen in hoeverre investeringen in beheer en onderhoud bijdragen aan (een deel van)onze missie: vlot en veilig verkeer. Nogmaals, dit lukt uiteindelijk wel, desnoods m.b.v. opnieuw inwinnen van gegevens of handmatige koppeling maar moet desondanks een stuk beter.

    Een van de dingen die we willen bereiken is het organiseren van ons gegevenslandschap door de informatieproducten en de bouwstenen van deze producten van elkaar te scheiden. We streven naar een basisset data waarmee d.m.v. verschillende views de diverse informatieproducten kunnen worden gemaakt. Nu wordt er per informatieproduct vaak apart gegevens ingewonnen. Hierdoor hebben veel informatieproducten eigen bijbehorende gegevensbestanden. Overlap tussen deze bestanden veroorzaakt dubbele inwinning en inconsistenties. We bekijken hiervoor o.a. de mogelijkheid (en eisen) voor basisregistraties die de ruggengraat van onze informatievoorziening moeten vormen.

    We zijn ook bezig met het opstellen van data principes die moeten bijdragen aan een structurele verbetering. Een van de conceptprincipes is: ‘Data hergebruik voor inwinnen’. Dit principe (waarvoor natuurlijk ook de toelichting en implicaties worden uitgewerkt) moet voorkomen dat voor het leveren van een nieuw informatieproduct een nieuw inwinproces wordt gestart terwijl de benodigde gegevens wel voorhanden zijn. We willen dit jaar een eerste set principes opstellen in samenwerking met o.a. inkoopmanagers en projectmanagers van de Data-Ict-Dienst. Deze uitgangsset willen we volgend jaar m.b.v. de business verder aanscherpen. We zullen de principes daarnaast ook nog juridisch checken en van goede illustraties (striptekeningen?) voorzien.

    Tot slot bekijken we ook hoe we gegevens uit verschillende domeinen beter koppelbaar kunnen maken. Daarbij is het ook belangrijk om te bepalen hoever onze ambitie gaat. Willen we alleen makkelijk dossiers bij elkaar kunnen zoeken of willen we ook het inzicht in functionele beïnvloeding tussen domeinen automatiseren? Denk hier bijvoorbeeld aan de invloed van maatregelen op het gebied van watermanagement op het scheepvaartverkeersmanagement.

    Je ziet, we hebben nog heel wat werk voor de boeg.

    Hartelijke groet,
    Mieke van Nierop

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here