Een beschrijvende data architectuur is een belangrijk kennisgebied van data management en daarmee relevant voor data gedreven organisaties.
Ten behoeve van data-architectuur modelleren zijn er diverse data-architectuur tools beschikbaar. Denk hierbij aan Collibra, The Essential Project of Talend. Echter bij organisaties zijn vaak reeds generieke modelleringstalen en tools beschikbaar voor modelleren van software, enterprise architectuur of requirements. In dit hoofdstuk gaan we in op het inzetten van een framework voor inrichting van een generiek tool gebaseerd op een aantal open modelleertalen. De voorbeelden die we hier gebruiken zijn uitgewerkt in Sparx Enterprise Architect. Een voorbeeld van een dergelijk generiek tool.
Hieronder is daartoe een metamodel uitgewerkt voor hoe een data-architectuur gemodelleerd kan worden. De data-architectuur kent meerdere gezichtspunten om data in een organisatie te beschrijven. Zo wordt er op verschillende niveaus in een organisatie gekeken. Daarnaast kan de mate van detail vanuit verschillende gezichtspunten verschillen.
We introduceren data-architectuur modelleren op basis van een uitwerking met behulp van een aantal modelleertechnieken. De belangrijkste modelleertechnieken hier gebruikt zijn:

• ArchiMate


• Unified Modeling Language


• Entity Relationship


• XML Schema Definition

Reden om voor deze modelleertalen te kiezen is dat ze een open standaard zijn, een breed toepassingsgebied hebben, goed met elkaar te integreren zijn en reeds veel toegepast worden binnen de aanpalende domeinen van data-architectuur. Hiermee kun je in je eigen organisatie data-architectuur modelleren introduceren op een natuurlijke manier. Dat doe je door die delen relevant voor de situatie binnen de organisatie stapsgewijs te introduceren op basis van de reeds toegepaste modelleertalen.
Daarnaast worden er meerdere verschijningsvormen van de data-architectuur gebruikt. De grafenweergave en de matrix zijn in dit metamodel de meestgebruikte verschijningsvormen.
Voor het uitwerken van het metamodel worden er twee data-architectuur niveaus uitgewerkt, namelijk:

• Domein data-architectuur: dit is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur


• Solution data-architectuur: architectuur voor het beschrijven van een data gedreven verandering binnen een project of oplossing.

Beide vormen worden hieronder nader toegelicht.

De beschrijvende architectuur beschrijft het huidige en gewenste, en eventueel tussenliggende, datalandschap voor een organisatie.
Voor de beschrijvende data-architectuur worden veelal gestandaardiseerde architectuurmodelleertalen gebruikt zoals ArchiMate, BPMN, UML en ER. Deze talen worden uitgewerkt op basis van een hybride modelleerwijze waarbij de architect een combinatie van modelleertalen combineert om op basis daarvan een beschrijvende data architectuur te laten.
Aangezien het ontwikkelen van een beschrijvende architectuur een continu proces is dient het managen van de modellen en het bewaken van de kwaliteit van de modellen bewaakt te worden.

In het beschrijvend model worden een aantal data modellen uitgewerkt van abstract (conceptueel model) naar technisch platform specifiek (fysiek model). Dit model is feitelijk het centrale model voor metadata waaraan de andere domeinen gekoppeld zijn.

In het beschrijvend model worden een aantal data modellen uitgewerkt van abstract (conceptueel model) naar technisch platform specifiek (fysiek model). Dit model is feitelijk het centrale model voor metadata waaraan de andere domeinen gekoppeld zijn.

Een beschrijvende data architectuur is een belangrijk kennisgebied van data management en daarmee relevant voor data gedreven organisaties.
Ten behoeve van data-architectuur modelleren zijn er diverse data-architectuur tools beschikbaar. Denk hierbij aan Collibra, The Essential Project of Talend. Echter bij organisaties zijn vaak reeds generieke modelleringstalen en tools beschikbaar voor modelleren van software, enterprise architectuur of requirements. In dit hoofdstuk gaan we in op het inzetten van een framework voor inrichting van een generiek tool gebaseerd op een aantal open modelleertalen. De voorbeelden die we hier gebruiken zijn uitgewerkt in Sparx Enterprise Architect. Een voorbeeld van een dergelijk generiek tool.
Hieronder is daartoe een metamodel uitgewerkt voor hoe een data-architectuur gemodelleerd kan worden. De data-architectuur kent meerdere gezichtspunten om data in een organisatie te beschrijven. Zo wordt er op verschillende niveaus in een organisatie gekeken. Daarnaast kan de mate van detail vanuit verschillende gezichtspunten verschillen.
We introduceren data-architectuur modelleren op basis van een uitwerking met behulp van een aantal modelleertechnieken. De belangrijkste modelleertechnieken hier gebruikt zijn:

• ArchiMate


• Unified Modeling Language


• Entity Relationship


• XML Schema Definition

Reden om voor deze modelleertalen te kiezen is dat ze een open standaard zijn, een breed toepassingsgebied hebben, goed met elkaar te integreren zijn en reeds veel toegepast worden binnen de aanpalende domeinen van data-architectuur. Hiermee kun je in je eigen organisatie data-architectuur modelleren introduceren op een natuurlijke manier. Dat doe je door die delen relevant voor de situatie binnen de organisatie stapsgewijs te introduceren op basis van de reeds toegepaste modelleertalen.
Daarnaast worden er meerdere verschijningsvormen van de data-architectuur gebruikt. De grafenweergave en de matrix zijn in dit metamodel de meestgebruikte verschijningsvormen.
Voor het uitwerken van het metamodel worden er twee data-architectuur niveaus uitgewerkt, namelijk:

• Domein data-architectuur: dit is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur


• Solution data-architectuur: architectuur voor het beschrijven van een data gedreven verandering binnen een project of oplossing.

Beide vormen worden hieronder nader toegelicht.

Een blauwdruk of grondplaat is een visuele weergave van delen van een data-architectuur die een vereenvoudigde weergave is van de datatoepassing.
Deze vereenvoudiging dient er echter wel aan bij te dragen dat de verbanden van de toepassingen inzichtelijk worden en daarmee overzicht te krijgen over het gehele data-architectuur landschap. Een data-architectuur blauwdruk beschrijft hoe data wordt beheerd, van verzameling tot transformatie, distributie en consumptie . De blauwdruk is daarmee met name van belang om de gewenste situatie van de data architectuur te beschrijven.

Data architecten voor de ontwikkeling van de Enterprise Data Architectuur. Hier wordt alleen gesproken over de Bedrijfsobjecten maar de andere onderdelen zijn ook van belang.

Data architectuur is een van de kennisgebieden binnen het DMBoK en modellen uitwerken rond dit kennisgebied zijn kaderstellend voor veranderingen in de organisatie vanuit data management perspectief.

Data architectuur van een architectuur repository. Dit is in dit document relatief eenvoudig van opzet en omvat alleen een conceptueel datamodel. Echter in het conceptueel datamodel wordt wel een overzicht gegeven van relevante concepten binnen een architectuur repository.

Overzicht of grondplaat van de aanwezige of toekomstige data objecten, datasets en databanken binnen het domein van de architectuur.

Een data-architectuur assessment is een evaluatieproces waarbij de huidige data-architectuur van een organisatie wordt geanalyseerd en beoordeeld. Het doel is om inzicht te krijgen in de sterktes, zwaktes, kansen en risico's van de bestaande data-architectuur (SWOT). Dit helpt organisaties om verbeterpunten te identificeren en een strategie te ontwikkelen voor een efficiënter en effectiever data-landschap. Het biedt daarmee inzicht van hoe de verandering van de data gedreven organisatie vormgegeven moet worden rekening houdend met de SWOT analyse die in het assessment is uitgevoerd.

Een data-architectuur patroon is een herbruikbare oplossing voor veelvoorkomende problemen of uitdagingen binnen de data-architectuur van een organisatie. Het biedt een gestandaardiseerde aanpak voor het ontwerpen, implementeren en beheren van data-oplossingen, zodat consistentie en efficiëntie worden bevorderd. Deze patronen zijn gebaseerd op best practices en kunnen worden aangepast aan de specifieke behoeften van een organisatie. Door het toepassen van patronen wordt het mogelijk om hergebruik te introduceren om hiermee consistentie te bewerkstelligen in het datalandschap.

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.

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.

Vanuit het data operations kennisveld waarbinnen vanuit het beheer van data activiteiten worden uitgevoerd voor het beschikbaarstellen van data worden uitgevoerd kunnen requirements opgesteld worden.
Deze requirements richten zich op de core elementen in het data architectuurlandschap die ervoor zorg dienen te dragen dat de eisen die vanuit het beheer perspectief dienen te worden geimplementeerd in het landschap.

Data architectuur principes zijn een belangrijk hulpmiddel voor de data architect. Hiermee heeft de data architect de mogelijkheid om kaders te stellen aan de verandering die plaatsvindt in organisaties. Zoals bij data gedreven werken initiatieven.
De data principes zijn gebaseerd (of een specialisatie van) op sectorale, organisatorische of data management principes. Daarnaast kunnen de data architectuur principes gerelateerd worden aan de doelen van de organisatie waarmee de principes een uitwerking zijn van de generieke missie en visie van de organisatie.

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.

De domein data-architectuur is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur. Het beschrijft de data gerelateerde architectuurconcepten voor de gehele organisatie en haar omgeving. De domein architectuur volgt het raamwerk dat beschreven is op basis van het raamwerk voor de beschrijvende architect. De navigatie is op deze manier uitgewerkt.
Binnen het uitwerken van de domein architectuur wordt in deze uitwerking geen rekening gehouden met een baseline en een target architectuur. Als dit relevant is kun je hiervoor in de naamgevingsconventie van de packages of de diagrammen de plateaus van de architectuur opnemen. Zie verder de voorbeelden binnen de Architectuur Repository sectie.

Dit is een weergave van alle elementen in het data architectuur model dat de uiteindelijke inrichting vormt. Zij realiseren of beinvloeden dan ook de capabilities, principes en de requirements. Met realisatie is dit positief met beinvloeden is dit negatief.

Specifieke architect verantwoordelijk voor data binnen de organisatie. Stelt data architectuur kaders op, maakt data modellen en werkt nauw samen met de andere architecten in de organisatie en de data governance groep.

Zorg dat bij een validatiestap van de data kwaliteiten in een proces dat er een feedback loop plaatsvindt naar de activiteit waar het issue ontstaan is. Houd er rekening mee dat dit ook mogelijk is naar metadata, datamodel of data architectuur activiteiten in de feedback

Zorg dat bij een validatiestap van de data kwaliteiten in een proces dat er een feedback loop plaatsvindt naar de activiteit waar het issue ontstaan is. Houd er rekening mee dat dit ook mogelijk is naar metadata, datamodel of data architectuur activiteiten in de feedback

Vanuit diverse werkvelden kunnen kaders gesteld worden aan de productie en het gebruik van data. Denk bijvoorbeeld aan data architectuur, security en privacy maar ook aan het stellen van kwaliteitseisen aan data.
Kenmerkend hierbij is, dat de kaders richting geven aan het gebruik van de data, maar ook aan andere aspecten zoals de opslag, het gebruik en incidenteel ook aan de wijze waarop de data geproduceerd wordt.
Kaders kunnen op meerdere wijzen beschreven worden bijvoorbeeld als risico, eis of beperking. In dit whitepaper sluiten we aan op de modelleerwijze van ArchiMate en werken we de kaders uit op basis van requirements en principes. Waarbij we principes beschouwen als generalisaties van de requirements.
Naast de kaders zul je binnen een metadata management model ook een uitwerking zien van de maatregelen die genomen kunnen worden om de gestelde kaders te realiseren. We zullen hierbij een aantal eenvoudige voorbeelden uitwerken in de volgende paragrafen.

Vanuit diverse werkvelden kunnen kaders gesteld worden aan de productie en het gebruik van data. Denk bijvoorbeeld aan data architectuur, security en privacy maar ook aan het stellen van kwaliteitseisen aan data.
Kenmerkend hierbij is, dat de kaders richting geven aan het gebruik van de data, maar ook aan andere aspecten zoals de opslag, het gebruik en incidenteel ook aan de wijze waarop de data geproduceerd wordt.
Kaders kunnen op meerdere wijzen beschreven worden bijvoorbeeld als risico, eis of beperking. In dit whitepaper sluiten we aan op de modelleerwijze van ArchiMate en werken we de kaders uit op basis van requirements en principes. Waarbij we principes beschouwen als generalisaties van de requirements.
Naast de kaders zul je binnen een metadata management model ook een uitwerking zien van de maatregelen die genomen kunnen worden om de gestelde kaders te realiseren. We zullen hierbij een aantal eenvoudige voorbeelden uitwerken in de volgende paragrafen.

Dit is een voorbeeld van modelleer- en naamgevingsconventies die ingezet kan worden binnen een architectuur repository. Deze uitwerking is een voorbeeld hoe je een metamodel en de conventies kunt uitwerken. In dit geval voor een data architectuur uitwerking.
Het metamodel is uitgewerkt op basis van het DMBoK raamwerk. Dit houdt in dat een deel van het raamwerk wel uitgewerkt is en de anderen nog niet. Hier is met name vanuit het gezichtspunt van de data architect een uitwerking van modelleerconventies en architecturele modellen.
Voor het werken met meta data geldt een whitepaper over de modelleerwijzen rond metadata.

Dit is de navigatie voor de domein architectuur. Op basis van het raamwerk om de beschrijvende en kaderstellende data-architectuur zijn in deze sectie links opgenomen naar de onderliggende diagrammen voor de verschillende secties in het raamwerk.

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

In de uitwerking van de beschrijvende data architectuur zul je een aantal diagrammen zien die het drielaagsdatamodel voor deze solution weergeven. Hier worden dus deelmodellen van het datamodel getoond. Vaak zal dit bestaan uit een baseline en target drielaagsmodel voor de scope van de solution.

In de uitwerking van de beschrijvende data architectuur zul je een aantal diagrammen zien die het drielaagsdatamodel voor deze solution weergeven. Hier worden dus deelmodellen van het datamodel getoond. Vaak zal dit bestaan uit een baseline en target drielaagsmodel voor de scope van de solution.

De solution architectuur is gericht op het beschrijven van de verandering die in een data gedreven organisatie wordt uitgevoerd.
In de meeste organisaties worden veranderingen met behulp van projecten en programma's geintroduceerd.
Om grip te krijgen op deze veranderingen in de organisatie zal de data-architect daarom een architecturele beschrijving gaan maken van wat deze verandering precies inhoudt. Daarnaast wordt beschreven met welke architecturele kaders deze verandering gebaseerd is.
Afhankelijk van de complexiteit van de verandering kan de data-architect ervoor kiezen om meerdere plateau architecturen uit te werken. Bijvoorbeeld de baseline en de target architectuur en desgewenst tussen architecturen.

De solution architectuur is gericht op het beschrijven van de verandering die in een data gedreven organisatie wordt uitgevoerd.
In de meeste organisaties worden veranderingen met behulp van projecten en programma's geintroduceerd.
Om grip te krijgen op deze veranderingen in de organisatie zal de data-architect daarom een architecturele beschrijving gaan maken van wat deze verandering precies inhoudt. Daarnaast wordt beschreven met welke architecturele kaders deze verandering gebaseerd is.
Afhankelijk van de complexiteit van de verandering kan de data-architect ervoor kiezen om meerdere plateau architecturen uit te werken. Bijvoorbeeld de baseline en de target architectuur en desgewenst tussen architecturen.

Beschrijving van de infrastructurele aspecten van een data gedreven en big data architectuur

Sinds medio mei 2024 is versie 17 van Sparx Enterprise Architect beschikbaar. Op dit moment van schrijven, juli 2024, nog als beta versie. In versie 17 zitten een aantal interessante uitbreidingen voor de data architect en de metadata specialist. Dit omdat er een perspectief ontwikkeld is die binnen Sparx Enterprise Architect DataWareHousing genoemd wordt. De naam is wellicht wat eigenaardig gekozen want de inhoud van het perspectief is veel breder. Het gaat namelijk ook in op allerlei zaken zoals data science, data architectuur en data governance rond bedrijfsrollen gerelateerd aan data.

Introductie van de data architectuur en doorverwijzing naar de voorbeeldmodellen die gemaakt zijn over data-architectuur.

Voorbeeld van een referentie architectuur op basis van ArchiMate en Enterprise Architect

Whitepaper met een analyse of masterdata architectuurconcepten ook ingezet kunnen worden bij metadata op basis van het DMBoK raamwerk. Masterdata patronen worden ingezet om metadata te implementeren.

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.

Fysieke datamodellen hebben tot doel om tot in detail de fysieke structuur van berichtuitwisseling tussen applicatiecomponenten of applicatieinterfaces te modelleren. Veelal wordt daarbij al rekening gehouden met de eisen, die vanuit een uitwisselprotocol of integratieplatform gesteld worden. Hiervoor worden veelal een aantal modelleertechnieken gebruikt zoals XML Schema Definition (XSD) en JSon Schema.
Schema Definition modellen geven een gedetailleerde notatiewijze voor het modelleren van berichtenverkeer. Daarnaast kun je met extra modelleertechnieken inzetten. Bijvoorbeeld OpenAPI biedt de mogelijkheid om de datastructuur te modelleren maar ook om APIs te documenteren.

Fysieke datamodellen hebben tot doel om tot in detail de fysieke structuur van een relationele database te modelleren. Veelal wordt daarbij al rekening gehouden met de eisen, die vanuit een specifiek databaseplatform gesteld worden aan de inrichting van een database. Hierdoor is het mogelijk om deze ER modellen rechtstreeks om te zetten naar een fysieke inrichting in een database. Dit staat bekend als de Data Definition Language (DDL).
Daarnaast is het mogelijk om extra fysieke modellen op te stellen voor specifieke platformen of implementaties. Denk hierbij aan berichtenuitwisseling met XML of JSON berichten of datawarehouses, die een specifiek fysiek datamodel kennen.
ER staat voor Entity-Relationship en ER diagrammen geven een gedetailleerde notatiewijze voor het modelleren van deze twee concepten. Daarnaast kun je met ER diagrammen de kolommen in een tabel modelleren en eventueel een aantal belangrijke constraints in relationele databases zoals primaire en verwijzende sleutels aangeven.

Hybride datamodel laat zien op welke wijze er een gezamenlijk model gemaakt kan worden op basis van de drie lagen in het datamodel: CDM, LDM en één of meerdere FDM.
Deze modelleertechniek biedt een overzicht van deze drie modelleertalen en de onderlinge verbanden. Deze modellen kunnen we vrij snel complex qua opzet worden.

Hybride datamodel laat zien op welke wijze er een gezamenlijk model gemaakt kan worden op basis van de drie lagen in het datamodel: CDM, LDM en één of meerdere FDM.
Deze modelleertechniek biedt een overzicht van deze drie modelleertalen en de onderlinge verbanden. Deze modellen kunnen we vrij snel complex qua opzet worden.

In dit diagram wordt de datamodelleervorm basis UML klassenmodel beschreven als modelleerwijze voor logische datamodellering. Deze modelleervorm staat in verhouding tot een aantal andere modelleervormen.

Voor het modelleren van informatie of data is het logisch datamodel. Hierbij is het van belang dat het uitgangspunt is, dat het de structuur van gegevens beschrijft. Het logisch datamodel vereist een aantal eigenschappen die ervoor zorgen dat de modellen relatief eenvoudig kunnen blijven (zeker bij basis modellen) maar toch veel zeggingskracht hebben. Dat maakt dat ze geliefd zijn in veel situaties in de informatievoorziening.

Mapping diagrammen kunnen gebruikt worden voor het inzichtelijk van de details van koppelingen. Daarbij zijn er een aantal mogelijkheden:

• In kaart brengen van de detail verbanden van het logisch model naar één van de fysieke datamodellen.


• Uitwerken van de detailverbanden bij twee of meer entiteiten binnen fysieke datamodellering. Bijvoorbeeld voor het mappen van een OLTP datamodel naar een OLAP datamodel op attribuutniveau.

Kenmerkend is dat er tussen twee entiteiten meerdere relaties gemodelleerd worden om aan te geven op welke wijze de attributen in de bronentiteit mappen naar de attributen in de doelentiteit. In een aantal gevallen is aanvullende detaillering wenselijk. Bijvoorbeeld wanneer meerdere attributen vanuit de bronentiteit gecombineerd worden naar een attribuut in de doelentiteit. Of waarbij één attribuut in de bron uitsplitst naar meerdere attributen in de doel entiteit.

Mapping diagrammen kunnen gebruikt worden voor het inzichtelijk van de details van koppelingen. Daarbij zijn er een aantal mogelijkheden:

• In kaart brengen van de detail verbanden van het logisch model naar één van de fysieke datamodellen.


• Uitwerken van de detailverbanden bij twee of meer entiteiten binnen fysieke datamodellering. Bijvoorbeeld voor het mappen van een OLTP datamodel naar een OLAP datamodel op attribuutniveau.

Kenmerkend is dat er tussen twee entiteiten meerdere relaties gemodelleerd worden om aan te geven op welke wijze de attributen in de bronentiteit mappen naar de attributen in de doelentiteit. In een aantal gevallen is aanvullende detaillering wenselijk. Bijvoorbeeld wanneer meerdere attributen vanuit de bronentiteit gecombineerd worden naar een attribuut in de doelentiteit. Of waarbij één attribuut in de bron uitsplitst naar meerdere attributen in de doel entiteit.

Data architectuur domein uitwerking gerelateerd aan de doelen, principes em de inrichting van de governance vanuit data architectuur perspectief

Metamodel voor de uitwerking van een solution architectuur gebaseerd op een aantal data specifieke viewpoints en een selectie uit de modelleervormen in UML, ER en XSD.

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.

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.

Dit is een overzicht van generieke principes die als startpunt kunnen fungeren voor een organisatie die wil starten met een kaderstellende architectuur op basis van data architectuur principes.

Deze principes zijn gebaseerd op een set van principes afkomstig uit het data architectuur model dat beschikbaar is in Sparx Enterprise Architect als voorbeeldmodel (MDG). Het is vervolgens vertaald naar de Nederlandse context.

Dit is een overzicht van een aantal algemene principes die toegepast kunnen worden binnen organisaties. Desgewenst kunnen ze specifiek gemaakt wordt met behulp van eigen specialisaties voor de eigen Albero organisatie context.

Navigatie van de kaderstellende producten die door een data architect worden ingezet voor het sturen van de verandering.

Meta data harvesting wordt gedaan als dataverwerking reeds heeft plaatsgevonden in het verleden zonder dat men toen meta data over de transformatie verzameld heeft. In die situatie dient data harvesting met terugwerkende kracht dataverwerkingsalgoritmen te ontdekken en te analyseren.

Data harvasting is vooral relevant in situaties waar het ontstaan van de huidige data architectuur evolutionair ontstaan is zonder rekening te houden met eisen en requirements die vanuit meta data management gesteld worden.
Het analyseren van de programmatuur die zorgdragen voor de data transformaties kan complex zijn. Zeker in situaties waar weinig gebruik gemaakt is van standaardisatie van transformaties, meerdere data verwerkingstools zijn gebruikt of waar de geschreven software door meerdere professionals ontwikkeld zijn, waarbij logging e.d. niet is ontwikkeld, kan meta data harvesting een uitdaging zijn.

Meta Data Harvesting is vooral relevant in de context van Business Intelligence, Master - en Referentie Data en data integratie relevant. Men dient met terugwerkende kracht meta data te verzamelen over de dataverwerking binnen deze werkvelden. In deze werkvelden zijn de kansen op succesvolle implementaties groot omdat hier de automatiseringsgraad van de dataverwerking hoog zal zijn gezien het repeterende en gestandaardiseerde karakter van de toepassingen die deze vormen van dataverwerking implementeren.

Diverse data architectuur diagrammen met daarin de solutions voor thuisbezorging en tijdregistratie.

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.

Een beschrijvende data architectuur is een belangrijk kennisgebied van data management en daarmee relevant voor data gedreven organisaties.
Ten behoeve van data-architectuur modelleren zijn er diverse data-architectuur tools beschikbaar. Denk hierbij aan Collibra, The Essential Project of Talend. Echter bij organisaties zijn vaak reeds generieke modelleringstalen en tools beschikbaar voor modelleren van software, enterprise architectuur of requirements. In dit hoofdstuk gaan we in op het inzetten van een framework voor inrichting van een generiek tool gebaseerd op een aantal open modelleertalen. De voorbeelden die we hier gebruiken zijn uitgewerkt in Sparx Enterprise Architect. Een voorbeeld van een dergelijk generiek tool.
Hieronder is daartoe een metamodel uitgewerkt voor hoe een data-architectuur gemodelleerd kan worden. De data-architectuur kent meerdere gezichtspunten om data in een organisatie te beschrijven. Zo wordt er op verschillende niveaus in een organisatie gekeken. Daarnaast kan de mate van detail vanuit verschillende gezichtspunten verschillen.
We introduceren data-architectuur modelleren op basis van een uitwerking met behulp van een aantal modelleertechnieken. De belangrijkste modelleertechnieken hier gebruikt zijn:

• ArchiMate


• Unified Modeling Language


• Entity Relationship


• XML Schema Definition

Reden om voor deze modelleertalen te kiezen is dat ze een open standaard zijn, een breed toepassingsgebied hebben, goed met elkaar te integreren zijn en reeds veel toegepast worden binnen de aanpalende domeinen van data-architectuur. Hiermee kun je in je eigen organisatie data-architectuur modelleren introduceren op een natuurlijke manier. Dat doe je door die delen relevant voor de situatie binnen de organisatie stapsgewijs te introduceren op basis van de reeds toegepaste modelleertalen.
Daarnaast worden er meerdere verschijningsvormen van de data-architectuur gebruikt. De grafenweergave en de matrix zijn in dit metamodel de meestgebruikte verschijningsvormen.
Voor het uitwerken van het metamodel worden er twee data-architectuur niveaus uitgewerkt, namelijk:

• Domein data-architectuur: dit is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur


• Solution data-architectuur: architectuur voor het beschrijven van een data gedreven verandering binnen een project of oplossing.

Beide vormen worden hieronder nader toegelicht.

In het beschrijvend model worden een aantal data modellen uitgewerkt van abstract (conceptueel model) naar technisch platform specifiek (fysiek model). Dit model is feitelijk het centrale model voor metadata waaraan de andere domeinen gekoppeld zijn.

In het beschrijvend model worden een aantal data modellen uitgewerkt van abstract (conceptueel model) naar technisch platform specifiek (fysiek model). Dit model is feitelijk het centrale model voor metadata waaraan de andere domeinen gekoppeld zijn.

Een beschrijvende data architectuur is een belangrijk kennisgebied van data management en daarmee relevant voor data gedreven organisaties.
Ten behoeve van data-architectuur modelleren zijn er diverse data-architectuur tools beschikbaar. Denk hierbij aan Collibra, The Essential Project of Talend. Echter bij organisaties zijn vaak reeds generieke modelleringstalen en tools beschikbaar voor modelleren van software, enterprise architectuur of requirements. In dit hoofdstuk gaan we in op het inzetten van een framework voor inrichting van een generiek tool gebaseerd op een aantal open modelleertalen. De voorbeelden die we hier gebruiken zijn uitgewerkt in Sparx Enterprise Architect. Een voorbeeld van een dergelijk generiek tool.
Hieronder is daartoe een metamodel uitgewerkt voor hoe een data-architectuur gemodelleerd kan worden. De data-architectuur kent meerdere gezichtspunten om data in een organisatie te beschrijven. Zo wordt er op verschillende niveaus in een organisatie gekeken. Daarnaast kan de mate van detail vanuit verschillende gezichtspunten verschillen.
We introduceren data-architectuur modelleren op basis van een uitwerking met behulp van een aantal modelleertechnieken. De belangrijkste modelleertechnieken hier gebruikt zijn:

• ArchiMate


• Unified Modeling Language


• Entity Relationship


• XML Schema Definition

Reden om voor deze modelleertalen te kiezen is dat ze een open standaard zijn, een breed toepassingsgebied hebben, goed met elkaar te integreren zijn en reeds veel toegepast worden binnen de aanpalende domeinen van data-architectuur. Hiermee kun je in je eigen organisatie data-architectuur modelleren introduceren op een natuurlijke manier. Dat doe je door die delen relevant voor de situatie binnen de organisatie stapsgewijs te introduceren op basis van de reeds toegepaste modelleertalen.
Daarnaast worden er meerdere verschijningsvormen van de data-architectuur gebruikt. De grafenweergave en de matrix zijn in dit metamodel de meestgebruikte verschijningsvormen.
Voor het uitwerken van het metamodel worden er twee data-architectuur niveaus uitgewerkt, namelijk:

• Domein data-architectuur: dit is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur


• Solution data-architectuur: architectuur voor het beschrijven van een data gedreven verandering binnen een project of oplossing.

Beide vormen worden hieronder nader toegelicht.

Data architectuur van een architectuur repository. Dit is in dit document relatief eenvoudig van opzet en omvat alleen een conceptueel datamodel. Echter in het conceptueel datamodel wordt wel een overzicht gegeven van relevante concepten binnen een architectuur repository.

Data architectuur is een van de kennisgebieden binnen het DMBoK en modellen uitwerken rond dit kennisgebied zijn kaderstellend voor veranderingen in de organisatie vanuit data management perspectief.

Data architectuur principes zijn een belangrijk hulpmiddel voor de data architect. Hiermee heeft de data architect de mogelijkheid om kaders te stellen aan de verandering die plaatsvindt in organisaties. Zoals bij data gedreven werken initiatieven.
De data principes zijn gebaseerd (of een specialisatie van) op sectorale, organisatorische of data management principes. Daarnaast kunnen de data architectuur principes gerelateerd worden aan de doelen van de organisatie waarmee de principes een uitwerking zijn van de generieke missie en visie van de organisatie.

De domein data-architectuur is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur. Het beschrijft de data gerelateerde architectuurconcepten voor de gehele organisatie en haar omgeving. De domein architectuur volgt het raamwerk dat beschreven is op basis van het raamwerk voor de beschrijvende architect. De navigatie is op deze manier uitgewerkt.
Binnen het uitwerken van de domein architectuur wordt in deze uitwerking geen rekening gehouden met een baseline en een target architectuur. Als dit relevant is kun je hiervoor in de naamgevingsconventie van de packages of de diagrammen de plateaus van de architectuur opnemen. Zie verder de voorbeelden binnen de Architectuur Repository sectie.

Vanuit diverse werkvelden kunnen kaders gesteld worden aan de productie en het gebruik van data. Denk bijvoorbeeld aan data architectuur, security en privacy maar ook aan het stellen van kwaliteitseisen aan data.
Kenmerkend hierbij is, dat de kaders richting geven aan het gebruik van de data, maar ook aan andere aspecten zoals de opslag, het gebruik en incidenteel ook aan de wijze waarop de data geproduceerd wordt.
Kaders kunnen op meerdere wijzen beschreven worden bijvoorbeeld als risico, eis of beperking. In dit whitepaper sluiten we aan op de modelleerwijze van ArchiMate en werken we de kaders uit op basis van requirements en principes. Waarbij we principes beschouwen als generalisaties van de requirements.
Naast de kaders zul je binnen een metadata management model ook een uitwerking zien van de maatregelen die genomen kunnen worden om de gestelde kaders te realiseren. We zullen hierbij een aantal eenvoudige voorbeelden uitwerken in de volgende paragrafen.

Vanuit diverse werkvelden kunnen kaders gesteld worden aan de productie en het gebruik van data. Denk bijvoorbeeld aan data architectuur, security en privacy maar ook aan het stellen van kwaliteitseisen aan data.
Kenmerkend hierbij is, dat de kaders richting geven aan het gebruik van de data, maar ook aan andere aspecten zoals de opslag, het gebruik en incidenteel ook aan de wijze waarop de data geproduceerd wordt.
Kaders kunnen op meerdere wijzen beschreven worden bijvoorbeeld als risico, eis of beperking. In dit whitepaper sluiten we aan op de modelleerwijze van ArchiMate en werken we de kaders uit op basis van requirements en principes. Waarbij we principes beschouwen als generalisaties van de requirements.
Naast de kaders zul je binnen een metadata management model ook een uitwerking zien van de maatregelen die genomen kunnen worden om de gestelde kaders te realiseren. We zullen hierbij een aantal eenvoudige voorbeelden uitwerken in de volgende paragrafen.

Dit is een voorbeeld van modelleer- en naamgevingsconventies die ingezet kan worden binnen een architectuur repository. Deze uitwerking is een voorbeeld hoe je een metamodel en de conventies kunt uitwerken. In dit geval voor een data architectuur uitwerking.
Het metamodel is uitgewerkt op basis van het DMBoK raamwerk. Dit houdt in dat een deel van het raamwerk wel uitgewerkt is en de anderen nog niet. Hier is met name vanuit het gezichtspunt van de data architect een uitwerking van modelleerconventies en architecturele modellen.
Voor het werken met meta data geldt een whitepaper over de modelleerwijzen rond metadata.

Dit is de navigatie voor de domein architectuur. Op basis van het raamwerk om de beschrijvende en kaderstellende data-architectuur zijn in deze sectie links opgenomen naar de onderliggende diagrammen voor de verschillende secties in het raamwerk.

In de uitwerking van de beschrijvende data architectuur zul je een aantal diagrammen zien die het drielaagsdatamodel voor deze solution weergeven. Hier worden dus deelmodellen van het datamodel getoond. Vaak zal dit bestaan uit een baseline en target drielaagsmodel voor de scope van de solution.

In de uitwerking van de beschrijvende data architectuur zul je een aantal diagrammen zien die het drielaagsdatamodel voor deze solution weergeven. Hier worden dus deelmodellen van het datamodel getoond. Vaak zal dit bestaan uit een baseline en target drielaagsmodel voor de scope van de solution.

De solution architectuur is gericht op het beschrijven van de verandering die in een data gedreven organisatie wordt uitgevoerd.
In de meeste organisaties worden veranderingen met behulp van projecten en programma's geintroduceerd.
Om grip te krijgen op deze veranderingen in de organisatie zal de data-architect daarom een architecturele beschrijving gaan maken van wat deze verandering precies inhoudt. Daarnaast wordt beschreven met welke architecturele kaders deze verandering gebaseerd is.
Afhankelijk van de complexiteit van de verandering kan de data-architect ervoor kiezen om meerdere plateau architecturen uit te werken. Bijvoorbeeld de baseline en de target architectuur en desgewenst tussen architecturen.

De solution architectuur is gericht op het beschrijven van de verandering die in een data gedreven organisatie wordt uitgevoerd.
In de meeste organisaties worden veranderingen met behulp van projecten en programma's geintroduceerd.
Om grip te krijgen op deze veranderingen in de organisatie zal de data-architect daarom een architecturele beschrijving gaan maken van wat deze verandering precies inhoudt. Daarnaast wordt beschreven met welke architecturele kaders deze verandering gebaseerd is.
Afhankelijk van de complexiteit van de verandering kan de data-architect ervoor kiezen om meerdere plateau architecturen uit te werken. Bijvoorbeeld de baseline en de target architectuur en desgewenst tussen architecturen.

Beschrijving van de infrastructurele aspecten van een data gedreven en big data architectuur