Voor de transformatie van woorden naar tref- en of stopwoorden kunnen transformatieregels ingezet worden. Denk hierbij bijvoorbeeld aan het herleiden van woorden naar een stam waarvoor geautomatiseerde transformatieregels opgesteld kunnen worden.

Verrijken en transformeren van data van en naar geo locaties bijvoorbeeld door gebruik van database logica en software

Transformatie ten behoeve van integratie is een veelvoorkomende bron van precisieproblemen bij integratie. Analyseer risico’s en zoek naar componenten en integratievormen die de gewenste precisie tijdens data transport kunnen handhaven.

Bij het bewaren van de log is een getrapte indeling te maken met de volgede indeling

• Laatste vijf minuten (hoge actualiteit, tijdigheid en beschikbaarheid) met name voor de inzet van signalering, monitoring en monitoring dashboards)
• Laatste half jaar (normale actualiteit, tijdigheid en beschikbaarheid) voor de inzet van rapportages omtrent het berichtenverkeer en het gebruik van de verschillende componenten
• Ouder dan een half jaar (lage actualiteit, tijdigheid en beschikbaarheid). Alleen te gebruiken voor toezichthouders en eventueel voor vergelijken van rapportages over een langere periode

Daarnaast is het van belang dat goed nagedacht wordt over wat bewaard wordt, alleen de berichtheaders of ook delen van de inhoud. Tevens dient nagedacht te worden wanneer de transformatie naar de signalering en rapportage structuren gedaan wordt

Opbouw van de boomstructuur naar een graaf of boom waarbij op basis van de transformatie regels en de interactie met de experts bepaald wordt welke associaties er horen bij de verschillende termen.

Converteren van datatypes naar andere datatypes (tekst {-} Numeriek). Inclusief transformatie naar datatypen op andere platformen zoals database, XML, softwaretalen en localisatie.

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

Transformatie van data naar diverse protocollen, bijvoorbeeld voor de implementatie van webservices, REST maar ook naar een voor rapportages leesbaar formaat

Transformatie van data naar diverse protocollen, bijvoorbeeld voor de implementatie van webservices, REST maar ook naar een voor rapportages leesbaar formaat

Deepsee is een replicatie van de ZIM data en is ingericht om de performance van de ZIM te handhaven. In Deepsee vinden complexe transformaties plaats naar fact en dimension modellen. In deepsee zijn ook de datamarts geimplementeerd.

Omdat er naar verwachting meerdere afnemers zijn van rapportage data bijvoorbeeld de leveranciers de interne beheerafdelingen binnen de infrastructuurleverancier en management en wellicht toezichthouders zal er bij deze rapportage interfaces een ETL inrichting gewenst zijn. Dit omdat iedere afnemende toepassing eigen wensen heeft rond de transformatie, selectie en filtering.

Automatiseer datapipes om het proces van gegevensopname, gegevensintegratie, gegevenstransformatie en gegevensanalyse te stroomlijnen. Beheer en verwerk grote hoeveelheden gegevens efficiënt, verkrijg zinvolle inzichten, neem weloverwogen beslissingen.

De gegevenstransformatie en verrijking zorgt ervoor dat de gegevens voor opslag in een databank getransformeerd worden naar een formaat dat voor de afnemende toepassingen gewenst is. Daarbij spelen issues als beschikbaarheid en verwerkingstijd van de transformaties mede een rol.

Import en handmatige transformatie van kantoordocumenten zoals Excel sheets etc.

Import en handmatige transformatie van kantoordocumenten zoals Excel sheets etc.

Deze functie biedt de mogelijkheid om data uit berichten verkeer of andere messaging protocollen op te halen en mee te nemen in de datatransformaties in een ETL proces

Stored procedures en functions maken het mogelijk om transformaties, controles en validaties te automatiseren in de vorm van scripts binnen deze stored procedures en functions. Hiermee heb je vanuit deze programmatuur direct toegang tot de inhoud van de verschillende tabellen.

Data modellering en meta modellering voor voorbeeldmodellen op basis van UBL en overheidsmodellen. Deze modellen worden gebruikt voor de opslag van de data maar ook voor de data integratie, - transformatie en - validatie

Data modellering en meta modellering voor voorbeeldmodellen op basis van UBL en overheidsmodellen. Deze modellen worden gebruikt voor de opslag van de data maar ook voor de data integratie, - transformatie en - validatie

Transformeren van modellen en protocollen. Bijvoorbeeld van en naar een Canoniek Model transformeren en protocol transformeren XML naar JSoN vice versa.

Een Architectuur Repository staat niet op zich in een applicatielandschap. Data moet uitgewisseld worden van en naar de architectuur repository. Hierbij is modeltransformatie bijna altijd noodzakelijk.

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

ETL verwerkt voor de transformatie van data van relationele naar relationele databases of gestructureerde bestanden

ETL verwerkt voor de transformatie van data van relationele naar relationele databases of gestructureerde bestanden

(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

In dit document wordt nadat de solution voor het werken met een architectuur repository is uitgewerkt een aantal generieke stappenplannen uitgewerkt. Deze stappenplannen geven een team een leidraad welke activiteiten uitgevoerd dienen te worden om de transformatie van een document gedreven werkwijze naar een repository gedreven werkwijze te realiseren. De stappenplannen in dit document bestaan uit een aantal generieke activiteiten voor de introductie van een architectuur repository. Echter deze stappen kunnen eenvoudig worden uitgebreid in de specifieke context van de eigen organisatie. Uitwerking is op basis van de volgorde van uitwerken van de architectuur en vervolgens een stappenplan voor het introduceren van de tooling van de architectuur repository.

Applicatie functie die geautomatiseerd een document omzet naar een lijst van termen inclusief de juiste vulling van de koppeltabel voor termen en documenten

Transformeren en modelleren van de bron data naar de gewenste rapportage vorm. Dit kan een sterschema of kubus zijn of een platte dataset in het geval van een data levering.

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

Het mappingdiagram wordt gebruikt om inzichtelijk te maken hoe de datum van een brontabel naar een doeltabel stroomt. Daarbij worden mappings gemaakt. Dit zijn lijnen vanuit welke kolom uit de brontabel verbonden is met een kolom in de doeltabel. In een aantal gevallen dienen kolommen bij de transformatie uitgesplitst of samengevoegd te worden. Hoe dit wordt gedaan is te zien in tussen elementen in het mdoel mergers en splitters genoemd. In dit diagram zien we een aantal mapping voor vestigingdata.

In dit document wordt nadat de solution voor het werken met een architectuur repository is uitgewerkt een aantal generieke stappenplannen uitgewerkt. Deze stappenplannen geven een team een leidraad welke activiteiten uitgevoerd dienen te worden om de transformatie van een document gedreven werkwijze naar een repository gedreven werkwijze te realiseren. De stappenplannen in dit document bestaan uit een aantal generieke activiteiten voor de introductie van een architectuur repository. Echter deze stappen kunnen eenvoudig worden uitgebreid in de specifieke context van de eigen organisatie. Uitwerking is op basis van de volgorde van uitwerken van de architectuur en vervolgens een stappenplan voor het introduceren van de tooling van de architectuur repository.