VOS vraag: masterdata en gegevensbeheer als speerpunten voor de informatie-architect

Ik zie bij veel organisaties veel knelpunten die te maken hebben met gegevens:

  • De kwaliteit van gegevens is laag, velden worden misbruikt of niet ingevuld
  • Gegevens zijn verspreid over allerlei systemen en worden niet consistent gehouden, waardoor ze meervoudig voorkomen
  • Mensen hebben geen toegang tot de gegevens die ze nodig hebben voor hun dagelijks werk omdat applicaties niet geïntegreerd zijn
  • Management krijgt geen integraal inzicht in de noodzakelijke gegevens
  • Getallen in rapportages zijn niet herleidbaar naar gegevens in de bronsystemen

Dit leidt in veel gevallen tot principes in de informatie-architectuur waarin wordt verwoordt dat eigenaarschap van gegevens moet worden belegd, dat gegevens moeten worden beheerd in de bron en dat organisatiebrede gegevens moeten worden uitgewisseld. Ik merk echter dat organisaties het lastig vinden om hier concrete stappen in te zetten. Er is behoefte aan concrete ondersteuning.

Hierdoor is bij mij het inzicht ontstaan dat gegevensbeheer in het algemeen en het beheren van mastergegevens in het bijzonder erg belangrijk is voor organisaties. Informatie-architecten hebben echter mijns inziens te weinig inhoudelijke kennis van deze onderwerpen om organisaties op weg te helpen. Ik zou daarom graag in een open space vorm samen met anderen komen tot een praktische invulling van gegevensbeheer die we vanuit architectuur kunnen trekken. Ik hoor natuurlijk graag wat jullie van het idee vinden.

Weergaven: 1133

Hierop reageren

Berichten in deze discussie

Hallo Frank,

Jouw verhaal en blog item zijn erg herkenbaar. Zowel het data management, infomatiemanagement als het architectuurvakgebied zijn nog sterk in ontwikkeling en hebben last van onduidelijke rollen, taken en verantwoordelijkheden. Ik probeer daar vanuit mijn primaire rol als architect meer duidelijkheid over te krijgen.

Mijn blog item probeert in ieder geval duidelijk te maken dat informatie-architecten zich meer zouden moeten richten op de data zelf en het beheer ervan. Uiteraard is dit grotendeels een organisatorisch vraagstuk, maar het is interessant om te zien wat de rol van de architect daarin zou moeten/kunnen zijn. Het lastige is dat er allerlei smaakjes architect zijn en dat het daarmee lastig is om de discussie in het algemeen zuiver te krijgen. Ik zie in ieder geval een duidelijk verschil tussen informatie-architecten die vooral functioneel naar het vraagstuk kijken en BI-architecten die vooral vanuit constructieperspectief naar het vraagstuk kijken en daarmee mijns inziens vooral BI-specialist zijn.

Ook de verdeling van verantwoordelijkheden tussen deze architecten en met andere betrokkenen bij data management is interessant. Ik heb de DAMA Guide to the Data Management Body of Knowledge ook gelezen. Het aardige is dat daar RACI-achtige tabellen in staan waarin je daar al een aardig beeld bij krijgt. De door bij benoemde rollen van informatie-architect en BI-architect matchen redelijk op de rollen applicatie-architect en data architect in de DAMA guide. Het is overigens interessant om te zien dat ook in COBIT (iig in versie 4) de informatie-architect ook een erg gegevensgerichte verantwoordelijkheid heeft.

Daarnaast is er natuurlijk nog de relatie met de informatiemanager. Ik ben met dat vraagstuk ook bezig vanuit het Ngi waarin we vanuit de afdelingen architectuur, informatiemanagment en governance rijken naar raakvlakken en overlap. Vooralsnog is mijn voorlopige conclusie dat de informatiemanager op dezelfde plek zit als de informatiearchitect (vanuit het Amsterdamse 9-vlaksmodel geredeneerd), maar dat de informatiemanager de nadruk legt op management, besluitvorming en sociale aspecten en de informatie-architect meer op de inhoud en analyse.

Het lijkt me leuk als je ook meedoet met de open space sessie op 14 maart zodat we van elkaar kunnen leren. In het algemeen geloof ik erg in een multi-disciplinaire aanpak waarin verschillende disciplines samen vraagstukken kunnen aanpakken. Ik denk dat (master) data management bij uitstek een gebied is waarbij een dergelijke multi-disciplinaire aanpak essentieel is.

Mvgr,

Danny

Hoi Frank, I seccond that.

Om het concreet genoeg te maken voor de VOS komt de volgende vragen bij mij naar voren:

- Wat doet er pijn nu die data-strategie er niet is?

- Welke aspecten zouden aan de orde moeten komen in de data-strategie?

- Zijn er voorbeelden van een ontwikkelde data-strategie?

- Welke principes en richtlijnen volgen hieruit voor de inrichting van de informatievoorzieningen?

 


Frank Harland zei:

De regel "Iedere business-strategie heeft een data-strategie" zou wat mij betreft altijd op moeten gaan. 

Het wordt misschien wat makkelijker duidelijk te maken wanneer we in ons achterhoofd houden dat, afhankelijk van de branche, 30-80% van de waarde van organisaties in de data zit.

Ik verwijs voor geïnteresseerden ook graag naar dama.org, de site van de Data Management Association, een groep data professionals die standaarden opzet voor gegevensmanagement en -governance. 

Allen,

In het licht van de laatste bijdragen ("De grootste uitdaging zit hem in het organiseren van de mensen rondom de data") is het wellicht ook zinnig om (nog eens) te verwijzen naar het boek "Information Orientation - The Link to Business" [1]. Mijn review daarvan is eveneens beschikbaar [2].

[1] http://www.amazon.com/Information-Orientation-Business-Donald-March... (inclusief review).
[2] Orientatie op Mens en Informatie: http://www.emovere.nl/?doc=110 

Atilla,

Wat je aangeeft is, denk ik, heel herkenbaar. Een klassiek probleem – het strompelt al een tijdlang rond… En de aanpak? Ook (nog steeds) klassiek? Met (als vanouds) een even klassieke uitkomst?

Is “ongestructureerde data” eigenlijk niet zoiets als een contradictio in terminis? Naar mijn idee is data zonder structuur… geen data.
Vanuit ITechnologie redenerend betreft gestructureerde data bij uitstek het data-gebied dat IT (reeds) ‘veroverde’ en onder de dwingende/knellende hoede bracht van tal van aparte, via interfaces gekoppelde, informatiesystemen. Ongestructureerde data betreft daarentegen het data-gebied dat nog niet door IT ‘ingelijfd’ of ‘gedomesticeerd’ is – daar kan IT ‘dus’ op haar oude en vertrouwde manier niets mee. In het scheiden van die twee categorieën in twee te koppelen werelden zie ik geen heil. Het gaat, naar mijn idee, ‘gewoon’ altijd om data die zich op de één of andere manier verhoudt tot andere data. En van sommige verhoudingen weten we (nu eenmaal) meer dan van andere verhoudingen (analogie: chaos niet zozeer zien als wanorde, maar veeleer als een orde die we (nog) niet (zo goed) kennen.

Belangrijker: Waartoe ordenen wij data eigenlijk? Dat heeft, naar mijn idee, alleen en uitsluitend te maken met de betekenis ervan. Wat is betekenis eigenlijk? Hoe komt betekenis in mensen tot stand? Hoe komt betekenis in onze informatiesystemen tot stand? Dat soort vragen speelt naar mijn idee nog veel te weinig een rol bij het (nadenken over het) managen van data.



Atilla Vigh zei:

Het is een klassiek probleem en wordt door de komst van "Social Media" alleen maar erger. Het probleem dat hier beschreven wordt gaat over gestructureerde data (=gegevens). Er is langzamerhand een wereld ontstaan die vele malen groter (in ieder geval in bits en bytes) is van de ongestructureerde data (≠gegevens).  Hoe gaan we daar dan mee om? Een stapje verder, hoe koppelen we die 2 werelden op een consistente en veilige manier. 

Je daagt me wel uit, Jan.

Ik onderscheid nog steeds de trilogie van data, gegevens, informatie. Daarbij definieer ik data als atomaire (niet "zinvol" deelbare) eenheden (dat kunnen cijfers en letters zijn, maar ook bits dat een visueel of audio fragment respresenteert zijn). Gegevens zijn voor mij niets anders dan logisch gegroepeerde data elementen, bijvoorbeeld NAW gegevens, polisgegevens of journaalposten (in een boekhouding). Informatie wordt het bij pas als het direct (of indirect) gebruikt kan worden en er vaak actie ondernomen kan worden, dan moet je denken aan de belastingaanslag, factuur, of je reisbescheiden voor je eerstvolgende trip. Ik ga er gemakshalve vanuit dat een ieder weet hoe deze tegenwoordig in de meeste organisaties worden opgeslagen in databases en ontsloten worden middels applicaties.Deze "oude stijl" data management schaar ik dan onder gestructureerde data. Dat komt omdat zowel de input en output van de organisatie verwerkende instanties en toeleveranciers of consumenten aan deze bedrijven/instellingen een van te voren te verwachten ("min of meer" resultaat af hebben gesproken.

 

Nu is er inmiddels een heel horde nieuwe data in de meest ongestructureerde constelaties ontstaan, niet alleen in de groepering van data in gegevens, maar ook een nieuwe dimensie, en dat is de factor tijd. Daar waar het duidelijk is wat de houdbaarheid is van een belastingaanslag, factuur en reisbescheiden, is dat bij bijvoorbeeld Social Media berichten helemaal niet het geval.  Er ontstaan temporale relaties. Dat maakt het gelijk een stuk lastiger. Vaak zijn heel veel berichten (dus veel data) zonder duidelijkheid van de "waarheid" (correctheid en compleetheid) in korte tijd beschikbaar, waar iets uit te destileren valt. Bijvoorbeeld een imagoprobleem. een operationeel probleem, of een ramp.

Maar ook de enorme hoeveelheid data die bijvoorbeeld in de olieindustrie, medische wereld en andere takken van sport, eisen dat er anders naar de data gekeken wordt ("Big Data"). Ik denk dat we op een punt in de tijd aanbeland zijn, dat de verbinding tussen de gestructureerde data en ongestructureerde data heel interessant kan zijn voor bedrijven en organisaties. Door analyses toe te passen op de ongestructureerde data kan een trend worden afgeleid, waarvan het resultaat direct in de gestructureerde data kan worden opgenomen. Denk bijvoorbeeld aan klachten over een operationeel probleem, na korte analyse, kan er een high level call worden aangemaakt in het trouble ticket systeem van de organisatie. Maar ook anders, er kan ook data nodig zijn (pull) uit de wereld in de gestructureerde datawereld. Denk aan het uitzetten van een marketingcampagne, waarbij social media wordt gebruikt. Narrowcasting, etc... zijn voorbeelden van zo'n actie. Het resultaat zou kunnen leiden tot productvernieuwing, innovatie, etc.... , maar in ieder geval iets voor de wereld van de gestructureerde data.

 

De vraag blijft nog steeds hoe dit allemaal te doen, want wat ik tot nu toe alleen gehoord heb (nee niet eens gezien of mee gespeelt) zijn hele specifieke point solutions, die zeer custom made waren en minimaal 3 x een dr titel verlangde om het te begrijpen.

 

Atilla,

Ja, graag mee eens, met die zich zo nadrukkelijk manifesterende “dimensie, en dat is de factor tijd.” Die dimensie ervaar ik, trouwens, niet als nieuw; de factor tijd speelde altijd al. Wel is het zo dat we de factor tijd nu ook expliciet haar (altijd al) rechtmatige plaats moeten (terug)geven. Daar waar we de factor tijd veelal maar wat wegmoffelden in achteraf-(log)-files etc., zullen we die nu expliciet naar voren moeten halen. Dat betekent – en nu schiet ik even door – dat we voor vrijwel elk attribuut de factor tijd moeten introduceren. Wanneer ontstaan? Wanneer registratie? Wanneer valide? Wanneer invalide? Wanneer gebruikt?
Als we, in principe, voor elk attribuut (als representatie van (een deel-)iets in de werkelijkheid) de waarde-ontwikkeling in Tijd en Ruimte afzonderlijk kennen… kunnen vanuit die Tijd/Ruimte-opspanning… eindeloos combineren. Dàt geeft Mogelijkheden!
Vraag is dan wel wat, zo verder redenerend, als zinvolle ordening van attributen(t) gaat gelden. Het zou maar zo kunnen zijn dat onze hedendaagse attributen, aaneengeknoopt tot netzo hedendaagse records, een nogal afwijkende waarde-ontwikkeling mee-maken. Het zou ook maar zo kunnen zijn dat oude en vertrouwde groeperingen (als Contract of NAW of …) ronduit raar worden…. Dat we een nieuwe en duurzamere ordening van data op het spoor komen. Een ordening die maakt dat we onze kijk op wat Data Management eigenlijk is maar beter bijstellen.

Ja, klopt, “[d]e vraag blijft nog steeds hoe dit allemaal te doen”.

Vraag je dat als de timmerman die met z’n gereedschapskist op de steiger staat? Tja, dat zit er niet veel anders op dan je oude ‘kunstje’ maar weer op de oude manier te gaan doen. Oude en vertrouwde bouwmaterialen met dito gereedschap leiden naar mijn idee vandaag de dag niet meer tot iets Werkelijk Nieuws waarmee we een heuse sprong vooruit komen.

Vraag je dat als de timmerman uit de situatie van hiervoor die zich, dit alles overwegende, van de steiger verwijderde en zich bij de opzichter vervoegde om aan te geven dat ‘we’ er zo niet langer uitkomen en dat er andere potjes op het vuur moeten worden gezet?

Vraag je dat als architect die bezoek heeft gehad van de opzichter uit voorgaande situatie? De opzichter die je uit kwam leggen dat de huidige verhouding bouwmateriaal en gereedschap niet langer toereikend is om nog langer tot duurzame, waardevolle enzovoort constructies te komen?

Naar mijn idee is vooral die laatste verhouding tot de (data management) problematiek nu broodnodig. De ontwerper is, nog steeds naar mijn idee, noodzakelijk omdat onze fundamenten aan herziening toe zijn. De manier waarop we tegen data aankijken, erover denken is aan herziening toe. Dat is wat ik je in mijn vorige reactie probeerde aan te reiken. Het draait uiteindelijk, aan de ene kant van het spectrum, om informatie van trefzekere menselijke betekenis... tot - helemaal aan de andere kant van het spectrum: welke ordening van computer-data pas dáár het beste bij? En dat is, lijkt mij, werk voor de ontwerper/architect; opzichter en timmerman weten zich er nu eenmaal geen raad mee.


Atilla Vigh zei:

[...] Nu is er inmiddels een heel horde nieuwe data in de meest ongestructureerde constelaties ontstaan, niet alleen in de groepering van data in gegevens, maar ook een nieuwe dimensie, en dat is de factor tijd.

[...] De vraag blijft nog steeds hoe dit allemaal te doen, want wat ik tot nu toe alleen gehoord heb (nee niet eens gezien of mee gespeelt) zijn hele specifieke point solutions, die zeer custom made waren en minimaal 3 x een dr titel verlangde om het te begrijpen.

De voorgaande (lange) posts zijn voor mij niet allemaal even gemakkelijk te volgen. Ik heb het gevoel dat de discussie van de hak op de tak springt, en ik zie het hele werkveld van informatie architectuur voorbijkomen. Wat de vraag van Danny interessant maakt is m.i. dat de trend van procesdenken naar gegevensdenken (of beter: meer multidisciplinair) al een tijdje aan het inzetten is. Een goed topic voor de komende jaren dus.

Voor mij is de kern van de zaak niet alleen de inhoudelijke kant van IA/MDM/... Ik wil ook geen alles omvattend verhaal hebben. Gewoon kleine stapjes zetten. Think Big Act Small. Bijvoorbeeld: Stel, je hebt je gegevensbeleid vastgesteld, je weet welke principes, modellen, repository, etc. je hebben wilt, en ook de business case is positief. Wat is dan een haalbaar pad? Wat zijn de eerste stappen? Wie is aan zet? Dit zou wat mij betreft vragen voor de Open Space kunnen zijn.

Ik heb zojuist een opdracht uitgevoerd waarbij deze vragen op tafel lagen. We hebben een antwoord geformuleerd, maar in hoeverre het geimplementeerd gaat worden... Ongetwijfeld een kwestie van lange adem. Vandaar dat ik zei: "De analyse is eenvoudig, de implementatie niet".

Serge

Serge,

Mijn vorige bijdrage mondde uit in, inderdaad, een soort "werkveld"-beschrijving: 'Het draait uiteindelijk, aan de ene kant van het spectrum, om informatie van trefzekere menselijke betekenis... tot - helemaal aan de andere kant van het spectrum: welke ordening van computer-data pas dáár het beste bij?' Een onderdeel van dat werkveld is data management (DM). Waar heeft DM zich op te richten? Andersom: vanuit welk vertrekpunt dient DM ingericht te worden opdat het doel kan treffen?

Mijn antwoord: op 'informatie van trefzekere menselijke betekenis'. Betekenisvolle Informatie, mee eens, is waar het om draait. Het draait, inderdaad, niet om processen of architectuur of DM of .... En dat is Interessant. En, dat ook: Nieuw. Vandaar dat een aantal posts wat lang(er) uitvalt.

Mee eens, in de daadwerkelijke constructie-praktijk van elke dag (de timmerman die met z’n gereedschapskist op de steiger) moet je kleine stapjes zetten. Anders struikel je maar zo. Maar die stapjes kun je alleen maar trefzeker, zinvol enzovoort zetten op een concreet en coherent Pad in een ordelijk in kaart gebracht Gebied.

Als ik jou goed begrijp is het Gebied geen issue. Ook het grootste deel van het Pad is helder. Voor eventuele problemen vervoeg je je bij de opzichter.

Mijn idee is dat het Gebied op de schop moet. Opnieuw uitvinden wat dat is, 'informatie van trefzekere menselijke betekenis' en zo door naar de consequenties ervan voor ordening van die informatie/data, eindigend bij de succesvolle(re) inrichting van DM. Inderdaad: Think Big! Dat geeft dan weer zicht op Paden en de kleine stapjes (Act Small) die je er weer trefzeker op zet. De verschuiving " van procesdenken naar gegevensdenken" is, inderdaad, Nieuw.

Bert,

Poging tot antwoord op je vragen:

- Wat doet er pijn nu die data-strategie er niet is?

Algemeen: Geen data-strategie betekent dat er door business management niet (voldoende samenhangend) is nagedacht over: 

  • Betekenis / definitie / relaties en samenhang (wellicht taxonomie en ontologie);
  • Beveiliging / autorisatie (manier en geautoriseerde rollen/gebruikers)
  • Gebruik (door wie en waarom) en wijze van gebruik
  • Kwaliteitsnormen en eisen
  • Invloed factoren van kwaliteit
van data en informatie. 
Daardoor voldoet de data en de informatie niet aan het door de business-gebruiker benodigde "kwaliteit niveau", althans dat is de perceptie. Gevolg daarvan is dat mensen centrale informatievoorziening links laten liggen en hun eigen informatie gaan maken. Ze zijn daar vaak heel succesvol mee, voor hun persoonlijke- of team doelen. Dit veroorzaakt de "Excel Hell" en de wildgroei aan spreadsheet en database applicatietjes.
Specifiek: 
Voor specifieke business doelen betekent het ontbreken van een data strategie in de praktijk meestal dat gegevens gebruikt worden voor doelen waar ze origineel niet voor bedoeld zijn. Dat kan soms toch volstaan, maar het moet de gebruikers van de gegevens wel duidelijk zijn dat ze in zo'n geval te maken hebben met afgeleide gegevens en daar een aangepaste kwaliteitsverwachting bij moeten hebben.
- Welke aspecten zouden aan de orde moeten komen in de data-strategie?
Zie voor een minimale set de opsomming hierboven.

- Zijn er voorbeelden van een ontwikkelde data-strategie?
Ik kan je uit de eerste hand helaas geen case geven wat als goed voorbeeld zou kunnen dienen. 

- Welke principes en richtlijnen volgen hieruit voor de inrichting van de informatievoorzieningen?
De architectuurkant van de zaak, terechte vraag. Ik zou in eerste instantie niet alleen naar informatievoorzieningen kijken, als dat niet ook betekent dat je kijkt naar aansluiting van informatie-architectuur op de business architectuur. Het zou een uit business architectuur voortkomende richtlijn kunnen zijn dat de dingen rond data die ik hierboven opnoem geregeld zijn in een programma of project.

Een voorwaarde voor die informatievoorziening is dus het regelen van de organisatiestructuren die nodig zijn om gegevens altijd goed te kunnen gebruiken in een organisatie. Daar vallen onder: 

  • Aanstellen van een verantwoordelijke binnen de directie (sponsor) en inrichten Data Governance board die overzicht heeft, data richtlijnen kan opstellen, risico's kunnen managen en de organisatiegegevens, als bedrijfsactief, in de organisatie positioneert.
  • De data management groep waaronder de data stewardship functie, die de dagelijkse beheertaken uitvoeren. De datasteward rol is bekend met bedrijfsprocessen, is gedelegeerd eigenaar van de gegevens en past gegevens integriteitsregels toe. 
  • De overige data management rollen die zorgen voor requirements, architectuur, kwaliteit, beveiliging en rechten en niet te vergeten metadata.
Voor mij zou de VOS avond geslaagd zijn wanneer data (dus ook BI)  professionals kennis zouden nemen van de standpunten van "traditionele" IT architectuur en vice versa. Ik kan er zelf helaas niet bij zijn.

Bert Kroek zei:

Hoi Frank, I seccond that.

Om het concreet genoeg te maken voor de VOS komt de volgende vragen bij mij naar voren:

- Wat doet er pijn nu die data-strategie er niet is?

- Welke aspecten zouden aan de orde moeten komen in de data-strategie?

- Zijn er voorbeelden van een ontwikkelde data-strategie?

- Welke principes en richtlijnen volgen hieruit voor de inrichting van de informatievoorzieningen?

 


Frank Harland zei:

De regel "Iedere business-strategie heeft een data-strategie" zou wat mij betreft altijd op moeten gaan. 

Het wordt misschien wat makkelijker duidelijk te maken wanneer we in ons achterhoofd houden dat, afhankelijk van de branche, 30-80% van de waarde van organisaties in de data zit.

Ik verwijs voor geïnteresseerden ook graag naar dama.org, de site van de Data Management Association, een groep data professionals die standaarden opzet voor gegevensmanagement en -governance. 

Jan, ik wil uit deze reatie het thema "ownership conflict" concretiseren.

Een groot aantal organisaties zitten midden in de omslag van productownership naar proces ownership. De holy graal van generieke processen. Dit wordt m.i. voor een groot gedeelte gevoed door oplossingen van de belangrijkste technologie leveranciers.

In de geduide organisaties is men op zoek naar proceseigenaren, en komt regelmatig tot de conclusie dat die theoretisch een CxO rol is. Je zult vast de dappere gestrande pogingen herkennen om de organisatie op te delen in logische domeinen.

De duivelsdriehoek die ontstaat in deze discussies is er een van Kennis - Proces - Data, drie van elkaar afhankelijke gegevensdimenties. Op ieder van deze drie assen is er sprake van een ownership dimentie. Voor mij is het ownership vacuum een van de grootste aanleidingen voor kwaliteits isssues en daarmee zoals Frank terecht aangeeft  het ontstaan van prive oplossingen en duplicaties.

Bottomline is mijn vraag: Hoe faciliteren we een organisatie in het verantwoordelijkheid nemen (lees beheren) van haar gegevens. Ik denk dat we ultiem als architecten de sleutels in de handen hebben voor de oplossing.

Welke rollen en welke principes zijn daarbij te onderkennen? 


 
Jan van Til zei:

De verschuiving " van procesdenken naar gegevensdenken" is, inderdaad, Nieuw.

Bedankt voor deze reactie Frank. Ik denk dat dit heel wat aanknopingspunten biedt om te concretiseren.

We gaan in ieder geval zorgen dat de inzichten die we opdoen op de Open Space hier worden gedeeld. En door jouw bijdrage op dit forum draag je al bij tot het richten van de gesprekken.

Daarom de volgende vraag aan jou. Kun je het gat in begrip en misschien ook communicatie tussen data professionals en IT professionals met een voorbeeld duiden?

Over welke standpunten zouden we het dan volgens jou moeten hebben? Misschien dat deze vraag op zichzelf al de moeite waard om neer te leggen op de Open Space. Aanwezigheid van BI Architecten is dus gewenst. Niet om direct kennis te delen, maar om te ervaren waar het knelt. Dat inzicht voegt op zich al waarde toe.

 Frank Harland zei:

Voor mij zou de VOS avond geslaagd zijn wanneer data (dus ook BI)  professionals kennis zouden nemen van de standpunten van "traditionele" IT architectuur en vice versa. Ik kan er zelf helaas niet bij zijn.

 

Allen,

Ik zie in de discussie veel interessante standpunten en ideeen, maar net als Serge merk ik dat ik soms behoefte krijg aan kleinere, concretere voorbeelden. Ik merk met name aan de input van Jan dat hij veel heeft nagedacht over het onderwerp en er veel kennis over heeft - ik krijg mijn vinger helaas niet achter idee hoe we dan precies "Think Big" moet uitvoeren. Ik kan meegaan in het idee dat bestaanden methoden en technieken niet tot (voldoende) resultaat hebben geleid in de afgelopen jaren, maar het wordt mij niet duidelijk wat er voor in de plaats moet komen. Wat kunnen we 14 maart proberen? Welke experimenten kunnen we uitvoeren om misschien een glimp van een oplossing zichtbaar te maken?

Een ander punt dat ik heb opgemerkt is dat veel van ons het eens zijn met de stelling dat het geen technisch probleem is. Ik ook. Ik heb echter daarbij ook het gevoel dat we daarmee niet allemaal precies hetzelfde bedoelen. Voor mij betekent het inzicht dat we maar in beperkte mate met een technisch probleem te maken hebben, dat ik er ernstig aan twijfel of dit een probleem is dat opgelost (of zelfs maar een stap vooruit geholpen kan worden) door er "alleen maar" over na te denken. En daarin zit onze valkuil als architecten: wij zijn goed in denken, wij zijn goed in analyses en discussies. De keerzijde van de medaille is dat we vaak een stuk minder bedreven zijn in "zomaar" wat uitproberen, "gewoon maar iets doen en kijken wat er van komt". En ik denk juist dat we dit laatste nodig hebben om als het ware aan experimentele data te komen op basis waarvan we nieuwe ideeen kunnen ontwikkelen (als alternatief voor oude ideeen die blijkbaar niet werken).

Er is als gezegd dat we naast architecten ook behoefte hebben aan BI specialisten. Op basis van het bovenstaande denk ik dat we ook behoefte hebben aan niet-architecten en niet-IT-ers. Aan doeners in plaats van denkers om echt multidisciplinair (Danny!) aan de slag te gaan. Bert, jij gaf aan dat we als architecten ultiem de sleutels in handen hebben voor een oplossing - ik twijfel daar sterk aan, zoals je merkt.

Conclusie (voor dit stukje tekst althans): ik ben ervan overtuigd dat we als architecten elk datadomein kunnen analyseren en modelleren en dat we ook alle rollen en processen rondom databeheer voor elke willekeurige organisatie of samenwerkingsverband van organisaties uitstekend in kaart kunnen brengen. Dit is ons dagelijkse werk en dit is (denk ik) zelfs relatief eenvoudig. Het essentiele probleem komt daarna pas: de rest van de wereld is het niet met ons eens! Verschillende partijen voelen zich bijvoorbeeld eigenaar van dezelfde data (en kunnen/willen niet meegaan in een datamodel waarbij je de desbetreffende aspecten netjes uit hebt gemodelleerd), of partijen zijn niet bereid om netjes data te beheren die essentieel is voor een andere groep mensen maar zijn tegelijkertijd niet bereid om die verantwoordelijkheid dan aan een ander over te laten. Enzovoort...

Antwoorden op discussie

RSS

Sponsoren

Advertenties