In deze (nogal lange) blog wil ik samenvatten welke inzichten de Via Open Space rondom Master Data Management mij heeft gegeven.

Naast de imponerende omgeving (haaien en mega-sardines) was het voor mij ook de perfecte setting waar allerlei verschillende aspecten van Master Data Management aan de orde kwamen. In de aanwezige personen was heel wat relevante ervaring verzameld. Juist de breedte van de onderwerpen maakte het mogelijk om tot nieuwe inzichten te komen.

Misschien dat deze blog een beetje taai is, veel tekst en weinig platen, daarom ga ik de komende tijd  proberen de context patronen met platen te illustreren. Als iemand al wat heeft op dat vlak, of wil meewerken aan het ontwikkelen daarvan, houd ik me aanbevolen!

Het vraagstuk, waarom is MDM nu zo lastig te realiseren, kan op zich zelf zonder twijfel complex worden genoemd. Dit geldt voor zowel het vraagstuk als de oplossing: beide hebben veel verschillende gezichten. Ik pak er in deze blog een paar uit.

Complexiteit wordt onderschat

De werkelijkheid van gegevensbeheer is complexer dan de meeste oplossingen aankunnen. In de eerste plaats is er een oerwoud van standaarden. Deze zijn vaak verankerd in wetgeving. Neem het systeem van basis registraties: geborgd in 13 verschillende wetten met ieder met een eigen definitie. Een ander voorbeeld is een stelsel als de AWBZ met haar AZR standaard.

Ik zal op een paar van de complicerende aspecten ingaan, maar op dit punt is het belangrijk te constateren dat het wezen van deze complexiteit moet worden afgeschermd voor de partijen aan de kant van gegevenslevering en gegevensafname. Maak het een apart concern en isoleer deze complexiteit waar mogelijk.

We komen wat mij betreft dan op het gebied van de zogenaamde non-functional requirements en zullen daar specifieke flexibiliteits-requirements moeten toevoegen. Het gaat dan om non-functionals die specifiek van toepassing zijn op de informatielaag.

Het is een Architectuurvraagstuk

Voor mij is de problematiek primair een modelleringsvraagstuk. Het is er een dat valt in de categorie verdwijnpunten oftewel de gereedschappen en technieken van de architecten en ontwerpers. Daarom is het ook essentieel om binnen de eigen architectenplatformen hiermee aan de slag te gaan. Deze dimensie naar buiten communiceren draagt bij aan de negatieve reputatie die de architectuurfunctie vaak heeft: we introduceren complexiteit en daarmee risico’s, dit zet de relatie met de projectleider zo heerlijk onder druk.

Het Golden Master patroon wijst in de verkeerde richting

Als het om MDM gaat is er een bekend patroon: De Golden Master. Het is belangrijk te weten wanneer je dit patroon toe kan passen. Het patroon simplificeert de werkelijkheid en het belangrijkste kenmerk daarbij is dat het informatie verliest. Het verliest de context van de data. Het creëert ook een nieuwe (laag van) verantwoordelijkheid die in de meeste organisaties niet te borgen is. Het verlies van context maakt de nieuwe gegevensverzamelingen onbruikbaar voor de meeste toepassingen; namelijk die toepassingen waar verantwoording over moet worden afgelegd. Alleen in specifieke situaties kan deze simplificatie nut hebben. Dan denk ik aan specifieke tegen CRM aanliggende doelen (klantsegmentatie), daar waar gewerkt wordt met een rollup.

Ownership is contextgebonden

Verdwijnpunt Ownership heeft alles te maken met het behoud van context. Met name als het gaat om gegevensuitwisseling is het belangrijk vast te houden wie verantwoordelijk is voor de kwaliteit van welke data. Deze problematiek speelt op twee niveaus: externe/keten-integratie en interne integratie.

Op beleidsniveau is het zeker te adviseren dat Ownerschip wordt gecentraliseerd / georganiseerd. Problemen ontstaan echter wanneer dit als uitgangspunt wordt genomen voor de inrichting van de systemen van vandaag. Het is een stip aan een heel verre horizon.

Eisen aan doelgebruik (vanuit de privacy wetgeving) kunnen alleen maar worden ingevuld als context van de gegevenslevering / creatie wordt vastgelegd en beheerd.

Standaardisatie biedt niet meer dan structuur

Op de Open Space werd door verschillende deelnemers standaardisatie genoemd als oplossing van het MDM probleem. Standaardiseren op beschrijving (SBVR, Nederlandse Taxonomie, XBRL) helpt wel met het beheersbaar krijgen van de filipperkast maar is de oplossing niet. In de eerste plaats is het een kwestie van een heel lange adem om alle modellen en wetten te harmoniseren. We zullen een heel lange tijd nog met parallelle modellen te maken hebben, laten we dat ook gewoon als uitgangspunt nemen. We zullen flexibiliteitsprincipes moeten definiëren.

Neem deze ook mee in de meta-modellering. Dit betekent onder andere dat we synoniemen mee zullen moeten modelleren en accepteren dat er meerdere contexten van dezelfde gegevensverzameling kunnen zijn, met ieder eigen belanghebbenden. Services en beheer moeten daar op worden ingericht.

Modellering is complex

Er wordt op verschillende punten al heel wat gedaan om aan flexibiliteits-requirements te voldoen. Ik zie verschillende patronen die in de goede richting bewegen. Bijvoorbeeld het Partij concept (specifieke contexten van het generieke concept persoon) in de meeste volwassen gegevensmodellen en Data Vault Modeling (hubs en satellites) als een model voor een adaptable Operational Data Store. Maar het is niet voldoende.

Een veel gehoorde klacht is dat informatiesystemen die dergelijke concepten gebruiken onleesbare databasemodellen hebben. Dit wordt met de toevoeging van het context concept alleen maar complexer. Dit is vanuit mijn rol als architect goed nieuws: integratie op datalaag en rapportage door zelfgemaakte queries waren vanuit applicatie-architectuur-oogpunt al uit den boze (niet loosely-coupled), het wordt op deze manier door de complexiteit van de modellen zelf al onuitvoerbaar.

Dit is in mijn optiek ook een van de belangrijkste redenen waarom er zoveel projecten mislukken, zeker SOA projecten: De werkelijkheid is complexer dan gemodelleerd. We missen een essentiële dimensie van gegevensvastlegging; We laten iedere keer contexten van gegevensverzamelingen wegvallen.

Kom ik als laatste toch even terug op het punt van verantwoordelijkheid van de architect.

Rol van Informatie Architect

Ik ben blij dat mijn mentor Steven van ’t Veld aanwezig was, het was erg inspirerend om zijn vertrouwde geluid weer te horen: De kennis en kunde van met name Informatie Architecten is de sleutel tot het ontwikkelen van de architectuurdiscipline op het vlak van deze problematiek. Ik hoop dat dit in het bovenstaande ook duidelijk is geworden. Ik kan me goed voorstellen dat veel van de lezers die een architectuur rol vervullen zullen zeggen dat deze vraagstukken buiten hun invloedssfeer liggen, zeker wanneer zij geen informatie architect zijn. De echte Informatie Architect is vaak niet te vinden. Mijn stelling is dat iedereen in het architectuur team medeverantwoordelijk is voor het functioneren van de integrale architectuur functie in de organisatie of in het project. Alleen architecten zelf kunnen beoordelen wat er nodig is voor het succesvol leveren van de architectuurdiensten, hoe de gereedschapskist en het gebruik daarvan in de verschillende architectuurrollen er uit moet zien. Ik steun Steven van harte in zijn missie om op Europees niveau te komen tot definities en standaarden rondom de discipline van Informatie Architectuur.

Weergaven: 599

Reactie van Jan van Til op 26 Maart 2012 op 10.40

Bert,

Een veelbelovende blog: “daarom ga ik de komende tijd proberen de context patronen met platen te illustreren.” Want inderdaad zonder context komt niets tot Betekenis. En snelle toekenning van de juiste betekenis wordt steeds belangrijker.

In mijn publicaties vormt context altijd een belangrijke rode draad. Voorbeelden hier op VNA:
In Uitzonderingen zat: neem alle relevante perspectieven (contexten) in ogenschouw.
In Gezocht: methode voor informatiemodellering volgens informatierelat...: modelleer de relevante contexten samen in één model
In Iets federatiefs gaan doen...: betekenis van informatie kan niet langer vanuit één partij (traditioneel: het eigen ‘verband’) worden gedicteerd; alle relevante verbanden moeten evenwichtig worden meegenomen.
In De Zin van Zijn gaan Zien: alle aparte, autonome ik-ken worden allemaal, elk vanuit het eigen perspectief/context, deelnemer aan informatieverkeer over informatie-infrastructuur.
In The Core of Information Oriented Architecture: Information is used by human beings for decision making. Making good decisions, requires you to avail yourself of the clear meaning of that information. And meaning of information simply depends on its context – as we readily know by now from social psychology. Other context? Other meaning! Other decision! Information is always and inextricably (sic!) connected to its context. Information never ever meaningfully exists an sich.
In Over Raakpunt Business en ICT: dat raakpunt moet een professioneel scharnierpunt worden via contextuele betekenis van informatie.
Ook op Emovere, Informatiekundig Bekeken en Information Roundabout kom je die rode draad steeds en stelselmatig tegen.

Wat betreft je oproep "[a]ls iemand al wat heeft op dat vlak, of wil meewerken aan het ontwikkelen daarvan, houd ik me aanbevolen", kan ik melden dat er – met gevoel voor understatement – al wel e.e.a. aan patronen/modellen is gepubliceerd.
In de bundel Interoperabel Nederland vind je Deel III, vanaf p204 al een aantal contextuele modellen danwel patronen, mede rondom persoon.
Op de site van Wisse zijn ook vele contextuele modellen/patronen beschikbaar: Modeling exercises with Metapattern.
Op Informatiekundig Bekeken staan: Kabellengte gesitueerd en Beveiligingsfietsenrek.
Op Information Roundabout werk ik zelf aan context-modellen/patronen. Daar staan momenteel twee patroontjes: Natural Persons en Person Numbers.

Reactie van Bert Kroek op 27 Maart 2012 op 23.40

Bedankt voor het huiswerk Jan ;)k zie wel wat herkenbaars als ik zo door de links blader. Ik zal op een later tijdstip wat due dilligence doen op deze bijdrage.

wat ik boeiend vind is dat je in het patroon Natural Persosn ervoor kiest om toch te starten met het uitgangspunt dat een persoon maar hooguit 1 keer bestaat. Dat zal conceptueel misschien zo zijn, maar in de werkelijkheid van de flipperkast zeker niet. Van meerdere contexten Zou je kunnen zeggen dat ze met een grote mate van waarschijnlijkheid dezelfde natuurlijke persoon zijn. Maar het model moet m.i. starten met het gegeven dat er meerdere representaties van die ene unieke persoon zijn. Neem bijvoorbeeld een afrikaans persoon die in Nederland leeft. Wij kunnen wel willen dat dit op 1 natuurlijk persoon wordt afgebeeld, maar er zijn minimaal twee representaties van twee landelijke overheden die deze persoon beschrijven. Een niveau creeren dat over het niveau van de losse beherende instanties heen gaat is moet voor mij heel erg los worden gerealiseerd, meer in de orde van synoniemen en mate van zekerheid dan een nieuw beheerde globale identiteit.

 

Reactie van Jan van Til op 28 Maart 2012 op 12.04

Bert,

Dank je wel voor de moeite die je nam de links door te ploegen en in het bijzonder ook te kijken naar het (kleine) systematische informatiemodel Natural Persons.

Ja, ik ben van mening dat een natuurlijk persoon in de werkelijkheid van alle dag precies één keer bestaat: “There is exactly one physical/biological you – flesh, blood, bones etc.” Niet alleen conceptueel; ook reëel – reëel, dus, in de werkelijkheid van de flipperkast.

En die ene Natural Person kan zich – heel reëel – in tijd en ruimte (lees ook: situationeel) op een veelheid aan manieren manifesteren (identificeren). Al die verdere manifestaties van Natural Person haken in het model aan op Person Identity. Een klein voorbeeld daarvan zie je in Person Numbers: Person Number hangt dus niet aan Natural Person, maar juist aan Person Identity. Op die manier kan één Natural Person dus – heel reëel – voorzien zijn van meerdere Person Numbers. Niet alleen over Sovereign States heen, maar ook per Sovereign State (NL: meerdere BSN’s). Met dit model kunnen we – expliciet! – alle manifestaties (legaal/gewenst of niet) via Person Identity relateren aan die ene Natural Person.

Jij stelt voor het “model [te laten] starten met het gegeven dat er meerdere representaties van die ene unieke persoon zijn”. Als je start bij representaties (Person Identity in het model)… hoe kom je dan uit bij die ene Natural Person die zich van die “meerdere representaties” bedient? Als je start in dat ene hoekje van de flipperkast… en de rest van de flipperkast negeert… hoe ga je dan om met die echte flipperkast? Want die echte flipperkast is er echt en laat zich ook steeds meer en nadrukkelijker horen.

Een Afrikaans Natural Person die in Nederland leeft… is een Afrikaans staatsburger… heeft in Nederland misschien wel de status vreemdeling. Stemrecht, …, enzovoort. Hoe dan ook… Hij/zij is en blijft één Natural Person en hij/zij manifesteert zich op een veelheid aan manieren (via Person Identity).

In een stelselmatig informatiemodel (model van de hele flipperkast) willen we juist dàt expliciet ‘vangen’ en samenhangend tot uitdrukking brengen: die ene X gerelateerd aan z’n veelheid aan manifestaties; Id(X). Klopt, dat is kwalitatief nieuw… daar zijn we niet aan gewend. We zijn niet gewend aan Stelselmatig Modelleren (hele flipperkast); we zijn gewend aan Specifiek Modelleren; het modelleren van ons eigen stekkie… dat ene hoekje van de flipperkast (waarbij we een soort van lange neus maken naar de rest van de flipperkast: ‘out of scope!’).

In wat uitgebreidere modellen (voorbeeld) – met meerdere informatieknooppunten dus, kun je goed zien hoe de knooppunten zich onderling verhouden. Neem bijv. knooppunt 5 in het gegeven voorbeeld: naar boven toe zie je de geëxpliciteerde context van dat knooppunt: de knooppunten 4, 2, 1, 3 en horizon. Ook zie je dat knooppunt 5 zelf onderdeel is van weer andere contexten: knooppunt 8 en ‘officieel identiteitsbewijs’ hebben knooppunt 5 etc. als context.

Dus, ja, ik ben het graag met je eens: Don’t loose context! Model IT!

Reactie van Bert Kroek op 28 Maart 2012 op 14.45

Als je start bij representaties (Person Identity in het model)… hoe kom je dan uit bij die ene Natural Person die zich van die “meerdere representaties” bedient? Als je start in dat ene hoekje van de flipperkast… en de rest van de flipperkast negeert… hoe ga je dan om met die echte flipperkast? Want die echte flipperkast is er echt en laat zich ook steeds meer en nadrukkelijker horen.

Dag Jan, ik herken de behoefte om singulair te beginnen. Ik denk dat je dan juist in een hoekje van de flipperkast rondloopt waar je gebonden bent aan wet en regelgeving ook werkt in geval van de beroemde happy flow: we communiceren met behulp van wettelijk bepaalde identificerende sleutels.

Prima stap om meerdere identiteiten te herkennen voor een natuurlijke persoon. Essentieel. Maar accepteer je ook dat een identiteit kan behoren bij meerdere personen (ik denk aan frauduleuze of foutieve identiteit)?  En wat doe je met het concept van aan zekerheid grenzende waarschijnlijkheid (of soms dus juist niet)?

Wie linkt en onlinkt de verschillende identiteiten? Wie is de eigenaar van dat abstracte object natuurlijk persoon?

Ik zoek even naar de afbakening van het begrip context. Semantiek. Zou het kunnen zijn dat we met het zelfde begrip iets heel anders bedoelen? Oftwel, zijn er meerdere type contexten?

Ik probeer context even te zien vanuit het verdwijnpunt Ownership. Context staat los van identiteit. Context staat voor mij bijna voor een instantie van 1 van de figuren uit het voorbeeld. Twee organisaties hebben minimaal twee verschillende contexten van de zelfde natuurlijke persoon.

Jouw vraag over hoe je dan begint wil ik alsvolgt beantwoorden: Begin altijd met de context die jezelf beheert (decompositie naar bedrijfsobjecten).  Daarnaast leg je een sleutelkastje aan met verwijzingen naar andere elders voorkomende (en hopenlijk beheerde) contexten (ook weer op bedrijfsobject niveau). In de verwijzing sla je informatie op over de mate van zekerheid, de eigenaar en de methode voor wijziging van het externe gegeven. Een standaard voor een dergelijk sleutelkastje zou geweldig zijn, dan kunnen we optioneel de inhoud meesturen met berichten die we versturen rondom een object. Volgens mij moeten we afscheid nemen van het hierarchisch (modern) denken en inrichten volgens een (postmodern) netwerk denken.

Reactie van Jan van Til op 28 Maart 2012 op 21.21

Bert,

Ik reageer op de, naar mijn idee, meest bepalende elementen in je bijdrage.

“Maar accepteer je ook dat een identiteit kan behoren bij meerdere personen (ik denk aan frauduleuze of foutieve identiteit)?”
Nee. In het model heet het geen Identity, maar Person Identity. Volgens welke Person Identity een Natural Person zich ook gedraagt… ik wil altijd die ene Natural Person kunnen aanwijzen die voor dat gedrag verantwoordelijk is. In geval een Natural Person bonafide handelt en malafide handelt en die beide soorten handelingen gescheiden probeert te houden middels twee BSN’s, wil ik via Natural Person altijd de link kunnen maken.

“Ik zoek even naar de afbakening van het begrip context.”
In het leven van alle dag stel je in geval van onduidelijkheid de vraag “Hoe bedoelt u?” Als je met de uitleg die volgt niet helemaal uit de voeten kunt, stel je die vraag op onderdelen nog eens. En evt. nog eens. Ieder antwoord is een contextuele aanvulling op hetgeen je al wist/begreep. Met alle aanvullingen samen kom je tot de (voldoende) duidelijke betekenis.
In Metapattern modellen ontleent elk informatieknooppunt zijn betekenis aan de contextuele knooppunten waaraan dat knooppunt ‘hangt’. Hoe meer informatie je nodig hebt om tot voldoende heldere betekenis te komen, hoe verder je omhoog ‘klimt’ in de informatie-ordening richting horizon. Waar dat eindigt? Dat eindigt in principe niet, maar wordt praktisch afgesloten door de horizon.

“Twee organisaties hebben minimaal twee verschillende contexten van de zelfde natuurlijke persoon.”
Die Natural Person kan zich op diverse manieren manifesteren in twee verschillende organisaties. Je zou kunnen zien: persoon@org1 en persoon@org2. Maar je zou ook fijnmaziger kunnen zien: persoon@project1@org1 en persoon@project2@org1. Enzovoort. Zoiets vanzelfsprekends wil je uiteraard netzo vanzelfsprekend in één stelselmatig model kunnen vangen.

“Jouw vraag over hoe je dan begint wil ik als volgt beantwoorden: Begin altijd met de context die jezelf beheert (decompositie naar bedrijfsobjecten).”
Oneens. Dat is wat mij betreft traditioneel denken; hoekje van de flipperkast denken. Om te beginnen zitten we in Ontwerp-mode; niet in Constructie-mode (dat komt later). We kijken (dus) naar de hele flipperkast (Stelselmatig, meerdere contexten in samenhang); niet (Specifiek) naar het eigen hoekje waarover je toevallig het beheer enzovoort hebt (en waarvoor we straks iets echts gaan bouwen). We zetten eerst een stelselmatig informatiemodel op (Natural Persons die via Person Identity tot heel gevarieerd en ook variërend gedrag komen). In Ontwerp-mode dus! Later kijken we wat dat voor de ontwikkelpaden van de onderscheiden de hoekjes van de flipperkast betekent.

Reactie van Bert Kroek op 28 Maart 2012 op 22.58

Bedankt voor je antwoord Jan.  Wat mij betreft zitten hier heel wat aanknopingspunten in om weer een stapje verder te komen. Laat ik het eerste punt er uit lichten:

In geval een Natural Person bonafide handelt en malafide handelt en die beide soorten handelingen gescheiden probeert te houden middels twee BSN’s, wil ik via Natural Person altijd de link kunnen maken.

De scenario´s waar ik op doel zijn malafiede: een Natuurlijk Persoon die zich bedient van de identiteit van een andere Natuurlijke Persoon.(fraude) en foutief: een Natuurlijk Persoon heeft een foutieve identieteit geassocieerd gekregen (dataquality issue), of mogelijk: Met een zekerheid van 95% is vast te stellen dat een Persoon Identiteit hoort bij een bepaalde Natuurlijke Persoon. In elk van deze situaties kun je stellen dat je met de kennis van de echte situatie (op later tijdstip) de relaties in het model corrigeert (vanaf welk moment jouw model weer klopt) maar mij gaat het er juist om dat je het misbruik juist moet vastleggen met behoud van (incorrecte) referentie. Het liefst ook met een verwijzing naar de beherende bron (mijn definitie van context).

Ik denk dat dat je te kort door de bocht gaat als je hier het onderscheid Ontwerp / Constructie introduceert. Ik wil juist niet over constructie praten maar over een ontwerp voor meerdere beheerde contexten van eenzelfde object. Dat is namelijk realiteit zonder dat het over constructie gaat. Dat is wat mij betreft juist de context die vergeten wordt bij het modelleren.

Als ik je goed begrijp is er in de Ontwerp-mode een uitgangspunt dat alle mogelijke aspecten van het informatiemodel in een uniek universeel model zijn te beschrijven. Niet alleen dat, vanuit deze Ontwerp-mode is het ook mogelijk om ieder uniek voorkomen uniek in een realisatie daarvan op te slaan. Het model staat geen datakwaliteits issues toe, alles moet eenduidig zijn gemodelleerd.en ik herken de mogelijkheden voor eenduidig ownership.

Vanuit die optiek snap ik dat je me in het hoekje van traditioneel denker plaatst. Ik probeer aandacht te vragen voor contexten in de werkelijkheid van vandaag en de komende 20 jaar. Alle huidige systemen zijn vanuit de Ontwerp-mode legacy systemen. En die systemen gaan niet weg, Die systemen hebben ook geen perfecte kwaliteit, of eenduidig ownership. Ik denk dat wij van mening verschillen over het antwoord op de vraag in hoeverre de Ontwerp-mode rekening moet houden met de beperkingen vanuit de constructies die we jarenlang hebben neergezet en nog neer zullen zetten.

Reactie van Jan van Til op 29 Maart 2012 op 10.35

Bert,

Ik weet niet hoe jij het beleeft, maar mijn indruk is nu toch stellig dat wij met onze reacties over en weer uit elkaars bocht vliegen. Omdat ik deze discussie belangrijk vind, vraag ik me oprecht af hoe we e.e.a. beter op rails krijgen. Als ik de bijdragen nog eens lees, krijg ik de indruk dat verwarring voor het belangrijkste deel voortkomt uit wat context nu eigenlijk is/zou moeten zijn.

Jouw insteek (titel van je blog): Don’t loose context! Model IT! Met die insteek ben ik het graag eens. Wij passen bar slecht op onze contextuele informatie, waardoor betekenis van informatie gemakkelijk gaat zweven. Contextuele informatie is cruciaal voor de betekenisgeving aan informatie. En juiste betekenisgeving aan informatie zet zonder vertraging (“Hoe bedoelt u?”) aan tot bedoeld gedrag.

Ronduit veelbelovend vind ik nog steeds je toezegging dat je “de komende tijd [gaat] proberen de context patronen met platen te illustreren.” Het lijkt mij het meest praktisch dat je concreet met voorbeelden gaat komen. Ik denk dat die voorbeelden ons zullen laten zien wat jij bedoelt met context.

In mijn vorige bijdragen heb ik, naar mijn idee, laten zien (op z’n Metapatterns) dat wat in het ene geval als informatie optreedt, in een ander tot contextuele informatie behoort. Ik heb, denk ik, ook laten zien dat context op z’n Metapatterns iets dynamisch is, iets dat voortdurend aan het gebeuren is. Mogelijk is ook opgevallen dat bepaalde informatie (bijv. BSN) die traditioneel als “key” wordt gezien (dus: waar van alles en nog wat aan opgehangen wordt) in een Stelselmatig Metapattern model terugkomt een attribuut (hangt zelf ergens aan). Enzovoort.

Vanwege het belang van deze discussie zie ik daarom graag wat van jouw probeersels, te weten “context patronen met platen [geïllustreerd]” tegemoet. Ik denk dat die probeersels ons een goed inzicht geven in wat jou met context - en met deze blog - voor ogen staat.

Reactie van Bert Kroek op 1 April 2012 op 17.10

Beste Jan, ik ben het met je eens dat dit een belangrijke discussie is.

Ik heb de afgelopen dagen veel na lopen denken over wat nu de essentie van de kennelijke spraakverwarring  is. Gisteren vielen voor mij heel wat aspecten op zijn plek. Ik zal proberen dat in deze bijdrage neer te zetten, de precieze patronen komen daarna wel.

Het komt mij voor dat het verschil ligt in een ander perspectief. Het lijkt erop alsof jij reageert vanuit het viewpoint Structuur: hoe structureer ik het gegevenslandschap. Mijn viewpoint is Gedrag: hoe geef ik informatie door. De verhouding tussen de twee viewpoints lijkt bijna complemantair. Het ene viewpoint is een black-box voor de ander.

Worstelend met het begrip doelbinding probeer ik inrichtingsprincipes te beschrijven voor het informatiemodel. Het belangrijkste aspect daarbij is voor mij zoals gezegd het eigenaarschap van de gegevens. Als voorbeeld, als een organisatie GBA gegevens ophaalt levert dat een context op die in meerdere organisaties wordt herkend en zelfs in de verschillende voorkomens wordt gesynchroniseerd (abonnement). De context (Context.GBA_identiteit) wordt ook middels een specifieke afspraak uitgeleverd.

In mijn huidige project rondom invoering van SEPA (internationaal rekeningnummer, obv ISO 20022) is een van de belangrijkste nieuwe concepten de introductie van een zogenaam mandaat. Dat mandaat krijgt een uniek nummer en wordt in de betaalketen meegegeven met de transacties. Ik verwacht dat we ook in de zorgketen dit concept zullen inbrengen: Een indicatiestelling levert een mandaat op voor te leveren zorg en daarme ook voor te innen eigen bijdragen. De informatie die in de zorgketen wordt doorgestuurd (Context.Zorgbehoefte)

Een van de patronen die ik wil beschrijven heet rugzak. Een organisatie krijgt gegevens binnen met een bepaald doel en voegt als taak nieuwe informatie toe. Het patroon rugzakje adviseerd om de inkomende context(en) ongewijzigd te laten en daar een rugzakje aan toe te voegen met door de organisatie gegenereerde gegevens. Dit introduceert vanuit de klassieke bril van datamodellering enorm veel gegevens-redundantie.

Gegevens komen vandaag de dag vaak binnen met een impliciet mandaat. De regie behouden wordt een steeds grotere uitdaging. Contexten samenvoegen betekent mandaten samenvoegen. Het probleem is dat mandaten zich meestal niet laten samenvoegen.

Dank je wel Frank Buytendijk voor jouw artikel in Computable [1]: wat je zegt is zo waar!

Er zijn nieuwe rollen nodig. De realiteit wordt te complex. Datatherapeuten. Ik wil het idee nog even een stapje verder doorhalen: We krijgen te maken met digitale burnouts. We hebben een nieuwe architectuur rol nodig, eentje die veel meer therapeutische karakter heeft! Met kenmerken van een gedrags therapeut.

Deze week sprak ik met een van mijn zussen, ze is psycholoog. We hadden het over problemen in persoonlijkheden: de oplossing ligt vaak in de transformtie van delegaten naar legaten.

Het muntje viel pas tijdens het schrijven van deze reatie: De moderne stroming in gedragstherapie heet:

 CONTEXTUELE THERAPIE

Ik besef me dat ik het daar over het als ik het heb over het expliciet maken van contexten.

Organisaties zijn net mensen: het zijn persoonlijkheden met impliciet (aangeleerd) gedrag. Als Architect zijn we coach en therapeut van een organisatie. Hier ligt volgens mij een aardige richtingwijzer voor de inrichting van architectuur opleidingen: (Her)gebruik modellen vanuit de gedragswetenschappen. (ik "toevallig" deze week een boek gekocht over 50 Coaching modellen, )

Now we are talking! CONTEXTUELE ARCHITECTUUR en CONTECTUEEL ARCHITECT. Op metaniveau een architectuur functie op het niveau van de business architectuur boven op de over het algemeen meer op applicatie en techniek gerichte IntegratieArchitect. De Contextuele Architect houdt zich bezig met informatiestromen en mandaten.

En zoals ik al zei: Welkom in de post-moderne wereld! De waarheid is veelkoppig.

Hier stop ik even met deze bijdrage. Ik hoop dat duidelijk is geworden wat ik bedoel met contexten.

[1] Frank Buytendijk: Bedrijf verliest controle door big data http://www.computable.nl/artikel/achtergrond/business_intelligence/...

 

 

 

Reactie van Jan van Til op 2 April 2012 op 21.52

Bert,

Dank je wel voor je nadere toelichting. Ik wil graag kort ingaan op twee zinnen uit je toelichting.

1. "Het lijkt erop alsof jij reageert vanuit het viewpoint Structuur: hoe structureer ik het gegevenslandschap."

Hoe komt een Mens tot Gedrag? Door een bepaalde Betekenis te hechten aan iets wat-ie ervaart. Dat iets komt tot die Betekenis op basis van de Context waarin dat iets zich aan die Mens manifesteert. Andere Context? Andere Betekenis! Ander Gedrag. Stukje Sociale Psychologie - alweer ruim 50 jaar gesneden koek.

Informatie-van-betekenis is onlosmakelijk verbonden met context. In geval van context-loze informatie-uitwisseling (zoals dat vandaag te doen gebruikelijk is) moet de ontvanger geheel op eigen kracht tot betekenis komen. In geval van contextuele informatie-uitwisseling wordt de ontvanger maximaal geholpen om tot bedoelde betekenis en daarmee tot bedoeld gedrag te komen. 

Wat is dan contextuele informatie? Dat is informatie. Informatie die andere informatie tot betekenis laat komen. Wat in het ene geval informatie is, maakt in een ander geval deel uit van contextuele informatie. Informatie orden je in een netwerk, waarbij elk knooppunt een beetje informatie bevat. Als je één van de knooppunten aanwijst als zijnde de informatie die je interesse heeft... dan bevatten alle daaraan gerelateerde knooppunten contextuele informatie t.o.v. het aangewezen knooppunt.

2. "Mijn viewpoint is Gedrag: hoe geef ik informatie door."

Ik zou zeggen: hoe geef ik de bedoelde Betekenis door. Ik orden informatie contextueel met het oog op trefzekere betekenis... met het oog op zo trefzeker mogelijk (bedoeld) gedrag. Zie verder bij punt 1.

 

Reactie van Bert Kroek op 3 April 2012 op 0.45

Beste Jan,

misschien dat ik een andere term nodig heb om te beschrijven wat ik met context bedoel: voor mij is het een samenhangende gegevens set die betekenis heeft in zichzelf en is aangeleverd voor een bepaald doel.

Als voorbeeld van mijn contextbegrip: stel ik leg persoonsgegevens vast van een verzekeraar die ook hypotheken verkoopt.

Via een bedrijfsproces in het verzekeringbedrijf krijg ik van een tussenpersoon persoonsgegevens door van een nieuwe deelnemer. Ik heb het dan over bijvoorbeeld de entiteiten persoon, adres, inkomen. Laat ik dit Context.Verzekering.Relatiegegevens noemen. In het hypotheekbedrijf krijg ik daarna ook persoonsgegevens door: de entiteiten persoon, adres, partner, inkomen en inkomen_partner binnen. Laat ik dat Context.Hypotheek.Relatiegegevens noemen. Laat dit een context zijn zonder bsn nummer omdat het te maken heeft met een vrijblijvende offerte. We doen daarbij zelf een GBA check op nog niet gevalideerde personen die binnenkomt: laten we in het voorbeeld zeggen de persoon in Context.Verzekering.Relatiegegevens. en de partner van We krijgen dan een rugzakje op deze context: Context.GBA.Relatiegegevens met de entiteiten persoon en adres. Zo komt er ook een GBA check op de persoon in Context.Hypotheek.Relatiegegevens. Dat is ook weer een Context.GBA.Relatiegegevens. Voor het gemak heeft dit bedrijf een generiek abonnement geregeld gekregen bij het GBA. Wat over het algemeen gebeurt is dat we proberen deze vier gegevenssets te normaliseren in onze systemen. Als we een oplettende organisatie hebben dan kan het voorkomen dat bijvoorbeeld voor adres herkend wordt dat er sprake is van drie verschillende adressen, en laten we zeggen dat er voor de gemeenschappelijke persoon in de twee niet GBA Contexten twee verschillende inkomens zijn binnengekomen.

Mijn punt is dat ik hier vier contexten heb die los van elkaar moetenworden geadministreerd..

Ik heb nu de volgende uitdagingen:

  •  Ik mag vanuit privacy wetgeving persoonsgegevens van de twee bedrijven niet onderling gebruiken.
  •  Ik weet niet zeker of de twee gelijk lijkende relaties wel dezelfde persoon zijn.

Ik wil nu niet even op de hoe ingaan, het gaat voor mij om het begrip Context en het idee dat je Contexten als aangeleverd moet vastleggen. Volgens mij wijkt dit af van jouw definitie.

 

 

 

 

Ik herken  de informatie ordening in een netwerk, daar zit wat mij betreft het post-moderne aspect: ieder knooppunt in het netwerk heeft haar eigen waarheid. Ik denk alleen dat de granulariteit van de knooppunten niet samenvalt met bedrijfsobjecten maar net een logische groep van entiteiten die in samenhang met elkaar worden beheerd (course-grained).

Verder verwacht ik dat de inhoud van een context bijna altijd een simplificatie zal zijn van het contextmodel.

Volgens mij is 1 van de eisen aan het model dat een context  (=

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Advertenties

Je kunt hier adverteren

© 2019   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden