Data Architectuur Metamodel | Master en Referentie Data | Objecten | Register Data Publicatie en Integratie Service |

Register Data Publicatie en Integratie Service

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

Package Objecten
Auteur 102401
Alias
Stereotypes ApplicationService

Diagrammen

Scenario consumenten perspectief

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.
Diagram in repository

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

MRDM Logisch Applicatie Model

Diagram in repository

Gekoppelde elementen

Objecten

Links 2 Tags

Archimate Architect Architectuur Architectuur document Architectuur repository Ario Azure Big data Bouwblokken en patronen Bpmn Criteria Custodian Data Data architectuur Data governance Data kwaliteit Data management Data modelleren Database Datamodelleren Document Enterprise architect Enterprise architectuur Idea Image library Instruction Intervisie Logisch applicatie model Master data Matrix Mdg Metadata Metafoor Metamodel Modelleren Open source Principes Register Releasemanager Repository Simulator Software Sparx enterprise architect Sql Stakeholders Stappenplan Time aware modelleren Tips en tricks Training Videokanaal Viewpoint Webvideo Werkproces Whitepaper Wpp