Services voor algemene datasets binnen Data omgeving zoals ontsloten herbruikbare laag gestructureerde data en reference data entiteiten met de daarbij behorende logische applicatie functies

Verwijst naar het vermogen van een datasysteem of architectuur om effectief te reageren op veranderingen in bedrijfsprocessen, vereisten, databronnen en technologische omgevingen. Door de flexibiliteit kan een systeem variaties in dataformaten, datamodellen en datastructuren ondersteunen.

Verwijst naar het vermogen van een datasysteem of architectuur om effectief te reageren op veranderingen in bedrijfsprocessen, vereisten, databronnen en technologische omgevingen. Door de flexibiliteit kan een systeem variaties in dataformaten, datamodel.

Aanwijzen van unieke bronnen, hiermee wordt bereikt dat de consistent groter wordt omdat deze unieke bron het aantal replica’s en schaduw registraties terugdringt. De data-integratie is vervolgens gebaseerd op het ontsluiten van deze unieke bron.

Aanwijzen van unieke bronnen, hiermee wordt bereikt dat de consistent groter wordt omdat deze unieke bron het aantal replica’s en schaduw registraties terugdringt. De data-integratie is vervolgens gebaseerd op het ontsluiten van deze unieke bron.

Abstracte Logische data entiteit is een hiërarchische indeling van de logische data entiteiten. Met behulp van specialisatie worden de kenmerken van een abstracte logische data entiteit overgedragen naar een concrete data entiteit. Dus attribuut 1-3 is ook attribuut van de concrete logische data entiteit. Er kunnen meerdere hiërarchieën ontstaan op basis van meerdere specialisatie connecties tussen data entiteiten.

Abstracte Logische data entiteit is een hiërarchische indeling van de logische data entiteiten. Met behulp van specialisatie worden de kenmerken van een abstracte logische data entiteit overgedragen naar een concrete data entiteit. Dus attribuut1-3 is ook attribuut van de concrete logische data entiteit. Er kunnen meerdere hiërarchieën ontstaan op basis van meerdere specialisatie connecties tussen data entiteiten.

Abstracte Logische data entiteit is een hiërarchische indeling van de logische data entiteiten. Met behulp van specialisatie worden de kenmerken van een abstracte logische data entiteit overgedragen naar een concrete data entiteit. Dus attribuut 1-3 is ook attribuut van de concrete logische data entiteit. Er kunnen meerdere hiërarchieën ontstaan op basis van meerdere specialisatie connecties tussen data entiteiten.

Accountancy voert financiële activiteiten met name gericht op het correct registreren en controleren van de financiële registratie. Daarmee een nauwe relatie met data-architectuur aangezien veel van de financiële transacties en controles ingebed dienen te zijn in de inrichting van het datalandschap.

Dit is een voorbeeld case waarin we data modellen uitwerken voor Alberto een keten van Italiaanse ijssalons. Op basis van deze uitwerking krijg je een overzicht van de modelleermethoden zoals die toegelicht worden in het boek "Grip op data modelleren. Daarbij zijn in de uitwerking de modellen onderling aan elkaar gerelateerd. Er zijn op basis van drie domeinen in de Alberto case domeinmodellen uitgewerkt:

• Vestiging, registratie van de vestiging gegevens.
• Tijdregistratratie, tijjdschrijven door medewerkers en accordering door vestigingsmanagers
• Thuisbezorging, data benodigd voor het bezorgen van ijs- en koffie producten op locaties van klanten.

De uitwerking is gebaseerd op een aantal deelgebieden rond modelleren en deze deelgebieden zijn gebaseerd op het DM-BoK raamwerk. Hierbij zijn de belangrijkste domeinen uitgewerkt vanuit het perspectief van data modelleren.

Dit is een logische dienst voor de publicatie van een bepaalde gestandaardiseerde dataset. In de huidige implementatie van TDP is plateau 1 een lijst met verschillen. Deze logische dataservice wordt geïmplementeerd in een of meerdere technische interfaces zoals gebruikersinterfaces of XML-webservices

Op basis van de business case kan er een inschatting gemaakt worden van de data behoefte. Dat wordt veelal gedaan door een eenvoudig datamodel op te stellen van de databehoefte voor de business case. Bijvoorbeeld een combinatie van een conceptueel en logisch datamodel van de databehoefte

Logische servicelaag voor de blootstelling van de gegevens die worden gepubliceerd vanuit de integratielaagsystemen aan het gegevensgebruik in rapportage en analyse enz

De applicatie architect richt zich op het uitwerken van een of meerdere applicaties in het informatiesysteem landschap. Binnen de applicaties wordt data verwerkt en opgeslagen en gebruikt in registratie. Daarom dienen data- en applicatie-architecten nauw samen te werken en gezamenlijk kaders te stellen aan de verandering in de enterprise in scope.

Applicatie integratie interfaces voor machine 2 machine integratie

Applicatie integratie interfaces voor machine 2 machine integratie

Statement Een architectuur bouwblok is de logische definitie van een functionaliteit Omschrijving Voor een architectuur bouwblok wordt de afkorting ABB gebruikt. Een architectuur bouwblok beschrijft de functionaliteiten die aangeboden worden aan een hoger liggende entiteit. Een ABB beschrijft WAT er nodig is, zonder te schrijven naar een specifieke oplossing. De hoger liggende entiteit kan een service of een samengestelde ABB zijn. Een ABB kan samengesteld zijn uit één of meerdere SBB. Deze SBB zijn de implementatie van de functionaliteit. Met andere woorden de SBB realiseert de ABB. Kenmerken

• Beschrijving van een functionaliteit
• Beschrijving van het gedrag van informatievoorziening elementen zonder kenmerken van fysieke implementatie
• ABB is logisch, zonder technische specificatie of merknamen
• Infrastructurele- en applicatie laag zijn in de huidige fase van dit model het belangrijkste toepassingsgebied.
• Architectuur bouwblokken zijn gerelateerd aan kwaliteiten, constraints en principes.
• Dit is het kader waarbinnen bijv. een productmanager een product kan selecteren.
• Wanneer een product aan het einde van de LCM is, kunnen de kaders in het ABB opnieuw worden gebruikt om een nieuw product te selecteren.
• Uitgangspunt is het voorkomen dat een ABB wordt geschreven naar een beschikbare oplossing. Deze dient daarom oplossing- en technologie neutraal te zijn.

Een architectuur bouwblok is een beschrijvend architectuur product. Een architectuur bouwblok is de logische definitie van een functionaliteit. Voor een architectuur bouwblok wordt de afkorting ABB gebruikt. Een architectuur bouwblok beschrijft de functionaliteiten die aangeboden worden aan een hoger liggende entiteit. Een ABB beschrijft WAT er nodig is, zonder te schrijven naar een specifieke oplossing. De hoger liggende entiteit kan een service of een samengestelde ABB zijn. Een ABB kan samengesteld zijn uit één of meerdere SBB. Deze SBB zijn de implementatie van de functionaliteit. Met andere woorden de SBB realiseert de ABB.

Bij het uitwerken van een data-architect ontstaan al snel allerlei architectuurproducten en modellen die nauw met elkaar samenhangen. Hierdoor ontstaat een data-architectuur die dusdanig complex is dat de inhoud van de data-architectuur gemanaged moet worden. Het managen van de data-architectuur bestaande uit de modellen en producten kan gedaan worden door inzet van een architectuur register of repository te introduceren. Dit is een informatiesysteem dat zorgdraagt voor het managen van de architectuur inhoud en het bewaken van de kwaliteit. Veelal wordt een architectuur register gebruikt door alle architecten binnen een organisatie. Zij dienen daarom nauw samen te werken om zorg te dragen dat het architectuur register een gezamenlijk ingericht en gemanaged informatiesysteem wordt voor de gezamenlijke architectuur.

De Architecture Repository is een softwaretool waarin de belangrijke architecturele input en output wordt opgeslagen, inclusief Architecturen zelf, de elementen waaruit ze zijn samengesteld, standaarden, referenties, principes en het Governance Register. Ongeacht het Architectuurraamwerk of de architectuurtaal dat is geselecteerd. Een enterprise-architectuur repository is daarmee een verzameling artefacten die het huidige en beoogde enterprise landschap van een organisatie beschrijft. Het doel van de enterprise-architectuur repository is om de inventaris van technologie, data, applicaties en zakelijke artefacten van de organisatie weer te geven en de relaties tussen deze componenten te tonen. Dit wordt bereikt door diagrammen en visualisaties te maken gebaseerd op de inhoud van de architectuur repository.

Naast de eerder beschreven persoonlijke kwaliteit 'Faciliteren', zijn er technieken die data-architecten kunnen gebruiken om discussie te stimuleren, ideeën te genereren en resultaten weer te geven tijdens een vergadering, workshop of focusgroep. Deze technieken omvatten: mindmapping, open space-technologie, brainstorming, cartoons of houtkoolschetsen. Bij het faciliteren wordt vaak gebruik gemaakt van visualisatietechnieken. Ze zijn snel te begrijpen en eenvoudig uit te leggen, en helpen om deelnemers aan de workshop te betrekken, of het nu gaat om het verkennen van zakelijke problemen, strategische keuzes of vereisten. Visuele representaties van informatie kunnen low-fidelity tekeningen zijn of kunnen worden geproduceerd met behulp van geautomatiseerde tools, waarbij het mogelijk is om verschillende scenario's te modelleren zonder uitgebreid opnieuw te tekenen.

xBB kennen attributen. Duncan heeft hiervan een eerste opzet gemaakt. Daarnaast is er een generiek model voor de attributen. Uitwerken in een logisch object model na discussie

Sommige attributen kenmerken zich dat zij bestaan uit een aantal attributen en of bedrijfsregels. Zij vormen daarmee een geaggregeerd attribuut. Echter in dat geval kan dit de notatie voor de betrokkenen veel eenvoudiger maken. Bijvoorbeeld een bezoekadres is een attribuut van een vestiging maar is in detail uitgewerkt in het attribuut type met straat, huisnummer en woonplaats etc.

Sommige attributen kenmerken zich dat zij bestaan uit een aantal attributen en of bedrijfsregels. Zij vormen daarmee een geaggregeerd attribuut. Echter in dat geval kan dit de notatie voor de betrokkeken veel eenvoudiger maken. Bijvoorbeeld een bezoekadres is een attribuut van een vestiging maar is in detail uitgewerkt in het attrbuut type met straat, huisnummer en woonplaats etc.

Sommige attributen kenmerken zich dat zij bestaan uit een aantal attributen en of bedrijfsregels. Zij vormen daarmee een geaggregeerd attribuut. Echter in dat geval kan dit de notatie voor de betrokkeken veel eenvoudiger maken. Bijvoorbeeld een bezoekadres is een attribuut van een vestiging maar is in detail uitgewerkt in het attrbuut type met straat, huisnummer en woonplaats etc.

Benoem authentieke en kernregisters die aangewezen worden voor de opslag van bedrijfsobjecten en ontsluit deze via een gestandaardiseerde interface op basis van views en/of services.

Benoem authentieke en kernregisters die aangewezen worden voor de opslag van bedrijfsobjecten en ontsluit deze via een gestandaardiseerde interface op basis van views en/of services.

Autoriseren van de verschillende betrokkenen tot de expertise en de verschillende logische functies van deze oplossing

Axway wordt geïntroduceerd als nieuwe bouwsteen voor beheerde bestandsoverdracht. Het kan worden gebruikt voor bestandsoverdracht waarvoor extra functionaliteit nodig is, zoals logboekregistratie en beveiliging

Naamgevingsconventie Gebruik: Werkwoord in de gebiedende wijs gevolgd door een zelfstandig naamwoord (enkelvoud), bijvoorbeeld: Controleer order, maak offerte, Meldt storing. Vermijd Beheer, verwerk, registreer ……

Naamgevingsconventies Gebruik: Werkwoord in de gebiedende wijs gevolgd door een zelfstandig naamwoord (enkelvoud), bijvoorbeeld: Controleer order, maak offerte, Meldt storing. Vermijd Beheer, verwerk, registreer ……

Functionaliteit waarin bedrijfsregels beheerd en toegepast worden. Het bestaat veelal uit een service en bijbehorende interface voor het beheer van de verschillende bedrijfsregels. Daarnaast is er een service die vragen stelt aan deze engine. Vervolgens interpreteert de engine deze vragen en geeft een (logisch) antwoord terug.

Ondanks de vele navigatie en zoekmogelijk aanwezig in een architectuur repository is een logische indeling een goed middel om modelleurs en reviewers structuur te bieden. In Sparx Enterprise Architect worden hiertoe packages gebruikt. De (boom)structuur van de packages in een repository is daarmee een belangrijk onderdeel van het inrichten van een architectuur repository.

Proces voor verwerken en registreren van het bezorgen van producten bij de klant.

Naamgevingsconventies Gebruik: Zelfstandig naamwoord in het enkelvoud. Bijvoorbeeld: Factuur, polis, Storingsmelding Logische naam. Vermijd technische namen.

Naamgevingsconventie Gebruik: Zelfstandig naamwoord in het enkelvoud. Bijvoorbeeld: Factuur, polis, Storingsmelding Logische naam. Vermijd technische namen.

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.

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

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

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

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

Inzetten van modelleeromgevingen voor het opstellen van modellen van de gegevensbehoefte en het – aanbod.

Inzetten van modelleeromgevingen voor het opstellen van modellen van de gegevensbehoefte en het – aanbod.

Een concrete logische data entiteit wordt gemodelleerd in een class stereotype. Een logische data entiteit heeft een naam en een definitie Voor concrete data entiteiten kunnen meerdere attributen gedefinieerd worden. Een concrete data entiteit erft alle kenmerken van een abstracte data entiteit als er een specialisatie bestaat tussen deze entiteiten.

Een concrete logische data entiteit wordt gemodelleerd in een class stereotype. Een logische data entiteit heeft een naam en een definitie Voor concrete data entiteiten kunnen meerdere attributen gedefinieerd worden. Een concrete data entiteit erft alle kenmerken van een abstracte data entiteit als er een specialisatie bestaat tussen deze entiteiten.

Een concrete logische data entiteit wordt gemodelleerd in een class stereotype. Een logische data entiteit heeft een naam en een definitie. Voor concrete data entiteiten kunnen meerdere attributen gedefinieerd worden. Een concrete data entiteit erft alle kenmerken van een abstracte data entiteit als er een specialisatie bestaat tussen deze entiteiten.

Introduceren van voorzieningen als het datawarehouse, centrale gegevensvoorziening en gestandaardiseerde webservices. Bij het selecteren van applicaties en (cloud)services rekening houden met het feit dat er gewerkt wordt met authentieke- en kernregisters. Met andere woorden: inzet van applicaties is gebaseerd op een servicelaag waarbinnen generieke data entiteiten worden ingezet.

Introduceren van voorzieningen als het datawarehouse, centrale gegevensvoorziening en gestandaardiseerde webservices. Bij het selecteren van applicaties en (cloud)services rekening houden met het feit dat er gewerkt wordt met authentieke- en kernregisters. Met andere woorden: inzet van applicaties is gebaseerd op een servicelaag waarbinnen generieke data entiteiten worden ingezet.

Verschillende management rollen die op strategisch niveau acteren in de organisatie. Voor de x kan onder andere executive, data, information, financial, operations etc ingevuld worden.

Logische service voor de import van data voor andere systemen

Logische service voor de import van data voor andere systemen

Een data-analist is een professional die gegevens (data) verzamelt, analyseert en interpreteert om inzichten en trends te ontdekken die helpen bij het nemen van zakelijke of strategische beslissingen. Dit omvat vaak het verwerken van grote hoeveelheden informatie, het herkennen van patronen en het presenteren van resultaten in de vorm van rapporten, grafieken of dashboards. Van daaruit heeft de analist een aantal concerns die voor de data-architect van belang zijn.

Data-analyse is het gericht zoeken naar (statistische) verbanden in gegevensverzamelingen met als doel profielen op te stellen voor wetenschappelijk, journalistiek of commercieel gebruik. Zo'n verzameling gegevens kan gevormd worden door gebeurtenissen in een praktijksituatie te registreren (aankoopgedrag van consumenten, symptomen bij patiënten, et cetera) of door de resultaten van eerder uitgevoerde wetenschappelijke onderzoeken met elkaar te vergelijken en te herinterpreteren.

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.

Transformatie van de data zoals opgeslagen in de asset data registratie en transformatie naar een model voor berichten (CGMES, datamarts of bestandsformaten).

Transformatie van de data zoals opgeslagen in de asset data registratie en transformatie naar een model voor berichten (CGMES, datamarts of bestandsformaten).

Naamgevingsconventie Gebruik: Zelfstandig naamwoord in het enkelvoud. Bijvoorbeeld: Zoekvraag, Zoekresultaat Logische naam. Vermijd technische namen als dossier, database.

Naamgevingsconventies Gebruik: Zelfstandig naamwoord in het enkelvoud. Bijvoorbeeld: Zoekvraag, Zoekresultaat Logische naam. Vermijd technische namen als dossier, database.

Een data object is een data element dat is uitgewerkt op applicatieniveau. Veelal is er een detailuitwerking hiervan in onder andere logische datamodellen. Echter deze data objecten komen vanuit een bronsysteem en met behulp van data verwerking omgezet naar een data object met een ander datamodel dat vervolgens ingezet kan worden in verschillende doelsystemen.

Data Owners of data eigenaren ontwikkelen strategisch beleid rond data sets en nemen hieromtrent de beslissingen, veelal gebaseerd op een opsplitsing in domeinen. Data eigenaarschap is een specifiek onderdeel van een rol als lijn- of divisiemanager. De data eigenaar en de data-architect dienen nauw samen te werken.De eigenaar bepaalt het databeleid, de data-architect vertaalt dit naar architectuur kaders zoals principes en architectuur patronen en -bouwblokken.

Functionaliteit om de gegevens te publiceren zoals opgeslagen in de gegevens registratie voor gebruik van verschillende soorten consumenten.

Functionaliteit om de gegevens te publiceren zoals opgeslagen in de gegevens registratie voor gebruik van verschillende soorten consumenten.

MDM functie van aggregatie van de data in een gestandaardiseerd data model

Actuele registratie functie met opslag en verwerking van de master en referentie data

Actuele registratie functie met opslag en verwerking van de master en referentie data

Validatie van gegevens op basis van de gegevens die in het systeem zijn ingevoerd en eventueel op de bestaande gegevens die zijn opgeslagen in de stamgegevens registratie. Het is essentieel dat alle gegevens die worden ontvangen van de acquisitie/registratie service in deze functies worden verwerkt voordat ze worden opgeslagen in het gegevens register

Validatie van gegevens op basis van de gegevens die in het systeem zijn ingevoerd en eventueel op de bestaande gegevens die zijn opgeslagen in de stamgegevens registratie. Het is essentieel dat alle gegevens die worden ontvangen van de acquisitie/registratie service in deze functies worden verwerkt voordat ze worden opgeslagen in het gegevens register

Inzet van voorzieningen voor data virtualisatie, authentieke- en kernregisters en ontsluiten van de basisregistraties.

Inzet van voorzieningen voor data virtualisatie, authentieke- en kernregisters en ontsluiten van de basisregistraties.

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.

Een data-architectuur advies is een specifiek en praktisch advies dat wordt gegeven door een data-architect om organisaties te helpen bij het optimaliseren van hun data-infrastructuur. Het richt zich op het oplossen van concrete problemen, zoals het verbeteren van datakwaliteit, het stroomlijnen van data-integratie, of het kiezen van de juiste technologieën voor data-opslag en -verwerking. Het advies is vaak gebaseerd op de unieke behoeften en doelen van de organisatie. De adviezen worden veelal gegeven op het moment dat binnen de organisatie veranderingen noodzakelijk zijn. Een data-architectuur kader daarentegen is een breder concept. Het is een raamwerk dat richtlijnen, principes en standaarden biedt voor het ontwerpen en beheren van data-architectuur binnen een organisatie. Het kader dient als een strategisch hulpmiddel om consistentie en samenwerking te bevorderen, en om ervoor te zorgen dat alle data-oplossingen binnen de organisatie aansluiten bij de lange-termijn doelen. Vanuit de architectuur kaders kan een advies opgesteld worden.

Richt eigenaarschap en beheerorganisatie in van bronsystemen èn koppelvlakken, door voor bronsystemen en koppelvlakken eigenaarschap te benoemen wordt de verantwoordelijkheid belegd. Deze verantwoordelijke zal veelal geselecteerd worden op basis van betrokkenheid bij de gegevensset (bijvoorbeeld door procesrelevantie). Introduceren van beslisbomen voor het bepalen van de behoefte aan actualiteit en beschikbaarheid van gegevenssets Inrichten van functionele beheerprocessen en het vastleggen van afspraken rond de actualiteitsniveau’ s van gegevensverzamelingen.

Richt eigenaarschap en beheerorganisatie in van bronsystemen èn koppelvlakken, door voor bronsystemen en koppelvlakken eigenaarschap te benoemen wordt de verantwoordelijkheid belegd. Deze verantwoordelijke zal veelal geselecteerd worden op basis van betrokkenheid bij de gegevensset (bijvoorbeeld door procesrelevantie). Introduceren van beslisbomen voor het bepalen van de behoefte aan actualiteit en beschikbaarheid van gegevenssets Inrichten van functionele beheerprocessen en het vastleggen van afspraken rond de actualiteitsniveau’ s van gegevensverzamelingen.

• Alberto’s is een keten van Italiaanse ijssalons in een aantal plaatsen
• Verkoop van schepijs, ijstaarten en koffieproducten
• Sterk seizoensgebonden (zomer en feestdagen)
• Historisch gezien hebben de filialen een grote mate van autonomie:
• Eigen leveranciers, inkoop, recepten en marketing
• Eigen ICT beleid en budget
• Eigen applicatie en data landschap
• Stafafdeling voor:
• P&O en salarisverwerking
• Facilitaire zaken inclusief een ICT afdeling ter ondersteuning van de filialen
• Gezamenlijke financiële verwerking en rapportage
• Centrale prijs- en productbepaling

Rooster waarop wordt geregistreerd waar, wanneer en hoe een medewerker activiteiten dient uit te voeren op een locatie.

Dimensioneel modelleren is een techniek bij het opstellen van een fysiek datamodel binnen relationele databases. Er zijn drie doelen voor dimensioneel modelleren : het classificeren van data in dimensies en facts. Dimensies zijn voor het bieden van hiërarchie in de data voor inzicht. Facts zijn voor vastleggen van de feiten in de werkelijk op een chronologische wijze. Dimensies bieden een vertaling van de datastructuren naar een voor de kenniswerker logische indeling die daardoor sterk kan afwijken van het genormaliseerde OLTP model. Daarnaast bieden facts de mogelijkheid om inzicht te krijgen op basis van data bevroren in de tijd.

Dimensioneel modelleren is een techniek bij het opstellen van een fysiek datamodel binnen relationele databases. Er zijn drie doelen voor dimensioneel modelleren : het classificeren van data in dimensies en facts. Dimensies zijn voor het bieden van hiërarchie in de data voor inzicht. Facts zijn voor vastleggen van de feiten in de werkelijk op een chronologische wijze. Dimensies bieden een vertaling van de datastructuren naar een voor de kenniswerker logische indeling die daardoor sterk kan afwijken van het genormaliseerde OLTP model. Daarnaast bieden facts de mogelijkheid om inzicht te krijgen op basis van data bevroren in de tijd.

Voor (stam)data en informatie is er maar ''één versie van de waarheid'' - Rationale Er is maar ''één versie van de waarheid''. Data en informatie is wat ze pretendeert te zijn. Dit voorkomt verwarring en wantrouwen, onnodige verschillenanalyses, en inefficiency. - Implicatie Eenmalige registratie van stamdata, die vervolgens op meerdere plekken kunnen worden gebruikt en een centraal datawarehouse waaruit informatieproducten putten. Versiebeheer wordt toegepast, waar van toepassing in samenwerking met ketenpartners.

Voor (stam)data en informatie is er maar ''één versie van de waarheid’. Voor elk stam en referentie gegeven moet de leidende bron vastgesteld worden. Zoveel mogelijk stam en referentiegegevens moeten centraal vastgelegd worden in TABS en van daaruit gedistribueerd worden naar afnemende systemen​

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.

ERP (of EAM) functionaliteit voor de registratie van data binnen een aantal sterk gestandaardiseerde processen met behulp van asset data.

Verschillende functionaliteiten zijn gewenst:

• Verrijking van de Log met gegevens uit andere (deel)componenten
• Beperkte configuratiemogelijkheden
• Huidig logging is niet logisch maar technisch
• Opzet van de logging voldoet niet aan de huidige berichtenstroom en ook niet aan de huidige gebruikerswensen.
• Inzet van verschillende gebruikersinterfaces zoals monitoring dashboards en signalering etc
• Aanpasbare en configureerbare beheerschermen voor de logging en monitoring

Het fysieke datamodel beschrijft de manier waarop gegevens in een databank zijn opgeslagen of in een bericht worden uitgewisseld. De verbinding tussen het logische en het fysieke datamodel wordt gelegd door het omzetten van de logische gegevensobjecten in database-definitie instructies conform een bepaalde Data Definition Language (DDL). Na uitvoeren van de DDL op een fysieke database, liggen de definities van de database-objecten vast in de data dictionary van die database. Of voor berichten in een schema definitie dat vastligt in een XSD. Fysieke modellering richt zich voornamelijk op het technische aspect.

Binnen fysieke datamodellen zijn volop data patronen beschikbaar. Veelal worden ze ook ingezet in modelleertools om het werk van de fysieke datamodelleur te vereenvoudigen met geautomatiseerde toepassingen. Daarnaast zijn er volop datamodellen die beschikbaar zijn om een start te maken met datamodellen voor een bepaald werkveld. Zoals bijvoorbeeld order registratie of gestandaardiseerde werkprocessen. In dit voorbeeld een eenvoudig voorbeeld van een fysiek model dat een transformatie is in een relationeel database management systeem op basis van een standaard modelleer concept in een logisch datamodel.

User interfaces voor gebruikers interactie met de data opgeslagen in het register

User interfaces voor gebruikers interactie met de data opgeslagen in het register

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

Data omtrent de medewerker die nodig zijn om tijd te kunnen registreren.

Geo-functionaliteit en register in combinatie met extractie van data in combinatie met geodata en kaarten

Is een extra klasse met dezelfde kenmerken als de Concrete Logische Data entiteit en is toegevoegd om de associaties goed leesbaar te houden.

Is een extra klasse met dezelfde kenmerken als de Concrete Logische Data entiteit en is toegevoegd om de associaties goed leesbaar te houden.

Is een extra klasse met dezelfde kenmerken als de Concrete Logische Data entiteit en is toegevoegd om de associaties goed leesbaar te houden.

Maatwerk toepassing binnen de IjsCo suite voor de registratie van personeelsgegevens en de indeling van de organisatie

In een modern applicatielandschap staat een architectuur repository niet los van andere registers. Integratie met andere registers zoals bijvoorbeeld een CMDB op basis van moderne berichtgeorienteerde integratie is wenselijk.

Inzet sleutelkasten, in een aantal gevallen kunnen bij de data integratie de gegevens van een gegevensset verrijkt worden met verwijzingen naar referentiele sleutels zoals die toegepast worden op andere plaatsen binnen de organisatie. Hiermee kan dan op eenvoudige wijze herleidt worden welke identificerende sleutel waar toegepast kan worden. Sleutelkasten worden veelal beschreven binnen de architectuur in samenspraak met de eigenaren van de verschillende registers.

Inzet sleutelkasten, in een aantal gevallen kunnen bij de data integratie de gegevens van een gegevensset verrijkt worden met verwijzingen naar referentiele sleutels zoals die toegepast worden op andere plaatsen binnen de organisatie. Hiermee kan dan op eenvoudige wijze herleidt worden welke identificerende sleutel waar toegepast kan worden. Sleutelkasten worden veelal beschreven binnen de architectuur in samenspraak met de eigenaren van de verschillende registers.

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.

Inrichten van voorzieningenpatronen voor het actueel houden van data entiteiten met name binnen de (interne) kernregisters. Bijvoorbeeld door de inzet van voorzieningen als digilevering en componenten ter ondersteuning van het observer patroon.

Inrichten van voorzieningenpatronen voor het actueel houden van data entiteiten met name binnen de (interne) kernregisters. Bijvoorbeeld door de inzet van voorzieningen als digilevering en componenten ter ondersteuning van het observer patroon.

Benoem authentieke- en kernregisters, door de inzet van deze registers kunnen maatregelen genomen worden om zorg te dragen voor de actualiteit van de gegevens. Mede door het terugbrengen van het beheer van de inhoud naar één verantwoordelijke heeft een positief effect op de actualiteit.

Benoem authentieke- en kernregisters, door de inzet van deze registers kunnen maatregelen genomen worden om zorg te dragen voor de actualiteit van de gegevens. Mede door het terugbrengen van het beheer van de inhoud naar één verantwoordelijke heeft een positief effect op de actualiteit.

Issue registratie voor kwaliteitsissues binnen een repository. Veelal wordt voor deze issue registratie een op ITIL gebaseerde werkwijze toegepast.

Issue registratie voor kwaliteitsissues. Voor een issue is in de ArchiMate taal niet echt een concept beschikbaar wat hier bruikbaar voor is. In de algemene modelleerconcepten in Sparx Enterprise Architect is het issue aanwezig en dit is wel een bruikbaar element.

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 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.

Aangezien de meeste dataveranderingsprojecten de ontwikkeling of aanschaf van softwaretoepassingen vereisen, is een algemeen begrip van technologie, technologische ontwikkelingen en benaderingen van softwareontwikkeling noodzakelijk, zodat data-architecten zinvol kunnen communiceren met hun technologiegerichte collega's en hun rol en bijdrage aan de oplossingsarchitectuur en het ontwikkelingsproces kunnen waarderen. De mate waarin data-architecten technische kennis nodig hebben, hangt af van de aard van het analysewerk dat wordt uitgevoerd. De belangrijkste vereiste is dat de data-architect het potentieel van technologie en de benaderingen en termen die door technische specialisten worden gebruikt, begrijpt. Enkele van de belangrijkste gebieden die data-architecten moeten begrijpen, worden hieronder opgesomd: Trends en ontwikkelingen zoals AI, robotic process automation (RPA), big data, software as a service (SaaS), visualisatie, mobiele technologieën, en hoe deze impact hebben op organisaties en de potentie die ze bieden voor nieuwe of verbeterde producten of diensten. Technische infrastructuurcomponenten zoals besturingssystemen, applicatiesoftware, hardware, netwerken, cloud computing. Levenscycli van systeemontwikkeling (SDLC's) en benaderingen zoals het 'V'-model en het uniforme proces. Benaderingen voor systeemmodellering zoals de UML. Agile ontwikkelingsbenaderingen zoals DSDM en Scrum. De relatieve voor- en nadelen van het ontwikkelen van software in plaats van het kopen van kant-en-klare softwareproducten. Organisatiestructuren Veel bedrijfsveranderingsprojecten omvatten het tot op zekere hoogte herstructureren van divisies of teams om overdrachten te verwijderen, taken te centraliseren of de klantenservice te verbeteren. Om deze redenen is het belangrijk dat een data-architect een goed begrip heeft van de verschillende organisatiestructuren die zich kunnen voordoen – functioneel, project, matrix, plat, virtueel – en van hun relatieve sterke en zwakke punten. Beheer van leveranciers Veel organisaties maken gebruik van externe leveranciers om hun IT-systemen te leveren, hetzij op ad-hocbasis, hetzij via een uitgebreidere outsourcingregeling, die hele bedrijfsprocessen of zelfs een hele bedrijfsfunctie kan omvatten. Veel organisaties hebben bijvoorbeeld hun salarisadministratieprocessen meerdere jaren uitbesteed, maar sommige hebben dit nu uitgebreid tot een groot deel van het personeelswerk (HR), van werving tot het bijhouden van gegevens. Selecteren en contracteren van leveranciers valt meestal binnen het domein van de inkoopfunctie. Voor sommige outsourcingcontracten kan de data-architect echter betrokken zijn om ervoor te zorgen dat de bedrijfsprocessen en -systemen efficiënt blijven werken. Dit vereist dat data-architecten een breed begrip hebben van inkoop- en leveranciersbeheerprocessen. Data-architecten moeten op zijn minst op de hoogte zijn van de verschillende contractuele regelingen die beschikbaar zijn, met name: Tijd en materiaal: Wanneer de gecontracteerde partij wordt betaald op basis van de gewerkte tijd en de te leveren prestaties die zijn geleverd; het tijdselement heeft geen betrekking op de verstreken tijd van het project, maar op de hoeveelheid inspanning die is geleverd. Levering tegen een vaste prijs: waarbij de gecontracteerde partij de prijs ontvangt die is overeengekomen voor de levering van het werk in overeenstemming met de oorspronkelijke specificatie. Risico en beloning: Wanneer de gecontracteerde partij ermee heeft ingestemd om een deel of het volledige risico van het project te dragen. Bijvoorbeeld door middelen te investeren zoals personeelstijd, materialen of kantoorruimte, maar waarbij de potentiële beloningen groter zijn dan bij andere contractuele regelingen. Data-architecten moeten in staat zijn om met leveranciers in contact te komen om ervoor te zorgen dat ze hun diensten effectief leveren. Dit vereist persoonlijke kwaliteiten zoals communicatie en het opbouwen van relaties, die eerder zijn besproken

Het logisch model wordt uitgewerkt op basis van de modelleertaal UML en dan met name het klassediagram. Het biedt daarmee de mogelijkheid om de data in detail te modelleren maar het staat nog steeds los van de fysieke implementatie.

Het logische datamodel beschrijft de structuur van en de referenties tussen de logische gegevensobjecten, genaamd objecten of tabellen. Het conceptuele model is verbonden aan het logische model doordat entiteiten worden omgezet in objecten of tabellen (of preciezer: -definities), en doordat er een detaillering plaatsvindt van de relaties en attributen. Het logische datamodel focust op semantisch- en syntactisch vlak.

Beschrijving van de aanwezige of gewenste applicatiefuncties binnen de scope van de architectuur. Meestal gerelateerd aan de beschrijving van het applicatielandschap.

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.

Uitwerking van het model op basis van logische applicaties inclusief de uitwerking van de deelfuncties

Het logisch model wordt uitgewerkt op basis van de modelleertaal UML en dan met name het klassediagram. Het biedt daarmee de mogelijkheid om de data in detail te modelleren maar het staat nog steeds los van de fysieke implementatie.

Logische datamodellering is een model uitgewerkt zonder de implementatie aspecten van de onderliggende technische platformen. Binnen logische datamodellering zijn patronen veel toegepast. Er zijn dan ook veel catalogi te vinden met logische datamodelleer patronen. Hier behandelen we een viertal voorbeelden van dergelijke logische datamodel patronen.

Beschrijving van de modelleer- en naamgevingsconventies op basis van een checklist. Hiermee worden naamgevingsconventies eenvoudig geïntroduceerd en onderhouden.

• Modellering binnen UMLclass diagram gebaseerd op Class en Enumaratie stereotypen Uitwerking op een beperkte set van concepten uit de UML statische modellering.
• Logische entiteit is een zelfstandig naamwoord Naamgevingsconventie dat entiteiten een zelfstandig naamwoord is
• Logische entiteit is in enkelvoud Logische datamodelling is (arbitrair) gekozen voor enkelvoud.
• Logische entiteiten worden aan elkaar gerelateerd met een UML associatie
• Logische UML associatie heeft een werkwoord als naam Er wordt een werkwoord opgegeven, niet op basis van een rolnaam aan beide zijden van de relatie
• UML associatie beschrijft onder- en bovengrens cardinaliteiten (meervoudigheid) aan beide zijden van de connector Cardinaliteiten meestal op basis van 0..1, 1..1, 1..*, 0..*.
• Specialisatie in het LDM is een is-een relatie conform definitie in CDM Hiermee wordt een hiërarchie geïntroduceerd voor modellering
• Aggregatie in het LDM is een heeft-een relatie conform definitie in het CDM Groepering en clustering van elementen met een aggregatie.
• Logische entiteit heeft een definitie Definitie is een tekstuele verklaring van de betekenis van het element
• Attributen hebben een beschrijvende naam In een Nederlandse beschrijving zonder beperkingen vanuit de technologie
• Attributen kunnen een definitie hebben Kan een attribuut meedere betekenissen hebben dan is een defiiniie noodzakelijk
• Attribuut heeft een datatype of een enumeratie naam als datatype Maak gebruik van een standaardlijst van datatypes, bijvoorbeeld de VB datatypes is een mooi startpunt voor datatypes.
• Attribuut kan een scope hebben als de scope gedefinieerd is in het metamodel Scope wordt alleen gebruikt als dit toegevoegde waarde heeft voor de context van de organisatie.
• Attribuut kan een onder en boven cardinaliteit hebben (default is 1..1) en 0..1 Meervoudigheid van attributen zelfde opzet als bij de relaties. Met name om de optionaliteit van attributen te definieren.
• Enumeraties op een attribuut worden gebruikt voor domeinspecificatie Modeldetaillering voor het toepassen van een regel op basis van een domein voor een attribuut
• Voor attributen kunnen naast enumeraties ook geaggregeerde attribuuttypen of complextypes worden gebruikt Complextypes kunnen gebruikt worden om de leesbaarheid van een model of diagram te kunnen vereenvoudigen.
• Modelleer specialisaties uit als deze eigen attributen of eigen relaties heeft Dit wordt toegepast als refactorings aspect om in het model gebruik te maken van de specialisaties om dit eenvoudig leesbaar te houden.

• Modellering binnen UMLclass diagram gebaseerd op Class en Enumaratie stereotypen Uitwerking op een beperkte set van concepten uit de UML statische modellering.
• Logische entiteit is een zelfstandig naamwoord Naamgevingsconventie dat entiteiten een zelfstandig naamwoord is
• Logische entiteit is in enkelvoud Logische datamodelling is (arbitrair) gekozen voor enkelvoud.
• Logische entiteiten worden aan elkaar gerelateerd met een UML associatie
• Logische UML associatie heeft een werkwoord als naam Er wordt een werkwoord opgegeven, niet op basis van een rolnaam aan beide zijden van de relatie
• UML associatie beschrijft onder- en bovengrens cardinaliteiten (meervoudigheid) aan beide zijden van de connector Cardinaliteiten meestal op basis van 0..1, 1..1, 1..*, 0..*.
• Specialisatie in het LDM is een is-een relatie conform definitie in CDM Hiermee wordt een hiërarchie geïntroduceerd voor modellering
• Aggregatie in het LDM is een heeft-een relatie conform definitie in het CDM Groepering en clustering van elementen met een aggregatie.
• Logische entiteit heeft een definitie Definitie is een tekstuele verklaring van de betekenis van het element
• Attributen hebben een beschrijvende naam In een Nederlandse beschrijving zonder beperkingen vanuit de technologie
• Attributen kunnen een definitie hebben Kan een attribuut meedere betekenissen hebben dan is een defiiniie noodzakelijk
• Attribuut heeft een datatype of een enumeratie naam als datatype Maak gebruik van een standaardlijst van datatypes, bijvoorbeeld de VB datatypes is een mooi startpunt voor datatypes.
• Attribuut kan een scope hebben als de scope gedefinieerd is in het metamodel Scope wordt alleen gebruikt als dit toegevoegde waarde heeft voor de context van de organisatie.
• Attribuut kan een onder en boven cardinaliteit hebben (default is 1..1) en 0..1 Meervoudigheid van attributen zelfde opzet als bij de relaties. Met name om de optionaliteit van attributen te definieren.
• Enumeraties op een attribuut worden gebruikt voor domeinspecificatie Modeldetaillering voor het toepassen van een regel op basis van een domein voor een attribuut
• Voor attributen kunnen naast enumeraties ook geaggregeerde attribuuttypen of complextypes worden gebruikt Complextypes kunnen gebruikt worden om de leesbaarheid van een model of diagram te kunnen vereenvoudigen.
• Modelleer specialisaties uit als deze eigen attributen of eigen relaties heeft Dit wordt toegepast als refactorings aspect om in het model gebruik te maken van de specialisaties om dit eenvoudig leesbaar te houden.

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

Gecontroleerde en veelal secure inrichting voor het overbrengen van data vanuit het register ten behoeve van de consumenten

Registratie van de historie van de volwassenheid scans en beschrijving van de progressie van de data management activiteiten in de tijd.

Registratie van de historie van de maturity scans en beschrijving van de progressie van de data management activiteiten in de tijd

Registratie van de historie van de maturity scans en beschrijving van de progressie van de data management activiteiten in de tijd

Melding einde boekingsperiode

Aggregatie van de verschillende registers, administratie en metamodellen voor data management (kennisgebieden).

Aggregatie van de verschillende registers, administratie en metamodellen voor data management (kennisgebieden).

Aggregatie van de verschillende registers, administratie en metamodellen voor data management (kennisgebieden).

Bepaald actualiteitsbehoefte en –aanbod en registreer dit.

Bepaald actualiteitsbehoefte en –aanbod en registreer dit.

Data patronen zijn generieke oplossingen voor frequent terugkerende meta data problemen. Voor dataverwerking en -vergaring is dit kenmerkend rond meta data. Dataverwerking en -transformatie is van zichzelf al een uitdaging. De behoefte om op adequate wijze ook de meta data te verzamelen en te registreren is daarmee een extra complicerende factor. In onderstaande paragrafen worden daarom een aantal kenmerkende meta data patronen beschreven.

• Model uitwerken met ArchiMate motivatie elementen Voor de governance modellen worden alleen ArchiMate concepten gebruikt omdat dit nauw aansluit bij de enterprise architectuur modelleerwijze.
• Centrale elementen zijn principes en doelen Principes realiseren de doelen. Desgewenst kun je de principes uitbreiden met eigenschappen zoals rationale en implicaties.
• Leg relatie tussen het conceptuele datamodel en de data management doelen en kaders Verbinding met de elementen in het CDM naar de doelen en principes zijn een essentieel aspect in de governance modellering.
• Leg de data governance elementen en modellen uit in een register gemodelleerd in deliverables Rond de uitgewerkte modellen is het opzetten van een metadata register een belangrijk effect van deze modellering.
• Metadata register is een aggregatie van een aantal verschijningsvormen van de data governance modellen Het register voegt de verschillende uitgewerkte modellen samen en legt verbanden tussen de elementen.

Dit is een pakket met vier logische scenario's voor de implementatie van een Master Data-oplossing. Deze logische modellen hebben geen relatie met enige fysieke implementatie. Daarom is de lange lijst met alternatieven relevanter. Deze scenario's kunnen helpen in de volgende situaties:

• Functionele vereisten toewijzen aan scenario's
• Het in kaart brengen van niet-functionele eisen en kwaliteiten aan scenario's
• Complexiteitsanalyse van scenario's
• Mogelijke oplossingen en componenten toewijzen aan scenario's

Logische datamodellen met een uitwerking voor verschillende referentie data logische structuren met data entititeiten, attributen en assoociaties.

In het logische applicatie model beschrijven we alleen welke logische applicatiefuncties nodig zijn binnen de oplossing zonder te kijken naar de beschikbare componenten en informatiesystemen. Dit helpt bij het maken van een technisch onafhankelijk applicatie model dat later kan worden gebruikt om verschillende oplossingsscenario's en componentstapels te modelleren. Deze stapels worden geanalyseerd en met elkaar vergeleken op basis van de functionele en niet functionele eisen.

Pas naamgevingsconventies toe voor entiteiten, attributen en relaties waardoor de kans op het ontstaan van dubbele opslag in registers verkleind wordt.

Pas naamgevingsconventies toe voor entiteiten, attributen en relaties waardoor de kans op het ontstaan van dubbele opslag in registers verkleind wordt.

Vertegenwoordig entiteiten, relaties en attributen op een passend granulariteitsniveau. Conceptuele datamodellen modelleren doorgaans geen attributen en de naamgeving is bedrijfsgericht. Logische gegevensmodellen voegen attributen toe met generieke gegevensmodellen. Fysieke modellen bevatten details omtrent de technische uitwerking in het specifieke platform.

Vertegenwoordig entiteiten, relaties en attributen op een passend niveau van granulariteit. Conceptuele datamodellen modelleren doorgaans geen attributen en de naamgeving is bedrijfsgericht. Logische datamodellen voegen attributen toe met generieke gegevens en details aan relaties.

Objectmodellen zijn diagrammen waarbij instanties worden gemaakt van een aantal klassen in het logisch klassemodel. Het kan gebruikt worden om voorbeelden te presenteren aan eindgebruikers met voor hen herkenbare objecten binnen het klassemodel.

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

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

Oudertabel dat in een logisch data model met een veel op veel relatie is gekoppeld met de andere oudertabel. Om deze koppeling mogelijk te maken is een primaire sleutel toegevoegd om dit te implementeren in de koppeltabel.

Oudertabel dat in een logisch data model met een veel op veel relatie is gekoppeld met de andere oudertabel. Om deze koppeling mogelijk te maken is een primaire sleutel toegevoegd om dit te implementeren in de koppeltabel.

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

Package is een concept dat het mogelijk maakt om de inhoud van je repository inhoud logisch te structureren. Het is te vergelijken met directories in een bestandssysteem.

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.

Abstracte architecturele entiteit voor de registergegevens consumenten, alle gebruikersinterfaces en gegevensintegraties zijn een mastergegevens consument

Allerlei gebruikersinterfaces waarin een gebruiker via een (grafische) gebruikersinterface data kan consumeren. Voorbeelden van gebruikersinterfaces zijn rapporten, formulieren, portalgrafieken, geoviews enz.

Applicatie- en database-integratie zoals webservices, bestandsoverdracht, databasekoppelingen, views etc. In een latere fase zullen we de verschillende integratiemethoden modelleren en in detail modelleren

Logische toepassingsfunctie voor de opslag en transformatie van stamgegevens in verschillende bronfuncties en de gegevensregisterfunctie

Logische diensten die de gegevens uit het register publiceren naar verschillende registergegevens consumenten

Logische diensten die de gegevens uit het register publiceren naar verschillende registergegevens consumenten

Met name rond toepassingsgebied overstijgende sleutels dient het beheer en eigenaarschap ingeregeld te worden. Enerzijds bij het selecteren en beschrijven van deze sleutels, anderzijds bij het bewaken van het gebruik van deze sleutels binnen projecten waar deze sleutels ingezet dienen te worden. Het is een logische keuze deze bewaking binnen de taken van de data-architect te beleggen.

Met name rond toepassingsgebied overstijgende sleutels dient het beheer en eigenaarschap ingeregeld te worden. Enerzijds bij het selecteren en beschrijven van deze sleutels, anderzijds bij het bewaken van het gebruik van deze sleutels binnen projecten waar deze sleutels ingezet dienen te worden. Het is een logische keuze deze bewaking binnen de taken van de data-architect te beleggen.

Werk eventueel met toepassingsgebied overstijgende sleutels voor het afdwingen van referentiele integriteit. Bijvoorbeeld bij service oriëntatie of keten integratie over de grenzen van een applicatie of organisatie heen. Hierbij kan de inzet van een sleutelkast component of service uitkomst bieden

Werk eventueel met toepassingsgebied overstijgende sleutels voor het afdwingen van referentiele integriteit. Bijvoorbeeld bij service oriëntatie of keten integratie over de grenzen van een applicatie of organisatie heen. Hierbij kan de inzet van een sleutelkast component of service uitkomst bieden

Functie voor de registratie en extractie van governance-aspecten van de datasets die via de logische services zijn gepubliceerd. Bijvoorbeeld datakwaliteiten, verbindingseisen en het gestandaardiseerde object- of informatiemodel

Zet registers en/of repositories in de beschrijving van entiteiten. Hiermee worden projecten en beheerprocessen gefaciliteerd in situaties waar herbruikbaarheid van gegevensdefinities relevant zijn.

Zet registers en/of repositories in de beschrijving van entiteiten. Hiermee worden projecten en beheerprocessen gefaciliteerd in situaties waar herbruikbaarheid van gegevensdefinities relevant zijn.

Pas repositories en registries toe als er gewerkt wordt met een gegevensopslag die het gebruik van sleutels minder goed ondersteunt. Denk bijvoorbeeld aan het ontsluiten van diverse soorten van bestanden waarbij de bestandsnaam als sleutel wordt gebruikt of waarbij de sleutel door precisieproblemen niet gelijk blijven.

Pas repositories en registries toe als er gewerkt wordt met een gegevensopslag die het gebruik van sleutels minder goed ondersteunt. Denk bijvoorbeeld aan het ontsluiten van diverse soorten van bestanden waarbij de bestandsnaam als sleutel wordt gebruikt of waarbij de sleutel door precisieproblemen niet gelijk blijven.

Registratie van de activiteiten die uitgevoerd worden door medewerkers.

(Traditionele) ETL voor het transformeren en overbrengen van data van relationele registers en consumenten. Voor NoSQL transformaties wordt veelal gebruik gemaakt van vergelijkbare ETL inrichting en daarom is dit niet nader gespecificiceerd

Afdeling waar de salarisverwerking, registratie en uitbetaling van salarissen.

Binnen of buiten de organisatie wordt een kwaliteits issue geconstateerd. Het issue wordt geanalyseerd en gecategoriseerd en vervolgens geregistreerd.

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

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

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

Registratie van de eigenschappen horend bij een element. Met name in gebruik bij UML objectmodellering en database modellering.

Tabel waarin de weergave van connectoren in een diagram geregistreerd wordt.

Tabel waarin de elementen die voorkeuren op een diagram worden geregistreerd. Hier dus allerlei coordinaat eigenschappen om te registreren waar een element staat op een diagram en hoe het element eruitziet op dat diagram.

Registreren van de tijd die aan een bepaalde activiteit besteed is door een medewerker. Vervolgens controleren en goedkeuren van de geregistreerde activiteiten.

Modelleertaal voor het modelleren van Software en van logische data modellen.

Bedrijfsproces voor het registreren van rollen binnen een vestiging ten behoeve van het organogram van de organisatie.

This is a template for a logical application model and a number of scenarios for selecting an implementation of an application with a register function

Boek data modelleren in de praktijk, ook verkrijgbaar via brave new books en leanpub maar hier voor geregistreerde gebruikers

Whitepaper met een introductie over Meta Data. Wat is het hoe kun je gebruiken, waar komt metadata vandaan en hoe registreer je metadata zodat je van data informatie kunt maken

Data analytics is een nieuw vakgebied dat door steeds organisaties wordt ingezet. Er zijn vele vormen van data analytics beschikbaar zoals BI, DWH, Predictive Analytics of Machine Learning. Binnen data analytics speelt data modellering een rol. Met name het leggen van verbanden tussen de data entiteiten in de bronnen en het logische model van de analyse is essentieel. In een vroeg stadium nadenken welke modelleervormen relevant zijn, hoe deze aan elkaar verbonden worden. In dit whitepaper hebben we een combinatie van modelleervormen beschreven die een (minimale) set is van generieke notatiewijzen op basis waarvan data analytics.

CRUD matrix is een datamodellering notatie waarmee de bewerkingen Create, Read, Update en Delete worden gecombineerd met Data entiteiten en gedragsentiteiten. De notatie wordt toegepast op alle drie de modelleerlagen, fysiek, conceptueel en logisch. Naast toepassingen in de datamodellering wordt de CRUD matrix gebruikt binnen data management, data security en data privacy. Hierbij gaat het meer om de autorisaties die gebruikers hebben op de verschillende data entiteiten.

ER diagram is een veelgebruikte notatiewijze met name voor het opstellen van fysieke datamodellen voor implementatie in relationele databases. Het legt daarmee een verbinding tussen de logische modellen en de fysieke implementatie in een relationeel database platform. Het is daarmee een onmisbare schakel in de data modelleerketen.

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

Geavanceerde UML klassenotatie is een veelgebruikte notatiewijze met name voor het opstellen van logische datamodellen voor bijvoorbeeld open standaarden. Het geeft een detaillering van de UML basisdiagrammen en introduceert met name hergebruik. Voor geavanceerde UML klassenotatie is een veelheid aan tooling aanwezig, in dit artikel slechts een beperkte opsomming. Wil je het klassediagram gaan inzetten voor het genereren van programmatuur dan is de tooling keuze minder breed maar nog steeds een ruim voldoende.

Beschrijving van het introduceren van een koppelingen register

Opzet van een metamodel voor een metadata register dat gebruikt kan worden als een startpunt voor een simulator of definitie van een architectuurtool

Whitepaper over normaalvormen ten behoeve van relationele databases gericht op registratieve en administratieve verwerking binnen OLTP

Sleutels zijn een belangrijk aspect van relationele databases. Bij het introduceren wordt het kiezen van de juiste sleutels een essentiële activiteit voor de data architect. Dit document beschrijft hoe registervorming invloed heeft op de keuze van sleutels en draagt voorstellen aan voor een gestructureerde aanpak.

Beschrijving van tools en requirements voor service repositories

Overzicht van een aantal verschijningsvormen in metadata registers relevant voor gebruikers

Voorbeeld uitwerking van een logisch applicatie model voor een register in ArchiMate

Webvideo about the Data Management Register in Sparx Enterprise Architect

Uitwerking van een beheerproces voor service registers.

Doel: Inzicht geven in de samenhang tussen applicaties en onderdelen van applicaties en welke applicatie functies deze realiseren. Verplicht Landschap van de relatie tussen verschillende applicaties. Gebruik hiervoor de Applicatie laag van ArchiMate 3 en hanteer twee soorten views: de logische applicatie view (applicatie functies) en de implementatie view met applicatie componenten.

Voor de urenadministratie wil Giovanna een applicatie model uitwerken:

• Logisch applicatiemodel
• Componenten

Maak een ArchiMate diagram van dit landschap aan, gebruik eventueel concepten uit je eigen organisatie. Begin eenvoudig dus naar de passieve structuur doen we nog niets Leg relevante associaties tussen de elementen in het diagram Voeg een uitlijning en layout toe Voeg kleuren toe en maak een legenda

Voor de urenadministratie wil Giovanna een applicatie model uitwerken:

• Logisch applicatiemodel
• Data object model
• Componenten

Maak een ArchiMate diagram van dit landschap aan met alle aspecten van de taal, gebruik eventueel concepten uit je eigen organisatie Leg relevante associaties tussen de elementen in het diagram Voeg een uitlijning en layout toe Voeg kleuren toe en maak een legenda

Doel: Inzicht geven in de samenhang tussen applicaties en onderdelen van applicaties en welke applicatie functies deze realiseren. Als een aparte applicatieview vereist is deze altijd van detail niveau 2 (zie 5.6 voor meer informatie over de niveau’s). Verplicht Landschapsview van de relatie tussen verschillende applicaties. Gebruik hiervoor de applicationlaag van Archimate 3 en hanteer twee soorten views: de logische applicatieview (applicatiefuncties)

Voor de urenadministratie wil Giovanna een ArchiMate proces uitwerken bestaande uit:

• Urenregistratie
• Controleer uren
• Salarisverwerking

Bepaal eventueel je viewpoint Maak een ArchiMate diagram van dit proces en Verzin er zelf een aantal rollen/actoren bij

Bij de loggingfunctionaliteit zijn bedrijfsregels van groot belang. Denk bijvoorbeeld aan:

• Wanneer moet een signaal gestuurd worden omtrent het berichtenverkeer
• Welke gegevens van een bericht worden opgeslagen in een log
• Wie heeft toegang tot welke rapportages en dashboards

Daar komt bij dat deze bedrijfsregels regelmatig wijzigen en daarom configureerbaar dienen te zijn. Reden om een bedrijfsregel functionaliteit op te nemen in dit model conform de opzet van de logische servicebus.

In dit diagram wordt een beschrijving gegeven van de datapipe van een (webservice) of (XML)-bestandsbron naar het doeldatamodel. Dit is gebaseerd op de transformatie van een XML-model naar een tussenliggend tabel- of relationeel model. Dit wordt vervolgens verwerkt in een ETL-proces om het brondatamodel in een aantal stappen te transformeren naar het gewenste doelmodel.

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.

Een stermodel is een type dimensioneel model binnen Business Intelligence is een datastructuurtechniek die is ontworpen om gegevens op een manier te organiseren die het eenvoudig maakt om informatie op te halen en te analyseren. Dit model bestaat uit twee hoofdcomponenten: feiten en dimensies. Hier het stermodel van het domein tijdregistratie binnen Alberto.

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.

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

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

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

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

In dit diagram wordt een beschrijving gegeven van de datapipe van een (CSV-webservice) of CSV-bestandsbron naar het doeldatamodel. Dit is gebaseerd op de transformatie van een CSV-model naar een tussenliggend tabel- of relationeel model. Dit wordt vervolgens verder verwerkt in een ETL-proces om het brondatamodel in een aantal stappen te transformeren naar het gewenste doelmodel.

In dit diagram wordt een beschrijving gegeven van de datapipe van een (webservice) of XML-bestandsbron naar het doeldatamodel. Dit is gebaseerd op de transformatie van een XML-model naar een tussenliggend tabel- of relationeel model. Dit wordt vervolgens verwerkt in een ETL-proces om het brondatamodel in een aantal stappen te transformeren naar het gewenste doelmodel.

Voor de data-architect zijn API's een belangrijk onderdeel van data die door het data- en applicatielandschap stromen. APIs zijn koppelvlakken die zich kenmerken door een fysiek datamodel van de API maar ook van de gebruikte protocollen van deze APIs. Wil je als data-architect grip krijgen op de APIs en wil je waar mogelijk APIs standaardiseren en hergebruiken dan is het van belang dat de aanwezige koppelvlakken en de data objecten die daar worden uitgewisseld worden gemodelleerd en geregistreerd. Voor de data objecten kan een koppeling gemaakt worden naar de onderliggende logische en fysieke datamodellen.

Voor de data-architect zijn API's een belangrijk onderdeel van data die door het data- en applicatielandschap stromen. APIs zijn koppelvlakken die zich kenmerken door een fysiek datamodel van de API maar ook van de gebruikte protocollen van deze APIs. Wil je als data-architect grip krijgen op de APIs en wil je waar mogelijk APIs standaardiseren en hergebruiken dan is het van belang dat de aanwezige koppelvlakken en de data objecten die daar worden uitgewisseld worden gemodelleerd en geregistreerd. Voor de data objecten kan een koppeling gemaakt worden naar de onderliggende logische en fysieke datamodellen.

Dit is een logische weergave van een data gedreven platform. Het beschrijft drie lagen en de daartussen liggende interfaces die functionaliteit bieden voor het implementeren van datapijpen voor de overdracht van (big) data van de bronnen naar de gebruikers. Dit overzicht wordt verder gedetailleerd beschreven met toegevoegde functionaliteiten. In de sectie Alternatieven vindt u cases en voorbeelden van de concrete implementatie van deze functionaliteiten.

Voorbeeld van op werkwijze met behulp van een score matrix geregistreerd kan worden wat het kwaliteitsniveau in de huidige en gewenste situatie is. In dit voorbeeld is een score 0 tot 9.

Datakwaliteiten kunnen met behulp van ArchiMate concepten in een viewpoint uitgewerkt worden. Er is hier gekozen voor één afwijking namelijk de registratie van issues rond datakwaliteiten waarvoor in dit metamodel een generiek concept issue gekozen is.

In dit diagram kan gemodelleerd worden welke data objecten vanuit één of meerdere bronsystemen geextraheerd kunnen worden. Vervolgens wordt gevisualiseerd hoe deze data objecten verband houden met de conceptuele data entiteiten. Dit laatste is gewenst omdat de conceptuele data entiteiten gerelateerd zijn aan de kaderstellende architectuur, de governance dimensies en data management in het algemeen. Voor de data object wordt vervolgens inzichtelijk gemaakt hoe deze data verwerkt wordt. Vaak zullen dit transformaties zijn voor het model of het protocol. Maar ook andere data verwerkingen zijn mogelijk. Denk hierbij bijvoorbeeld aan aggregaties, cleansing of anonimiseren van de data afkomstig uit het datamodel. Hierbij kan vervolgens beschreven worden welke applicatie componenten deze dataverwerking uitvoeren. Voor de data objecten kan er vervolgens een koppeling gelegd worden naar diagrammen waarin het onderliggende logische of fysiekemodel gepresenteerd kan worden.

In dit diagram kan gemodelleerd worden welke data objecten vanuit één of meerdere bronsystemen geextraheerd kunnen worden. Vervolgens wordt gevisualiseerd hoe deze data objecten verband houden met de conceptuele data entiteiten. Dit laatste is gewenst omdat de conceptuele data entiteiten gerelateerd zijn aan de kaderstellende architectuur, de governance dimensies en data management in het algemeen. Voor de data object wordt vervolgens inzichtelijk gemaakt hoe deze data verwerkt wordt. Vaak zullen dit transformaties zijn voor het model of het protocol. Maar ook andere data verwerkingen zijn mogelijk. Denk hierbij bijvoorbeeld aan aggregaties, cleansing of anonimiseren van de data afkomstig uit het datamodel. Hierbij kan vervolgens beschreven worden welke applicatie componenten deze dataverwerking uitvoeren. Voor de data objecten kan er vervolgens een koppeling gelegd worden naar diagrammen waarin het onderliggende logische of fysiekemodel gepresenteerd kan worden.

In dit diagram kan gemodelleerd worden welke data objecten vanuit één of meerdere bronsystemen geextraheerd kunnen worden. Vervolgens wordt gevisualiseerd hoe deze data objecten verband houden met de conceptuele data entiteiten. Dit laatste is gewenst omdat de conceptuele data entiteiten gerelateerd zijn aan de kaderstellende architectuur, de governance dimensies en data management in het algemeen. Voor de data object wordt vervolgens inzichtelijk gemaakt hoe deze data verwerkt wordt. Vaak zullen dit transformaties zijn voor het model of het protocol. Maar ook andere data verwerkingen zijn mogelijk. Denk hierbij bijvoorbeeld aan aggregaties, cleansing of anonimiseren van de data afkomstig uit het datamodel. Hierbij kan vervolgens beschreven worden welke applicatie componenten deze dataverwerking uitvoeren. Voor de data objecten kan er vervolgens een koppeling gelegd worden naar diagrammen waarin het onderliggende logische of fysiekemodel gepresenteerd kan worden.

Omdat de logische positie van een datasysteem relevant is voor de implementatie en data-integratie, wordt een eenvoudig model gemaakt met on-premise, cloud en externe systemen. Op basis van deze classificatie zijn aanvullende eisen en metingen nodig.

Gegevensverwerking omvat functies voor het transformeren, filteren, selecteren en routeren van gegevens. In dit diagram wordt geen onderscheid gemaakt tussen berichtgebaseerde verwerking en gegevensopslaggebaseerde verwerking. Zodra dit duidelijk wordt, zal dit onderscheid worden gemaakt.

Overzicht van de transformatie van bestandsgebaseerde data naar een datadoel

Diagram met deelmodel voor de tabellen waarin de data van het tijdregistratie domein worden opgeslagen. Een deel van de tabellen in het model zullen ook worden gebruikt in de andere deelmodellen. Hierbij ontstaat een gezamenlijk model uitgewerkt in meerdere diagrammen.

Opsomming en hiërarchie relevante applicatie functies bij het werken met een architectuur repository. Met andere woorden noodzakelijke functionaliteiten voor een te selecteren tool voor een repository.

Dit logische applicatiemodel beschouwd de architectuur repository als een master data register en benoemd de relevante applicatie functies en - interfaces die relevant zijn vanuit het master data perspectief en daarmee ook voor een architectuur repository. Ieder element is kort beschreven en geeft een beeld welke elementen relevant zijn in de eigen context. Want in de beginsituatie van de introductie van een architectuur repository zullen niet alle concepten relevant zijn. Echter bij een doorontwikkeling van het werken met een architectuur repository zal het register meer en meer een master data functie gaan vervullen in het applicatie landschap van de organisatie.

Dit model geeft aan welke logische componenten binnen de oplossing relevant zijn. Hierbij bestaat de applicatie uit een aantal deelfuncties die vervolgens ook weer uit deelfuncties kunnen bestaan. Deze (sub)functies zijn allen afzonderlijk beschreven in algemene termen.

In het conceptueel model wordt een uitwerking gegeven van hoe de woorden uit de documenten zich verhouden tot elkaar en tot de documenten. Het is hierbij het idee dat en tekst die verwerkt is tot boom in een later stadium opnieuw samengesteld kan worden maar ook dat in een later stadium andere text analyse vormen toegepast kunnen worden. Hierbij is de uitwerking van de graafstructuur in het model uitgewerkt door een koppel object voor koppeling met een daarbij behorend type. Verder is er een onderscheid gemaakt tussen kern en stopwoorden. Het ligt in de verwachting dat de kernwoorden een verdere specialisatie zullen gaan krijgen en de stopwoorden wellicht ook.

Dit is een logisch data model voor een eenvoudige opzet van een referentie data codelijst. Het bestaat in basis uit twee LDM entiteiten waarbij op basis van de CodelijstNaam de lijst van waarden kan worden opgezocht. Er zijn een aantal meer complexe vormen voor deze opzet voor de introductie van hiërarchie Er wordt gewerkt met Begin en Einddatum in een slowly changing dimension opzet. We moeten onderzoeken of dit voor Voorbeeld wenselijk is of dat een ander slowly change beter past bij de context

Diagram met een basis logisch model van de concepten binnen het tijdregistratie domein. Dit bestaat alleen uit entiteiten, relaties en attributen.

Diagram met een basis logisch model van de concepten binnen het vestiging domein. Dit bestaat alleen uit entiteiten, relaties en attributen.

Uitbreiding van het logisch datamodel voor de vestiging waarbij ook enumeraties worden gemodelleerd voor het bepalen van domeinen voor attributen.

Uitbreiding van het logisch datamodel voor het vestiging domein waarbij de specialisaties van de medewerker zijn omgevormd tot een model op basis van rollen die een medewerker kan uitvoeren binnen een vestiging.

Dit patroon gaat in op het verzamelen van meta data bij de dataverwerking, bij voorkeur daadwerkelijk tijdens de dataverwerking zelf. Data transformatie en -verwerking tussen de data bron en -toepassing kent vele vormen en implementaties. Dat betekent feitelijk dat ook tussen de dataverwerking functionaliteiten en het meta data register als data toepassing een data transformatie implementatie ingericht moet worden naar het meta datamodel in het meta data register. Gezien de vele vormen van data verwerking is dit daardoor een complexe implementatie. De context van meta data insertion zit voornamelijk binnen de (technische) implementatie van datatransformatie toepassingen. Soms is dit als implementatie beschikbaar in data transformatie tools (ETL) of in (big) data platformen en data lakes. Echter veel organisaties kennen een divers data transformatie landschap van data transformaties en data verwerking waardoor meta data insertion bij de inrichting van een dergelijke omgeving speciale aandacht vraagt van onder andere de data architect.

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

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

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

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

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

Dit is een logisch data model voor een eenvoudige opzet van een referentie data codelijst. Het bestaat in basis uit twee LDM entiteiten waarbij op basis van de CodelijstNaam de lijst van waarden kan worden opgezocht. Er zijn een aantal meer complexe vormen voor deze opzet voor de introductie van hiërarchie Er wordt gewerkt met Begin en Einddatum in een slowly changing dimension opzet. We moeten onderzoeken of dit voor Medux wenselijk is of dat een ander slowly change beter past bij de context

Dit is een logisch data model voor een eenvoudige opzet van een hiërarchie in de vorm van een boomstructuur in een codelijst. Binnen de codelijstitems kan een hiërarchie opgebouwd worden. Bijvoorbeeld bij een thesaurus opzet. Dit is een eenvoudige opzet en kan desgewenst verder uitgewerkt worden bijvoorbeeld als de associatie gelabeld dient te worden

Dit is een logisch data model voor een eenvoudige opzet van een referentie data codelijst. Het bestaat in basis uit twee LDM entiteiten waarbij op basis van de CodelijstNaam de lijst van waarden kan worden opgezocht. De Hiërarchische lijst wordt gebruikt in scenario's zoals provincie en gemeente

In situaties waar er meerdere sleutels gebruikt worden voor dezelfde entiteit in verschillende bronsysteem zal er een koppeling gelegd moeten worden tussen de bedrijfssleutel en de bronspecifieke sleutels

Overzicht van de transformatie van een NoSQL-database naar een datatarget. Aanvankelijk met een ETL-proces als tussenstap.

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

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

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

Overview of the transformatie from a relational database to a data target

In dit masterdata-consumentenmodel wordt een beperkte weergave van de relevante architecturele entiteiten weergegeven. Hier ziet u een model op hoog niveau van het verbruik van registergegevens. Via verschillende applicatiefuncties wordt data verbruikt. Via gebruikersinterfaces zoals rapporten, portals, geoviewers enz. worden gegevens bijvoorbeeld direct door verschillende eindgebruikers gebruikt. Een gedetailleerde inventarisatie van deze eindgebruikers en gebruikersinterfaces zal worden gemodelleerd.

In dit scenario is er slechts één toepassing voor het produceren van stamgegevens. Dat is het dataregister. Het kan ook een van de bestaande bronsystemen zijn. Alle andere applicaties verbruiken deze gegevens uit het dataregister en gebruiken deze in hun aanvraagprocessen. Dit omvat de applicatiefuncties voor ERP en geo enz. Voordelen:

• Het servicedesign wordt direct in kaart gebracht in het dataregister.
• Mogelijkheid om het informatiemodel en service-interfaces te standaardiseren
• Verificatie en bedrijfsregels worden alleen geïmplementeerd in het dataregister.
• Realtime uitlijning van de gegevens alleen op lezen/verzoek
• Hoge beschikbaarheid alleen nodig voor het dataregister.
• Uiteindelijk geen replicatie van data (afhankelijk van de volwassenheid van de verbruikende systemen)

Nadelen:

• Elke verandering in datamodel bij consumenten leidt tot verandering in service, dit zou op elkaar moeten worden afgestemd of een groot gestandaardiseerd datamodel in de service-interface vereisen.
• Informatievoorziening aan applicaties moet opnieuw worden ontworpen, wat veel werk is
• Herontwerp van het volledige applicatielandschap
• Hoge vraag naar prestaties en beschikbaarheid voor het dataregister
• Invoering van een single point of failure dus extra niet-functionele eisen in AIC

In dit scenario werkt het masterdataregister samen met de verschillende dataproducerende applicatiefuncties. Dit betekent dat wanneer gegevens in een van de systemen worden gewijzigd, deze wijzigingen worden gedeeld tussen alle samenwerkende functies. Daarom is de integratie tussen deze dataproducenten essentieel in dit scenario Een interessant scenario hierbij is dat het Dataregister alleen als sleutelarchief of sleutelkast wordt gebruikt en de detailgegevens in de andere bronsystemen worden bewaard. Voordelen:

• Gegevens worden rechtstreeks uit bronsystemen verzameld en zijn dus altijd nauwkeurig en realtime.
• Gegevens kunnen in de bronsystemen worden opgeslagen in een specifiek formaat dat de bedrijfsprocessen binnen deze systemen ondersteunt
• Verschillen in beschikbaarheid tussen consumenten en bronnen kunnen worden opgevangen door het Dataregister
• Hergebruik van schermen, workflows en validaties in de bronsystemen
• Datastandaardisatie binnen het Dataregister
• Introductie van een sleutelkast of sleutelkast.

Nadelen:

• Het beheren van de synchronisatie tussen systemen is extra werk en complexiteit.
• Replicatie van gegevens
• Complexe datatransformaties van bronnen naar register en terug

In dit scenario is er geen dataregister maar worden alle masterdata opgeslagen binnen de dataproducenten zoals ERP en geofuncties. Voor de dataconsumenten zijn de data echter op gestandaardiseerde wijze beschikbaar via de asset data services. Dit betekent dat wanneer een consument assetdata nodig heeft, dit via de dataservices wordt opgevraagd en uit de verschillende dataproducerende applicaties wordt verzameld. De implementatie van de dataservices zorgt voor de standaardisatie van het masterdatamodel en het data-uitwisselingsprotocol Voordelen:

• Realtime afstemming van de gegevens.
• Eén punt van waarheid en onderhoud
• Geen replicatie van data (en de bijbehorende complexiteit)
• Hergebruik van bestaande gebruikersinterfaces, validaties en (verborgen) integraties

Nadelen

• Het serviceontwerp mag de gegevens niet verbeteren, dus de toepassing moet mogelijk opnieuw worden ontworpen.
• Elke verandering in datamodel in bronnen leidt tot verandering in service, dit moet op elkaar worden afgestemd.
• Verificatie en bedrijfsregels worden geïmplementeerd in bronsystemen.
• Hoge beschikbaarheid en prestatie-eisen voor alle producerende systemen
• Complexe modeltransformaties binnen de servicelaag om voor een specifiek producentensysteemmodel te transformeren naar het vereiste model door de consumenten
• Releases van de bronsystemen worden complexer door de nieuwe afhankelijkheden in de dataservices

In dit scenario worden data verzameld uit de verschillende dataproducerende applicaties en gecombineerd en gestandaardiseerd in het masterdataregister. Dit houdt in dat gegevens worden gewijzigd in een van de gegevensproducerende toepassingen en uiteindelijk worden verrijkt in het gegevensregister. Het dataregister is voornamelijk een datareplicatie met een gestandaardiseerd datamodel van de andere dataproducenten. Een voorbeeld is een datawarehouse Voordelen:

• Alle gegevens direct geïntegreerd bij de hand.
• Standaardisatie van data is mogelijk binnen het Data Register
• Er is een mogelijkheid om gegevens te verbeteren door deze intelligent te combineren tot nieuwe informatie.
• Hoge beschikbaarheid alleen voor het dataregister wanneer consumenten een hoge beschikbaarheid nodig hebben
• Gegevensvalidatie kan worden geïmplementeerd in het systeem waar dit het voordeligst/efficiëntst is
• Hergebruik van schermen, validaties, bestaande data-integraties en workflows
• Ondersteunt een iteratieve migratie naar een meer gecentraliseerd (register)scenario

Nadelen

• Wanneer integratie van data asynchroon is, is de data niet op elk moment hetzelfde als in bronsystemen. Dit zal geen probleem zijn als timing geen probleem is.
• Wanneer de synchronisatie van gegevens synchroon is, zijn hoge beschikbaarheidseisen voor de registersystemen noodzakelijk
• Gegevensreplicatie en behoefte aan extra opslagruimte
• Het heen en weer ophalen en distribueren van data is even veel werk als bij een MDM-oplossing
• Mogelijk zeer complexe datatransformaties nodig

Gedetailleerde ABB voor het beschrijven van de logische service-interface in combinatie met extra governance-functionaliteiten

In dit diagram kan gemodelleerd worden welke data objecten vanuit één of meerdere bronsystemen geextraheerd kunnen worden. Vervolgens wordt gevisualiseerd hoe deze data objecten verband houden met de conceptuele data entiteiten. Dit laatste is gewenst omdat de conceptuele data entiteiten gerelateerd zijn aan de kaderstellende architectuur, de governance dimensies en data management in het algemeen. Voor de data object wordt vervolgens inzichtelijk gemaakt hoe deze data verwerkt wordt. Vaak zullen dit transformaties zijn voor het model of het protocol. Maar ook andere data verwerkingen zijn mogelijk. Denk hierbij bijvoorbeeld aan aggregaties, cleansing of anonimiseren van de data afkomstig uit het datamodel. Hierbij kan vervolgens beschreven worden welke applicatie componenten deze dataverwerking uitvoeren. Voor de data objecten kan er vervolgens een koppeling gelegd worden naar diagrammen waarin het onderliggende logische of fysiekemodel gepresenteerd kan worden.

Diagram met een basis logisch model van de concepten binnen het thuisbezorging domein. Dit bestaat alleen uit entiteiten, relaties en attributen.

Uitbreiding van het basis logisch datamodel voor thuisbezorging. In de uitbreiding zijn enumeraties toegevoegd voor een aantal attributen

In dit diagram wordt de datamodelleervorm basis UML klassenmodel beschreven als modelleerwijze voor logische datamodellering voor de scope van een solution . 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.

Overzicht van de transformatie van een streamingbron naar een datadoel via een ETL-stap naar de dataconsumenten

In een drielaagsdatamodel wil je graag zien hoe de drie lagen aan elkaar verbonden zijn. Voor de verbanden tussen het logische datamodel en het fysieke datamodel wil je graag met mappings laten zien op welke wijze het logische datamodel in de tabellen of berichten in het fysieke datamodel aan elkaar verbonden zijn. In een mapping die je dat op attribuut - kolom niveau. In dit diagram voor de thuisbezorging wordt dit geïllustreerd in een voorbeeld.

In een drielaagsdatamodel wil je graag zien hoe de drie lagen aan elkaar verbonden zijn. Voor de verbanden tussen het logische datamodel en het fysieke datamodel wil je graag met mappings laten zien op welke wijze het logische datamodel in de tabellen of berichten in het fysieke datamodel aan elkaar verbonden zijn. In een mapping die je dat op attribuut - kolom niveau. In dit diagram voor de thuisbezorging wordt dit geïllustreerd in een voorbeeld.

Diagram met een basis logisch model van de concepten binnen het thuisbezorging domein. Dit bestaat alleen uit entiteiten, relaties en attributen.

Uitbreiding van het basis logisch datamodel voor thuisbezorging. In de uitbreiding zijn enumeraties toegevoegd voor een aantal attributen

Objectmodel met instanties voor het bezorgen vvan een bestelling van Peter Ijsma in de uiterwaarden bezorgd door Joke.

Voorbeeld van een model van de verbinding van het data landschap op basis van data of business objecten naar het applicatie landschap voor de tijdregistratie. Hierbij wordt zowel het applicatie gedrag als de actieve structuur in ArchiMate gemodelleerd. Daardoor wordt het mogelijk om impact analyses te doen over de verbinding van applicatie- en datalandschap.

Dit diagram toont de belangrijkste concepten van het tijdschrijven domein. Het tijdregistreren beschrijft een bedrijfsproces vanuit data perspectief en de concepten die rond tijdschrijven van belang zijn.

Een detailproces model in BPMN van tijdregistratie waarin niet alleen de procesactiviteiten en events zijn gemodelleerd maar ook de swimminglanes, de actor die het proces uitvoert. Daarnaast een model met data objecten die een procesactiviteit ingaan of er uitkomen voor een ander proces.

Data Flow Diagram van de tijdregistratie bestaande uit externe actoren, processtappen, stromen van data en eventueel een data store.

Een diagram bestaande uit events en procesactiviteiten van de tijdregistratie en hun onderlinge relaties met daarbij de data objecten die in een proces activiteit worden geconsumeerd en of geproduceerd.

Diagram met deelmodel voor de tabellen waarin de data van het tijdregistratie domein worden opgeslagen. Een deel van de tabellen in het model zullen ook worden gebruikt in de andere deelmodellen. Hierbij ontstaat een gezamenlijk model uitgewerkt in meerdere diagrammen.

In een drielaagsdatamodel wil je graag zien hoe de drie lagen aan elkaar verbonden zijn. Voor de verbanden tussen het logische datamodel en het fysieke datamodel wil je graag met mappings laten zien op welke wijze het logische datamodel in de tabellen of berichten in het fysieke datamodel aan elkaar verbonden zijn. In een mapping die je dat op attribuut - kolom niveau. In dit diagram voor het tijdregistratie domein wordt dit geïllustreerd in een voorbeeld.

In een drielaagsdatamodel wil je graag zien hoe de drie lagen aan elkaar verbonden zijn. Voor de verbanden tussen het logische datamodel en het fysieke datamodel wil je graag met mappings laten zien op welke wijze het logische datamodel in de tabellen of berichten in het fysieke datamodel aan elkaar verbonden zijn. In een mapping die je dat op attribuut - kolom niveau. In dit diagram voor de tijdregistratie wordt dit geïllustreerd in een voorbeeld.

Diagram met een basis logisch model van de concepten binnen het tijdregistratie domein. Dit bestaat alleen uit entiteiten, relaties en attributen.

Objectmodel met instanties van ijsmaken in vestiging Zoetermeer door Beppe

Dit SIPOC diagram geeft een samenvattende weergave welke data naar het proces tijd registreren stroomt en wat de data producten zijn die vanuit tijd registreren geproduceerd worden en naar de consumenten stromen.

Een stermodel is een type dimensioneel model binnen Business Intelligence is een datastructuurtechniek die is ontworpen om gegevens op een manier te organiseren die het eenvoudig maakt om informatie op te halen en te analyseren. Dit model bestaat uit twee hoofdcomponenten: feiten en dimensies. Hier het stermodel van het domein tijdregistratie binnen Alberto.

Diagram met deelmodel voor de berichten waarmee de data van het tijdregistratie domein kunnen worden uitgewisseld. Een deel van de entiteiten binnen de berichten in het model zullen ook worden gebruikt in de andere deelmodellen. Hierbij ontstaat een gezamenlijk model uitgewerkt in meerdere diagrammen.

Diagram met deelmodel voor de berichten waarmee de data van het tijdregistratie domein kunnen worden uitgewisseld. Een deel van de entiteiten binnen de berichten in het model zullen ook worden gebruikt in de andere deelmodellen. Hierbij ontstaat een gezamenlijk model uitgewerkt in meerdere diagrammen.

Een model waarin de tijdregistratie wordt weergegeven in de vorm van bedrijfsfuncties gecombineerd met de data die geproduceerd of geconsumeerd wordt in de vorm van business objecten. Daarnaast de bedrijfsactoren of -rollen die toegewezen zijn aan de bedrijfsfuncties.

Opsomming van beschikbare tools voor inzet als architectuur repository. Dit is geen uitputtende lijst van architectuur repository tools. Gartner produceert jaarlijks een magisch kwadrant van deze tools. Vreemd in deze is dat Sparx Enterprise Architect niet voorkomt in deze kwadranten. Zie voor meer details ook https://www.gartner.com/reviews/market/enterprise-architecture-tools. In dit document is een uitwerking gekozen op basis van Sparx Enterprise Architect. Echter een aantal stappen en model uitwerking komen overeen met de uitwerking in dit document.

In de context van data gedreven werken is de logische toepassing van transformatie van data een karakteristiek patroon. Dit patroon omvat aspecten zoals het extraheren van data uit de bron, transformatie van het model of het protocol en selectie van het bron- en het doelmodel. transformatie bestaat op twee niveaus in de zandloper. De eerste is transformatie van de brondata naar de doeldata in een gestandaardiseerd model. De tweede is de transformatie van het generieke model naar een specifiek model dat door de consument wordt gebruikt. De laatste is niet expliciet gemodelleerd in het zandlopermodel omdat dit wordt beschouwd als een implementatie van de consument.

Diagram met een basis logisch model van de concepten binnen het vestiging domein. Dit bestaat alleen uit entiteiten, relaties en attributen.

Uitbreiding van het logisch datamodel voor de vestiging waarbij ook enumeraties worden gemodelleerd voor het bepalen van domeinen voor attributen.

Uitbreiding van het logisch datamodel voor het vestiging domein waarbij de specialisaties van de medewerker zijn omgevormd tot een model op basis van rollen die een medewerker kan uitvoeren binnen een vestiging.

Dit model is relatief eenvoudig van opzet, er is een applicatie service die wordt ingevuld door één logische applicatie functie. Echter dit kan in andere situaties een meer complexe samenstelling zijn. Wordt er voor de architectuur bouwblokken een register of portfolio opgesteld dan is dit een extra vorm van aggregatie. Alternatief is om via het service portfolio te aggregeren en groeperen. Is een discussiepunt.

Dit is een voorbeeld case waarin we data modellen uitwerken voor Alberto een keten van Italiaanse ijssalons. Op basis van deze uitwerking krijg je een overzicht van de modelleermethoden zoals die toegelicht worden in het boek "Grip op data modelleren. Daarbij zijn in de uitwerking de modellen onderling aan elkaar gerelateerd. Er zijn op basis van drie domeinen in de Alberto case domeinmodellen uitgewerkt:

• Vestiging, registratie van de vestiging gegevens.
• Tijdregistratratie, tijjdschrijven door medewerkers en accordering door vestigingsmanagers
• Thuisbezorging, data benodigd voor het bezorgen van ijs- en koffie producten op locaties van klanten.

De uitwerking is gebaseerd op een aantal deelgebieden rond modelleren en deze deelgebieden zijn gebaseerd op het DM-BoK raamwerk. Hierbij zijn de belangrijkste domeinen uitgewerkt vanuit het perspectief van data modelleren.

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

• Alberto’s is een keten van Italiaanse ijssalons in een aantal plaatsen
• Verkoop van schepijs, ijstaarten en koffieproducten
• Sterk seizoensgebonden (zomer en feestdagen)
• Historisch gezien hebben de filialen een grote mate van autonomie:
• Eigen leveranciers, inkoop, recepten en marketing
• Eigen ICT beleid en budget
• Eigen applicatie en data landschap
• Stafafdeling voor:
• P&O en salarisverwerking
• Facilitaire zaken inclusief een ICT afdeling ter ondersteuning van de filialen
• Gezamenlijke financiële verwerking en rapportage
• Centrale prijs- en productbepaling

Dimensioneel modelleren is een techniek bij het opstellen van een fysiek datamodel binnen relationele databases. Er zijn drie doelen voor dimensioneel modelleren : het classificeren van data in dimensies en facts. Dimensies zijn voor het bieden van hiërarchie in de data voor inzicht. Facts zijn voor vastleggen van de feiten in de werkelijk op een chronologische wijze. Dimensies bieden een vertaling van de datastructuren naar een voor de kenniswerker logische indeling die daardoor sterk kan afwijken van het genormaliseerde OLTP model. Daarnaast bieden facts de mogelijkheid om inzicht te krijgen op basis van data bevroren in de tijd.

Dimensioneel modelleren is een techniek bij het opstellen van een fysiek datamodel binnen relationele databases. Er zijn drie doelen voor dimensioneel modelleren : het classificeren van data in dimensies en facts. Dimensies zijn voor het bieden van hiërarchie in de data voor inzicht. Facts zijn voor vastleggen van de feiten in de werkelijk op een chronologische wijze. Dimensies bieden een vertaling van de datastructuren naar een voor de kenniswerker logische indeling die daardoor sterk kan afwijken van het genormaliseerde OLTP model. Daarnaast bieden facts de mogelijkheid om inzicht te krijgen op basis van data bevroren in de tijd.

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.

Het fysieke datamodel beschrijft de manier waarop gegevens in een databank zijn opgeslagen of in een bericht worden uitgewisseld. De verbinding tussen het logische en het fysieke datamodel wordt gelegd door het omzetten van de logische gegevensobjecten in database-definitie instructies conform een bepaalde Data Definition Language (DDL). Na uitvoeren van de DDL op een fysieke database, liggen de definities van de database-objecten vast in de data dictionary van die database. Of voor berichten in een schema definitie dat vastligt in een XSD. Fysieke modellering richt zich voornamelijk op het technische aspect.

Binnen fysieke datamodellen zijn volop data patronen beschikbaar. Veelal worden ze ook ingezet in modelleertools om het werk van de fysieke datamodelleur te vereenvoudigen met geautomatiseerde toepassingen. Daarnaast zijn er volop datamodellen die beschikbaar zijn om een start te maken met datamodellen voor een bepaald werkveld. Zoals bijvoorbeeld order registratie of gestandaardiseerde werkprocessen. In dit voorbeeld een eenvoudig voorbeeld van een fysiek model dat een transformatie is in een relationeel database management systeem op basis van een standaard modelleer concept in een logisch datamodel.

Het logisch model wordt uitgewerkt op basis van de modelleertaal UML en dan met name het klassediagram. Het biedt daarmee de mogelijkheid om de data in detail te modelleren maar het staat nog steeds los van de fysieke implementatie.

Het logische datamodel beschrijft de structuur van en de referenties tussen de logische gegevensobjecten, genaamd objecten of tabellen. Het conceptuele model is verbonden aan het logische model doordat entiteiten worden omgezet in objecten of tabellen (of preciezer: -definities), en doordat er een detaillering plaatsvindt van de relaties en attributen. Het logische datamodel focust op semantisch- en syntactisch vlak.

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.

Uitwerking van het model op basis van logische applicaties inclusief de uitwerking van de deelfuncties

Het logisch model wordt uitgewerkt op basis van de modelleertaal UML en dan met name het klassediagram. Het biedt daarmee de mogelijkheid om de data in detail te modelleren maar het staat nog steeds los van de fysieke implementatie.

Logische datamodellering is een model uitgewerkt zonder de implementatie aspecten van de onderliggende technische platformen. Binnen logische datamodellering zijn patronen veel toegepast. Er zijn dan ook veel catalogi te vinden met logische datamodelleer patronen. Hier behandelen we een viertal voorbeelden van dergelijke logische datamodel patronen.

Data patronen zijn generieke oplossingen voor frequent terugkerende meta data problemen. Voor dataverwerking en -vergaring is dit kenmerkend rond meta data. Dataverwerking en -transformatie is van zichzelf al een uitdaging. De behoefte om op adequate wijze ook de meta data te verzamelen en te registreren is daarmee een extra complicerende factor. In onderstaande paragrafen worden daarom een aantal kenmerkende meta data patronen beschreven.

Dit is een pakket met vier logische scenario's voor de implementatie van een Master Data-oplossing. Deze logische modellen hebben geen relatie met enige fysieke implementatie. Daarom is de lange lijst met alternatieven relevanter. Deze scenario's kunnen helpen in de volgende situaties:

• Functionele vereisten toewijzen aan scenario's
• Het in kaart brengen van niet-functionele eisen en kwaliteiten aan scenario's
• Complexiteitsanalyse van scenario's
• Mogelijke oplossingen en componenten toewijzen aan scenario's

Logische datamodellen met een uitwerking voor verschillende referentie data logische structuren met data entititeiten, attributen en assoociaties.

In het logische applicatie model beschrijven we alleen welke logische applicatiefuncties nodig zijn binnen de oplossing zonder te kijken naar de beschikbare componenten en informatiesystemen. Dit helpt bij het maken van een technisch onafhankelijk applicatie model dat later kan worden gebruikt om verschillende oplossingsscenario's en componentstapels te modelleren. Deze stapels worden geanalyseerd en met elkaar vergeleken op basis van de functionele en niet functionele eisen.

Objectmodellen zijn diagrammen waarbij instanties worden gemaakt van een aantal klassen in het logisch klassemodel. Het kan gebruikt worden om voorbeelden te presenteren aan eindgebruikers met voor hen herkenbare objecten binnen het klassemodel.

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

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

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