Data Architectuur Metamodel | Master en Referentie Data | Objecten | Overige Data Producenten |

Overige Data Producenten

Overige MDM data producerende applicatie functies zoals kantoorautomatisering.

Package	Objecten
Auteur	102401
Alias
Stereotypes	ApplicationFunction

Diagrammen

Scenario model data verzamelen

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

Diagram in repository

Scenario model data samenwerking

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

Diagram in repository

Scenario model data service

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

Diagram in repository

Scenario model data registry

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

Diagram in repository

Overige Data Producenten

Diagrammen

Scenario model data verzamelen

Scenario model data samenwerking

Scenario model data service

Scenario model data registry

Gekoppelde elementen

Objecten

Links 2 Tags