Abstracte Logische data entiteit is een hierarchische indeling van de logische data entiteiten. Metbehulp 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 hierarchien 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.

Applicatie integratie interfaces voor machine 2 machine integratie

Applicatie integratie interfaces voor machine 2 machine integratie

Application integration interfaces for machine 2 machine integration

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.

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.

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.

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

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

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

Eigenschappen van de software die van invloed zijn op de benodigde inspanning van de gebruiker om het logische concept en de toepassing daarvan te herkennen

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.

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.

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

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.

Logische service voor de import van data voor andere systemen

Logische service voor de import van data voor andere systemen

Logical service for the import of data from other systems and sources

Register function for the governance of data sets in relation to consumers, business owners and qualities.

In deze viewpoints worden de verschillende notatiewijzen beschreven waarmee de data catalogus kan worden opgebouwd. Het is initieel gebaseerd op vier hoofdelementen maar kan eenvoudig worden uitgebreid. De elementen zijn:

• Data Management
• Conceptueel model
• Logisch model
• Fysiek model

Uitbreidingen waar je aan kunt denken zijn bijvoorbeeld Data Security, Privacy maar ook aan interfaces zoals webservices, webapi's NoSQL etc. Indien deze later binnen de community relevant blijken te zijn dan worden deze alsnog uitgewerkt

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

Transformation of the data as stored in the asset data registration and transformation to a model for messages (CGMES, data marts or file formats).

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.

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.

Functionality to publish the data as stored in the data registration for use of various consumer types.

MDM like function that aggregates all the data in a standardized data model

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

Actual registration function with storage and processing of the master 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

Validation of data based on the data entered in the system and eventually on the existing data stored in the master data registration. It is essential that all the data received from the acquisition/registration service is processed in these functions before it is stored in the data register

• 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

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.

ERP (or EAM) functionality for the registration of data within a number of highly standardized processes using 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

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.

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

Geo functionality and register in combination with the extraction of asset data in combination with geo data and maps

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.

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.

Issue registratie voor kwaliteitsissues

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

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

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

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

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

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

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

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.

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.

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

Abstract architectural entity for the register data consumers, all user interfaces and data integrations are an master data consumer

Application and database integration like webservices, file transfer, database links, views etc. In a later phase we will model the various integration methods and model these in detail

All kinds of user interfaces in which an user can consume data via a (graphical) user interface. Examples of user interfaces are reports, forms, portals graphs, geoviews etc.

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

Logical application function for the storage and transformation of master data in various source function and the data register function

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

Logical services that publish the data from the register to various register data consumers

Function for the registration and extractions of governance aspects of the datasets published over the logical services. For example data qualities, connection requirements and the standardized object or information model

A registration is a record in which is described that a trainee particates in a training

(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

Administration and registration of security concepts in a Big Data environment.

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.

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

User interfaces for human interaction with the data stored in the data registration

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 BOL.Com maar hier voor geregistreerde gebruikers

Whitepaper met een introductie over Meta Data. Wat is het hoe kun je gebruiken, waar komt meta data vandaan en hoe registreer je meta data 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 en hoe de stakeholders daarbij betrokken zijn ondersteunt de introductie van effectieve analytics. In dit whitepaper hebben we een combinatie van modelleervormen beschreven die een (minimale) set is van generieke notatiewijzen op basis waarvan data analytics in organisaties gemodelleerd kunnen worden. Voor specifieke toepassingen kunnen specialistische modelleervormen nodig zijn.

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

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

Service hergebruik is een belangrijk onderliggend principe voor de inzet van service registers

Beschrijving van governance en continuiteitsproblemen bij inzet van een service register.

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.

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.

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.

Een voorbeeld van een hiërarchie van de entiteiten in het conceptuele datamodel. Deze afbeelding is een weergave specifiek voor het gebruikte modelleertool. Echter ook andere modelleertools zullen een dergelijke weergave kennen. Het voorbeeld is uitgewerkt in ArchiMate, deze modelleertaal bestaat uit een gestereotypeerde graaf waarin op eenvoudige wijze te zien is welke verbanden er zijn tussen de concepten op basis van verschillende soorten associaties, zoals specialisatie, aggregatie en een associatie. De concepten zijn in dit voorbeeld uitgewerkt als ArchiMate business objecten Kenmerken Het conceptueel model (begrippenlijst en begrippenboom) heeft de volgende kenmerken:

• Krachtige notatiewijze waarin begrippen op eenvoudige wijze aan elkaar gerelateerd kunnen worden
• Eenvoudig toepasbaar bij gebruik voor stakeholders zonder modelleerervaring
• Kan goed gebruikt worden in interactieve workshops
• Toepasbaar op hoge abstractie niveaus, voornamelijk conceptueel
• Goed eerste startpunt bij een top down benadering van een objectmodel
• Goed model om discussie op gang te brengen tussen domeinexperts
• Belangrijk hulpmiddel bij het opstellen van datamodellen bij ketenintegraties
• Hiërarchieën kunnen complex worden als er veel generalisaties worden gebruikt

Toepassingen Conceptuele datamodellen worden vooral toegepast op een hoog abstractieniveau van datamodellering. Het biedt een goed startpunt voor het in kaart brengen van het gegevensdomein. In complexe domeinen is de begrippenboom een goed startpunt om te komen tot een gezamenlijk domeinmodel waarbij de begrippen de hoogste hiërarchie omvatten. Houdt er rekening mee dat ondanks de eenvoud van de notatiewijze het opstellen van een conceptueel model een complex traject kan zijn, zeker bij een complex domein of binnen een organisatiecontext waar rond datamodellering weinig volwassenheid is. Gerelateerde domeinen Gezien het hoge abstractieniveau van het conceptueel model is het een centraal model voor meta data. In onze drie bij drie matrix zijn alle andere domeinen op enigerlei wijze gerelateerd aan het conceptueel datamodel Binnen ArchiMate is in het voorbeeld met behulp van business objects een begrippenboom opgesteld. Deze objecten worden vervolgens als koppelpunt naar bijvoorbeeld bedrijfsprocessen of -functies ingezet. Ook wordt de begrippenboom veelvuldig gecombineerd met een Logisch Data Model. Hiermee ontstaat een hybride datamodel waarbij de begrippenboom als startpunt dient op een hoog abstractieniveau en logisch datamodel de detaillering van deze begrippen uitwerken in de klassen, attributen en associaties.

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 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 layer).
• Voor het conceptueel data model wordt alleen het stereotype Business Object gebruikt.
• Het conceptuele model heeft een hierarchische 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.
• Hetconceptuele model kan gerelateerd worden aan bijvoorbeeld de andere data management business functies binnen Medux.

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

Voor meta data management kan een raamwerk uitgewerkt worden. Met dit raamwerk wordt een registratie gedefinieerd voor de verschillende data management kennisgebieden. Dit raamwerk bestaat veelal uit een groeimodel en is specifiek voor iedere organisatie. Enerzijds vanwege de structuur van de organisatie en anderzijds door de volwassenheid van de organisatie op het vlak van data management. In onderstaande afbeelding zie je een drie bij drie matrix waarin een beperkt aantal kennisgebieden zijn gedefinieerd. Deze matrix zal als indeling gelden voor de rest van dit whitepaper. In de afbeelding worden drie categorieën voor kennisdomeinen genoemd namelijk beschrijvend, kaderstellend en omgeving. De onderwerpen binnen deze domeinen kunnen beschouwd worden als een startpunt voor het uitwerken van meta data management vanuit het perspectief van data management. Dit gaan we doen door voor ieder onderwerp een aantal modelleerwijzen te introduceren waarmee de stakeholders zich op eenvoudige wijze een adequaat beeld kunnen vormen van de situatie van dit meta data onderwerp. In de afbeelding zijn naast de negen kennisdomeinen een viertal pijlen opgenomen. Deze pijlen geven aan dat de kennisdomeinen met elkaar verbonden dienen te zijn. Hierbij neemt het beschrijvende model een centrale plaats in, meer specifiek het conceptueel model. De entiteiten in dit model fungeren feitelijk als centraal koppelpunt voor alle andere aspectgebieden. In de volgende hoofdstukken zullen we van ieder onderwerp een beschrijving geven van een registratie. Echter deze registratie doen we op basis van een aantal gestandaardiseerde modelleertechnieken zoals ArchiMate, UML Klasse diagrammen en ER Diagrammen. Ook hierbij is het uitgangspunt van een startpunt gebruikt. Bij een verdere uitwerking van het meta data model is het desgewenst eenvoudig mogelijk om extra modelleertechnieken toe te voegen.

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

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.

In this viewpoint we see the relationship of the logical model with the conceptual model. An association is therefore made between two modeling languages and that is a specific extension for IDEA and is not part of both standards. Within EA there are three standard association types for modeling between modeling languages. Within IDEA we opt for the trace association for an association between the three modeling layers.

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 this scenario the master data register collaborates with the various data producing application functions. This means that when data is modified in one of the systems these modifications are shared between all collaborating functions. Therefore the integration between these data producers is essential in this scenario An interesting scenario in this is where the Data Register is only used as a key store or key cabinet and the detailed data is kept in the other source systems Advantages - Data is gathered directly from source systems and thus it is always accurate and real time. - Data can be stored within the source systems in a specific format supporting the business processes within these systems - Differences in availability between consumers and sources can be handled by the Data Register - Reuse of screens, workflows and validations in the source systems - Data standardization within the Data Register - Introduction of a key store or key cabinet. Disadvantages - Managing the synchronization between systems is an extra piece of work and complexity. - Replication of data - Complex data transformations from sources to register and back

In this scenario data is collected form the various data producing applications and combined and standardized in the master data register. This means that data is modified in one of the data producing applications and eventually enriched in the data register. The data register is mainly a data replication with a standardized data model of the other data producers. An example is a datawarehouse Advantages - All data directly integrated at hand. - Standardization of data is possible within the Data Register - There is a possibility to enhance data by intelligently combing it to new information. - High availability only for the data register when consumers need a high availability - Data validation can be implemented in the system where it is most advantageous/efficient - Reuse of screens, validations, existing data integrations and workflows - Supports a iterative migration to a more centralized (register) scenario Disadvantages - When integration of data is asynchronous the data is not the same as in source systems on every moment. This will not be a problem if timing is not an issue. - When synchronization of data is synchronous high availability requirements for the registry systems is necessary - Data replication and need for extra storage - Fetching and distributing data back and forth is equally much work as with an MDM solution - Possible very complex data transformations necessary

In this scenario there is only one master data producing application. That is the data register. It can also be one of the existing source systems. All other applications are consuming this data from the data register and use this in their application processes. This includes the application functions for ERP and geo etc. Advantages - The service design is directly mapped in the data register. - Possibility to standardize the information model and service interfaces - Verification and business rules are implemented only in the dasset data register. - Real time alignment of the data only upon read/request - High availability only necessary for the data register. - Eventually no replication of data (depends on the maturity of the consuming systems) Disadvantages - Any change in data model in consumers leads to change in service, this should be aligned or require a large standardized datamodel in the service interface. - Information provisioning to applications needs to be redesigned which is a lot of work - Redesign of the full application landscape - High demand in performance and availability for the data register - Introduction of a single point of failure so extra non functional requirements in AIC

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 this scenario there is no data register but all master data is stored within the data producers like ERP and geo functions. However for the data consumers the data is available via the asset data services in a standardized manner. This means that when a consumer needs asset data this is requested via the data services and collected from the various data producing applications. The implementation of the data services handles the standardization of the master data model and the data exchange protocol Advantages - Real time alignment of the data. - Single Point of Truth and Maintenance - No replication of data (and the involved complexity) - Reuse of existing user interfaces, validations and (hidden) integrations Disadvantages - The service design should not enhance the data so the application might have to be redesigned. - Any change in data model in sources leads to change in service, this should be aligned. - Verification and business rules are implemented in source systems. - High availability and performance needs for all the producing systems - Complex model transformations within the service layer to transform for specific producer system model to the required model by the consumers - Releases of the source systems become more complex because of the new dependencies in the data services

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

In this master data consumer model a limited view of the relevant architectural entities are displayed. Here you see a high level model of register data consumption. Via different application functions data is consumed. For example via user interfaces like reports, portals, geo viewers etc data is directly consumed by various end users. A detailed inventarization of these end users and user interfaces will be modeled.

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.

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.

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

In deze viewpoints worden de verschillende notatiewijzen beschreven waarmee de data catalogus kan worden opgebouwd. Het is initieel gebaseerd op vier hoofdelementen maar kan eenvoudig worden uitgebreid. De elementen zijn:

• Data Management
• Conceptueel model
• Logisch model
• Fysiek model

Uitbreidingen waar je aan kunt denken zijn bijvoorbeeld Data Security, Privacy maar ook aan interfaces zoals webservices, webapi's NoSQL etc. Indien deze later binnen de community relevant blijken te zijn dan worden deze alsnog uitgewerkt

• 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

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.

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

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.