XXX verantwoordt de omgang met data en informatie en is aantoonbaar in control - Rationale Toezichthouders en stakeholders willen zekerheid over kwaliteit van en zorgvuldige omgang met data en informatie. - Implicatie Data en informatie is auditeerbaar in opzet, bestaan en werking, waarbij de maatregelen die daarvoor worden genomen passen bij de waarde die data en informatie vertegenwoordigt.

Architectuur modellen kunnen altijd mooier en gedetailleerder. Veelal is dat niet nodig en zelfs ongewenst. Deze overgemodelleerde architecturen moeten in een latere fase ook bijgehouden en beheerd worden. Daarnaast is een gedetailleerd model voor veel stakeholders niet relevant en ook niet duidelijk.

Deelarchitecturen dienen aangeleverd te kunnen worden in een formaat waarmee stakeholders zonder toegang tot de repository zich eenvoudig de modellen eigen kunnen maken. Denk hierbij aan Word en PDF documenten die samengesteld worden vanuit de Architectuur Repository,

Niet iedere stakeholder kan en wil toegang tot de modellen via complexe modelleertools. Veelal is er behoefte aan een eenvoudige toegang met een intuïtieve navigatie structuur tot de (deel)modellen.

Deelmodellen worden ontsloten via HTML pagina's. Hiermee wordt het mogelijk om deelmodellen in een aantrekkelijke opmaak met een eenvoudige navigatie te gebruiken voor stakeholders met weinig kennis over modelleertools.

De Architectuur requirements en -eisen collectie biedt een overzicht van alle geautoriseerde architectuur requirements en eisen die zijn overeengekomen met de stakeholders binnen de architectuurraad (architectuur board).

Bij met name project architecturen is de inventarisatie van de baseline, impact van het project, de requirements van de verschillende stakeholders en de te selecteren oplossingsrichtingen een belangrijk werkproces.

Opstellen van architecturen wordt meestal door meerdere verschillende stakeholders gedaan. Daarnaast zijn de werkzaamheden in de architectuur niet altijd projectmatig van opzet. Hierdoor kan het architectuurmodel inconsistent worden. Reden om deze inconsistenties te voorkomen door het architectuur model in een proces te bewaken.

Team dat de architectuur tool gaat inzetten in de architectuurprocessen. Zijn daarmee niet alleen stakeholder maar ook een belangrijke rol in de processen.

We heeft er belangen en concerns rond het gebruik van een architectuur repository.

Dit is een proces die uit een aantal deelstappen bestaat om de gekozen tool dusdanig in te richten dat modelleurs er makkelijk in kunnen werken en de andere stakeholders eenvoudig het voor hen relevante materiaal kunnen vinden.

Capability is een vaardigheid of competency die nodig is om doelen van stakeholders in een organisatie te kunnen bereiken. Deze worden vanuit het onderliggende data verwerkende landschap gerealiseerd.

Uitgewerkt Conceptueel data model in een (meta data) register in een voor de stakeholders toegankelijke representatie.

Uitgewerkt Conceptueel data model in een (meta data) register in een voor de stakeholders toegankelijke representatie.

Uitgewerkt Conceptueel data model in een (meta data) register in een voor de stakeholders toegankelijke representatie.

Stakeholders en concerns worden weergegeven in een model. Een concern is een beschrijving welke belangen en "zorgen" stakeholders hebben over een domein in de data-architectuur. Meestal hebben stakeholders meerdere verschillende concerns. Ook kunnen concerns tegenstellingen zijn van elkaar. Bijvoorbeeld "Data is toegankelijk en data is beveiligd" kunnen in tegenspraak met elkaar zijn. Vandaar dat er een concern model nodig is om de complexiteit van, meestal vele, concerns inzichtelijk te maken inclusief hun onderlinge verbanden en de relaties naar de stakeholders. Voor concerns wordt meestal het ArchiMate motivation aspect gebruikt. Dit is een visuele representatie presentatiewijze van de concerns in een model.

Concerns zijn de belangen en "zorgen" die de verschillende stakeholders hebben bij de introductie van data gedreven werken en de introductie van een data platform. Hieronder worden een aantal algemeen geldende concerns beschreven die voor vrijwel alle data gedreven toepassingen gelden. Houdt er echter rekening mee dat de specifieke situatie van de eigen organisatie bepalend kan zijn voor een aantal concerns en requirements. Breng daarom de specifieke concerns voor de organisatie en voor de solutions of data gedreven toepassingen in kaart en gebruik deze om de voorgestelde oplossing in te kaderen.

Container begrip voor verschillende controlerende stakeholders die concerns hebben die de data-architect dient uit te werken in de data-architectuur.

Een architectuur principe beschrijft kaders die gesteld worden aan veranderingen in de organisatie. Een principe is daarmee een algemeen statement dat requirements en concerns van stakeholders. Principes beschrijven daarmee op welke wijze het resultaat van de verandering bijdraagt aan het verwezenlijken van de strategische uitgangspunten, doelen, eisen en wensen.

Voor de data-architect zijn stakeholders en concerns essentiele begrippen die bepalend zijn voor de data-architectuur. Het inventariseren en beschrijven van welke stakeholders en concerns van invloed zijn op de data-architectuur is daarmee een belangrijke activiteit voor de data-architect.

Data is bij data gedreven organisaties een belangrijk domein. Het domein is gerelateerd aan de andere domeinen binnen een organisatie zoals infrastructuur, applicaties en bedrijfsprocessen. De data domein architectuur is daarmee een holistische beschrijving van de data bestaande uit meerdere uitwerkingen onder andere de kaders zoals data principes, modellen van de stakeholders maar ook een beschrijving van de huidige en toekomstige data architectuur in de vorm van blauwdrukken, modellen en visualisatie's. De data domein architectuur is daarmee veelal kaderstellend en initiërend voor data solution architecturen.

Container begrip voor een aantal stakeholders die vanuit een specifiek kennisgebied binnen data management requirements en concerns hebben die relevant zijn voor de data-architect.

Duidelijke verantwoordelijkheid voor het beheer en eigendom van data binnen een organisatie. Inrichten van beleid en procedures. Data governance en data-architectuur zullen hierbij nauw moeten samenwerken en ervoor zorgdragen dat de communicatie naar de andere stakeholders op elkaar wordt afgestemd.

Data wordt veelal als een waardevol productiemiddel gezien en wordt daarom gemanaged. Dit managen zal op meerdere enterprise niveaus vorm krijgen. In de bedrijfslaag wordt gekeken in welke bedrijfsprocessen en organisatie onderdelen welke data wordt gebruikt voor het uitvoeren van de diverse activiteiten. Daarnaast wordt op dit niveau data ontsloten voor diverse (interne en externe) stakeholders. Deze laag zal daartoe ondersteund worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur meerwaarde geboden kan worden op het moment dat er behoefte is aan veranderingen binnen het data platform en de data-toepassingen. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Data wordt veelal als een waardevol productiemiddel gezien en wordt daarom gemanaged. Dit managen zal op meerdere enterprise niveaus vorm krijgen. In de bedrijfslaag wordt gekeken in welke bedrijfsprocessen en organisatie onderdelen welke data wordt gebruikt voor het uitvoeren van de diverse activiteiten. Daarnaast wordt op dit niveau data ontsloten voor diverse (interne en externe) stakeholders. Deze laag zal daartoe ondersteund worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur meerwaarde geboden kan worden op het moment dat er behoefte is aan veranderingen binnen het data platform en de data-toepassingen. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Deze laag zal vanuit de solution aangepast of uitgebried worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap dat in de solution wordt uitgewerkt. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er binnen de soltion data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur voor en na de implementatie van de solution. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data na deze solution implementatie opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Een data solution architectuur is een gedetailleerde beschrijving van een specifieke oplossing voor een probleem of verandering binnen een organisatie. Het omvat de bedrijfskundige-, technische- en functionele aspecten van de oplossing en hoe deze aansluit bij de bredere doelen en data-architectuur van de organisatie. Het doel is om een werkbare en efficiënte oplossing te bieden die voldoet aan de eisen en wensen van de stakeholders. Kenmerken van een data-solution architectuur richten zich veelal op een beschrijving van een oplossing rekening houden met de strategie van de organisatie en de relevante data architectuurkaders zoals principes binnen een organisatie. Solution architectuur wordt vaak gebruikt in projecten om ervoor te zorgen dat de voorgestelde data gedreven oplossing haalbaar is en goed geïntegreerd kan worden in het bestaande en toekomstige data landschap.

Definitie en model van de stakeholders en constraints van de organisatie op het gebied van data gedreven werken. Inclusief een model voor de roadmap van huidige situatie naar een gewenste situatie van data gedreven werken.

Zichtbaar maken van de analyse resultaten ter ondersteuning van de analisten of voor presentatie aan andere stakeholders

Rond het werkveld kent de data-architect veel stakeholders. Niet alleen op strategisch niveau ook op tactisch en operationeel niveau. Daarbinnen is een nieuw werkveld ontstaan, waar data-engineers, data beheerders en data-analisten en -scientist actief zijn. Deze rollen in het datawerkveld hebben specifieke requirements maar brengen ook specifieke kennis in rond het data werkveld. Daarom dient de data-architect de verschillende rollen in het data werkveld te adviseren over hoe data ingezet kan worden in hun werkveld maar daarbij wel rekening houden met de kaders en requirements die vanuit stakeholders uit andere domeinen een rol spelen.

Data-architecten hebben te maken met allerlei stakeholders. Al deze stakeholders hebben behoeften aan producten waarmee zij zich een beeld kunnen vormen van hoe data ingezet wordt in de organisatie en welke eisen en kaders daaraan gesteld worden. Daarom zal de data-architect afhankelijk van de wensen en behoeften van de stakeholders verschillende architectuur producten uitwerken. Met deze architectuur producten kan iedere stakeholder afhankelijk naar hun gezichtspunt zich op efficiënte wijze een beeld vormen van de data-architectuur

Een data-architectuur visualisatie is een grafische weergave die de structuur, processen, systemen en relaties rond de data als productiemiddel binnen een organisatie inzichtelijk te maken. Het doel is om complexe datastructuren en -stromene begrijpelijk te maken, zodat zowel technische als niet-technische stakeholders een helder beeld krijgen van hoe de organisatie functioneert en hoe veranderingen kunnen worden doorgevoerd. Deze visualisaties worden vaak gebruikt als communicatiemiddel om bestuurders en beslissers te ondersteunen bij het nemen van geïnformeerde beslissingen. Ze bevorderen begrip en draagvlak voor veranderingen binnen een organisatie.

Generieke beschrijving van de stakeholders binnen het data-governance domein. Deze stakeholder kan met behulp van specialisatie uitgewerkt worden in data governance stakeholders zoals eigenaar of steward.

Zeker bij grote organisaties zullen er al diverse onderdelen van het architectuurmodel zijn uitgewerkt in andere tools. Deels door de architecten zelf, deels door andere stakeholders. Hier moeten afspraken over worden gemaakt over het gebruik van verwijzigingen of integratie hulpmiddelen.

Data en informatie mag binnen wettelijke en beleidsmatige kaders worden gedeeld - Rationale Delen tenzij, zowel intern als extern. XXX staat midden in de samenleving. De externe stakeholders verwachten transparantie en openheid en interne transparantie draagt bij aan een verbetering van de dienstverlening. - Implicatie De classificatie van de vertrouwelijkheid bepaalt met wie en hoe, informatie met anderen mag worden gedeeld. Degene die de informatie bewerkt is verantwoordelijk voor het naleven van het beleid over omgang met de informatie.

Projecten en programma's leveren deliverables dit zijn producten of diensten die ervoor zorgen dat de requirements vanuit de verschillende stakeholders worden gerealiseerd. Meestal realiseert een deliverable twee elementen. Allereerst zijn dit de generieke elementen in het data gedreven landschap. Denk hierbij aan bedrijfsprocessen en -functies, applicatiesystemen en infrastructuur elementen. Daarnaast realiseert een deliverable via de generieke- of infrstructuurelementen de data gedreven requirements.

Architectuur modellen voor de uitwerking van stakeholders, doelen, behoeften en principes rond de introductie van een architectuur repository binnen een architectuur team.

De data-architect zal te maken krijgen met een breed palet van externe leveranciers. Leveranciers van data gerelateerde consultancy, data-sets, dataplatformen en tooling maar ook leveranciers van cloudgebaseerde dataplatformen zullen data-architecten benaderen met hun producten en diensten. De data-architect dient zich bewust te zijn van de vaardigheden die externe leveranciers hebben om hun dataproducten onder de aandacht te brengen van de data stakeholders. Externe leveranciers zullen er alles aan doen om deze stakeholders, inclusief de data-architect zelf, om hen een positief beeld te geven van de door hen geleverde producten en diensten. Dit vraagt specifieke vaardigheden van de data-architect om de werkelijke kenmerken van de producten van leveranciers op waarde te schatten voor de stakeholders binnen de eigen organisatie, en hen hiervan te overtuigen.

Deze checklist wordt gebruikt om te bewaken dat de modellen in de repository voor verschillende stakeholders eenvoudig zijn terug te vinden en dat zij een logische volgorde krijgen in de diagrammen om een beeld te krijgen van de solution of de vastgestelde architecturen.

De data-eigenaar is doorgaans een zakelijke stakeholder of afdeling binnen een organisatie met de uiteindelijke verantwoordelijkheid en verantwoordelijkheid voor een specifieke dataset (entiteit).

De data-eigenaar is doorgaans een zakelijke stakeholder of afdeling binnen een organisatie met de uiteindelijke verantwoordelijkheid en verantwoordelijkheid voor een specifieke dataset.

Generieke functionaliteiten die veelal relevant zijn voor alle stakeholders voor de architectuur repository,

De governance rollen en met name de rollen gericht op data-governance zijn verantwoordelijk voor het beleid rond data in de organisatie. Het zijn rollen die sterk in opkomst zijn, met name door data gedreven werken en het introduceren van data management. Daarmee zijn deze data-governance rollen belangrijke stakeholders voor de data-architecten. Data-governance en data-architectuur dienen nauw met elkaar samen te werken om ervoor te zorgen dat de data-strategie wordt geïntroduceerd in de organisatie en vertaald wordt naar beleid en kaders om sturing te geven aan de verandering in de organisatie naar data gedreven werken.

Met data en informatie wordt zorgvuldig omgegaan, rekening houdend met de geldende waarden, normen en wet- en regelgeving - Rationale XXX staat midden in de samenleving. De stakeholders verwachten dat XXX zich houdt aan alle relevante weten regelgeving en zorgvuldig omgaat met alle data en informatie van alle betrokkenen. Zorgvuldig gebruik daarvan kan de beeldvorming over XXX positief beïnvloeden. - Implicatie XXX heeft de regels voor het omgaan met data en informatie vastgelegd in de XXX gedragscode voor alle medewerkers. Relevante wet- en regelgeving (o.a. ten aanzien van privacy en mededinging) wordt geïdentificeerd en opgenomen in XXX-normenkaders en beleid.

Data-architecten werken nauw samen met veel verschillende soorten stakeholders in de organisatie. Gezamenlijk werken zij producten en modellen uit rond data gedreven werken en de data-architectuur. Deze stakeholders leveren niet alleen input aan de architectuur zij dienen ook betrokken te worden bij de uitwerking van de architectuur. Daarnaast zullen zij in een later stadium de rol van ambassadeur gaan vervullen bij het introduceren van data gedreven werken onder een data-architectuur. Om die samenwerking te optimaliseren en de stakeholders te enthousiasmeren voor het bijdragen aan de data-architectuur kunnen verschillende interactieve werkvormen ingezet worden. Deze interactieve werkvormen dienen aan te sluiten bij waar deze stakeholders het gevoel hebben een zinvolle bijdrage te leveren aan de data-architectuur. De keuze van de juiste werkvormen dienen hieraan bij te dragen.

Bij het introduceren van data gedreven werken zullen vele soorten stakeholders betrokken zijn bij het introduceren van data gedreven toepassingen onder architectuur. Om hun wensen en behoeften op gestructureerde wijze in kaart te brengen dienen adequate interviewtechnieken te worden toegepast. Vormen als groepsinterviews, een op een interviews en eventueel weg gebaseerde schriftelijke interviews zijn hiervoor beschikbaar. Echter welke interview vorm past het beste in welke context is een criterium dat een data-architect bij het afnemen van interviews dient toe te passen. De data-architect dient daarom bekend te zijn welke interviewvormen beschikbaar zijn en welke interviewvorm in welke situatie het meest geschikt is.

Wil je de kwaliteit van data waarborgen dan kun je zorgen dat er een kwaliteitsstap wordt ingebouwd in een werkproces. Hierbij zijn verschillende vormen mogelijk. Zoals dat de activiteit door de data producent zelf gedaan wordt of door een andere anders dan de stakeholder zelf. Bekendste voorbeeld is het twee paar ogen principe

Wil je de kwaliteit van data waarborgen dan kun je zorgen dat er een kwaliteitsstap wordt ingebouwd in een werkproces. Hierbij zijn verschillende vormen mogelijk. Zoals dat de activiteit door de data producent zelf gedaan wordt of door een andere anders dan de stakeholder zelf. Bekendste voorbeeld is het twee paar ogen principe

Bewustwording van kwaliteiten vergt training want het is gericht op bewustwording en gedragsverandering bij de verschillende stakeholders. Dit kan gedaan worden mat klassikale, peer to peer en ook e-learnings getraind worden

Bewustwording van kwaliteiten vergt training want het is gericht op bewustwording en gedragsverandering bij de verschillende stakeholders. Dit kan gedaan worden mat klassikale, peer to peer en ook e-learnings getraind worden.

Verschillende kwaliteitsdimensies zoals accuraatheid, compleetheid en validiteit. Datakwaliteit is een van de kernconcerns waar iedere stakeholder in de dagelijkse praktijk tegenaan zal lopen. Data-architectuur dient altijd bewust te zijn van data kwaliteiten en zal bij data gedreven oplossingen kwaliteitsverhogende maatregelen in de oplossing benoemen.

Binnen steeds meer organisaties wordt voor de inrichting van de diverse architecturen gekozen voor standaard oplossingen. In dit geval is de betrokken leverancier van deze oplossingen een stakeholder vanuit perspectief van aanleveren van bepaalde oplossingen en afnemer van de architectuur artifacten.

Het logische of conceptuele model is abstract van aard en staat daarom onafhankelijk van het implementatieplatform. In de meeste gevallen moet dit model leesbaar zijn voor niet-IT-stakeholders.

Data-architecten adviseren meerdere soorten stakeholders binnen organisaties. Bij organisaties die data-gedreven willen werken of data-management willen introduceren is het management van de organisatie een relevante stakeholder. Bij het uitwerken van de organisatie strategie zullen aspecten, requirements en principes vanuit data-gedreven perspectief een rol spelen die de data-architect gebruikt voor het adviseren van het management.

Master data is een categorie van generieke data relevant voor veel stakeholders met daarom hoge kwaliteitseisen.

Master en Referentie Data (MRDM) zijn de werkprocessen gericht op het realiseren van generieke data entiteiten relevant voor een grote groep van verschillende stakeholders. Dit stelt bijzondere eisen aan de inrichting vanuit het perspectief van data kwaliteit. Daarmee ontstaat er een nauwe relatie tussen deze kennisdomeinen.

Het werkveld van data is complex en deze complex kan inzichtelijk gemaakt worden door modellen van het werkveld op te stellen. De data-architect zal daartoe meerdere modelleertechnieken toepassen om hiermee de verschillende stakeholders met modellen te ondersteunen op basis waarvan deze stakeholders inzicht krijgen van deze complexiteit en op basis daarvan een gefundeerde beslissing kunnen nemen.

Het objectmodel beschrijft het concept bouwblok zoals dat gedefinieerd is binnen het architectuurproces. Bouwblokken zijn communicatieve concepten tussen architecten onderling en tussen architectuur en de verschillende stakeholders zoals ontwikkelaars en beheerders. Daarnaast ook interne diensten en eventueel externe stakeholders zoals leveranciers of ketenpartners. Het model bestaat uit een beperkte set aan concepten met onderlinge relaties. Dit model is uitgewerkt in een ArchiMate business objecten diagram. De concepten in het objecten en definitie diagram zijn vervolgens in detail uitgewerkt en beschrijven hiermee de kaders van de bouwblokken.

Met name in situaties waar de verschillende stakeholders niet fysiek in dezelfde ruimte werken is het werken met collaboratie functionaliteiten zoals chat en discussie of review functies wenselijk. Maar ook in andere situaties kan dit toegevoegde waarde hebben.

Opgestelde modellen dienen te worden gereviewed op toepasbaarheid en realiseerbaarheid voor de organisatie. Hiervoor is een review van diverse stakeholders noodzakelijk. Dit dient op adequate wijze te worden ondersteund.

Architectuur Repositories worden al snel omvangrijk (veel elementen, diagrammen en verbanden). Daarom moeten er functionaliteiten zijn waar mee het mogelijk is om op eenvoudige wijze relevante deelmodellen te vinden. Dit is relevant voor alle stakeholders.

Effectieve ondersteuning vereist uitgebreide interpersoonlijke en organisatorische vaardigheden en is meestal het resultaat van een combinatie van een goede voorbereiding, een duidelijk begrip van de doelstellingen, 'buy-in' van senior stakeholders en het gebruik van nuttige technieken gezien de taak, de deelnemers en de organisatorische context. Een goede facilitator moet beschikken over een aantal van de andere persoonlijke kwaliteiten die elders worden besproken. Er kunnen echter enkele specifieke eigenschappen worden geïdentificeerd die bijzonder relevant zijn bij het faciliteren. Facilitators moeten het vermogen hebben om snel de persoonlijkheidstypes en de voorkeursleerstijl te evalueren van een groep mensen die ze al dan niet eerder hebben ontmoet. Aanpassingsvermogen is een andere belangrijke kwaliteit, aangezien facilitators in staat moeten zijn om de voortgang van workshops te beoordelen en de aanpak waar nodig aan te passen om op koers te blijven. Het vermogen om snel te reageren en zich aan te passen is vereist omdat een facilitator voortdurend verwerkt wat de deelnemers zeggen, de vragen formuleert die helpen om de discussie vooruit te helpen en beoordeelt of de huidige technieken werken en wat er nog meer in plaats daarvan kan worden geprobeerd. Facilitators moeten ook assertief zijn en in staat zijn om hun autoriteit tijdens de workshop te vestigen. Een kwestie die vaak naar voren komt in verband met facilitering is of de facilitator een materiedeskundige (SME) moet zijn in het te bespreken onderwerp. Enige kennis is vereist om de discussie te volgen, maar het is niet nodig dat een facilitator een expert is in het onderwerp. In veel situaties kan dit de facilitator helpen om objectief te zijn en vragen te stellen. De rol van de facilitator is immers om anderen te helpen tot een conclusie te komen, niet om een eigen beslissing op te leggen

Architecturen zijn een belangrijke input voor (ICT) projecten en daarmee relevant voor veel stakeholders. Goedkeuring van deze architecturen door bijvoorbeeld een architectuur board of een Lead Architect is daarmee noodzakelijk.

Bij architecturen zijn veel stakeholders betrokken, deze stakeholders dienen te worden geconsulteerd of zij akkoord gaan met de uitwerking binnen de architectuur. Daartoe is een (gestandaardiseerd) reviewproces noodzakelijk.

Sommige diagrammen zijn bij het uitwerken van de solution architectuur optioneel. Ze worden alleen uitgewerkt als daarmee voor een aantal stakeholders een nadere verklaring in een diagram wenselijk is. Deze optionele modelleervormen worden hieronder uitgewerkt.

Binnen de verschillende soorten stakeholders is veelal diepgaande kennis aanwezig van kwaliteitsissues in de data. In workshops is dit een zeer waardevolle bron van problemen in de data. Maar het is ook een mogelijkheid om de bewustwording van datakwaliteit te verhogen

Binnen de verschillende soorten stakeholders is veelal diepgaande kennis aanwezig van kwaliteitsissues in de data. In workshops is dit een zeer waardevolle bron van problemen in de data. Maar het is ook een mogelijkheid om de bewustwording van datakwaliteit te verhogen.

Naast issue workshops kan het ook interessant zijn om samen met stakeholders op basis van issues te kijken naar relevante en (eenvoudig implementeerbare maatregelen en hiermee de datakwaliteit te verhogen. Deze maatregelen kunnen vervolgens worden opgenomen in het maatregelenregister.

Naast issue workshops kan het ook interessant zijn om samen met stakeholders op basis van issues te kijken naar relevante en (eenvoudig implementeerbare maatregelen en hiermee de datakwaliteit te verhogen. Deze maatregelen kunnen vervolgens worden opgenomen in het maatregelenregister

Architectuur is een werkveld gericht op het stellen van kaders aan de verandering en het beschrijven van deze veranderingen. Vandaar dat vanuit elk architectuur werkveld de stakeholders geadviseerd worden. Met name stakeholders op strategisch niveau zullen door architecten geadviseerd worden. Dit stelt eisen aan de adviesvaardigheden van de data-architect en andere architecten. Daarnaast zullen de verschillende architecten in een organisatie om ervoor zorg te dragen dat er een consistent en gelijkluidend advies wordt gegeven aan de strategische stakeholders vanuit de verschillende architecten.

Overzicht in de vorm van een collectie van de requirements van de verschillende stakeholders binnen en buiten de organisatie. Veelal uitgewerkt op basis van de motivation extensie binnen ArchiMate. De opsomming kan gedaan worden in de vorm van een lijst, een matrix of een aantal grafische representaties van de requirements. Zie ook de uitwerking van de solution architectuur repository in een voorgaand hoofdstuk voor een aantal voorbeelden.

Overzicht samenstellen van de aanwezige data architectuur oplossingen beschikbaar op de markt en configureerbaar naar de situatie van de verschillende stakeholders

Een architectuurprincipe beschrijft kaders die gesteld worden aan veranderingen in de organisatie. Een principe is daarmee een algemeen statement dat requirements en concerns van stakeholders. Principes beschrijven daarmee op welke wijze het resultaat van de verandering bijdraagt aan het verwezenlijken van de strategische uitgangspunten, doelen, eisen en wensen.

De inhoud van een architectuur repository dient in meerdere verschijningsvormen voor de diverse stakeholders beschikbaar gesteld te worden.

Generatie van (deel) architecturen in de vorm van documenten. Denk aan project- en referentie architecturen voor stakeholders die geen toegang hebben tot de architectuur repository inhoud.

Een verbijzondering van een inventarisatie binnen de architectuur is het opstellen van de requirements voor de target architectuur voor de verschillende stakeholders binnen en buiten de organisatie waarbinnen de architectuur opgesteld wordt.

Binnen architectuur repositories kunnen eenvoudige meerdere weergaven worden gemaakt van een architectuur. Deze weergaven kunnen specifiek gemaakt worden voor verschillende stakeholders in het reviewproces. Daarnaast zijn er functionaliteiten aanwezig in een repository ter ondersteuning van het reviewproces. Dit maakt het reviewproces eenvoudiger voor zowel de modelleurs als de reviewers

Beschrijving van de dimensie van de rol van de data architect. Bijvoorbeeld welke stakeholders zijn relevant voor de data architect, welke vaardigheden zijn gewenst bij deze rol en welke producten levert een data-architect op.

Deze laag zal vanuit de solution aangepast of uitgebried worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap dat in de solution wordt uitgewerkt. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er binnen de soltion data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur voor en na de implementatie van de solution. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data na deze solution implementatie opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Dit is een globlale uitwerking van welke oplossing de solution gaat introduceren. Het is een samenvattende weergave van de oplossing. Echter wel vanuit meerdere data gedreven gezichtspunten zoals governance, stakeholders en de producten die gerealiseerd worden door het project.

Dit is een globlale uitwerking van welke oplossing de solution gaat introduceren. Het is een samenvattende weergave van de oplossing. Echter wel vanuit meerdere data gedreven gezichtspunten zoals governance, stakeholders en de producten die gerealiseerd worden door het project.

Model van de stakeholders betrokkenheid rond data gedreven werken. Waarbij er over twee dimensies wordt gekeken naar de macht en de interesse van data gedreven werken.

stakeholder model is een grafische weergave van de stakeholders of belanghebbenden die bij een architecturele oplossing of een domein een betrokkenheid hebben. De belangen die zij hebben worden veelal concerns genoemd. Het in kaart brengen van de stakeholders en hun concerns wordt uitgewerkt in een visuele representatie om de stakeholders. Veelal wordt dit gedaan op basis van een ArchiMate motivation diagram. De stakeholders zijn van belang voor het in kaart brengen van het hoe en waarom van een architectuur in relatie tot de doelen en de strategie van de organisatie.

Matrix weergave voor het visueel representeren van de relaties tussen doelen en stakeholders.

Matrix weergave voor het visueel representeren van de relaties tussen doelen en stakeholders.

Een stakeholder is een persoon, groep of organisatie die belang heeft bij een bepaalde verandering. Meestal in de vorm van veranderingen in een project, besluit of bedrijf, omdat hij of zij wordt beïnvloed door de uitkomst ervan of er zelf invloed op kan uitoefenen. Stakeholders kunnen zowel intern als extern zijn en hebben vaak uiteenlopende belangen. Stakeholders spelen een belangrijke rol in het succes van verandering, en het begrijpen en beheren van hun behoeften is vaak cruciaal voor de data-architect. Vanuit een data-architectuurperspectief zijn er enkele belangrijke bijzonderheden met betrekking tot stakeholders: Verschillende belangen: Stakeholders in data-architectuur hebben vaak uiteenlopende belangen. Bijvoorbeeld:

• Business stakeholders: Gericht op hoe data waarde kan toevoegen aan bedrijfsprocessen.
• Technische stakeholders: Gefocust op de implementatie en technische haalbaarheid.
• Regelgevende stakeholders: Bezorgd over naleving van wet- en regelgeving, zoals GDPR.

Complexiteit van concerns: Stakeholders hebben vaak specifieke zorgen, zoals datakwaliteit, beveiliging, schaalbaarheid en interoperabiliteit. Het is de taak van de data-architect om deze zorgen te begrijpen en te adresseren. Viewpoints en modellen: Data-architecten gebruiken vaak verschillende modellen en visualisaties om de behoeften van diverse stakeholders te communiceren. Dit kan variëren van technische blauwdrukken tot strategische dashboards. Veranderende rollen: De rol van stakeholders kan veranderen naarmate de organisatie evolueert. Dit vereist flexibiliteit in de aanpak van de data-architect.

Inventariseren van de stakeholders en hun requirements en deze vertalen naar een model wat de vraagkant van een architectuur beschrijft

Stakeholdermanagement is een belangrijk onderdeel van bedrijfsanalyse. Het omvat het vermogen om belanghebbenden te identificeren, het belang van de belanghebbenden te beoordelen, de perspectieven van belanghebbenden te analyseren en strategieën voor stakeholdermanagement te ontwikkelen.

Datakwaliteiten tijdigheid en accuraatheid zijn nodig om de data op adequate wijze om te zetten naar informatie.

Inleiding Toepassen bouwblokken beschrijft de opzet en de definitie van bouwblokken. Bouwblokken worden bij een organisatie geïntroduceerd vanuit het perspectief van:

• Hergebruik.
• Ontkoppeling
• Generalisatie en specialisatie.
• Standaardisatie.
• Interactie tussen aanbieders en afnemers van informatievoorziening. concepten (op dit moment applicaties en infrastructuur maar dit moet ook toepasbaar zijn op bedrijfsarchitectuur).
• Specificatie van kosten en opbrengsten.
• Verbeteren (versnellen) van de dienstverlening.
• Informatiebeveiliging.

Dit document bestaat uit de volgende delen:

• Model: beschrijft de definitie, kenmerken en verbanden van het concept bouwblok en de bijbehorende specialisaties
• ArchiMate viewpoints: uitwerking van de viewpoints voor de bouwblokken. Deze viewpoints zijn opgebouwd uit een beperkte set aan ArchiMate elementen en associaties.
• Voorbeelden van uitwerking van de verschillende bouwblokken binnen de hierboven gedefinieerde ArchiMate viewpoints
• Sparx implementatie, wijze waarop dit geïmplementeerd wordt in Sparx en hoe het gecommuniceerd/gepubliceerd wordt naar de verschillende stakeholders.

Maak inzichtelijk voor stakeholders die datakwaliteitsproblemen veroorzaken wat het effect is van handelen bij het werken met de data. Denk bijvoorbeeld aan het misbruiken van velden in schermen die daarmee de kwaliteit in de achterliggende databanken kunnen verlagen.

Maak inzichtelijk voor stakeholders die datakwaliteitsproblemen veroorzaken wat het effect is van handelen bij het werken met de data. Denk bijvoorbeeld aan het misbruiken van velden in schermen die daarmee de kwaliteit in de achterliggende databanken kunnen verlagen.

Volledigheid is van belang om de verschillende stakeholders een volledig beeld te laten krijgen van de (deel)architectuur of de solution. Dit is alleen mogelijk door toelichtende teksten te maken voor diagrammen en de elementen in deze diagrammen.

Bij het uitwerken van de data-architectuur, met name bij het in kaart brengen van de requirements en concerns van stakeholders kunnen op meerdere wijzen de behoeften van betrokkenen in kaart worden gebracht Het opstellen en verwerken van vragenlijsten is hierbij een veel toegepaste werkwijze. Daartoe dient de data-architect te beschikken over hulpmiddelen en vaardigheden om dergelijke vragenlijsten te kunnen opstellen en te verwerken. Hiermee heeft de data-architect een krachtig hulpmiddel om een duidelijk beeld te krijgen van de concerns en op basis hiervan een data-architectuur uit te werken.

Is wat ik vaak een onzichtbare stakeholder noem. Het is een stakeholder die je niet op de werkvloer zult tegenkomen. Echter het is zeer zeker een stakeholder met belangen en eisen die van grote invloed zijn aan de kaders die vanuit de architectuur aan de enterprise gesteld zal worden. Bij veel organisaties geldt het principe compliant aan wetgeving en dat is wat voortkomt uit deze stakeholder.

Wetgevers en compliancy instellingen beschouw ik als onzichtbare stakeholders. Echter zij stellen kaders aan de architecturen binnen de organisatie. Daarmee zijn ze ten zeerste relevante stakeholders. Denk bijvoorbeeld aan de AVG.

Naast het afnemen van interviews en het werken met vragenlijsten zijn interactieve workshops met stakeholders een krachtige werkwijze om de concerns en requirements van stakeholders in beeld te krijgen Met name in situaties waar de stakeholders nog weinig ervaring hebben met data-management en/of data-gedreven werken is de inzet van intensievere werkvormen in de vorm van verschillende soorten workshops een hulpmiddel dat de data-architect kan inzetten. Kennis van de organisatiestructuren -cultuur en bekend met de data context kan de data-architect helpen in het bepalen welke interactieve workshops succesvol ingezet kunnen worden bij het uitwerken van data-architectuur producten.

Dama biedt een aantal mooie onderdelen doe goed ingezet kunnen worden voor de uitwerking van architectuur. Dit document geeft een voorbeeld. Dit document geeft een uitwerking van een workshop om data kwaliteiten met een groep stakeholders te inventariseren

Data goverance wordt bij steeds meer organisaties een belangrijk werkveld. Inzetten van data governance kan veel redenen hebben, echter vrijwel altijd dient er een antwoord gevonden te worden op problemen rond het eigenaarschap van data. Binnen data governance speelt data modellering een belangrijke zo niet centrale rol. Met name het leggen van verbanden tussen de data entiteiten en de eigenaren en stewards is essentieel. In een vroeg stadium nadenken welke modelleervormen relevant zijn, hoe deze aan elkaar verbonden worden en hoe de stakeholders daarbij betrokken zijn ondersteunt de introductie van data governance. In dit whitepaper hebben we een combinatie van modelleervormen beschreven die een (minimale) set is van notatiewijzen op basis waarvan data governance in organisaties gemodelleerd kunnen worden.

Data kwaliteit is bij steeds meer organisaties een belangrijk werkveld. Inzetten van data kwaliteit kan veel redenen hebben, echter vrijwel altijd dient er een antwoord gevonden te worden op problemen rond de kwaliteit van data. Binnen data quality speelt data modellering een belangrijke zo niet centrale rol. Met name het leggen van verbanden tussen de data entiteiten en een lijst van kwaliteiten inclusief een score is essentieel. In een vroeg stadium nadenken welke modelleervormen relevant zijn, hoe deze aan elkaar verbonden worden en hoe de stakeholders daarbij betrokken zijn ondersteunt de introductie van data quality. In dit whitepaper hebben we een combinatie van modelleervormen beschreven die een (minimale) set is van notatiewijzen op basis waarvan data quality in organisaties gemodelleerd kunnen worden.

Data security en privacy wordt bij steeds organisaties een belangrijk werkveld. Inzetten van data security kan veel redenen hebben, echter vrijwel altijd is compliancy aan de AVG één van de redenen. Binnen data security speelt data modellering een steeds belangrijker rol. Met name het leggen van verbanden tussen de data entiteiten en de BIVP classificatie is essentieel. In een vroeg stadium nadenken welke modelleervormen relevant zijn, hoe deze aan elkaar verbonden worden en hoe de stakeholders daarbij betrokken zijn ondersteunt de introductie van adequaat informatiebeveiligingsbeleid. In dit whitepaper hebben we een combinatie van modelleervormen beschreven die een (minimale) set is van notatiewijzen op basis waarvan data security en -privacy in organisaties gemodelleerd kunnen worden.

Service oriëntatie is bij veel organisaties het fundament van hun data integratie. Inzetten van data integratie kan veel redenen hebben, echter vrijwel altijd dient er een antwoord gevonden te worden op problemen rond de wendbaarheid van een organisatie door het ontstane ICT landschap. Binnen de service oriëntatie speelt data modellering een belangrijke zo niet centrale rol. In een vroeg stadium nadenken welke modelleervormen relevant zijn, hoe deze aan elkaar verbonden worden en hoe de stakeholders daarbij betrokken zijn ondersteunt de introductie van een SOA. In dit whitepaper hebben we een combinatie van modelleervormen beschreven die een (minimale) set is van notatiewijzen op basis waarvan data stromen in een SOA gemodelleerd kunnen worden.

ArchiMate Data & applicatiemodellering is een onderdeel van de modelleertaal ArchiMate voor het modelleren van Enterprise Architecturen. Het wordt gecombineerd met een aantal andere viewpoints binnen ArchiMate waarmee krachtige modellen opgesteld kunnen worden voor verschillende soorten stakeholders. ArchiMate Data & Applicatiemodellering is een secundair viewpoint maar omvat entiteiten uit de primaire viewpoint. Hiermee ontstaat een verbinding met de andere (secundaire) viewpoints.

ArchiMate Data & bedrijfslaagmodellering is een onderdeel van de modelleertaal ArchiMate voor het modelleren van Enterprise Architecturen. Het wordt gecombineerd met een aantal andere viewpoints binnen ArchiMate waarmee krachtige modellen opgesteld kunnen worden voor verschillende soorten stakeholders. ArchiMate Data & Bedrijfslaagmodellering is een secundair viewpoint maar omvat entiteiten uit de primaire viewpoint. Hiermee ontstaat een verbinding met de andere (secundaire) viewpoints.

ArchiMate motivation datamodellering is een onderdeel van de modelleertaal ArchiMate voor het modelleren van Enterprise Architecturen. Het is een combinatie van een model van data entiteiten en motivation concepten. Er worden krachtige modellen opgesteld worden voor het in kaart brengen van stakeholders en hun concerns.

ArchiMate Datamodellering is een onderdeel van de modelleertaal ArchiMate voor het modelleren van Enterprise Architecturen. Het wordt gecombineerd met een aantal andere viewpoints binnen ArchiMate waarmee krachtige modellen opgesteld kunnen worden voor verschillende soorten stakeholders. De modellen worden met name gebruikt voor interactie met business vertegenwoordiging. Daarnaast kan deze notatie gebruikt worden om de verbanden tussen de bedrijfslaag met de onderliggende lagen (applicatie en technologie).

De begrippenlijst en begrippenboom zijn krachtige notatiewijzen voor het op hoog abstractie niveau in kaart brengen van begrippen en hun onderlinge relaties. De notatie is eenvoudig en kan daardoor ingezet worden bij stakeholders met weinig modelleerervaring en weinig affiniteit met ICT.

RACI matrix is een datamodellering notatie waarmee de bewerkingen Responsible, Accountable, Consulted en Informed worden gecombineerd met Data entiteiten en gedragsentiteiten. De notatie wordt toegepast op met name de conceptuele datamodellering. Naast toepassingen in de datamodellering wordt de RACI matrix met name gebruikt binnen data management, data governance, data security en data privacy. Hierbij gaat het meer om de verantwoordelijkheden en betrokkenheid die rollen of stakeholders in de organisatie hebben op de verschillende data entiteiten.

UML klassenotatie is een veelgebruikte notatiewijze met name voor het opstellen van logische datamodellen. Het legt daarmee een verbinding tussen de fysieke modellen en de conceptuele modellen en is daarmee een onmisbare schakel in de data modelleerketen. Het klassediagram wordt in veel situaties toegepast, met name waar een relatie is met softwareontwikkeling. De basisnotatie biedt al een ruime hoeveelheid mogelijkheden om complexe modellen op te stellen. Dit is enerzijds de kracht van het UML klassediagram en anderzijds een zwakte omdat de modellen veelal te complex zijn voor stakeholders met minder modelleerervaring.

Image library inzetten voor visualisaties in EA

Stakeholders behoeften en concerns afbeelden op het togaf raamwerk

Veranderingen in en rond organisatie zijn van invloed op de rol van de data-architect. Door deze veranderingen wisselen stakeholders en hun concerns. Dit whitepaper gaat in op de belangrijkste stakeholders, hun belangen en hoe de architect dit kan gebruiken bij het uitvoeren van zijn rol. Naast de concerns en requirements wordt ingegaan op een aantal andere concepten zoals kwaliteiten, principes en patronen. Deze worden uitgewerkt gericht op het invullen van de drie data functies en worden gerelateerd aan de genoemde concerns

Dit is een voorbeeld van een wat uitgebreider datalandschap van data uitwisseling tussen bronsystemen en doelsystemen. Dit is voor meerdere kennisgebieden relevant. Denk hierbij aan Master Data, Reference Data of data integratie. In dit voorbeeld gaan we in op de data stromen nodig bij Datawarehousing en BI. Je ziet hier een detaillering van de data verwerking op basis van ETL Daarnaast wordt ook hier de link gelegd naar het conceptuele datamodel. Dit omdat daar mogelijk data governance, securtiy of stakeholder aspecten van belang zijn.

Het conceptueel data model heeft tot doel om op semantisch niveau de data- of bedrijfsconcepten binnen een domein in kaart te brengen. Dit wordt veelal gedaan door het opstellen van een begrippenlijst en/of een begrippenboom. Dit in kaart brengen bestaat allereerst uit het opstellen van een lijst van begrippen met de daarbij behorende definities of beschrijvingen. Met name in omvangrijke domeinen zoals grote organisaties of clusters van verschillende organisaties is het opstellen van een begrippenlijst (in het Engels veelal Glossary genoemd) een complexe activiteit. Is een begrippenlijst als conceptueel datamodel opgesteld dan kan vervolgens een begrippenboom opgesteld worden waarbij verschillende hiërarchieën en verbanden tussen de conceptuele data entiteiten gemodelleerd kunnen worden. Het doel van een conceptueel datamodel is om op semantisch vlak overeenstemming te bereiken bij de betrokken stakeholders wat de betekenis of de definitie van een begrip is. Vandaar dat de combinatie van begrip en beschrijving van het begrip een randvoorwaarde is voor een conceptueel datamodel.

Dit diagram is een viewpoint voor het uitwerken van een conceptueel datamodel.Dit viewpoint geeft aan welke soorten objecttypen en connectortypen gebruikt kunnen worden binnen het opstellen van een conceptueel data model. Voor het conceptueel datamodel gelden een paar uitgangspunten:

• Conceptueel data model is voor meerdere stakeholders(ook niet-ICTers en dient eenvoudig van opzet te zijn.
• Conceptueel data model is uitgewerkt in ArchiMate (business laag).
• Voor het conceptueel data model wordt alleen het stereotype Business Object gebruikt.
• Het conceptuele model heeft een hiërarchische structuur gebaseerd op domeinen.
• Voor een domein kunnen als dit de complexiteit verlaagd meerdere diagrammen gemaakt worden.
• Het conceptuele model wordt gerelateerd aan het logische data model. Zie hiervoor het hybride meta datamodel.
• Het conceptuele model kan gerelateerd worden aan bijvoorbeeld de andere data management business functies binnen Voorbeeld.

Dit diagram is een viewpoint voor het uitwerken van een logisch datamodel.Dit viewpoint geeft aan welke soorten objecttypen en connectortypen gebruikt kunnen worden binnen het opstellen van een logisch data model. Voor het logisch datamodel gelden een paar uitgangspunten:

• Logisch data model is voor alle stakeholders (ICTers en niet-ICTers en dient begrepen te worden door alle stakeholders na een toelichting van het metamodel.
• Logisch data model is uitgewerkt in UML Class Modeling.
• Voor het logisch data model wordt alleen de stereotypen Class en Enumeratie gebruikt.
• Het logisch model heeft een hiërarchische structuur gebaseerd op abstracte en concrete entiteiten met een specialisatie connector.
• Voor een logisch domein kunnen als dit de complexiteit verlaagd meerdere diagrammen gemaakt worden.
• Het logische model wordt gerelateerd aan het bovenliggende conceptuele model en aan de onderliggende fysieke datamodellen. Zie hiervoor het hybride meta datamodel.

Navigatie voor de rol van de data architect met een aantal voorbeelden voor stakeholders, capabilities en het definieren van architectuur producten.

Dit is een voorbeeld van een wat uitgebreider datalandschap van data uitwisseling tussen bronsystemen en doelsystemen. Dit is voor meerdere kennisgebieden relevant. Denk hierbij aan Master Data, Reference Data of data integratie. In dit voorbeeld gaan we in op de data stromen nodig bij Datawarehousing en BI. Je ziet hier een detaillering van de data verwerking op basis van ETL Daarnaast wordt ook hier de link gelegd naar het conceptuele datamodel. Dit omdat daar mogelijk data governance, securtiy of stakeholder aspecten van belang zijn.

Wordt er in een organisatie gewerkt met capabilities modellen om dit inzichtelijk te maken voor de data strategie dan is het uitwerken van de capabilities op basis van de ArchiMate strategielaag concepten een mooie manier van werken. In dit model zijn de capabilities uitgewerkt, echter je kunt desgewenst ook voor value stream elementen kiezen. kenmerkend is dat als de data strategie reeds is uitgewerkt met doelen en stakeholders deze modelleerwijze niet noodzakelijk is.

Model in ArchiMate van de rollen en actoren die gemodelleerd worden als data eigenaar en data steward als stakeholders in data governance.

Detail modellering van welke stakeholders welke data strategie doelen beinvloeden. Hiermee is dit een belangrijk startpunt voor de data-architect. Want op basis van deze stakeholder-doelen matrix kunnen de data-architectuur principes worden opgesteld. Deze principes zijn vanzelfsprekend gebaseerd op de doelen en de stakeholders.

Wordt er in een organisatie gewerkt met capabilities modellen om dit inzichtelijk te maken voor de data strategie dan is het uitwerken van de capabilities op basis van de ArchiMate strategielaag concepten een mooie manier van werken. In dit model zijn de capabilities uitgewerkt, echter je kunt desgewenst ook voor value stream elementen kiezen. kenmerkend is dat als de data strategie reeds is uitgewerkt met doelen en stakeholders deze modelleerwijze niet noodzakelijk is.

In dit diagram leggen we de link vanuit de principes naar de doelen zoals geformeerd door de stakeholders binnen data governance. We werken hierbij het model uit op basis van ArchiMate motivation concepten.

Model in ArchiMate van de rollen en actoren die gemodelleerd worden als data eigenaar en data steward als stakeholders in data governance.

Detail modellering van welke stakeholders welke data strategie doelen beinvloeden. Hiermee is dit een belangrijk startpunt voor de data-architect. Want op basis van deze stakeholder-doelen matrix kunnen de data-architectuur principes worden opgesteld. Deze principes zijn vanzelfsprekend gebaseerd op de doelen en de stakeholders.

Voor data governance zijn een aantal stakeholders van belang. Met name een uitwerking van de stewards en eigenaren van verschillende data domeinen of data objecten is bij deze relevant. Wil je een precieze detaillering van wie eigenaar, steward of custodian is kan een uitbreiding van het model wenselijk zijn. Bijvoorbeeld door de stakeholder met behulp van business actoren de governance precies te definieren.

Voor data governance zijn een aantal stakeholders van belang. Met name een uitwerking van de stewards en eigenaren van verschillende data domeinen of data objecten is bij deze relevant. Wil je een precieze detaillering van wie eigenaar, steward of custodian is kan een uitbreiding van het model wenselijk zijn. Bijvoorbeeld door de stakeholder met behulp van business actoren de governance precies te definieren.

ArchiMate diagram met de stakeholders en de doelen die gedefinieerd zijn en de invloed tussen doelen en stakeholders. Desgewenst is te modelleren of de invloed van een doel positief of negatief is voor de stakeholders. Dat is in dit diagram niet toegevoegd.

Data principes modellering heeft tot doel om de relatie van bedrijfsentiteiten, data entiteiten en artefacten met stakeholders en hun concerns te beschrijven. Hierbij wordt een duidelijk onderscheid gemaakt tussen de entiteiten in de architectuurlagen en worden er meestal per laag afzonderlijke modellen opgesteld. Hierbij wordt met behulp van principes een verbinding gelegd met de data entiteiten, bijvoorbeeld in het conceptueel datamodel naar de behoeften en doelen van de stakeholders binnen en buiten de organisatie. Het doel van deze modelleerwijze is om deze verbanden tussen stakeholders en hun concerns in relatie te brengen met de data entiteiten op de verschillende lagen. Daarnaast worden met de principes veelal ook de definities uitgewerkt op basis van de voor deze concepten geldende standaarden. Voor de data entiteiten is reeds een beschrijving opgesteld binnen de primaire modellering.

Data principes modellering heeft tot doel om de relatie van bedrijfsentiteiten, data entiteiten en artefacten met stakeholders en hun concerns te beschrijven. Hierbij wordt een duidelijk onderscheid gemaakt tussen de entiteiten in de architectuurlagen en worden er meestal per laag afzonderlijke modellen opgesteld. Hierbij wordt met behulp van principes een verbinding gelegd met de data entiteiten, bijvoorbeeld in het conceptueel datamodel naar de behoeften en doelen van de stakeholders binnen en buiten de organisatie. Het doel van deze modelleerwijze is om deze verbanden tussen stakeholders en hun concerns in relatie te brengen met de data entiteiten op de verschillende lagen. Daarnaast worden met de principes veelal ook de definities uitgewerkt op basis van de voor deze concepten geldende standaarden. Voor de data entiteiten is reeds een beschrijving opgesteld binnen de primaire modellering.

Het meta data register is een data gedreven toepassing met een aantal bijzondere kenmerken met name op het vlak van gebruikerswensen zoals zoeken, filteren, relaties leggen en visualisaties. Meta data wordt in veel toepassingen gebruikt en dient dan ook raadpleegbaar te zijn voor meerdere soorten stakeholders. Allemaal hebben zij hun eigen kijk (of context) op meta data van databron tot -toepassing. De context van meta is relatief breed. Kenmerkend is dat data management hierin een essentiële rol vervuld. De rollen dataeigenaar, -steward en -architect zijn verantwoordelijk voor het bepalen van de requirements van alle stakeholders. Op basis daarvan wordt een toepassing als meta data register aangeschaft, geconfigureerd of zelf ontwikkeld. Daarmee is de context van de meta data dus de gehele organisatie in de breedste zin van het woord. Namelijk ook stakeholders van buiten de eigen organisatie kunnen gebruik maken van het door de organisatie aangeboden data uit het meta data register.

Dit diagram is een viewpoint voor het uitwerken van een conceptueel datamodel.Dit viewpoint geeft aan welke soorten elementen en relaties gebruikt kunnen worden binnen het opstellen van een conceptueel data model. Voor het conceptueel datamodel gelden een paar uitgangspunten:

• Conceptueel data model is voor meerdere stakeholders (ook niet-ICTers) en dient eenvoudig van opzet te zijn.
• Conceptueel data model is uitgewerkt in ArchiMate (business layer).
• Voor het conceptueel data model wordt alleen het stereotype Business Object gebruikt.
• Het conceptuele model heeft een hiërarchische structuur gebaseerd op domeinen.
• Voor een domein kunnen als dit de complexiteit verlaagd meerdere diagrammen gemaakt worden.
• Het conceptuele model wordt gerelateerd aan het logische data model. Zie hiervoor het hybride meta datamodel.
• Het conceptuele model kan gerelateerd worden aan de andere data management kennisgebieden zoals governance, architectuur en datakwaliteit.

Dit diagram is een metamodel voor het uitwerken van een logisch datamodel.Dit metamodel geeft aan welke soorten elementen en relaties gebruikt kunnen worden binnen het opstellen van een logisch data model. Voor het logisch datamodel gelden een paar uitgangspunten:

• Logisch data model is voor alle stakeholders (ICTers en niet-ICTers en dient begrepen te worden door alle stakeholders na een toelichting van het metamodel.
• Logisch data model is uitgewerkt in UML Class modelleren.
• Voor het logisch data model worden alleen de stereotypen Class en Enumeratie gebruikt.
• Het logisch model heeft een hiërarchische structuur gebaseerd op abstracte en concrete entiteiten met een specialisatie relatie.
• Voor een logisch domein kan de complexiteit verlaagd worden door meerdere diagrammen te maken.
• Het logische model wordt gerelateerd aan het bovenliggende conceptuele model en aan de onderliggende fysieke datamodellen. Zie hiervoor het hybride meta datamodel.

Voor het applicatielandschap wil Giovanna een aantal principes opstellen

• Cloud implementatie tenzij
• Applicatie interfaces alleen via het web

Maak een ArchiMate diagram van dit landschap aan, gebruik eventueel concepten uit je eigen organisatie Leg relevante associaties tussen de elementen, eventueel koppelelementen in het diagram en de elementen uit het applicatielandschap. Benoem ook een aantal stakeholders Voeg een uitlijning en layout toe

Het bouwblokken model bestaat uit de generieke entiteiten bouwblok en catalogus. Deze vormen de basis van een referentie architectuur. Catalogi zijn groeperingen van bouwblokken binnen een bepaald domein. Er zullen meerdere catalogi ontstaan die aan elkaar gerelateerd zijn en elkaar overlappen binnen de visualisaties. Het voordeel van de opzet van het werken met catalogi en bouwblokken is:

• Er ontstaan registers van herbruikbare architectuur onderdelen gericht op een bepaald werkveld.
• Inzet van bouwblokken brengt standaardisatie met zich met en stimuleert hergebruik van architecturele configuraties.
• Bouwblokken maakt het architectuur- en het ontwikkelproces eenvoudiger.
• Er ontwikkelen zicht architecturele product catalogi gericht op specifieke werkvelden. Dit heeft een positieve invloed op de dienstverlening naar de rest van de organisatie.

De bouwblokken kennen drie specialisaties waarvan de definities in detail zijn uitgewerkt. Deze beschrijvingen zijn hieronder in de paragrafen uitgewerkt. Indien relevant is aan deze uitwerking extra informatie toegevoegd zoals links naar Togaf en voorbeelden van de implementatie van deze architecturele concepten In het model wordt gewerkt met een pragmatisch model voor wat betreft de associaties tussen Service en SBB. Vanuit ArchiMate perspectief is de route van service via ABB naar SBB. Dit heeft als kenmerk dat het functionele aspect goed ingebed is in het bouwblokken model. Bij het publiceren van deze modellen wordt gezocht naar een mogelijkheid om rapporten en webpagina's te genereren die voor niet architectuur stakeholders geen gegevens bevatten niet relevant voor het model, dat kan betekenen dat in een aantal situaties de ABBs niet uitgewerkt hoeven te worden. Het in de modellering toepassen van de directe associatie tussen service en SBB voldoet niet aan de viewpoints.

Opsomming van een aantal architectuur principes relevant bij het werken met een repository gedreven aanpak. Let op dit diagram is een vereenvoudigde weergave. Er is in de repository ook een relatie gelegd naar bijvoorbeeld de stakeholders en de doelen. Echter die worden niet in dit deel getoond maar zijn terug te vinden binnen de uitwerking van de matrices voor de motivatie van het inzetten van een architectuur repository.

Beschrijving van de rollen binnen een architectuur repository aanpak. Dit is dus meer gedetailleerd dan het overzicht van stakeholders. In dit model zal men ook de projectleden of rollen selecteren. Een aantal generiek benoemde rollen. Rollen nemen wel actief deel aan de activiteiten tbv de introductie van de AR. Houdt er rekening mee dat dit veelal een organisatie specifiek karakter heeft. Pas daarom dit model gerust naar de eigen context aan. In dit diagram zijn de rollen gerelateerd aan een aantal stakeholders in het model.

Het conceptueel data model heeft tot doel om op semantisch niveau de data- of bedrijfsconcepten binnen de solution in kaart te brengen. Dit wordt veelal gedaan door het opstellen van een begrippenlijst en/of een begrippenboom. Dit in kaart brengen bestaat allereerst uit het opstellen van een lijst van begrippen met de daarbij behorende definities of beschrijvingen. Met name in omvangrijke solution zoals grote data gedreven programma's organisaties is het opstellen van een begrippenlijst (in het Engels veelal Glossary genoemd) een complexe activiteit. Het doel van een conceptueel datamodel is om op semantisch vlak overeenstemming te bereiken bij de betrokken solution stakeholders wat de betekenis of de definitie van een begrip is. Vandaar dat de combinatie van begrip en definitiebeschrijving van het begrip een randvoorwaarde is voor een conceptueel datamodel.

Dit diagram legt een relatie met het project en de doelen die de organisatie op het gebied van data gedreven werken wil realiseren. De producten of deliverables die vanuit het project zullen een positieve of een negatieve uitwerking hebben op de doelen en de stakeholders rond data gedreven werken. In dit diagram wordt realisatie van doelen als een positief effect. Beinvloeden is een negatief effect op de doelen die bereikt willen worden.

In dit diagram wordt in een matrix weergave een overzicht gegeven van hoe de doelen en de stakeholders die geraakt worden door dit project en de uitkomsten getoond in een matrix.

Het conceptueel data model heeft tot doel om op semantisch niveau de data- of bedrijfsconcepten binnen de solution in kaart te brengen. Dit wordt veelal gedaan door het opstellen van een begrippenlijst en/of een begrippenboom. Dit in kaart brengen bestaat allereerst uit het opstellen van een lijst van begrippen met de daarbij behorende definities of beschrijvingen. Met name in omvangrijke solution zoals grote data gedreven programma's organisaties is het opstellen van een begrippenlijst (in het Engels veelal Glossary genoemd) een complexe activiteit. Het doel van een conceptueel datamodel is om op semantisch vlak overeenstemming te bereiken bij de betrokken solution stakeholders wat de betekenis of de definitie van een begrip is. Vandaar dat de combinatie van begrip en definitiebeschrijving van het begrip een randvoorwaarde is voor een conceptueel datamodel.

Dit diagram legt een relatie met het project en de doelen die de organisatie op het gebied van data gedreven werken wil realiseren. De producten of deliverables die vanuit het project zullen een positieve of een negatieve uitwerking hebben op de doelen en de stakeholders rond data gedreven werken. In dit diagram wordt realisatie van doelen als een positief effect. Beinvloeden is een negatief effect op de doelen die bereikt willen worden.

In dit diagram wordt in een matrix weergave een overzicht gegeven van hoe de doelen en de stakeholders die geraakt worden door dit project en de uitkomsten getoond in een matrix.

Een aantal generiek benoemde stakeholders. Stakeholders hebben concerns en requirements voor de inzet van een architectuur repository. Echter ze hoeven niet perse deelnemer te zijn in het project dat de architectuur repository introduceert. Houd er rekening mee dat dit veelal een organisatie specifiek karakter heeft. In dit model worden alleen een aantal generieke stakeholders benoemd. Pas daarom dit model gerust aan naar de eigen context aan zodat dit overeenkomt met de stakeholder relevant binnen jouw organisatie.

De stakeholder matrix wordt beschreven in het Togaf raamwerk en biedt een mooie weergave en classificatie van de stakeholders. Voor meer informatie zie https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap21.html

In dit diagram worden de meest relevante stakeholders van een data-architect getoond in een groepering op basis van werkvelden rondom data-architectuur. Professional wordt hier als algemene term gebruikt, kan een architect, beheerder en manager zijn. Mocht voor de eigen situatie een uitbreiding nodig zijn neem dan specialisaties op voor deze professional rollen. Desgewenst kun je deze stakeholders in een stakeholdermatrix plaatsen of de stakeholders indelen in een andere classificatie. Bij het uitwerken van data-architectuur modelleren komt in ieder geval de stakeholdermatrix terug.

Concerns zijn de belangen en "zorgen" die de verschillende stakeholders hebben bij de introductie van data gedreven werken en de introductie van een data platform. Hieronder worden een aantal algemeen geldende concerns beschreven die voor vrijwel alle data gedreven toepassingen gelden. Houdt er echter rekening mee dat de specifieke situatie van de eigen organisatie bepalend kan zijn voor een aantal concerns en requirements. Breng daarom de specifieke concerns voor de organisatie en voor de solutions of data gedreven toepassingen in kaart en gebruik deze om de voorgestelde oplossing in te kaderen.

Data wordt veelal als een waardevol productiemiddel gezien en wordt daarom gemanaged. Dit managen zal op meerdere enterprise niveaus vorm krijgen. In de bedrijfslaag wordt gekeken in welke bedrijfsprocessen en organisatie onderdelen welke data wordt gebruikt voor het uitvoeren van de diverse activiteiten. Daarnaast wordt op dit niveau data ontsloten voor diverse (interne en externe) stakeholders. Deze laag zal daartoe ondersteund worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur meerwaarde geboden kan worden op het moment dat er behoefte is aan veranderingen binnen het data platform en de data-toepassingen. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Data wordt veelal als een waardevol productiemiddel gezien en wordt daarom gemanaged. Dit managen zal op meerdere enterprise niveaus vorm krijgen. In de bedrijfslaag wordt gekeken in welke bedrijfsprocessen en organisatie onderdelen welke data wordt gebruikt voor het uitvoeren van de diverse activiteiten. Daarnaast wordt op dit niveau data ontsloten voor diverse (interne en externe) stakeholders. Deze laag zal daartoe ondersteund worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur meerwaarde geboden kan worden op het moment dat er behoefte is aan veranderingen binnen het data platform en de data-toepassingen. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Deze laag zal vanuit de solution aangepast of uitgebried worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap dat in de solution wordt uitgewerkt. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er binnen de soltion data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur voor en na de implementatie van de solution. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data na deze solution implementatie opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Definitie en model van de stakeholders en constraints van de organisatie op het gebied van data gedreven werken. Inclusief een model voor de roadmap van huidige situatie naar een gewenste situatie van data gedreven werken.

Data-architecten hebben te maken met allerlei stakeholders. Al deze stakeholders hebben behoeften aan producten waarmee zij zich een beeld kunnen vormen van hoe data ingezet wordt in de organisatie en welke eisen en kaders daaraan gesteld worden. Daarom zal de data-architect afhankelijk van de wensen en behoeften van de stakeholders verschillende architectuur producten uitwerken. Met deze architectuur producten kan iedere stakeholder afhankelijk naar hun gezichtspunt zich op efficiënte wijze een beeld vormen van de data-architectuur

Architectuur modellen voor de uitwerking van stakeholders, doelen, behoeften en principes rond de introductie van een architectuur repository binnen een architectuur team.

Master en Referentie Data (MRDM) zijn de werkprocessen gericht op het realiseren van generieke data entiteiten relevant voor een grote groep van verschillende stakeholders. Dit stelt bijzondere eisen aan de inrichting vanuit het perspectief van data kwaliteit. Daarmee ontstaat er een nauwe relatie tussen deze kennisdomeinen.

Het objectmodel beschrijft het concept bouwblok zoals dat gedefinieerd is binnen het architectuurproces. Bouwblokken zijn communicatieve concepten tussen architecten onderling en tussen architectuur en de verschillende stakeholders zoals ontwikkelaars en beheerders. Daarnaast ook interne diensten en eventueel externe stakeholders zoals leveranciers of ketenpartners. Het model bestaat uit een beperkte set aan concepten met onderlinge relaties. Dit model is uitgewerkt in een ArchiMate business objecten diagram. De concepten in het objecten en definitie diagram zijn vervolgens in detail uitgewerkt en beschrijven hiermee de kaders van de bouwblokken.

Sommige diagrammen zijn bij het uitwerken van de solution architectuur optioneel. Ze worden alleen uitgewerkt als daarmee voor een aantal stakeholders een nadere verklaring in een diagram wenselijk is. Deze optionele modelleervormen worden hieronder uitgewerkt.

Overzicht in de vorm van een collectie van de requirements van de verschillende stakeholders binnen en buiten de organisatie. Veelal uitgewerkt op basis van de motivation extensie binnen ArchiMate. De opsomming kan gedaan worden in de vorm van een lijst, een matrix of een aantal grafische representaties van de requirements. Zie ook de uitwerking van de solution architectuur repository in een voorgaand hoofdstuk voor een aantal voorbeelden.

Beschrijving van de dimensie van de rol van de data architect. Bijvoorbeeld welke stakeholders zijn relevant voor de data architect, welke vaardigheden zijn gewenst bij deze rol en welke producten levert een data-architect op.

Deze laag zal vanuit de solution aangepast of uitgebried worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap dat in de solution wordt uitgewerkt. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er binnen de soltion data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur voor en na de implementatie van de solution. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data na deze solution implementatie opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Dit is een globlale uitwerking van welke oplossing de solution gaat introduceren. Het is een samenvattende weergave van de oplossing. Echter wel vanuit meerdere data gedreven gezichtspunten zoals governance, stakeholders en de producten die gerealiseerd worden door het project.

Dit is een globlale uitwerking van welke oplossing de solution gaat introduceren. Het is een samenvattende weergave van de oplossing. Echter wel vanuit meerdere data gedreven gezichtspunten zoals governance, stakeholders en de producten die gerealiseerd worden door het project.

Model van de stakeholders betrokkenheid rond data gedreven werken. Waarbij er over twee dimensies wordt gekeken naar de macht en de interesse van data gedreven werken.

Een stakeholder is een persoon, groep of organisatie die belang heeft bij een bepaalde verandering. Meestal in de vorm van veranderingen in een project, besluit of bedrijf, omdat hij of zij wordt beïnvloed door de uitkomst ervan of er zelf invloed op kan uitoefenen. Stakeholders kunnen zowel intern als extern zijn en hebben vaak uiteenlopende belangen. Stakeholders spelen een belangrijke rol in het succes van verandering, en het begrijpen en beheren van hun behoeften is vaak cruciaal voor de data-architect. Vanuit een data-architectuurperspectief zijn er enkele belangrijke bijzonderheden met betrekking tot stakeholders: Verschillende belangen: Stakeholders in data-architectuur hebben vaak uiteenlopende belangen. Bijvoorbeeld:

• Business stakeholders: Gericht op hoe data waarde kan toevoegen aan bedrijfsprocessen.
• Technische stakeholders: Gefocust op de implementatie en technische haalbaarheid.
• Regelgevende stakeholders: Bezorgd over naleving van wet- en regelgeving, zoals GDPR.

Complexiteit van concerns: Stakeholders hebben vaak specifieke zorgen, zoals datakwaliteit, beveiliging, schaalbaarheid en interoperabiliteit. Het is de taak van de data-architect om deze zorgen te begrijpen en te adresseren. Viewpoints en modellen: Data-architecten gebruiken vaak verschillende modellen en visualisaties om de behoeften van diverse stakeholders te communiceren. Dit kan variëren van technische blauwdrukken tot strategische dashboards. Veranderende rollen: De rol van stakeholders kan veranderen naarmate de organisatie evolueert. Dit vereist flexibiliteit in de aanpak van de data-architect.

Inleiding Toepassen bouwblokken beschrijft de opzet en de definitie van bouwblokken. Bouwblokken worden bij een organisatie geïntroduceerd vanuit het perspectief van:

• Hergebruik.
• Ontkoppeling
• Generalisatie en specialisatie.
• Standaardisatie.
• Interactie tussen aanbieders en afnemers van informatievoorziening. concepten (op dit moment applicaties en infrastructuur maar dit moet ook toepasbaar zijn op bedrijfsarchitectuur).
• Specificatie van kosten en opbrengsten.
• Verbeteren (versnellen) van de dienstverlening.
• Informatiebeveiliging.

Dit document bestaat uit de volgende delen:

• Model: beschrijft de definitie, kenmerken en verbanden van het concept bouwblok en de bijbehorende specialisaties
• ArchiMate viewpoints: uitwerking van de viewpoints voor de bouwblokken. Deze viewpoints zijn opgebouwd uit een beperkte set aan ArchiMate elementen en associaties.
• Voorbeelden van uitwerking van de verschillende bouwblokken binnen de hierboven gedefinieerde ArchiMate viewpoints
• Sparx implementatie, wijze waarop dit geïmplementeerd wordt in Sparx en hoe het gecommuniceerd/gepubliceerd wordt naar de verschillende stakeholders.