Berichten in deze discussie

Permalink Antwoord van Serge Bouwens op 6 Februari 2012 op 22.34

Danny,

IMHO heb je hier wel de moeder van alle architectuurvraagstukken te pakken. Niet nieuw. Wel taai. Altijd leuk om over te discussieren. Deze open space zal ik maar eens volgen.

Groet,

Serge Bouwens

• ▶ Beantwoorden

Permalink Antwoord van Karin Middeljans op 7 Februari 2012 op 10.42

Goed plan. Dit is m.i. inderdaad bij veel organisaties een lastig vraagstuk.

Wellicht komt dit mede doordat gegevens en de vraagstukken die je noemt een stuk ongrijpbaarder zijn voor de meeste mensen dan applicaties. Dit speelt zeker een rol je een businesscase moet schrijven voor het doorvoeren van veranderingen aan de informatievoorziening.Het wordt dan makkelijker om 'iets' te doen aan applicaties dan om 'iets' te doen aan gegevens.

• ▶ Beantwoorden

Permalink Antwoord van Jan van Til op 7 Februari 2012 op 12.39

En... ga je dat probleem dan beetpakken vanuit het perspectief van de enkele organisatie... of... ga je het stelselmatig bekijken zodat je voor zowel de federatie/infrastructuur als voor de enkele organisatie (begin van) oplossingen genereert? In het laatste geval is er een sterke connectie met hetgeen Marlies al VOS-end aandroeg.

• ▶ Beantwoorden

Permalink Antwoord van Danny Greefhorst op 7 Februari 2012 op 15.43

Hoi Jan,

Ik had nog niet direct het ketenperspectief in gedachten. Was vooral ook benieuwd naar specifieke vragen waar anderen mee worstelen binnen het thema.

Mvgr,

Danny

• ▶ Beantwoorden

Permalink Antwoord van Ed van der Winden op 12 Februari 2012 op 18.43

Hallo Danny,

Eens dat dit in veel organisaties een belangrijk en taai probleem is.

Ik denk zelf dat een groot deel van de problematiek voortkomt uit het feit dat bij veel gegevens meerdere partijen een rol spelen. En bij de lastigste vraagstukken op dit gebied is de partij die de gegevens levert (en er dus werk aan heeft) niet de partij (of partijen) die de gegevens gebruiken (en er dus baat bij hebben).

De belangrijkste uitdagingen voor dit probleem liggen m.i. niet op het analytische vlak, maar eerder op het gebied van communicatie, samenwerking en management. Dit zijn al heel grote uitdagingen binnen de meeste organisaties, dus ik ben huiverig om dit probleem aan te pakken vanuit een federatief perspectief.

Ed van der Winden

• ▶ Beantwoorden

Permalink Antwoord van Jan van Til op 12 Februari 2012 op 22.36

Ed,

Ja, die uitdagingen zijn zelfs zo groot... dat ze op het vlak van de enkele organisatie niet oplosbaar zijn. Wie dáár dus blijft zoeken... omdat-ie zo huiverig is... vind dus... Niets. Juist door te stoppen met navelstaren... te stoppen met het rondrennen is alsmaar hetzelfde rondje - omdat het anders zo huiverig is - en door over het randje van die navel heen te kijken... zie je zomaar Oplossing. Stelselmatig, Systematisch, Federatief, ... Al navelstarend kom je eenvoudigweg niet op het idee...

Jan van Til
 
Ed van der Winden zei:

[...] Dit zijn al heel grote uitdagingen binnen de meeste organisaties, dus ik ben huiverig om dit probleem aan te pakken vanuit een federatief perspectief.

• ▶ Beantwoorden

Permalink Antwoord van Serge Bouwens op 13 Februari 2012 op 8.53

Jan,

Het is natuurlijk zo dat gegevensuitwisseling tussen organisaties belangrijker is geworden, en dat het grip krijgen op de gegevens daarom meer aandacht krijgt. Door het probleem in de context te plaatsen van een e-overheid, ketenproblematiek, allianties, fusiepartners, etc. worden oplossingen als standaardisatie, open data e.d. onvermijdelijk. Toch loop je als organisatie recht in het mes als je niet ook iets doet aan het organiseren van je eigen databeleid. Dat is deels inhoud (metagegevens, principes, modellen), maar vooral ook organisatie en proces.

Vragen als: "waar kan ik <deze gegevens> vinden? mogen we deze gegevens gebruiken/leveren? onder welke voorwaarden? hoe lang moeten we ze bewaren? En wie gaat hier eigenlijk over?" zijn vaak niet te beantwoorden omdat het domweg niet geregeld is. Architectuur maakt dat zichtbaar, maar de stap naar het formuleren EN implementeren van databeleid blijkt een lastige te zijn. Verantwoordelijkheden worden dan expliciet, budgetkwesties (kosten hier, baten daar), wetgeving, de immer ontbrekende repository, eigenaarschap, en zo kan ik nog wel een tijdje doorgaan.

Het is een praktijkgegeven dat de afwezigheid van een geimplementeerd databeleid in organisaties leidt tot hoge onzichtbare kosten en dat projecten gemiddeld 10% duurder zijn dan nodig. Waarom doen we het dan niet? 1. het is lastig om oorzaak en gevolg bij elkaar te brengen. 2. kosten gaan voor de baat uit. 3. het is best ingewikkeld. 4. je raakt aan allerlei interne verantwoordelijkheden en bevoegdheden.

Welke boodschap wil ik nu overbrengen?

1. Context meenemen is een goed idee, levert perspectief en zo, maar in eigen huis is nog werk zat.

2. Architecten, informatiemanagers, beleidsadviseurs en dat soort volk moeten vooral proberen de beslissers te verleiden tot implementatie van het databeleid. De analyse is 'eenvoudig'; de implementatie niet.

Serge Bouwens

Jan van Til zei:

... Oplossing. Stelselmatig, Systematisch, Federatief, ...

• ▶ Beantwoorden

Permalink Antwoord van Jan van Til op 13 Februari 2012 op 12.40

Serge,

Laten we eens scherp onderscheid maken tussen Ontwerp en Constructie. Qua Constructie gaat het, uiteraard, niet om de 'hele wereld', maar primair om de eigen organisatie. Alleen... volgens welk Ontwerp? Hanteer je een Ontwerp-bereik dat gelijk is aan het Constructie-bereik (zo heeeeel er-rug traditioneel dus)... of... hanteer je voor Ontwerp een veel ruimer, een stelselmatig, federatief, netwerk, infrastructureel, ... bereik? In het laatste geval heeft dat ruimere Ontwerp-bereik al heel verduurzamend effect op de ontwikkeling van Constructies.

Want, inderdaad, het laatste wat je "als organisatie" wilt is "recht in het mes [lopen]". En ook, klopt al weer: "in eigen huis is nog werk zat". Maar dat moet natuurlijk geen smoes worden om maar rondjes te blijven rennen binnen oude en vertrouwde eigen navel. Klim uit die navel... aanschouw de ruimte... verwonder je... en ga stelselmatig aan de (ontwerp)slag. Tegen de tijd dat het op Constructie aankomt... kan opnieuw beschutting van navel worden gezocht.

Jan van Til

Serge Bouwens zei:

Toch loop je als organisatie recht in het mes als je niet ook iets doet aan het organiseren van je eigen databeleid.

Welke boodschap wil ik nu overbrengen?
Context meenemen is een goed idee, levert perspectief en zo, maar in eigen huis is nog werk zat.

Jan van Til zei:

... Oplossing. Stelselmatig, Systematisch, Federatief, ...

• ▶ Beantwoorden

Permalink Antwoord van Ed van der Winden op 14 Februari 2012 op 19.29

Hallo Jan,

Ik herken je insteek dat het zinvol kan zijn om een probleem ruimer te bekijken. Bij wiskundige problemen is het bijvoorbeeld soms eenvoudiger om een algemeen probleem op te lossen dan een specifiek probleem.

Het oprekken van de context waarin je gegevensbeheer bekijkt - van een enkele organisatie naar een federatief samenwerkingsverband - lijkt zich daar in mijn ogen minder voor te lenen. Ik heb het gevoel dat je in een federatieve context in het geval van gegevensbeheer niet zozeer kijkt naar een algemener probleem, maar in essentie naar hetzelfde probleem, maar dan wel groter en daardoor complexer. Meer partijen, meer verantwoordelijkheden, meer afspraken. Ik heb dan ook de neiging om me aan te sluiten bij Serge: de analyse is het probleem niet, wel de implementatie en ik begrijp niet hoe die eenvoudiger wordt in een ruimere context.

Tegelijkertijd is er (denk ik) een goede reden waarom jij wel denkt dat een ruimere kijk het probleem van gegevensbeheer vereenvoudigt. Kun je dit toelichten? Is er wellicht een specifieke ervaring waar je dit op baseert? Ik ben benieuwd.

Ed van der Winden

 Jan van Til zei:

Serge,

Laten we eens scherp onderscheid maken tussen Ontwerp en Constructie. Qua Constructie gaat het, uiteraard, niet om de 'hele wereld', maar primair om de eigen organisatie. Alleen... volgens welk Ontwerp? Hanteer je een Ontwerp-bereik dat gelijk is aan het Constructie-bereik (zo heeeeel er-rug traditioneel dus)... of... hanteer je voor Ontwerp een veel ruimer, een stelselmatig, federatief, netwerk, infrastructureel, ... bereik? In het laatste geval heeft dat ruimere Ontwerp-bereik al heel verduurzamend effect op de ontwikkeling van Constructies.

Want, inderdaad, het laatste wat je "als organisatie" wilt is "recht in het mes [lopen]". En ook, klopt al weer: "in eigen huis is nog werk zat". Maar dat moet natuurlijk geen smoes worden om maar rondjes te blijven rennen binnen oude en vertrouwde eigen navel. Klim uit die navel... aanschouw de ruimte... verwonder je... en ga stelselmatig aan de (ontwerp)slag. Tegen de tijd dat het op Constructie aankomt... kan opnieuw beschutting van navel worden gezocht.

Jan van Til

Serge Bouwens zei:

Toch loop je als organisatie recht in het mes als je niet ook iets doet aan het organiseren van je eigen databeleid.

Welke boodschap wil ik nu overbrengen?
Context meenemen is een goed idee, levert perspectief en zo, maar in eigen huis is nog werk zat.

Jan van Til zei:

... Oplossing. Stelselmatig, Systematisch, Federatief, ...

• ▶ Beantwoorden

Permalink Antwoord van Jan van Til op 14 Februari 2012 op 20.03

Ed,

Het informatische leven in full blown informatiemaatschappij speelt zich vandaag de dag - of je het nu wilt of niet... leuk vindt of niet... - af in één grote flipperkast. De ballen vliegen je vanuit varierende en ook heel gevarieerde hoeken en gaten op 'lichtsnelheid' om de oren. Zie maar dat je de ballen in het spel houdt. Wie niet uitkijkt is out of business. En er is geen Game Over.

Dat betekent dus dat je informatisch gezien en ontwerpendeweg gezien moet kijken op flipperkastniveau. Hoe ingewikkeld dat misschien ook is/lijkt. Het is nu eenmaal zo ingewikkeld als het is. Wie dat weigert en zich domweg/willens en wetens beperkt tot zijn eigen vertrouwde hoekje (waar nog zoveel werk te doen is)... tja, die raakt vandaag de dag meer en meer aan de wilde spinnen overgeleverd en weet in steeds mindere mate wat um te wachten staat, wat um alsmaar overkomt, laat staan uit welke onverwachte hoek de ene knock out knal kwam.

Al extrapolerend vanuit het eigen hoekje krijg je eenvoudigweg geen idee van hedendaagse flipperkast. Denk aan de grot van Plato. Of aan het boekje Flatland. Ook goed. Pas wanneer je bereid bent de eigen organisatie als autonoom vertrekpunt voor het informatisch handelen los te laten... en bereid raakt om op flipperkastniveau te gaan kijken omdat op dat beschouwingsniveau pas werkelijk houtsnijdend inzicht kan doorbreken inzake het eigen kleine hoekje... pas dan zie je echt goed hoe je dat kleine eigen hoekje het beste inricht (Constructie). Andersom zie ik geen mogelijkheden.

Het is dus niet zo dat ik de context oprek... Nee, ik neem de reele context ter hand - de flipperkast - en ga er mee aan de slag. Ontwerpend in de breedte. Construerend voor het eigen hoekje.

Jan van Til

 
Ed van der Winden zei:

Hallo Jan,

[...] Het oprekken van de context waarin je gegevensbeheer bekijkt - van een enkele organisatie naar een federatief samenwerkingsverband - lijkt zich daar in mijn ogen minder voor te lenen. [...]

Ed van der Winden

 Jan van Til zei:

Serge,

Laten we eens scherp onderscheid maken tussen Ontwerp en Constructie. [...]. Tegen de tijd dat het op Constructie aankomt... kan opnieuw beschutting van navel worden gezocht.

Jan van Til

Serge Bouwens zei:

Toch loop je als organisatie recht in het mes als je niet ook iets doet aan het organiseren van je eigen databeleid.

Welke boodschap wil ik nu overbrengen?
Context meenemen is een goed idee, levert perspectief en zo, maar in eigen huis is nog werk zat.

Jan van Til zei:

... Oplossing. Stelselmatig, Systematisch, Federatief, ...

• ▶ Beantwoorden

Permalink Antwoord van Bert Kroek op 21 Februari 2012 op 14.49

Ed en Jan, ik kan me helemaal vinden in het idee dat we ons eerst focussen op ontwerp. Maar de (on)mogelijke constructie stelt hier zeker kaders (performance).

De theorie zowel als de ervaring leert dat er een mooi principe bestaat voor het oplossen van dergelijke problemen: De oplossingsrichting ligt minimaal een logisch niveau (van verandering) hoger dan het niveau waarop het probleem zich manifesteerd.

Wordt de masterdata discussie (zoeken naar DE oplossing) misschien toch een metadata discussie?

Volgens mij zijn we op zoek naar een federatief model waarbij gegevens in de basis worden gebruikt in de context van de beherende organisatie. Daar zullen we het moeten hebben over concepten als locale caches. Als afnemer van masterdata zul je je eigen contexten creeren en moeten administreren. Volgens mij is het op zich niet al te moeilijk om goede ontwerpen te maken rondom deze problematiek. Seperation of concern, functionele decompositie en decomposite per eigenaar/classificatie zijn aspecten waar naar zal moeten worden gekeken.

Het uitwerken vereist wel erg veel discipline, en bottomline zul je heel wat redundantie krijgen vanwege performance zaken als je de bedrijfsprocessen batchgewijs hebt geimplementeerd. Daar breekt het in de praktijk. Belangrijk is om een set aan requirements te delen (vanuit ervaring met implementaties) om te kunnen komen tot succesvolle inrichting.

Verder is het vrij delen van modelinformatie (onderdeel van open data?) tussen organisaties essentieel. Laten we eens stoppen met het voor iedere organisatie weer opnieuw uitvinden van het wiel.

 

 

 

• ▶ Beantwoorden

Permalink Antwoord van Marlies van Steenbergen op 21 Februari 2012 op 17.27

Gefeliciteerd Danny,

Jouw thema is geselecteerd als onderwerp voor de volgende VOS bijeenkomst op 14 maart!

Wij gaan je helpen om hier een mooie en verrijkende sessie van te maken.

 

VOS werkgroep

• ▶ Beantwoorden

▶ Antwoorden op discussie

• ‹ Vorige
• 1
• 2
• 3
• 4
• Volgende ›
• Pagina