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.

Wat zijn de relevante applicatiefuncties ter ondersteuning van de benoemde werkprocessen. Deze kunnen vervolgens gekoppeld worden aan modulen in het architectuurtool of aan requirements (bij een selectie traject).

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.

Generieke en specifieke requirements bij inzet van een architectuur repository in de organisatie.

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.

The Big Data pipeline compound pattern generally comprises multiple stages whose objectives are to divide complex processing operations into down into modular steps for easier understanding and debugging and to be amenable to future data processing requirements.

The Big Data Processing Environment represents an environment capable of handling the range of distinct requirements of large-scale dataset processing.

BIV is een beveiligingscategorie voor drie IB gebieden. Zie de uitgewerkte boomstructuur

Statement Een collectie van logisch gerelateerde bouwblokken van dezelfde specialisatie (service, ABB of SBB). Omschrijving Een catalogus is een collectie of register van bouwblokken van eenzelfde type. Het is veelal gericht op een specifiek werkveld, denk hierbij bijvoorbeeld aan infrastructuur, geo, integratie. Binnen een catalogus zitten veelal bouwblokken van dezelfde specialisatie dus services, architectuur - of solution bouwblokken. Echter de bouwblokken hierbinnen zullen veelal eveneens samengesteld zijn. Een catalogus kan gezien worden als een etalage van generieke en herbruikbare architecturele producten. Wanneer deze bouwblokken door een project worden ingezet wordt voldaan aan een aantal architecturele eisen, principes en requirements. Voordeel voor architectuur is dat deze bouwblokken worden hergebruikt. Voordeel vanuit projectperspectief is dat er voldaan wordt aan de architecturele principes en dat implementatie gestandaardiseerd wordt en waarschijnlijk sneller kan. Vanuit veranderingen in de omgeving (projecten, LCM, innovaties) zal de inhoud van een catalogus regelmatig worden aangepast, uitgebreid of meer gedetailleerd worden uitgewerkt. Een catalogus en de daarin opgenomen entiteiten wordt daarmee een "levend" ecosysteem. In eerste instantie wordt gewerkt met een aanbod gestuurd catalogus model. Met andere worden. Iedere domein architect maakt voor zijn domein een bouwblokken catalogus. In een later stadium wordt dit aangepast naar een vraaggerichte uitwerking, het zogenaamde etalagemodel. Kenmerken

• Collectie van bouwblokken.
• Bouwblokken van hetzelfde (architectuur) concept kunnen opgenomen worden in een catalogus.
• Catalogi worden gecategoriseerd op basis van een scope. (bijvoorbeeld, infrastructuur, integratie, geo).
• Catalogi binnen een scope hebben een eigenaar.
• Catalogi worden beschreven in een register (beheerd in Sparx Enterprise Architect en gepubliceerd naar HTML en PDF documenten)
• Catalogi zijn veelal hiërarchisch cq gelaagd van opzet. Enerzijds door de indeling in Service, ABB en SBB, anderzijds door de opzet met samengestelde bouwblokken.

In dit onderdeel wordt een logisch model beschreven van de boom- en een netwerk of graafstructuur. Daarbij worden een aantal requirements uitgewerkt op basis waarvan een keuze voor een fysieke implementatie gemaakt kan worden

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.

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.

Dit kennisgebied richt zich op het zorgdragen van data data wanneer gewenst beveiligd wordt opgeslagen, verwerkt en gebruikt. Hierbinnen zijn drie dimensies relevant die vanuit data beveiliging in de vorm van BIV wordt uitgewerkt. Daarnaast is data privacy onderdeel van deze requirements.

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.

Datakwaliteit conform kwaliteitsdimensies in het raamwerk van DMBoK. Datakwaliteit conform het raamwerk van DMBoK

Datakwaliteit conform het raamwerk van DMBoK

Datakwaliteit dimensie conform het raamwerk van DMBoK.

Datakwaliteit conform kwaliteitsdimensies in het raamwerk van DMBoK.

Data modelleren is een van de kennisgebieden binnen het DMBoK en modellen uitwerken rond dit kennisgebied beschrijft de data requirements vanuit de organisatie en ondersteunt daarmee de data management functie.

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.

Bepalen van de gegevensbehoefte binnen de verschillende activiteiten van werkprocessen en het vergelijken van deze behoefte met de reeds aanwezige gegevensverzamelingen.

Bepalen van de gegevensbehoefte binnen de verschillende activiteiten van werkprocessen en het vergelijken van deze behoefte met de reeds aanwezige gegevensverzamelingen.

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.

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.

Eisen zijn de beschrijvende kenmerken die vanuit de aanbieder in het bouwblok worden geleverd of door de aanbieder worden gevraagd. Denk hierbij aan:

• Requirements.
• Principes.
• Constraints.
• Functionele kwaliteiten.
• Non functionele kwaliteiten.

Dit is de vastgestelde architectuur van organisatie. Het omvat veelal de uitwerking van de baseline architectuur en soms ook van de target architectuur. Belangrijk is dat de indeling gebaseerd dient te zijn op een raadpleeg functie. Architecten gebruiken dit als een register van de architectuur bij inventarisaties van requirements maar ook voor het raadplegen van de architectuur landschappen en de kaders binnen de architectuur.

Gebruiksorganisatie geeft aan welke requirements, wensen en beperkingen er zijn rond de binnen de architectuur te ontwikkelen artefacten en daaruit voortvloeiende implementaties naar de target architectuur.

Deze requirement geeft aan dat privacy gevoelige data alleen beschikbaar mag zijn in het productionele deel van het Data omgeving landschap

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.

Met name op het vlad van de technische infrastructuur zullen architectuur elementen de requirements rond data operation realiseren. Denk hierbij aan zaken zoals systeem software voor backup en restore, uitwijk, performance en andere kwaliteitsdimensies voor data binnen de organisatie.

Houdt bij de initiële inrichting van een omgeving rekening met de precisie requirements van (toekomstige) afnemers. Zeker bij opslag van registerdata dient door de eigenaar geïnventariseerd te worden wat de precisiebehoefte van de afnemers is. Richtlijnen opstellen omtrent inrichting van gegevensbestanden, applicatie componenten en elementen binnen de presentatielaag op het vlak van precisie.

Houdt bij de initiële inrichting van een omgeving rekening met de precisie requirements van (toekomstige) afnemers. Zeker bij opslag van registerdata dient door de eigenaar geïnventariseerd te worden wat de precisiebehoefte van de afnemers is. Richtlijnen opstellen omtrent inrichting van gegevensbestanden, applicatie componenten en elementen binnen de presentatielaag op het vlak van precisie.

Ontwikkelen en beheer van een kaders en richtlijnenregister zoals een lijst van data principes, standaarden en eventueel data requirements gerelateerd aan de enterprise principes.

Ontwikkelen en beheer van een kaders en richtlijnen register zoals een lijst van data principes, standaarden en eventueel data requirements gerelateerd aan de enterprise principes.

Ontwikkelen en beheer van een kaders en richtlijnenregister zoals een lijst van data principes, standaarden en eventueel data requirements gerelateerd aan de enterprise principes.

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.

Voor de functionaliteiten in een architectuur repository kunnen gestandaardiseerde non functionele requirements, kwaliteiten genaamd, uitgewerkt worden.

Voorbeeld van een logisch architectuur model voor een register of MDM module. Geeft een voorbeeld van hoe je applicatie functies, interfaces en services in ArchiMate kunt combineren om een beschrijving te geven van de gewenste requirements. Als je een architectuur repository vanuit het perspectief van master data beschouwd dan kun je feitelijk een aantal bouwblokken inzetten om functionaliteiten, applicatie services en -interfaces op generieke wijze beschrijven.

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.

• Maak waar mogelijk gebruiik van ArchiMate concepten Kwaliteitsmodel is uitgewerkt op basis van Enterprise Architectuur modellering.
• Hergebruik de ArchiMate concepten die worden uitgewerkt in andere modellen Uitbreiding van het reeds aanwezige enterprise architectuur model door hergebruik van de concepten.
• Leg verbinding vanuit het conceptuele datamodel (ArchiMate Business Object) naar de kwaliteitsdimensies (ArchiMate Requirement) Verbinding op basis van een ArchiMate associatie.
• Issues worden uitgewerkt in generieke elementen Voor issues wordt gebruik gemaakt van een niet ArchiMate element.
• Issues worden opgelost met behulp van kwaliteitsmaatregelen (Deliverables) Deliverables worden gebruikt om aan te geven dat het issue wordt opgelost. Desgewenst kan een deliverable ook een Enterprise Architectuur model voor een bouwblok of patroon realiseren.
• Indien nodig worden maatregelen gecombineerd in een datakwaliteitsrelease Complexe maatregelen met een grote impact op het data landschappen kunnen gecombineerd worden in een release en als een project worden uitgevoerd.
• Van de associatie tussen kwaliteit en data entiteit kan een score worden gegeven tussen 0 en 9 De associatie tussen maatregel en CDM kan worden gelabeld met een score van 0 - 9 voor de baseline en de target van de kwaliteitsdimensies.
• Score kan gemaakt worden van de baseline en de target van de kwaliteitsniveaus Hiervoor kan een matrix weergave worden gebruikt. Desgewenst kun je baseline en target in één matrix weergave combineren.

Beschrijving van de doelen en drivers van de organisatie. Desgewenst uitgebreid met een model van principes en/of requirements.

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.

Bij registerfunctie van de benoemde gegevensopslag dient bij afwijking van de standaard precisie deze beschreven te zijn in de (interface) documentatie zodat toekomstige afnemers het kwaliteitsniveau kunnen toetsen aan de eigen behoefte.

Bij registerfunctie van de benoemde gegevensopslag dient bij afwijking van de standaard precisie deze beschreven te zijn in de (interface) documentatie zodat toekomstige afnemers het kwaliteitsniveau kunnen toetsen aan de eigen behoefte.

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.

Bij de keuze van het opslagplatform wordt rekening gehouden met de eisen die vanuit informatiebeveiliging gesteld worden denk bijvoorbeeld aan zaken als autorisatie, identificatie en authenticatie, encryptie en beschikbaarheid. De requirements worden getoetst op basis een data classificatie van de gegevens (zie de beheerprocessen).

Bij de keuze van het opslagplatform wordt rekening gehouden met de eisen die vanuit informatiebeveiliging gesteld worden denk bijvoorbeeld aan zaken als autorisatie, identificatie en authenticatie, encryptie en beschikbaarheid. De requirements worden getoetst op basis een data classificatie van de gegevens (zie de beheerprocessen).

Leg verbanden tussen requirements en doelen.

Naamgevingsconventies Gebruik: Korte titel Code in attribuut Alias Bijvoorbeeld: 24/7 beschikbaar.

Functionele en non functionele requirements

Selectieproces integratievorm, bij het uitwerken van de integratievormen kan beschreven worden wat de effecten zijn van een specifieke integratievorm op het vlak van precisie. Vervolgens kan dit vertaald worden in beslisbomen en –documenten rond het selecteren van integratievormen binnen een project.

Selectieproces integratievorm, bij het uitwerken van de integratievormen kan beschreven worden wat de effecten zijn van een specifieke integratievorm op het vlak van precisie. Vervolgens kan dit vertaald worden in beslisbomen en –documenten rond het selecteren van integratievormen binnen een project.

Requirements engineering (RE) is een raamwerk van activiteiten die worden toegepast bij het definiëren van vereisten en omvat een scala aan elicitatie-, analyse- en modelleringsvaardigheden. Requirements vormen de basis van waaruit bedrijfs- en IT- oplossingen worden ontworpen en ontwikkeld, dus dit is een belangrijk competentiegebied voor data-architecten.

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.

Statement Services zijn de beschrijving van een combinatie van functionaliteiten en diensten tussen aanbieder(s) en afnemer(s). Omschrijving Services zijn een vorm van inkapseling van de functionaliteit en implementatie van een samenstelling van bouwblokken. Services worden, net als ABB en SBB, gebruikt als communicatiemiddel om tussen aanbieder en afnemer aan te geven welke dienst door de aanbieder aan de afnemer geleverd gaat worden. Services kunnen ook intern binnen de organisatie gedefinieerd zijn (ook in aanbieder en afnemer verband), bijvoorbeeld infrastructurele services voor een applicatieve service of afnemer. Een service kan een samenstelling zijn van een bouwblok dat functionaliteit implementeert binnen het ICT landschap. Daarnaast kan een service bestaan uit het leveren van een meer ingerichte (ICT) werkprocessen in relatie met de bovengenoemde ICT landschappen, bijvoorbeeld een servicedesk. In dit document hebben we de scope beperkt gehouden tot die van de ICT architectuur, ICT werkprocessen worden hier niet uitgewerkt maar zijn binnen andere delen van de organisatie zeker relevant (service management). Dit bouwblokken model kan desgewenst op meerdere manieren toegepast worden en niet alleen in het ICT werkveld. Hier beperken we ons tot ICT architectuur. Services kunnen samengesteld zijn uit onderliggende services. Daarnaast kunnen zij opgebouwd zijn uit een of meerdere architectuur bouwblokken. Door deze samenstellingen kunnen constellaties ontstaan van bouwblokken die zorgdragen voor standaardisatie van herbruikbare toegepaste services. Denk hierbij aan een standaard ingerichte applicatieserver met services (zoals back-up en restore) en ABB (bijvoorbeeld relationele opslag) Services zijn gerelateerd aan requirements, constraints en principes. Dit is bij voorkeur uitgewerkt om aan te geven aan welke behoeften vanuit afnemersperspectief een invulling wordt gegeven en aan welke niet. Rond de term service bestaat veel verwarring. Om te voorkomen dat bij iedere samenstelling van personen een discussie over de definitie ontstaat wordt gekozen voor de term service welke gebaseerd is op onderstaande kenmerken. Daarnaast is er een lijst van synoniemen geformuleerd die verwijzen naar dezelfde onderstaande kenmerken. Kenmerken

• Een herhaalbare activiteit of gedrag die wordt gevraagd te worden uitgevoerd.
• Een service biedt een of meerdere voor de afnemer begrijpelijke invulling van ICT behoeften.
• Combinatie van een implementatie van een functionaliteit in een of meerdere ABBs.
• Eventueel in combinatie met een of meer ICT werkprocessen als service.
• Services worden aangeboden aan afnemers vanuit aanbieders.
• Services hebben een commercieel en een financieel (kosten) aspect.
• Services kennen voorwaarden voor gebruik cq implementatie.

Beschrijf bij een software selectie traject eventuele precisie aspecten op basis van requirements. Zoals precisie aspecten meenemen in het ontwerpproces van nieuwe applicaties e.d.

Beschrijf bij een software selectie traject eventuele precisie aspecten op basis van requirements. Zoals precisie aspecten meenemen in het ontwerpproces van nieuwe applicaties e.d.

Een solution bouwblok (SBB) is de fysieke implementatie van een functionaliteit uitgewerkt in één of meerdere ABB. Voor een solution bouwblok wordt de afkorting SBB gebruikt. Een SBB beschrijft de implementatie waarmee een functionaliteit gerealiseerd wordt. Een SBB biedt deze implementatie aan een hoger liggende entiteit. In ons model is een SBB implementatie van ABB of van een samengestelde SBB. Hierbij is het relevant dat er een onderscheid gemaakt wordt in architecturele lagen. Voor ons zijn de infrastructurele- en de applicatie laag het belangrijkste toepassingsgebied. Een SBB op applicatieniveau kan hiermee een samenstelling zijn van SBBs op zowel de applicatie- als de infrastructurele laag. SBB zijn gerelateerd aan kwaliteiten, constraints en principes. Dit is bij voorkeur uitgewerkt om aan te geven aan welke vereisten vanuit implementatie perspectief een invulling wordt gegeven en aan welke niet. Dit in combinatie met het model van kwaliteiten binnen de ABB en de requirements zoals op serviceniveau zijn uitgewerkt biedt een complete beschrijving van de kenmerken die door een service worden aangeboden.

Statement Een solution bouwblok is de fysieke implementatie van een functionaliteit uitgewerkt in één of meerdere ABB. Omschrijving Voor een solution bouwblok wordt de afkorting SBB gebruikt. Een SBB beschrijft de implementatie waarmee een functionaliteit gerealiseerd wordt. Een SBB biedt deze implementatie aan een hoger liggende entiteit. In ons model is een SBB implementatie van ABB of van een samengestelde SBB. Hierbij is het relevant dat er een onderscheid gemaakt wordt in architecturele lagen. Voor ons zijn de infrastructurele- en de applicatie laag het belangrijkste toepassingsgebied. Een SBB op applicatieniveau kan hiermee een samenstelling zijn van SBBs op zowel de applicatie- als de infrastructurele laag. SBB zijn gerelateerd aan kwaliteiten, constraints en principes. Dit is bij voorkeur uitgewerkt om aan te geven aan welke vereisten vanuit implementatie perspectief een invulling wordt gegeven en aan welke niet. Dit in combinatie met het model van kwaliteiten binnen de ABB en de requirements zoals op serviceniveau zijn uitgewerkt biedt een complete beschrijving van de kenmerken die door een service worden aangeboden. Kenmerken

• SBB is een fysieke implementatie van een (deel van) of meerdere ABBs cq functies.
• Technische en productspecificatie zijn bekend.
• Merk- en leveranciersnamen zijn bekend.
• Een SBB is veelal vervangbaar door een ander product of implementatie.

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

Infrastructurele inrichting heeft een nauwe relatie met tijdigheid. Beschreven dient te zijn welke eisen op het vlak van tijdigheid en op welke wijze dat met de juiste infrastructurele componenten gerealiseerd kan worden. Hierbij kunnen ook infrastructurele componenten noodzakelijk zijn die in de huidige inrichting nog niet aanwezig zijn. Vanuit architectuur dient dit voldoende bewaakt te worden in samenspraak met de beheerorganisatie. Optimalisatie van de applicatie infrastructuur. De applicatie infrastructuur kan een grote bijdrage leveren aan de tijdigheid. Denk bijvoorbeeld aan het kiezen van virtuele werkomgevingen die ingezet worden voor bewerkingen die hoge eisen stellen aan de onderliggende infrastructuur terwijl de schermwijzigingen beperkt zijn en daarom via (tragere) netwerkvoorzieningen kunnen verwerkt. Inzetten van elasticiteitshulpmiddelen. Tijdigheid kan negatief beïnvloed worden op momenten dat er veel vraag is naar een bepaalde voorziening. Inzet van elasticiteit bijvoorbeeld cloud technologie, kan bijdragen aan een verbeterde tijdigheid.

Infrastructurele inrichting heeft een nauwe relatie met tijdigheid. Beschreven dient te zijn welke eisen op het vlak van tijdigheid en op welke wijze dat met de juiste infrastructurele componenten gerealiseerd kan worden. Hierbij kunnen ook infrastructurele componenten noodzakelijk zijn die in de huidige inrichting nog niet aanwezig zijn. Vanuit architectuur dient dit voldoende bewaakt te worden in samenspraak met de beheerorganisatie. Optimalisatie van de applicatie infrastructuur. De applicatie infrastructuur kan een grote bijdrage leveren aan de tijdigheid. Denk bijvoorbeeld aan het kiezen van virtuele werkomgevingen die ingezet worden voor bewerkingen die hoge eisen stellen aan de onderliggende infrastructuur terwijl de schermwijzigingen beperkt zijn en daarom via (tragere) netwerkvoorzieningen kunnen verwerkt. Inzetten van elasticiteitshulpmiddelen. Tijdigheid kan negatief beïnvloed worden op momenten dat er veel vraag is naar een bepaalde voorziening. Inzet van elasticiteit bijvoorbeeld cloud technologie, kan bijdragen aan een verbeterde tijdigheid.

Een lijst van voorstellen, in de vorm van requirements en eisen ten behoeve van de op te stellen architectuur. Maar ook voor het metamodel of de modelleerconventies van de uit te werken architecturen.

Vanuit het beleid zoals opgesteld door de data governance betrokkenen wordt een algemeen beleid beschreven meestal op basis van principes om kaders te stellen aan veranderringen in combinatie met requirements voor specifieke architecturele oplossingen.

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.

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.

Score matrix is een datamodellering notatie waarmee een score, bijvoorbeeld van 0 - 10 worden gecombineerd met Data entiteiten en eisen, requirements of kwaliteiten. De notatie wordt toegepast op met name de conceptuele datamodellering. Naast toepassingen in de datamodellering wordt de score matrix met name gebruikt binnen data management, data kwaliteiten, data security en data privacy. Hierbij gaat het veelal om twee perspectieven, bijvoorbeeld de huidige en de gewenste situatie.

Beschrijving van tools en requirements voor service repositories

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

Voorbeeld van een BIV Matrix op basis van conceptuele data entiteiten in relatie tot de requirements Beschikbaarheid, Integriteit en Vertrouwelijkheid (BIV). Bij de relaties tussen deze entiteiten kan een score worden gegeven op een 123 schaal. Waarbij 1 een laag risico is en 3 hoog.

Eenvoudige uitwerking van de Google cloud diensten ter ondersteuning van de verschillende applicatie functies ook hier geldt weerdat een analyse van de requirements en de functionaliteiten binnen de services de geschiktheid bepaald moet worden

Sharepoint en office 365 bieden een palet aan functies die inzetbaar zijn bij de ondersteuning van een expertise netwerk. Daarbij is het mooi om te zien dat er voor elke logische functie een component lijkt te zijn die inzetbaar is. Een andere analyse van de functionele requirements en een mapping naar de componenten is vanzelfsprekend gewenst.

Bij het ontwikkelen en beheren van de architectuur in de modellen en documenten is het consistent houden van de repository een uitdaging binnen een repository. Bij een document gedreven aanpak is het consistent houden feitelijk onmogelijk. Bij het werken met een architectuur repository en de inzet van tooling ontstaan er mogelijkheden om, met name iteratieve, taken te automatiseren of grotendeels te ondersteunen. Hierbij zijn voor architectuurteams belangrijke voordelen te behalen. Het is dan ook aan te bevelen dat goed wordt nagedacht welke activiteiten geautomatiseerd kunnen worden en welke requirements er zijn bij het modelleerteam.

Modelleren van data security en privacy is gebaseerd op een hiërarchie van maatregelen. Wat het niveau is van deze maatregelen kan gemodelleerd worden met een score matrix. Dit is een bijzondere vorm van data modelleren, omdat het zowel voor de vraag- als aanbodkant van datasets gebruikt kan worden. Het doel is om de beveiligingsmaatregelen (gemodelleerd als requirements) in relatie te brengen met data entiteiten en vervolgens een numerieke- of ordinale waarden worden toegekend. Voor security wordt vaak een BIV classificatie gebruikt. BIV staat voor Beschikbaarheid, Integriteit en Vertrouwelijkheid. Dit kan uitgebreid worden met een privacy classificatie, waarmee een BIVP classificatie ontstaat. Dit zijn feitelijk bijzondere data kwaliteiten en deze kunnen op soortgelijke wijze gemodelleerd worden.

Modelleren van data security en privacy is gebaseerd op een hiërarchie van maatregelen. Wat het niveau is van deze maatregelen kan gemodelleerd worden met een score matrix. Dit is een bijzondere vorm van data modelleren, omdat het zowel voor de vraag- als aanbodkant van datasets gebruikt kan worden. Het doel is om de beveiligingsmaatregelen (gemodelleerd als requirements) in relatie te brengen met data entiteiten en vervolgens een numerieke- of ordinale waarden worden toegekend. Voor security wordt vaak een BIV classificatie gebruikt. BIV staat voor Beschikbaarheid, Integriteit en Vertrouwelijkheid. Dit kan uitgebreid worden met een privacy classificatie, waarmee een BIVP classificatie ontstaat. Dit zijn feitelijk bijzondere data kwaliteiten en deze kunnen op soortgelijke wijze gemodelleerd worden.

Modelleren van data kwaliteiten kan met een score matrix. Dit is een bijzondere vorm van data modelleren, omdat het zowel voor de vraag- als aanbodkant van datasets gebruikt kan worden. Het doel is om kwaliteiten (gemodelleerd als requirements) in relatie te brengen met data entiteiten en daar vervolgens numerieke- of ordinale waarden aan toe te kennen. Score matrices zijn voor verschillende doeleinden te gebruiken, waarbij opvallend is, dat dit zowel in de ontwikkelfase als in de beheerfase hulp biedt, hierbij komt wederom zowel de vraag- als aanbodzijde aan bod.

Modelleren van data kwaliteiten kan met een score matrix. Dit is een bijzondere vorm van data modelleren, omdat het zowel voor de vraag- als aanbodkant van datasets gebruikt kan worden. Het doel is om kwaliteiten (gemodelleerd als requirements) in relatie te brengen met data entiteiten en daar vervolgens numerieke- of ordinale waarden aan toe te kennen. Score matrices zijn voor verschillende doeleinden te gebruiken, waarbij opvallend is, dat dit zowel in de ontwikkelfase als in de beheerfase hulp biedt, hierbij komt wederom zowel de vraag- als aanbodzijde aan bod.

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.

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.

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.

Doel: Inzicht te geven in de betrokkenen en de motivation elementen gerelateerd aan core) elementen om uiteindelijk het bestaansrecht van deze elementen te herleiden. Daarnaast biedt het inzicht in welke oplossingen requirements worden gebruikt. Deze wordt gebruikt bij minder omvangrijke trajecten. Bij omvangrijke trajecten maak bij voorkeur gebruik van de meer gedetailleerde motivation viewpoints. Niet verplicht Gebruik hiervoor de motivation elementen van Archimate. Daar is het requirement element opgenomen. Dit kan eventueel aangevuld worden met constraints. Daarnaast kan, als dat wenselijk is, de volledige motivatie in principes, drivers etc. uitgewerkt worden.

Doel: Inzicht te geven in de requirements gerelateerd aan elementen om uiteindelijk het bestaansrecht van deze elementen te herleiden. Daarnaast biedt het inzicht in welke oplossingen dezelfde requirements invullen. Niet verplicht Gebruik hiervoor de motivation elementen van Archimate. Daar is het requirement element opgenomen. Dit kan eventueel aangevuld worden met constraints. Daarnaast kan, als dat wenselijk is, de volledige motivatie in principes, drivers etc. uitgewerkt worden.

Doel: Inzicht te geven in de principes gerelateerd aan elementen om uiteindelijk het bestaansrecht van deze elementen te herleiden. Daarnaast biedt het inzicht in welke oplossingen dezelfde principes invullen. Niet verplicht Gebruik hiervoor de motivation elementen van Archimate. Daar is het principe element opgenomen. Dit kan eventueel aangevuld worden met requirements/ constraints om de implicaties aan te geven. Het principe kan worden gekoppeld aan een Outcome, waarbij de rationale in de associatie van principe naar Outcome wordt beschreven. Daarnaast kan, als dat wenselijk is, de volledige motivatie in principes, drivers etc. uitgewerkt worden.

Dit is een lijst van veelkomende requirements voor een architectuur repository. Zijn er organisatie specifieke requirements, voeg deze dan toe aan dit model. Zijn er requirements in dit overzicht die niet relevant zijn voor de organisatie verwijder die dan van dit diagram.

Uitwerking van de hierarchie van de verschillende requirements in gebruik binnen het metamodel

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.

Belangrijke extra dimensie bij het beschrijven van de xBB zijn de kenmerken die bij de communicatie tussen aanbieder van het xBB en de afnemer relevant zijn. Deze extra dimensie richt zich met name op de kenmerken waaraan een xBB wel of niet voldoet. Dit kunnen beperkingen, regels of principes zijn. In het viewpoint worden een drietal ArchiMate concepten gebruikt uit de motivation extensie:

• Principe, veelal afkomstig van de landelijke overheidsreferentie architecturen.
• Requirements, eisen en (non functionele) kwaliteitsaspecten.
• Beperkingen, zijn vereisten welke meestal gelden voor de SBB, bijvoorbeeld gericht op bepaalde programmeerparadigma's of talen.

Voor de associaties tussen de motivation elementen en de andere elementen kan gebruikt gemaakt worden van de associatie, influence en realisation. Hierbij kun je met realisatie een positieve relatie leggen tussen de core elementen en de motivation elementen. Influence is dan voorbehouden voor een negatieve invloed vanuit de core elementen naar de motivatie elementen. In dit model is alleen een uitwerking gemaakt van het bouwblokken viewpoint binnen de applicatie laag. Vanzelfsprekend geldt hetzelfde als hierboven beschreven voor de viewpoint op de technische laag.

Hieronder een overzicht van een aantal generieke concerns gemodelleerd in een ArchiMate motivation diagram met een lijst van requirements.

Dit voorbeeld laat op eenvoudige wijze zien hoe de kenmerken/eisen op basis van requirements, constraints, kwaliteiten en principes inzichtelijk gemaakt kunnen worden. In dit voorbeeld is te zien hoe de kenmerken van de verschillende xBB op basis van ArchiMate concepten in kaart gebracht kunnen worden. Dit wordt straks een belangrijk mechanisme in de verschillende xBB catalogi. Naast deze aanpak kunnen de kenmerken ook uitgewerkt worden via de interne kenmerken van de entiteiten in EA. Zoals requirements, constraint en scenario. Als laatste is er de mogelijkheid om tagged values te gebruiken. In de werkgroep is bepaald dat hierbij het leggen van associaties tussen ArchiMate concepten de voorkeur verdiend. Is een uitwerking met ArchiMate concepten onvoldoende en wil men uitwijken naar interne eigenschappen of tagged values dan dient dit kortgesloten te worden

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 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 dit onderdeel wordt een logisch model beschreven van de boom- en een netwerk of graafstructuur. Daarbij worden een aantal requirements uitgewerkt op basis waarvan een keuze voor een fysieke implementatie gemaakt kan worden

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 modelleren is een van de kennisgebieden binnen het DMBoK en modellen uitwerken rond dit kennisgebied beschrijft de data requirements vanuit de organisatie en ondersteunt daarmee de data management functie.

Dit is de vastgestelde architectuur van organisatie. Het omvat veelal de uitwerking van de baseline architectuur en soms ook van de target architectuur. Belangrijk is dat de indeling gebaseerd dient te zijn op een raadpleeg functie. Architecten gebruiken dit als een register van de architectuur bij inventarisaties van requirements maar ook voor het raadplegen van de architectuur landschappen en de kaders binnen de architectuur.

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.

Voorbeeld van een logisch architectuur model voor een register of MDM module. Geeft een voorbeeld van hoe je applicatie functies, interfaces en services in ArchiMate kunt combineren om een beschrijving te geven van de gewenste requirements. Als je een architectuur repository vanuit het perspectief van master data beschouwd dan kun je feitelijk een aantal bouwblokken inzetten om functionaliteiten, applicatie services en -interfaces op generieke wijze beschrijven.

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.