Informatiearchitectuur in de keten. Jan Campschroer

Informatiearchitectuur in de keten

16-3-2015

Deze reader is bedoeld om cursisten en docenten van andere modules van de masterclass kennis te laten nemen van mijn visie op informatiearchitectuur. Het idee is dat zij dit van te voren doornemen. Dan kunnen we tijdens de sessie meer tijd aan interactie geven en samen dingen ontdekken. Ook kunnen we de diverse modules hierdoor beter op elkaar aan laten sluiten.

Jan Campschroer

1


16-3-2015

In deze visie komen mijn antwoorden op deze vragen aan bod. Met die antwoorden hoef je het trouwens niet eens te zijn. Als je de relevantie er maar van inziet en jij je eigen antwoorden maar kunt onderbouwen. Hopelijk heb je baat bij de antwoorden die ik hier geef. Mijn motto voor doceren is namelijk het volgende: Een goede docent maakt de studenten bewust van de vragen en nieuwsgierig naar de antwoorden. Dat zorgt er namelijk voor dat iedere student zelf aan de slag kan en energie steekt in dingen die hem echt interesseren, op een manier die bij hem of haar past. Daar heeft die student dan ook nog eens veel meer tijd voor, dan in die paar uur in het klaslokaal. Buiten het klaslokaal leer je meer dan er in! Van een goede vraag leer je meer, dan van een goed antwoord. Meer over deze onderwijsfilosofie vind je bij: -David Kolb (http://nl.wikipedia.org/wiki/David_Kolb ) -Lev Vygotski (http://nl.wikipedia.org/wiki/Lev_Vygotski en http://nl.wikipedia.org/wiki/Zone_van_de_naaste_ontwikkeling ) -Constructivistisch onderwijs (http://nl.wikipedia.org/wiki/Constructivistisch_onderwijs) Let op. In de sessie gaat het in hoofdzaak over mijn antwoord op de laatste vraag..

Jan Campschroer

2


16-3-2015

Het heeft geen zin om informatiearchitectuur te definiëren, als je niet weet waar je het voor wilt gebruiken. Hier staan wat mij betreft de 5 belangrijkste argumenten waarom je als organisatie aan informatiearchitectuur zou willen doen. Ze worden in de volgende pagina’s uitgewerkt. Ik heb lang zitten twijfelen over de volgorde. Ik denk dat de tweede over organisatiekracht vooral van toepassing is op Informatiearchitectuur. De anderen gaan denk ik op voor alle (organisatie gerichte) architecturen.

Jan Campschroer

3


16-3-2015

Regeren is vooruit zien. Als je vandaag goed geïnformeerd wil worden, moet je gisteren (en de dagen daarvoor) gegevens hebben verzameld of systemen hebben gebouwd om goed om kunnen gaan met wat je hebt. Daarvoor moeten processen worden ingericht, mensen opgeleid, taken verdeeld, systemen worden bedacht, gemaakt en geïnstalleerd. Kortom: je moet de informatievoorziening organiseren. Dat kost tijd. Dat kost geld. Dat wil je dus optimaal plannen: wat is wanneer nodig? Hoeveel kost me dat? Wat levert het me op en wat kost het me als het er niet of in mindere mate is? Als je aan ‘architectuur’ doet, dan zijn dat vragen waar je een antwoord op wilt. De toekomst is echter ook onzeker. Er zijn verschillende dingen mogelijk. Door met de (informele) leiders na te denken over die toekomst creëer je een gezamenlijk beeld van de verschillende mogelijkheden. Over wat je zou willen, wat er zou kunnen gebeuren en hoe je daar (als organisatie) op zou willen reageren. Met het ontwikkelen van een architectuur ontstaat er een coalitie die samen ergens naar toe wil, weet wat de (on)mogelijkheden zijn, van te voren nagedacht heeft over de manier waarop ze gaan re(a)geren en over de manier waarop je daarop gaat anticiperen. Samen spreek je regels af die je hanteert om je doel te behalen.

Door na te denken over de verschillende mogelijkheden kun je bovendien die dingen gaan realiseren die ‘altijd’ goed zijn. Je creëert een stabiele basis waarmee je zo goed als mogelijk op de toekomst bent voorbereid. (Zie ook verderop bij: Doe de goede dingen) Informatiearchitectuur, de Informatiearchitect, moet de keuzes ondersteunen. Keuzes die je moet maken met maar een beperkte kennis over hoe het allemaal in elkaar zit en hoe de toekomst kan (of moet) worden.

Jan Campschroer

4


16-3-2015

Ons vermogen tot communiceren zorgt ervoor dat we ons kunnen organiseren en in samenwerking meer bereiken dan we afzonderlijk zouden kunnen. Communicatie tussen mensen is dus een belangrijke steunpilaar voor organisaties. Om gerichte en gecoördineerde actie te kunnen ondernemen moeten we goed geïnformeerd zijn. Voor een deel informeren we ons door gewoon om ons heen te kijken. Je doet bijvoorbeeld een jas aan als je naar buiten gaat en je gezien hebt dat het regent. Maar informatie komt ook (en vooral) binnen via gesprekken (face-to-face of telefonisch), via een beeldscherm of een luidspreker(tje). Toepassingen van Informatie- en Communicatie Technologie (ICT) zorgen er voor dat we zaken die andere mensen of technische opnameapparaten op andere tijden en op andere plaatsen hebben waargenomen, bedacht of berekend, mee kunnen nemen in ons besluit om al dan niet wat te gaan doen. Door goed te communiceren met onze omgeving (medewerkers, managers, leveranciers, (potentiële) klanten, aandeel- en toezichthouders) kunnen we er voor zorgen dat we onze doelen bereiken. ICT heeft onze communicatie competentie enorm versterkt en dat beïnvloedt daarmee ons organisatievermogen enorm. Daar liggen de kansen. ICT is echter ook ingezet om (administratief) werk te automatiseren of om dit werk bij de bron te laten gebeuren (mijn banktransactie maak ik tegenwoordig zelf kenbaar en dat is ook gelijk de digitale vorm waarin het verder wordt verwerkt). ICT vergroot daarmee ook de mogelijkheden wat je wel en niet kunt. ICT maakt sommige manieren van werken mogelijk en/of betaalbaar. Informatiearchitectuur , eigenlijk de Informatiearchitect, moet helpen deze kansen te grijpen. En daarmee de kracht van de organisatie te vergroten. Noot: Voor mij gaat informatiearchitectuur vooral om het optimaal bieden van informatie en minder om het inzetten van IT voor automatisering, maar de scheidslijn is dun, zeker bij grote gegevensintensieve organisaties als Belastingdienst , UWV en banken.

Jan Campschroer

5


16-3-2015

Het inzetten van ICT leidt tot meer mogelijkheden en steeds grotere wereldwijd opererende organisaties, dat brengt echter ook risico’s met zich mee. Je zult niet alleen na moeten denken over de ‘goed’ situatie, maar ook moeten nadenken over wat er allemaal fout kan lopen. (In feite is dit een verbijzondering van het verkennen van de toekomst. ) Je moet bewuste keuzes maken of je daar al dan niet van te voren maatregelen voor wilt treffen. Ga je de kans op die risico’s verkleinen of ga je de impact van risico’s beperken. Ook hier zal een gezamenlijk beeld van gevormd moeten worden. Het is aan het bedrijfsmanagement of en hoeveel ze willen investeren in risicobeperkende voorzieningen. Zij moeten het ondernemingsrisico bewust dragen. Voorbeeld: De Belastingdienst gebruikt MijnBelastingdienst.nl. Dit systeem ondersteunt onder meer de aangifte Inkomstenbelasting. Dat impliceert privacy gevoelige gegevens en een hoge continuïteit van dit vitale bedrijfsproces. Je wilt dus van te voren kunnen zien of het fout dreigt te gaan. Dan moet je dus het proces kunnen monitoren. Ook de beheerder heeft goede informatie nodig om zijn werk te doen. Monitoring, als onderdeel van beheer, vergt dat je na ga denken over wat je wilt monitoren , hoe je in wilt kunnen grijpen en waar en op welke manier je dat in het (bedrijfs)systeem in gaat bouwen. Dat doe je er niet meer achter af eventjes bij. En dat kost ook wat. Dat is functionaliteit voor de beheerder die de ‘gewone’ manager mogelijk niet als relevant had beschouwd, maar waar hij wel voor moet betalen. Informatiearchitectuur, de Informatiearchitect, moet helpen de risico’s de identificeren en met zijn ontwerpen voorstellen doen om de kans of de impact van deze risico’s te verminderen.

Jan Campschroer

6


16-3-2015

Als er een project is om de informatievoorziening te veranderen, is er veel aandacht voor hardware en software en nauwelijks voor de gegevens. Op het moment dat er een laptop op straat gevonden wordt, maakt niemand zich druk over de hard- en software maar iedereen over de gegevens en documenten die er op staan…. Ik wil met deze tekst aangeven dat Informatiearchitectuur niet hetzelfde is als IT-architectuur. Ook het verzamelen van gegevens behoort tot het te ontwerpen informatieproces. Een (tijdelijke) handmatige procedure kan een heel goed alternatief zijn voor een geautomatiseerd proces. Dat moet je dan wel in je scope willen zien. Zo horen ook gegevensverzamelingen tot het ontwerp van Informatiearchitectuur. Gegevens zijn de grondstoffen van de informatie, IT is de machinerie. Informatiearchitectuur kijkt ook naar de processen waarbij gegevens door mensen of machines worden gecreëerd, bewaard, getransporteerd en gecommuniceerd. Deze zaken moeten in samenhang worden bekeken en ontworpen. Als organisatie moet je jouw aandacht en energie dus verdelen over diverse zaken: IT, gegevens, organisatie, processen. Je heb echter ook maar een beperkte (ontwikkel) capaciteit. Een vraag die bij het inrichten van je informatievoorziening dus zekert speelt is: op welke manier zet ik mijn capaciteit optimaal in? Hoe zorg ik ervoor dat ik dingen voor elkaar krijg? Daarvoor moet je een analyse maken van ‘waar je naar toe wilt’ naar ‘wat je daarvoor nodig hebt’. Dat kun je per project doen, maar beter is het om ook breder te kijken (vanuit strategie, bedrijfsdoelstellingen en missie) en de product break down structure zodanig te maken dat onderdelen voor verschillende zaken bruikbaar zijn. (re use by design). Elk project kan dan binnen het grotere bestemmingsplan zijn stukje verder inkleuren via bijvoorbeeld een projectarchitectuur Op die manier voorkom je dat je dingen maakt die al bestonden (maar net niet goed waren) of later toch niet nodig bleken te zijn. Of dat je dingen vergeet: het ITsysteem is klaar, maar het levert geen informatie omdat we verzuimt hebben de gegevensprocessen in te richten.

Noten: IT-architectuur kun je zowel zien als een aspectsysteem maar ook als een subsysteem van Informatiearchitectuur. Daarmee bedoel ik het volgende. Als je nadenkt over de manier waarop je er voor wilt zorgen dat mensen in en om je organisatie de juiste informatie krijgen, dan ontkomt je er tegenwoordig niet aan om na te denken welke ICT-producten je daarvoor gaat inzetten. In elk gebiedje dat je raakt komt de vraag naar boven: Welke IT zet ik hier voor in? Belangrijker is echter de vraag: wie wil welke informatie hebben en welke gegevens heb ik daar voor nodig? Dus bezie IT als een subsysteem van de informatievoorziening. IT zijn globaal die dingen die te maken hebben met die hard- en software; de content is een andere belangrijk deel van de Informatievoorziening. Bij nadere beschouwing zul je merken dat deze (conventionele) scheiding in de praktijk toch wat lastiger te maken is. Zijn bedrijfsregels of waardelijsten content of software? Maakt het uit in welke taal je dit vastlegt?

Jan Campschroer

7


16-3-2015

Informatieprocessen en de ICT-systemen die daar onderdeel van uit maken zijn complexe abstracte zaken. Het bouwen van ICT-systemen luistert nauw en vergt veel verschillende expertises met elk hun eigen jargon. Datzelfde geldt voor het realiseren van informatievoorzieningen. Slechte administratieve processen resulteren in vervuilde gegevensverzamelingen. Die zijn nauwelijks als zodanig te herkennen en (achteraf) nauwelijks meer op te schonen. Of het juiste gevraagd, gespecificeerd, gebouwd, beschreven en ingericht is, kan alleen door veel lees, praat , review, test- en accreditatiewerk worden bepaald. Vanaf het begin moet je er boven op zitten om alles goed te laten werken. Dat vergt duidelijke aansturing, helder taalgebruik, weten waar je het over hebt. Specificaties moeten scherp geformuleerd zijn. Dat vergt een duidelijk beeld over de wijze waarop je dit soort systemen beheersbaar realiseert. Dat vergt ook een duidelijk beeld over de wijze waarop je er voor zorgt dat het ook na oplevering nog werkt en werkbaar en betaalbaar blijft. Daarvoor moet je weten waar de risico’s (waaronder misverstanden) op de loer liggen. Behalve het eindplaatje moet de informatiearchitect ook het proces er naar toe vormgeven om er voor te zorgen dat we ergens komen waar we willen zijn. Om te voorkomen dat de vele mensen die bezig zijn om die toekomst vorm te geven onderweg te ver afdwalen. Dat wil niet zeggen dat het allemaal in één keer goed hoeft te gaan, maar je zult zaken in moeten bouwen om te bepalen of je nog op de goede weg bent. Nota bene: De goede architect denkt na over de volledig levenscyclus van de informatievoorziening. Niet alleen de ontwikkeling,. Ook operatie en af-, om- en uitbouw moeten meegenomen worden in deze continu veranderende wereld.

Jan Campschroer

8


16-3-2015

Simpel gezegd is informatie architectuur dat wat je moet doen om het waarom vanuit de vorige antwoorden uit te voeren.

Jan Campschroer

9


16-3-2015

Informatiearchitectuur komt in veel gedaanten voor. De voorgaande 5 doelen van informatiearchitectuur kun je met een verschillende scope uitvoeren. Die scope gaat van groot naar klein, van het hele bedrijf tot aan één project, van strategisch naar operationeel. Bijgevolg is vaak ook de tijdshorizon anders. Die loopt van enkele jaren naar een paar maanden. Informatiearchitectuur met een grotere scope levert kaders waarbinnen de informatie architecturen met kleinere scope die daarbinnen vallen, moeten werken. Je zou kunnen spreken van een hiërarchie van informatie architecturen. De inhoud van die architecturen bestaat (onder meer) uit modellen en principes. Hoe groter de scope hoe meer het hangt op principes. Als de scope groot is, is de onzekerheid ook groter. Het gaat er dan vooral om inspirerend te zijn en de grote groep een bepaalde kant op te laten bewegen. Welke kant dat precies is, is dan vaak ook wat onzeker, wat ambivalent. Hoe kleiner de scope hoe concreter en eenduidig de architectuur is. In de projecten is de architectuur (meer) maakbaar. Op de wat hogere lagen is de architectuur meer een baken, een kompas waarop opdrachtgevers, projectleider en projectarchitecten hun ontwerpen afbakeningskeuzes maken. Noot: In menig grote organisatie kom je diverse van die architecturen tegen. Ze zijn echter zelden ‘topdown’ ontworpen. Elk van die architecturen heeft dan meer weg van een middeleeuwse landkaart waar het thuisland centraal staat en alle andere zaken daar omheen, met een eigen schaalverdeling, met een eigen richtingkeuze, met een eigen mate van detail en diepgang en mogelijk nog eens ook met een eigen afstandsmaat. Het is vervolgens nog een gigantisch werk om al die architecturen uit te lijnen om efficiency te bereiken.

Jan Campschroer

10


16-3-2015

Voor mij is architectuur in eerste instantie een ontwerp. Dat wil zeggen een model (in de brede zin van het woord) waarin de vorm van een toekomstige situatie is weergegeven. Op basis van wat je wilt bereiken, heb je bedacht hoe dat er uit ziet. Die vorm is in geval van informatiearchitectuur trouwens wel in termen van abstracte dingen. Dingen die je niet kun ruiken, proeven of horen. De informatiearchitectuur is een model (mogelijk in de vorm van meerdere beschrijvingen) van de toekomstige inrichting van de IV-processen die ervoor moeten zorgen dat betrokken partijen (blijvend) de informatie krijgen die nodig is om de organisatie optimaal te laten presteren. Om die vorm te kunnen vinden zijn er diverse vragen te beantwoord. Dat begint met vragen als: • Wie of wat heeft informatie nodig? En waarvoor (voor welke besluiten) en waartoe (voor welke doelen) dan? • Wat is die informatie voor deze actoren? • Welke gegevens, documenten, waarnemingen zijn er nodig om die informatie te kunnen leveren? • Op welke manier kunnen we dat (tijdig) verzamelen of verkrijgen? • Op welke manier brengen we dat samen (via informatieprocessen) om de noodzakelijke informatie te leveren. • Wat kost dat, wat levert het op en hoe zetten we onze middelen optimaal in? • Kortom: wat is er nodig voor goede informatie? Een architectuur geeft dus een model dat het betrokken management in staat stelt om (enige tijd) consequente besluiten te nemen in geval van investeringsvraagstukken. Een model dat programmaen projectmanagers in staat stelt om te sturen op de kwaliteit van resultaten

Jan Campschroer

11


16-3-2015

Een doel van een informatiearchitectuur is het betrokken management in staat te stellen om (enige tijd consequente) besluiten te nemen in geval van investeringsvraagstukken. Een informatiearchitectuur stelt verder programmaen projectmanagers in staat om te sturen op de kwaliteit van resultaten. Een informatiearchitectuur zorgt ook voor kaders waarbinnen delen er van verder kunnen worden uitgewerkt. De architectuur is daarmee een scharnier van wens naar realiteit. Om de daarvoor consistente antwoorden te krijgen op de hiervoor genoemde vragen moet er een gedragen, gedeelde en inspirerende visie zijn op de toekomst voor de organisatie of het organisatieonderdeel waarvoor je die informatiearchitectuur opstelt. Onder een gedeelde visie versta ik daarbij een met verschillende betrokkenen besproken en vanuit verschillende relevante invalshoeken bekeken en beproefde opvatting. Daarin krijgen bepaalde termen een heel expliciete betekenis. Dat zijn de kernbegrippen. Daar hoort dus ook jargon – de lokale taal van de groep – bij.

Jan Campschroer

12


16-3-2015

Die visie zal er niet altijd of niet altijd in voldoende mate zijn. Bijgevolg zal een deel van het werk van de architect (of het architectenteam) bestaan uit het inrichten en faciliteren van een proces waarin de betrokkenen (de stakeholders) samen werken aan deze gemeenschappelijke visie. Dat betekent niet dat al deze betrokken de gehele visie moeten delen. Niet alle delen zullen voor alle deelnemers even relevant zijn. De (deel)visies van de betrokkenen moeten echter wel 100% in lijn zijn met elkaar. Dat betekent dat je potentieel tegenstrijdige principes zoals: “we gaan voor maximaal gebruik van externe gegevens’” en “we respecteren de privacy van werknemers en klanten”, uit moet ‘onderhandelen’. Daarnaast zal er ook in verband met gebrek aan resources, tijd en/of geld onderhandeld worden over de wijze waarop de realisatie ter hand genomen gaat worden. Het is niet voldoende om een luchtkasteel te tekenen, je moet ook de weg er naar toe ontwerpen. Daarbij word je gehinderd of geholpen door de legacy: dat wat er al staat en al dan niet goed werkt. Dat heeft vervolgens ook weer consequenties voor het eindresultaat. Dus ook het ontwerp is onderhevig aan onderhandeling.

Noot: Aan het eind van deze reader nog wat vormen waarin onderhandeling plaats vindt over de gehele wereld. Ongetwijfeld zal in elke organisatie “de onderhandeling” andere patronen volgen.

Jan Campschroer

13


16-3-2015

Alles bij elkaar zou dit een definitie kunnen zijn van wat een informatiearchitectuur is.

Jan Campschroer

14


16-3-2015

Om een architectuur te kunnen maken, heb je een aantal competenties nodig. Je zult niet alleen inhoudelijk goed moeten zijn, maar ook procesmatig. Soms is de opgave zo groot dat je het niet meer in je eentje af kunt. Dat betekent dat er specialisaties zullen zijn, maar ook dat er een lead-architect moet zijn die inhoudelijk de boel kan overzien en de (sub) architecten bij elkaar houden. Op de volgende pagina mijn ordening van de competenties van de architect. Voor mij zijn competenties trouwens dingen -Die je kent (je kunt er over vertellen, je kunt er over filosoferen) (kennis) -Die je kunt (je kunt deze dingen doen en doet ze ook in de praktijk) (gedrag) -Die je gelooft (dit geeft je de energie om iets te doen of juist niet. Het zijn je overtuigingen) (houding) Deze dingen kun je voor een deel leren en voor een deel is het aangeboren. Daarnaast heb je een bepaalde persoonlijkheid (een voornamelijk aangeboren eigenschap). Goede architecten zijn van nature sociaal vaardig en intelligent en als gevolg daarvan op een prettige manier eigenwijs.

Jan Campschroer

15


16-3-2015

De architect is eigen-wijs. Omdat architectuur nog een jong vakgebied is, moet je je eigen beeld vormen over wat het wel en niet is. Moet je je eigen (beargumenteerde) antwoorden hebben op de 5 vragen die ik hier op mijn manier heb beantwoord. Moet je misschien beter je eigen lijst van vragen hebben die jouw visie op informatiearchitectuur vorm geven. Vanuit jouw eigen visie op IA geef je invulling aan je rol als architect. Dat is dus uniek (eigen) en specifiek voor de architect. En je bent wijs. Dat wil zeggen dat je veel van je vakgebied kent en daar zelf ook een eigen mening over vormt. De architect is adviesvaardig. Uit voorgaande blijkt (hopelijk) dat je met veel mensen van velerlei pluimage om moet kunnen gaan, dan je belangen bij elkaar kunt brengen, dat je kunt zorgen voor gemeenschappelijke beeldvorming,dat je om kunt gaan met weerstand. Dat je je ook in kunt leven in het werk en de taak van een ander zodat je zijn problemen en behoefte begrijpt en van daar uit dingen kunt bedenken waar niet specifiek om is gevraagd. Deze vaardigheid is niet specifiek voor de architect. Ook voor vele andere rollen moet je hier vaardig in zijn. Dat betekent ook dat er opleidingen te kust en te keur zijn.

Jan Campschroer

16


16-3-2015

De architect is modelleervaardig. Om inzicht te kunnen geven in huidige en toekomstige situatie, mensen enthousiast te maken, of duidelijk te kunnen instrueren zijn modellen hét hulpmiddel. Als architect ben je dus bekwaam in het hanteren van bestaande technieken, maar ook op basis van de deelnemers in de communicatie eigen modellen bedenken om optimaal te kunnen communiceren. Je kunt hoofd- en bijzaken scheiden en dat kun je vervolgens ook weergeven in de modellen die je opstelt. Dit betreft modeltalen als Archimate en UML, maar ook BusinessCase en risico-analyse en het maken van inspirerende visualisaties. De architect is ontwerpvaardig. Om oplossingen te bedenken voor problemen (te grijpen kansen of te verwijderen knelpunten) moet je nieuwe dingen kunnen bedenken. Je moet ook weten wat er aan oplossingen is voor bepaalde problemen. Dat kan heel specifiek zijn dat je heel veel projecten hebt gedaan (en weet of het uiteindelijk gewerkt heet) maar dat kan ook op basis van of designpatterns – oplossingen van anderen met voor- en nadelen. Je moet dus weet hebben van welke constructies welke eigenschappen hebben en die op de juiste manier op een creatieve manier inzetten.

Jan Campschroer

17


16-3-2015

De architect is materiaal- en materieeldeskundig Het materiaal omvat de zaken die in de uiteindelijke informatievoorziening een rol spelen. Het materieel omvat alle zaken die te maken hebben met het realiseren van informatievoorziening.

De architect moet niet alleen een schets van de toekomst kunnen maken, hij zal ook moeten weten met welk materiaal dat uiteindelijk is gerealiseerd. Dus als je aangeeft dat er een WFM component nodig is, dan moet je ook weten welke varianten je daarvan hebt en wat daar de kosten, de functionaliteit en de voor- en nadelen van zijn. Omdat in veel grote organisaties eigenbouw (dus in feite eigen materiaal) aanwezig is, moet je daar de functionaliteit (wat kun je er mee, waar is het voor bedoeld) en de technische kwaliteit (wat kost beheer en onderhoud, wat is de up-time, etc.). Omdat een informatiesysteem niet bestaat uit alleen maar IT moet je ook bekend zijn met gegevensverzamelingen en administratieve en informatieprocessen. Uiteindelijk gaat het menselijke communicatie. Ook daar zul je dus kennis van moeten hebben: hoe werkt de menselijke kennisverwerving? Hetzelfde gaat mutatis mutandis op voor het materieel. Het niveau waarop je informatiearchitectuur bedrijft (meer strategisch of meer operationeel) zal daarbij bepalen welk materiaal en materieel er te onderscheiden zijn. Op projectniveau is bijvoorbeeld gedetailleerde applicatie, gegevens en productkennis nodig. Op strategisch niveau zal dat globaler van aard zijn. De architect is domein, keten en organisatie deskundig. Om een goede (informatie)architect te zijn moet je je kunnen inleven in de opgave van het bedrijfsmanagement. Je moet dus weten wat hun doel en missie is. Je moet de omgeving van de organisatie kennen (de branche en de ketens waar ze deel van uitmaken) . En je moet weten welke strategie ze volgen of overwegen. Daarnaast moet je ook het proces en de mensen kennen welke de informatievoorziening vormen of als afnemer van diezelfde IV gezien kunnen worden. Op basis daarvan zijn voorstellen te maken zonder steeds te vragen wat nodig is. Door je in te leven als architect weet je wat nodig is, of kun je daar in ieder geval een goede inschatting van maken. Dat is voor een deel algemeen, maar je zult ook in de organisatie moeten vertoeven om het goed te kunnen doen. Je moet de organisatie kunnen lezen. Helemaal mooi is het als je de organisatie kent als je broekzak.

Jan Campschroer

18


Jan Campschroer

16-3-2015

19


16-3-2015

De belangrijkste concepten hebben te maken met de twee onderdelen van het woord informatiearchitectuur. In de volgende sheets ga ik daar verder op in

Jan Campschroer

20


16-3-2015

Bij architectuur speelt (voor mij) het begrip ‘functie’ een belangrijke rol. Daarbij bedoel ik functie als in de zin: “Wat is de functie van een beker?”. Heel kort gezegd gaat het er om “wat je er aan hebt” of “waar het voor zorgt”. De functie van een beker zou je kunnen definiëren als: ”Zorgen dat ik een drank op een fatsoenlijke manier kan drinken”. Je ziet dat er meer dingen zijn die dezelfde functie kunnen hebben. De beker is in dit voorbeeld een manier waarop je de functie kunt vervullen. Door je eerst te richten op de functie (waar moet je voor zorgen) en dan op het hoe (hoe ga je er voor zorgen), krijg je meer ontwerpvrijheid. Een functie is dus niet ‘een globaal proces’. Als het goed is heeft elk proces in de organisatie een functie. Als het dat niet heeft, dan kun je het proces weglaten. Een functie is in deze betekenis een abstractie van een proces: je laat de details hoe het resultaat tot stand komt (nog even) weg. Let op. Een proces kan meerdere functies hebben (voor verschillende doelgroepen). Dat zie je bijvoorbeeld in een hoveniersbedrijf. Als functies van het primaire proces zou je kunnen zien: - Zorgen dat medewerkers zinvol bezig zijn (in een SW-bedrijf) - Zorgen dat tuinen op orde zijn en blijven (voor de klanten) - Zorgen dat er geld wordt verdiend (als commercieel bedrijf).

Zoals we weten hinderen die functies elkaar soms. Daar moet je wel van te voren overeenstemming over hebben! Activiteiten zijn de dingen die actoren op enig moment doen. Als het goed is werken de diverse actoren samen. Dat betekent dat de activiteiten die ze uitvoeren samenhangen. Ze worden mogelijk in een vaste volgorde uitgevoerd. Dat kan echter alleen maar bij routinematige processen. Er zijn echter veel processen waar wel duidelijk is wat er uit moet komen (wat de functie is), maar waarbij voor elk geval op elk moment weer bekeken moet worden wat de volgende activiteit is. Processen kun je zien als keten van activiteiten. Dat is echter niet zo handig als je voorzieningen moet inrichten. Een proces zie ik daarom als de inrichting van een gedeelte van het bedrijf voor het realiseren van één of meer functies voor bepaalde gevallen. Dat is een wat abstractere visie op proces, maar dat geeft de mogelijkheid aan de actoren in dat proces om de activiteiten uit te voeren in de volgorde en op de manier die voor de specifieke situaties het best is. Slecht in de ‘lopende band situaties’ (dus zeer gestandaardiseerde routinematige processen) is het handig om een proces te zien als een tijdens ontwerp bedachte keten van activiteiten. In alle andere gevallen zijn er ook wel reeksen van opeenvolgende activiteiten, maar die zijn nooit allemaal zo netjes en geordend dat je ze kunt vangen in een stroomschema van activiteiten. (Zie ook: “Informatie architectuur - De infrastructurele benadering” voor dit functie- en procesbegrip) In die processen voeren actoren het werk uit. Vroeger was dat veelal de mens, maar meer-en-meer wordt dat ook gedaan door de machine, de robot. Deze mechanisering en automatisering, wordt gedaan door of ondersteund door computers. Als het echter gaat om begrip, contextueel handelen, besluiten nemen is echter de mens nog wel even aan zet.

Jan Campschroer

21


16-3-2015

Architectuur is gebaseerd op een visie. Dan moet je natuurlijk wel weten wat met ‘visie’ bedoeld wordt. Die visie moet ook over de toekomst gaan, en dan kun je mogelijk beter over toekomstvisie of toekomstvisioen moeten spreken. Je kunt (volgens mij) echter ook een visie hebben op de oorzaken van een bepaald probleem, die ‘oorzaak’visie bepaalt dan wel de manier waarop je het probleem aanpakt. Architectuur gaat over de essentie . Die probeer je te vangen in principes (grondbeginselen). De belangrijkste uitgangspunten waar je niet aan tornt. Een goede collega wees mij nog op het volgende (waar ik hem gelijk in geef): ‘Voordat ik een mening heb, heb ik eerst "een gevoel" (intuïtie inderdaad), als in: "ik heb het gevoel dat de visie op een visie nog niet helemaal compleet is" (en dat is nu dan eigenlijk weer een mening geworden)’. Wat is jouw visie op visie?

Jan Campschroer

22


16-3-2015

Architectuur gaat –in de situaties waar ik het tegenkom voornamelijk- over de toekomst. Het maakt daar ontwerpen van. Het schetst hoe het er uit ziet. Dat doe je met modellen. Modellen in veel verschillende maten en soorten. Afgestemd op de stakeholders. Afgestemd op het doel van wat je wilt communiceren. Voor sommige mensen is een model eerder de “natuurkundige theorie” . Het geeft aan hoe het werkt. Dit zijn meer ‘basismodellen van hoe het werkt’. Zoiets als ‘het principe van de ijskast”, maar dan voor organisaties. Deze principes vertonen meer gelijkenis met designpatterns. Het geeft het onveranderlijke weer. Dit pas je dan vervolgens toe bij het ontwerp. Dus in de deze betekenis leg je bij een model vast “hoe het werkt”, de uitgangspunten, de principes. Ook deze betekenis van het woord model is zeker relevant in het vakgebied. Het helpt om van deze principes visualisaties te maken. Dat helpt ten eerste om ze te communiceren en te begrijpen. Ten tweede zijn ze op deze manier beter te combineren.

Jan Campschroer

23


16-3-2015

Een ander punt van aandacht is het paradigma, de (impliciete) vooronderstelling waarmee je de werkelijkheid bekijkt. Je kunt eigenlijk nooit ‘waardenvrij’ , objectief, kijken. Je hebt (of kiest) een zienswijze, daarna pas kun je bedenken of waarnemen… Voorbeeldje van een paradigma: alle hemellichamen draaien rond de aarde. Je probeert dan alles volgens dat model te verklaren, totdat iemand met een nieuw paradigma komt (Copernicus).. Je paradigma zorgt dat je modellen gekleurd zijn.

Jan Campschroer

24


16-3-2015

Bij het opstellen van modellen maak je modelleringsbeslissingen en ontwerpbeslissingen. Het onderscheid is van belang omdat: -

Een wijziging in de modelleringsbeslissing het (uiteindelijke) systeem niet anders maakt . Je kunt dit bijvoorbeeld doen om de communicatie te verbeteren. Een wijziging in een ontwerpbeslissing verandert het uiteindelijke systeem wel. Een wijziging in de ontwerpbeslissingen moet je dus weer afstemmen/onderhandelen met de stakeholders. Als er al gebouwd is, moet je dat mogelijk veranderen. Deze wijzigingen zijn dus vaak veel duurder. Let echter op. Als je het model niet of verkeerd begrepen wordt, kan dat ook behoorlijke consequenties hebben.

-

Een modelleringsbeslissing kun je als architect maken, een ontwerpbeslissing kun je alleen voorstellen maar moet gemaakt worden door de stakeholders.

Jan Campschroer

25


16-3-2015

In de volgende sheets ga ik in op het specifieke gedeelte van informatiearchitectuur.

Jan Campschroer

26


16-3-2015

Basismodel voor de informatievoorziening is deze. Een zender communiceert met een ontvanger door een boodschap te coderen en de resulterende code te verzenden waarna de ontvanger deze ontvangt en decodeert.

Eventueel is er nog een terugkoppeling over de ontvangst of over de inhoud. Wat verder in dit verhaal zal ik hier wat kanttekeningen bij maken. Maar laten we eerst beginnen met dit eenvoudige model.

Jan Campschroer

27


16-3-2015

Hierboven een grove schets van het informatieproces. Ook hier gaan de gegevens van links (de zenders) naar rechts (de ontvangers). Het proces waar het eigenlijk om gaat (het te ondersteunen proces) is als afnemer aan de rechterkant getekend. Aan de linkerkant wordt de werkelijkheid of de gedachten van mensen gevangen in gegevens, documenten , films, foto’s, geluidsfragmenten, kaarten, etc. Die zaken worden bewaard, bewerkt en getransporteerd om uiteindelijk bij een afnemer te komen die daar zijn informatie uithaalt. Meer en meer van dit proces wordt geautomatiseerd of gedigitaliseerd. Aan de rechterkant heb ik ‘analogiseren’ gebruikt als term om het omgekeerde van digitaliseren weer te geven: een digitaal signaal leidt tot een echte actie (een garagedeur die omhoog gaat, het blikje dat je krijgt na een pinbetaling) De situaties waar IT wordt gebruikt om een bestaand proces te automatiseren vallen hier ook onder. Vaak is dan het proces dat ondersteund moet worden niet zo in beeld. We hebben in dit soort situaties te maken met vele zenders. Elke persoon die gegevens registreert in een applicatie is in feite een zender. We hebben ook vele ontvangers van die gegevens. Soms zijn die gegevens verder onbewerkt. Soms worden vele gegevens samengevoegd en bewerkt om ze op te nemen in een rapportage, een dashboard. De mensen aan deze kant interpreteren deze informatieproducten en gaan – voor ze het (goed) begrijpen – hier ook naar handelen. In het midden ontstaat daardoor een soort Klant Order Ontkoppeling Punt (KOOP). Doordat al veel gegevens aanwezig zijn kan ik de informatieproducten snel maken. Dat wil zeggen: dat is het idee…. Aan de linker en aan de rechterkant zijn er mensen die: a)

óf de wereld waarnemen of iets bedenken en dat coderen in termen, geluiden of plaatjes

b) de geluiden, termen en plaatjes (de code) proberen te begrijpen binnen hun context. Die (de)codering vraagt nog even wat specifieke aandacht vandaar dat ik op de volgende pagina’s wat concepten die hierbinnen een rol spelen verder toelicht.

Jan Campschroer

28


16-3-2015

Informatie is de toename van relevante kennis van een persoon op enig moment. Iemand krijgt informatie als hij een (begrijpelijk) antwoord krijgt op een impliciet gestelde vraag. Hoe beter het antwoord in terminologie, vorm, actualiteit en juistheid aansluit bij de behoefte, hoe beter het is. Let op: het antwoord an sich is niet de informatie. De informatie is de verandering binnen de persoon. Informatie is (voor mij) de interpretatie van het antwoord door de ontvanger. Hetzelfde antwoord kan voor verschillende personen tot heel andere informatie leiden. De krant van morgen (met name de aandelen koersen) levert vandaag veel informatie, morgen veel minder. De krant van morgen is vandaag voor een ongeletterde persoon veel minder waard, dan voor een ervaren beurshandelaar. Een gegeven is een abstractie van enige situatie. “Ik ben ouder dan 18 jaar”, “Ik ben in 1957 geboren” en “Ik ben jonger dan 80 jaar” zijn drie (aanduidingen van) gegevens. De tijdspanne waarin die uitspraken waar zijn, is echter anders. Bij het verzamelen van gegevens proberen we die gegevens te registreren die ‘eeuwig’ waar zijn. Dat vermindert namelijk de beheerkosten: anders moet je bij het verstrijken van de tijd, steeds je registratie bijwerken. Met het opnemen van de materiële tijd (van wanneer tot wanneer is deze uitspraak waar) bij gegevens creëer je correctere gegevensverzamelingen.

Jan Campschroer

29


16-3-2015

Je kunt hetzelfde op heel veel verschillende manieren communiceren. Gegevens kun je op verschillende manieren representeren. Dat gebeurt aan de lopende band in IT-systemen: op het scherm zien de gegevens er anders uit als in de database en dat ziet er ook weer anders uit als in een bericht. Daarbij is het wel zo dat die tekens een beperkte reikwijdte hebben. Dat komt omdat de schrijver en de lezer eenzelfde ‘codeermechanisme’ moeten gebruiken. Dus als je wilt overdragen wat je bedoelt moet de lezer jouw tekens kunnen begrijpen. Ter overdenking even het volgende: - Zou 1957 een plaats kunnen zijn? - Welke jaar bedoelen ze in China met 1957? - Is “er is een jaar met de aanduiding 1957” een gegeven? - Is “er is een persoon met de naam K. Bergmans” een gegeven? - Hoeveel gegevens communiceer je als je zegt: ‘K. Bergmans is geboren in 1957’ - En is “er is een verband tussen een persoon en een jaar met de aanduiding ‘K. Bergmans is geboren in 1957’ “ ook een gegeven? - Rood betekent in China heel wat anders dan hier

Jan Campschroer

30


16-3-2015

In de klassieke opvatting over het ontwerpen van informatiesystemen begin je met een informatieanalyse (aan de rechterkant in het informatieproces) om er achter te komen wat de relevante (vast te leggen) gegevens zijn. Als je dat niet doet dan verzuip je namelijk in dat wat je allemaal zou kunnen registreren. Er zijn 1000-den gegevens te bedenken over een eenvoudige glazen bol. Er zijn echter situaties waar je van te voren niet weet wat relevant is. Bijvoorbeeld bij een inbraak. Daar krijg je dus allerlei losse gegevens die je van te voren niet geklassificeerd hebt. Noot: Zelfs foto’s van de situatie zijn mogelijk niet voldoende. Mogelijk moet je ook de temperatuur opnemen, de luchtvochtigheid, een monster van de lucht, wie weet… Ter overweging: Stel: anderen hebben gegevens verzameld voor een ander proces. Hoe groot is dan de kans dat die gegevens ook in jou situatie (exact) bruikbaar zijn? Tegen welke problemen loop je aan?

Jan Campschroer

31


Jan Campschroer

16-3-2015

32


16-3-2015

In het boek ‘Meaning of meaning’ (C. K. Ogden and I. A. Richards) wordt de driehoek geïntroduceerd met op de hoekpunten (van linksonder met de klok mee) de term (het symbool), de gedachte en de referent( het ding). Belangrijk is echter dat de actor (de mens) de verbinding legt tussen die drie zaken. Soms zijn er echter geen drie zaken, maar slechts twee. Ooit een witte eenhoorn in het wild gezien? Omdat die mens de verbinding legt, is het ook belangrijk om het verschil tussen de perceptie (wat je daadwerkelijk ervaart) en de conceptie (wat je denkt te ervaren). In ons hele leven zien we eigenlijk altijd maar één zijde van een huis tegelijkertijd, in ons hoofd maken we er één ding van. Een uitgebreide beschrijving is terug te vinden in Friso rapport: http://csexhibitions.uni-klu.ac.at/index.php?id=445. Bij communicatie wordt de term overgedragen, maar er zijn zowel aan de kant van de spreker als aan de kant van de ontvanger nog verschillende ‘vertalingen’. Op al die punten kan het mis gaan en gaat het ook wel eens mis. Bij het inrichten van de informatievoorziening moet je met deze basisbeginselen van communicatie rekening houden.

Jan Campschroer

33


16-3-2015

Je ziet 1 dag (1 perception) je kunt er echter twee dingen van maken (2 conceptions).

Mopje van Franse dame en Engelse heer. Dame zegt: ”Je t’adore” Man hoort : “Shut the door” Je hoort 1 ding, je kunt er echter twee dingen van maken.

Jan Campschroer

34

In het naieve (simpele) model van communicatie hebben we een zender (die iets zegt) en een ontvanger (die iets hoort). Op deze manier is er een wisselwerking tussen de gedachten van de een en de gedachten van de ander. Met een beetje geluk (en als dat überhaupt mogelijk is) beleven de twee partijen in de communicatie dat het gaat over dezelfde ‘werkelijkheid’.

Jan Campschroer

35


16-3-2015

In een wat uitgebreider model onderkennen we echter meer interactie: - Je hoort niet alleen wat er gezegd wordt, je ziet ook wie het zegt, op welke manier hij het zegt en wat voor gezicht hij er bij trekt en in welke omgeving het wordt gezegd. - Je weet al het een en ander over het voorgaande, over de persoon, over de omgeving. Dit is allemaal context. Context is al die kennis die je van te voren hebt en ervaringen die je tegelijkertijd met de code krijgt en je helpt om de code te interpreteren. Bij communicatie via digitale kanalen is veel van deze context weg. Bijgevolg geeft dat ook meer misverstanden.

Jan Campschroer

36


Jan Campschroer

16-3-2015

37


16-3-2015

Organisaties (eigenlijk, mensen in en om organisaties) hebben informatie nodig om te kunnen (samen) werken. Voor die informatie heb je gegevens nodig. Die gegevens moet je voor een deel zelf vastleggen en verzamelen, maar meer en meer is het zo dat er al gegevens zijn die behoorlijk voldoen aan wat je nodig hebt. Ze zijn mogelijk niet zo actueel, gedetailleerd of volledig als je zou willen hebben, maar ze zijn wel direct beschikbaar. Als je de gegevens eerst zelf nog moet verzamelen, gaat dat meer tijd en hoogstwaarschijnlijk meer geld kosten. En met name die ‘tijd’ is belangrijk, want je wilt snel kunnen schakelen. In de private sector omdat anders je concurrent je voor is, in de public sector om de beloofde kwaliteit te realiseren (kijk naar de veranderingen in de zorg). Vervolgens kun je, terwijl het proces al draait, werken aan het verzamelen van betere gegevens om het proces en de dienstverlening of product (nog) beter te maken. De IT-systemen van de toekomst moeten dus zodanig zijn dat ze gewoon om kunnen gaan met de gegevens die er zijn en waarvan is vastgesteld dat je ze mag gebruiken. Dat betekent dus dat ze snel die gegevens in combinatie wat je al hebt omzetten naar de maximale informatie die er uit te halen is. Dus geen lange conversie, geen lange applicatie-integratie, geen moeizaam koppelingstraject: als helder is dat je gegevens mág gebruiken en je kúnt ze ook gebruiken, dan moet het een kwestie zijn van de kraan open draaien om ze tot je beschikking te krijgen. Daarnaast moet je in een kort ontwikkelingstraject deze nieuwe gegevens in combinatie met wat je al had optimaal bruikbaar maken voor je organisatie. Dat kan trouwens ook betekenen dat je jouw omgeving van betere informatie voorziet of nieuwe informatieproducten in de verkoop krijgt. Kortom gegevens stroomt het huis binnen als water en we zet het om naar informatie waar nodig.

Als dit de toekomst is waar we naar toe willen werken, wat moet er dan (nog) allemaal bedacht, gemaakt, georganiseerd en geregeld worden? Dát is de opgave van Informatiearchitecten.

Jan Campschroer

38


16-3-2015

Volgens mij het belangrijkste dat hindert bij ‘informatie uit de kraan’ is dat IT-systemen niet om kunnen gaan met ongestructureerde gegevens. Dat wil zeggen ze kunnen dat niet bewerken. Wel transporteren en opslaan, maar niet interpreteren, redeneren, transformeren. Daar zijn steeds weer mensen voor nodig die nu continu bezig zijn om het ongestructureerde gestructureerd te maken zodat de machine er iets mee kan (Zie ook de belofte van het semantic web). Maar de gewenste structuur is afhankelijk van het doel. Dus dat geeft veel werk. Bovendien krijg ik het dan mogelijk wel uiteindelijk in een werkbare structuur. Mogelijk dat bij registratie belangrijke zaken zijn weggevallen. Daar moet je dus of mee om kunnen gaan, of je moet een gok doen. Daar kunnen vervolgens de bestaande systemen dan ook weer niet mee omgaan.

Jan Campschroer

39


16-3-2015

Ik zie de volgende: 1. ICT werd en wordt nog steeds ingezet om administratieve en gegevensintensieve processen te automatiseren. Daarmee maakt de organisatie voornamelijk een efficiency slag (vraag de Belastingdienst maar eens). Daarmee verhoog je de perfomance, maar creëer je gelijk ook een star proces. (Vraag diezelfde Belastingdienst maar eens). Door het aanbrengen van structuur (nodig voor automatiseren) loop je telkens achter de feiten aan omdat de wereld verandert. 2. Alle energie (geld, middelen, besturingsaandacht) gaat naar het maken van ICT-applicaties en er is weinig meer over om er voor te zorgen dat de mensen de juiste informatie krijgen. ICTapplicaties zijn middel, geen doel. Goed voorzien van informatie is het (sub)doel waarmee je vervolgens de performance van je organisatie verbetert. 3. De huidige ICT-applicaties hebben gestructureerde gegevens nodig om deze geautomatiseerd te kunnen verwerken. (*) Die structuur moeten we van te voren bedenken om er later achter te komen dat die te kort schiet (voor een nieuw product, dienst of doelstelling) en/of niet past bij de structuur van de partner met wie we (ineens) moeten gaan samenwerken in de keten. Structuur is nodig voor ICT, maar het hindert in flexibiliteit. (*) Ongestructureerde gegevens (documenten, teksten, filmpjes, foto’s, geluidsopnames) kunnen alleen opgeslagen, getransporteerd of in zo goed als de oorspronkelijke vorm worden weergegeven. De software om deze te structureren en geautomatiseerd te kunnen interpreteren en verwerken begint een beetje te komen, maar is nog zeker niet op het juiste niveau. 4. Je hebt een krachtig instrument waarmee je veel in één keer goed kunt doen, maar ook veel in één keer fout. Eén verkeerde tweet kan immens veel schade aanrichten. 5. Via mail kun je wel ruzie krijgen, maar niet oplossen. Voor dat laatste is toch weer even ‘echt’ contact nodig. In digitale communicatie verliezen we blijkbaar wat. Op social media wordt niet direct altijd lekker sociaal gereageerd. Je zou kunnen zeggen dat we ‘de emotie’, maar je mag het ook een andere naam geven, verliezen. De vraag is echter wat dat met onze contacten en informatie doet als we heel veel digitaal gaan communiceren. De ‘emotie’ is een wezenlijk bestanddeel in onze normale menselijke communicatie. Krijgen we niet een ernstige scheefgroei als we die ‘emotie’loze digitale communicatie tot DE (enige) communicatie verheffen? 6. Door onvoldoende bewustheid over de (on)bruikbaarheid van andermans gegevens voor je eigen doel worden besluiten genomen op basis van informatie waarvan de juistheid onvoldoende wordt meegenomen. Klanten worden niet goed geholpen, burgers komen in de knel. Integratieprojecten voor hergebruik van andermans gegevens kosten veel meer dan voorzien. Voor 80% gaat het misschien wel goed, maar die 20% waar het fout gaat bepalen wel je imago. 7. De gegevenskwaliteit laat te wensen over. En gegevensmodellen en definities dan ? Tja, dat kost toch alleen maar geld, ‘t gaat toch om de software en de datastructuren, en uiteindelijk bepaalt de schrijver wat t betekent … Gegevensmanagement is een vorm van risicomanagement.

Jan Campschroer

40


16-3-2015

Het naïeve model van communicatie is onvoldoende voor onze veranderlijke maatschappij. Hoe zorgen we voor afstemming van de code (der code(der code(…)))?

Kijken we wel op de goede manier?

Jan Campschroer

41


16-3-2015

Veel van de vertragingen en fouten bij het realiseren van IT-systemen komen voort uit de noodzaak om met andere IT-systemen te koppelen. Die koppelpunten zijn per definitie zorgpunten voor projectleiders en applicatie ontwerpers. Voordat we gaan koppelen zijn weer eerst weer de code aan het vaststellen….

Jan Campschroer

42


16-3-2015

De interactie tussen mens en machine is niet ‘natuurlijk’. Hij is star en bevroren. Van te voren in de machine gestopt. Je belt omdat je een probleem of een vraag hebt. Vervolgens krijg je een ingeblikt stem die zegt: “Als …. kies een 2…. Als …. kies een 3… Vervolgens mag jij bedenken in welke klasse het valt. Klassen die ontworpen zijn voor een aantal gevallen, die in de praktijk nooit precies zo voorkomen.. Mooier zou anders om zijn. Je stelt de vraag en de computer bepaalt dan (eventueel met doorvragen waarop je dan ook als leek antwoord op kunt geven) wat de beste route is om snel te een antwoord te komen. Ander voorbeeld: Je hebt nu de mogelijkheid om te zeggen wie je wilt spreken, de computer zegt wat hij er van gemaakt heeft. Als dat niet goed is, moet je snel een * toetsen! Ook daar is het goed om even een mondelinge terugkoppeling in te bouwen.

Jan Campschroer

43


16-3-2015

Als de tekens waarmee je de gegevens hebt gecodeerd verder van de oorsprong af komen te liggen: andere tijd, ander locatie, andere organisatie, andere cultuur, dan is de kans groter dat je de tekens niet meer begrijpt. De ‘gegevens’ zijn dus niet ‘oneindig transporteerbaar’. Je moet er meer (tekstuele context) aan toevoegen om duidelijk te maken wat je bedoelt. Net als dat jaartal van even zojuist (je moet dan voor een Chinees ook de jaartelling uitleggen die je gebruikt) voor ons is dat "logisch“. Dat laatste is een veel gehoord argument om niet specifiek te zijn: luie communicatie. Ook bij het toevoegen van context gegevens maak je weer (pragmatische) keuzes. Hoer ver met je hier in gaan. Kun je dit voor-een-en voor altijd vastleggen? De vraag is wel of je het met het (statisch) toevoegen van (tekstuele) context redt. Mogelijk moet je eerst een proces(je), een interactie, opstarten om elkaars taal en gebruiken te leren kennen voordat je effectief kunt gaan communiceren. Die ‘leermodus’ gaan wij in feite aan op het moment dat we zien dat de ander ons niet begrijpt of als we verwachten dat de ander ons niet zonder meer begrijpt.

Jan Campschroer

44


16-3-2015

Als je gegevens ziet als een ‘conception’ dan is dat niet transporteerbaar. Wil je bij een andere partij de juiste conception laten ontstaan, dan is dat moet je weten of er achter zien te komen welke taal/talen hij verstaat en van daaruit het communicatieproces in gang zetten om (uiteindelijk) te kunnen zeggen wat je wilde zeggen. Hoe beter je elkaar kent, hoe kleiner de inspanning vooraf. Ofwel: een als je elkaar goed kent, dan heb je aan een half woord genoeg. (

Jan Campschroer

45


16-3-2015

Net zoals we vliegtuigen hebben gebouwd naar het voorbeeld van de vogel, maken we informatiesystemen naar het voorbeeld van de menselijke manier van communiceren.

Daarnaast moeten we - zeker de komende tijd – zoveel mogelijk context aan gegevens gaan toevoegen. Verder moeten we – en daar ga ik verder niet op in – die dingen regelen die 1. de datalogistiek goed mogelijk maken. Dus geheel los van semantiek van de data zorgen dat het van A naar B komt op de manier zoals nodig is in het proces. (bulk, op aanvraag, of op abonnement) 2. De beveiliging goed geregeld is. Dus zorgen dat niemand data kan stelen. 3. De autorisatie goed geregeld is. Dus je moet weten wie welke data je aan wie kunt en mag geven waarbij je op een of andere manier kunt nagaan dat de data alleen die informatie levert aan de persoon die hij mag hebben . (Dit is de lastigste) Mogelijk helpt het structureren van gegevens in termen van linked-data. Die lost – is mijn overtuigingechter het paradigma-probleem (de code der code) niet op! Het zorgt echter wel dat de datalogistiek makkelijker gaat c.q. minder problematisch wordt.

Jan Campschroer

46


16-3-2015

In de huidige manier van ontwikkelen van informatiesystemen zijn heel veel overgangen te onderkennen die een risico vormen voor helder communicatie. Dat hebben we tot nu toe opgevangen door: veel terugkoppeling en heel precies specificeren wat je wilt.

In ketens heb je die terugkoppeling echter niet (vanzelf). Ook kun je de deelnemers in de keten niet dwingen om jouw manier van de wereld beschouwen en coderen over te nemen. Je moet het dus doen met wat je krijgt. Je zult zelf steeds weer je eigen interpretatie moeten maken van de werkelijkheid.

Jan Campschroer

47


16-3-2015

Het lijkt er op dat we daar als mensen beter mee om kunnen gaan. Tuurlijk, als je geen chinees kent en je wordt in China gedropt, dan heb je het een tijdje moeilijk. Maar als je een tijdje blijft zul je de taal (enigszins) leren, als je er moeite voor doet. Maar ook als je in een andere organisatie komt kun je al gelijk aan de slag ook al begrijp je niet iedereen voor de 100%. Je herkent het jargon (je wordt gekneed in de cultuur) en nar een tijdje praat je gewoon mee. Dus met het leren van het jargon word je ook effectiever en efficienter.

Jan Campschroer

48


Jan Campschroer

16-3-2015

49


16-3-2015

Dat betekent dat elke situatie uniek is en dat je van te voren de betekenis niet (precies) vast kunt leggen.

“…sentences are not carriers of propositions …” De context bepaalt de betekenis van een “symbol”.. (meaning is use) Dit is min of meer tegenstrijdig met de algemene binnen IT gewenste situatie dat één symbool voor één ding staat, ongeacht waar het staat. Dus contextvrij. Het is juist die context die communicatie via niet van te voren afgesproken tekens mogelijk maakt. (is mijn overtuiging)

Jan Campschroer

50


16-3-2015

Het gaat er niet om dat je de theorie die de menselijke communicatie “verklaart” goed begrijpt. Het gaat erom dat je ziet dat je in de communicatie waarneemt en verbindt met geheugen. Al deze (onbewust) aanwezige kennis gebruik je om te communiceren met je omgeving. D.w.z. om te begrijpen of iemand met jou aan het communiceren is en wat hij wil zeggen, maar ook om te communiceren met die ander. Base space is de basiskennis over waar je bent. Hierin zie je de dingen. Presentation space is je kennis over symbolen (dat iets een symbool kan zijn) Memory is wat je weet van de spreker Reference is wat je in zijn algemeenheid weet Relevance is de (on)bewuste selectie van de (onbewuste) waarneming welke je onderdeel vindt van de communicatie. Blend is de combinatie die tot stand komt door Presentation, Memory en Reference te combineren binnen de beperking van wat voor mensen relevant is.

Jan Campschroer

51


Jan Campschroer

16-3-2015

52


16-3-2015

ICT systemen zijn ingewikkelde (en soms krakkemikkige) hulpmiddelen waarmee mensen tijd en plaats kunnen overbruggen om met elkaar te communiceren. We doen soms alsof we de mensen (meervoud) hebben en de computer (enkelvoud). Binnen die computer doen we dan het liefst niet aan redundancy. Het is mijn overtuiging dat we van dat beeld af moeten stappen en ook binnen de (geautomatiseerde) informatievoorziening (intelligente, veelwetende) actoren moeten onderkennen die met elkaar en met de mensen communiceren. Zo’n informatie-actor zal ik hierna infactor noemen. Waarbij data door alle verbindingen stroomt en lokaal steeds weer betekenis wordt gegeven. Door de mensen maar ook door de infactoren. Hoeveel en hoe groot die infactoren zijn weet ik niet. Mogelijk is Google een infactor in wording en de e-Overheid een andere. Misschien heb je er ook kleinere die samen soms acteren alsof ze een eenheid zijn. Dus dan heeft elke gemeenten zijn infactor (een soort avatar van de gemeente) en kunnen die samenwerken om zo een infactor van de VNG te vormen. Je krijgt zo als het ware een spiegeling van de rechtspersonen in het handelsregister. Maar mogelijk krijg je ook infactoren welke de tegenhanger zijn van organisatie onderdelen. Daar is dus nog wat ontwerpen ontdekkingswerk te doen. Wat is de ideale grote en zo. Mogelijk levert het zelfs juridische en ethische kwesties. Als de infactor het allemaal doet en de mensen er omheen alleen maar de IT in de lucht houden, wie is dan verantwoordelijk?

Jan Campschroer

53


16-3-2015

Als we inzoomen op de communicatie tussen een mens en infactor dan zien we dat ze op meerdere manieren met elkaar contact hebben: via geluid, licht, gevoel en geur. Nog niet al die interfaces zijn er. Maar er zijn zelfs interfaces die rechtstreeks op de zenuwen aansluiten. Die redundancy in interactie heeft een functie. Verder bouwt niet alleen de mens een eigen beeld op, ook de infactor doet dat. In eerste instantie vertalen we de mentalspaces naar kennisbanken zodat de infactor ‘weet’ waar hij is, met wie die praat, etc. Google heeft dat voor een deel al ingebouwd doordat ze jouw vragen onthouden en (afhankelijk van hoe je communiceert) kunnen ‘zien’ waar je bent. De infactor die met je communiceert kent je dus (op den duur) en weet je vragen en de dingen die je vertelt te interpreteren.

Jan Campschroer

54


16-3-2015

Voor de communicatie tussen infactoren geldt mutatis mutandis hetzelfde. De vraag hier is dan wel op welke manieren zij met elkaar communiceren. Hoeveel verschillende manieren van communiceren zijn er? Of blijft het hier bij het een-dimensionale digitale berichtenverkeer? Is hier geen redundancy nodig om beter te kunnen communiceren? Hier is nog wat onderzoek werk te doen. Blijven we in het voorgaande patroon verder denken dan horen daar enkele principes . Deze staan in het vervolg. Deze principes lijken–zeker als je bijvoorbeeld naar de NORA en het stelsel van basisregistraties kijkt – strijdig te zijn met wat nu nog heel erg gangbaar is en soms ook nog gangbaar aan het worden is.

Jan Campschroer

55


16-3-2015

Structureer achteraf voor Rationale Op dit moment structuren we eerst de benodigde informatieproducten en de daartoe benodigde gegevens. Daarbij maken we allerlei keuzes (omdat het anders te veel werk wordt), de gegevens en de verwerkende processen worden geoptimaliseerd voor het gebruik. Als je die gegevens dan ergens anders voor wilt inzetten dan passen ze niet. Ze zijn gevormd (misvormd) naar het gebruik en dus niet meer zo algemeen bruikbaar. Als we al dat structureren achterwege kunnen laten, dan kunnen we veel meer onbevangen en objectief (zonder vooroordeel over wat belangrijk is of niet) de situatie vastleggen. Als we al die structuren van te voren niet meer hoeven te ontwikkelen, dan kun je in ieder geval al veel eerder beginnen met registreren. (Iedereen kan Note-pad gebruiken zogezegd). Implicaties Dat betekent wel dat je uit het vastgelegde de voor jou relevante gegevens en regels kunt vinden. Die gegevens moeten er dan toch wel inzitten én de software moet die structurering zelf kunnen doen. Het eerste kun je regelen met opleidingen en – waar nodig- later met software die controleert of bepaalde gegevens in de vastligging zitten en zo niet bij de schrijver gaan vragen om aanvulling. Ook daar heb je weer voor nodig dat de software een interpretatie (en structurering) kan doen van ongestructureerde gegevens. In het onderwijs kom je dat tegen bij opgaven in de vorm van redactiesommen.

Gebruik gegevens redundantie Rationale Eenmalig registreren is natuurlijk goedkoop, maar is ook foutgevoelig. Je bent helemaal afhankelijk van die ene actor die de gegevens heeft geregistreerd. Hoor- en wederhoor. 4-ogen principe zijn invullingen van de principe om ervoor te zorgen dat de gegevens betrouwbaar zijn. Ze zorgen ook voor nuancering om dat ‘hetzelfde’ toch net iets anders is verwoord. Je zou kunnen zeggen dat je meer beelden krijgt van de werkelijkheid en daardoor meer diepte en meer context ziet. Implicaties Dat betekent wel dat je veel meer data hebt om vast te leggen. Dat moet dan geen issue zijn Gebruik data redundantie Rationale Als gegevens maar op één plaats liggen creëer je daarmee een Single Point Of Failure. Redundancy is een veelgebruikt principe om robuustheid en snelheid te creëren. Als de ene server er uit ligt, kun je nog altijd bij die ander terecht. Door gegevens op verschillende servers te repliceren kan het proces parallel worden uitgevoerd. Daarnaast wil je ook je eigen gegevens kunnen verbinden met de gegevens van een ander. Als het ene proces verantwoordelijk is voor het identificeren, toekennen van een klantnummer en registreren van de klant, dan is het wel handig dat in het ordersysteem datzelfde klantnummer gebruikt wordt voor diezelfde klant. Dat klantnummer moet daarvoor toch echt worden gekopieerd. Door verschillende gegevens fysiek bijeen te brengen kun je patronen herkennen en (business) intelligente uitspraken doen. Je weet van te voren niet welke gegevens je daarvoor van een ander nodig hebt. Gevolg is dat je zoveel mogelijk (big) data bij elkaar brengt.

Jan Campschroer

56


16-3-2015

Ik heb hiervoor mental spaces al vertaald naar kennisbanken (dataspaces) die gebruikt worden om de binnenkomende indrukken te vertalen naar tekens. Die tekens vormen de perception. Het is – op een bepaalde manier – dat wat is gezegd, de wereld zoals hij binnenkomt bij de infactor. Een patroon wordt een digitaal geconstrueerd ding binnen een infactor welke een weergave is van zijn ‘begrip’ van de werkelijkheid. Patronen vormen (een deel van) de conceptions. Het zijn de dingen die er van gemaakt worden. Het is dus niet iets wat is gecommuniceerd aan de infactor, maar wat daarbinnen is ontstaan. Soms is dit ook wat de infactor verteld, maar dan weer in zijn eigen woorden. Dat betekent dat het vermengd is met, beïnvloed is door, de kennis die de infactor al had. Wat de infactor meldt, is een (meer of minder) onderbouwde mening geworden, die meer of minder waar is. Dat betekent nogal wat voor de IT. Patroonherkenning wordt belangrijk. Je moet echter ook wat is gezegd onderscheiden van wat je er van gemaakt hebt. Dat vergt nogal wat van de reken- en opslagcapaciteit. Ik weet niet of we daar al aan toe zijn. Daarnaast zijn er een aantal zekerheden, waar we nu al wel aan kunnen gaan werken. Ik heb ze bij de start genoemd. Ik herhaal ze hier: We moeten zorgen dat: 1. datalogistiek goed mogelijk is. 2. De beveiliging goed geregeld is. 3. De autorisatie goed geregeld is.

Jan Campschroer

57


Jan Campschroer

16-3-2015

58


Jan Campschroer

16-3-2015

59


Jan Campschroer

16-3-2015

60


Jan Campschroer

16-3-2015

61


Jan Campschroer

16-3-2015

62


Jan Campschroer

16-3-2015

63


Jan Campschroer

16-3-2015

64


Jan Campschroer

16-3-2015

65

Informatiearchitectuur in de keten. Jan Campschroer

Recommend Documents