Door de wereldwijde data management community (dama.org) is in de afgelopen jaren een model ontwikkeld in de Data Management Body of Knowledge (DMBoK). Dit is een praktisch uitgewerkt raamwerk met elf kennisgebieden. Hieronder een visuele representatie van het raamwerk en een korte definitie van ieder kennisgebied.  

• Data Governance: Is het uitvoeren van controle en beheer omtrent het beheer van data assets. Data Goverance stuurt alle andere dataprocessen
• Data architectuur: Managen, ontwikkelen en beheren van de requirements en principes rond data
• Data modelleren: Is het ontdekken, analyseren en beschrijven van data requirements in de vorm van gestandaardiseerde modellen die een data structuur beschrijven
• Data storage en operations: Ontwerp en implementatie van data opslag en -persistentie
• Data security: Activiteiten rond de bescherming van informatie en data door autorisatie, authenticatie, toegang, auditing
• Data integratie en interoperabiliteit: Managen van het transport en consolidatie van data tussen informatiesystemen en organisaties
• Document- en content management: Managen en (levensloop)beheer van alle soorten data inclusief documenten en content
• Reference en Master Data: Managen van generieke en algemene (herbruikbare) data en referentie data (codelijsten e.d.)
• Datawarehousing en BI: Planning, ontwikkeling en beheer van activiteiten voor het samenstellen van data ter ondersteuning van besluitvorming en kenniswerkers
• Meta Data: Managen, ontwikkelen en beheren van metadata.
• Data kwaliteit: Activiteiten voor kwaliteitsmanagement van data assets zodat het geschikt is voor gebruik en voldoet aan de wensen van de data consumenten

In het DMBoK is meta data een separaat kennisgebied en is in detail uitgewerkt. Hiermee kunnen we de verschillende data entiteiten binnen een organisatie in de context van de afzonderlijke data management kennisgebieden plaatsen.

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.

Applicatie interfaces voor applicatie naar applicatie integratie. Dit omvat de volledig geautomatiseerde systeem integratieprocessen, ETL implementaties en de geautomatiseerde en beheerde bestandsoverdracht.

Applicatie interfaces voor applicatie naar applicatie integratie. Dit omvat de volledig geautomatiseerde systeem integratieprocessen, ETL implementaties en de geautomatiseerde en beheerde bestandsoverdracht.

Applicatie integratie interfaces voor machine 2 machine integratie

Applicatie integratie interfaces voor machine 2 machine integratie

Toepassen van architectuur principes, architectuur principes kunnen bij de uitwerking binnen projecten (bijvoorbeeld in een PSA) zorg dragen dat toegewerkt wordt naar een informatievoorziening die bijdraagt aan een hoge consistentie van data bij opslag, integratie en gebruik.

Beperken van replica’s brengt met zich mee dat de kans op verschillende inhoud van datasets kleiner wordt. Zeker de situaties waarbij replica’s veranderd en verrijkt worden tijdens de data integratie zijn veroorzakers van inconsistentie en moeten daardoor ontmoedigd worden.

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.

Beveiliging van integratiestromen zal bijdragen aan de beveiliging van de gegevensset tijdens het transport. Dit gebeurd veelal door het versleutelen van de gegevensstroom en het authenticeren en autoriseren van bron- en afnemers. Houdt er rekening mee dat deze activiteiten een negatief effect kunnen hebben op de andere kwaliteiten als actualiteit en tijdigheid. Door het uitwerken van de verschillende beveiligingsvormen kan een adequate keuze van maatregelen gemaakt worden.

Applicatie of organisatie overstijgende sleutels, bij data integratie kan een sleutel vanuit een bronsysteem onvoldoende uniek zijn. Zeker in het geval waar bijvoorbeeld gegevensset gecombineerd worden met andere sets kunnen aanvullende maatregelen noodzakelijk zijn. In die gevallen kan het benoemen van sleutels met voldoende uniekheid vanuit architectuur of de eigenaar van gegevenssets noodzakelijk zijn. Denk bijvoorbeeld aan het BSN en KvK nummer als organisatie overstijgende sleutel.

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.

Functionaliteiten kunnen worden geconfigureerd zodat de werking aangepast kan worden naar de specifieke situatie van de gebruikende organisatie, relevant voor zaken zoals valideren, integratie en publiceren.

Beleggen eigenaarschap en beheerorganisatie. Hiermee wordt gerealiseerd dat de definitie van een gegevensentiteit bewaakt wordt door een eigenaar en dat de beheerorganisatie zorgdraagt voor de bewaking van deze consistentie op basis van de door de eigenaar benoemde definitie. De integratie is vervolgens gebaseerd op deze definitie.

Zeker bij grote organisaties zullen er al diverse onderdelen van het architectuurmodel zijn uitgewerkt in andere tools. Deels door de architecten zelf, deels door andere stakeholders. Hier moeten afspraken over worden gemaakt over het gebruik van verwijzigingen of integratie hulpmiddelen.

Stel generieke eisen aan gangbare validaties zoals datum en numerieke waarden, postcodes etc en beschrijf hoe en waar deze geïmplementeerd en getest moeten worden. Dit kan zowel op gegevensopslag als op gegevensintegratieval geïmplementeerd worden.

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.

Er is een duidelijk (technisch) ontkoppelpunt voor integratie tussen bron (leverende partij) en de D&A omgeving (ontvangende partij). Kwaliteit van de geleverde data (volledigheid, juistheid, tijdigheid) is verantwoordelijkheid van de bron. Integratie is gestandaardiseerd en volgt de integratie architectuur principes.

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

Uitwisselen van (deel)modellen op basis van de ArchiMate uitwissel standaard zodat uitwisseling met andere (ArchiMate) modelleertools mogelijk is

Uitwisselen van (deel)modellen op basis van de BPMN uitwissel standaard zodat uitwisseling met andere (BPMN) modelleertools mogelijk is

Component toegewezen aan de integratie functie als middleware functionaliteit.

Naamgeving: {naam van de service} Afnemer Bijvoorbeeld: Relatie_SRV Afnemer

Betreft de interface binnen de integratielaag die toegang geeft tot de bron. Dit kan een IMH of ORCH zijn. Naamgeving: {naam van de service} Bron Bijvoorbeeld: Relatie_SRV Bron

Voor de uitwisseling van data (import en export), met name voor incidentele uitwisseling via bijvoorbeeld CSV of XLS bestanden dienen configureerbare voorzieningen aanwezig te zijn

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.

Uitwisselen van (deel)modellen op basis van de UML uitwissel standaard zodat uitwisseling met andere (UML) modelleertools mogelijk is.

Integratievorm keuze bijvoorbeeld door inzet van beslisbomen opgesteld vanuit architectuur kunnen zorgdragen dat op het vlak van tijdigheid voldoende rekening gehouden wordt met de risico’s die gelden. Dit zal uitgewerkt worden in de projectdocumenten zoals de PSA e.d.

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 servicecontract of gegevensleveringsovereenkomst. Deze documenten met afspraken kunnen redelijkheid formaliseren en op deze wijze een bijdrage leveren aan een realistische uitwerking van vraag en aanbod op diverse aspecten van redelijkheid bij data integratie. Denk hierbij aan de uitwerking van bijvoorbeeld tijdigheid, actualiteit, consistentie en validiteit Om redelijkheid te ondersteunen is het van belang dat voor de belangrijkste gebruiksgevallen beschreven is wat de redelijkheidsgrenzen dienen te zijn. Dit houdt in dat aangegeven wordt in welke situatie de kwaliteiten dermate laag zijn dat redelijkheid niet meer geldend is.

Kies integratievormen die een maximale mutatiesnelheid ondersteunen. De ene integratievorm kent een snellere doorlooptijd dan een andere. Zo zal berichtuitwisseling veelal een betere bijdrage leveren aan de actualiteit bij integratie dan bijvoorbeeld bestandsuitwisseling. Voor de inrichting van deze integratievormen kunnen aanvullende infrastructurele voorzieningen noodzakelijk zijn. Denk bijvoorbeeld aan de inzet van servicebus- of orchestratieplatformen Bepalen van inrichtingswijzen zoals ETL, service technologie en databaseconcepten als views e.d. die de gewenste behoefte aan actualiteit adequaat ondersteunen.

Inrichten dataclassificatie, slechts voor een beperkt aantal typen gegevenssets speelt privacy een rol. Denk bijvoorbeeld aan persoonsgegevens of gegevens over financiën, opsporing en handhaving. In alle andere gevallen zijn bij integratie privacy aspecten van minder belang. In die situatie kan volstaan worden met minder maatregelen voor de beveiliging. Door in kaart te brengen voor welke data objecten privacy relevant is kan eenvoudig bepaald worden in welke projecten met data integratie aanvullende maatregelen nodig zijn.

Beschrijving van data objecten en – attributen. Door een gedetailleerde en gestructureerde beschrijving te maken van data objecten die ingezet worden voor data integratie wordt het mogelijk om op basis van deze beschrijving validaties te ontwikkelen en deze te implementeren in bovengenoemde validatie componenten.

Inzet van protocollen. Denk hierbij bijvoorbeeld aan WS-reliable messaging dat kan zorgdragen voor het compleet afleveren van een gegevensset, het zorgdragen voor de juiste volgorde van de pakketten na ontvangst en dergelijke. Dit soort protocollen kunnen zorgdragen voor een voldoende hoge integriteit

Selectie van open standaarden, bij het ontwikkelen van open standaarden zal het precisie aspecten aan de orde komen. Hiermee zal de precisie aansluiten op de wensen van een grote groep organisaties. Door het inzetten van deze standaarden bij de integratie zal de precisie voldoende gewaarborgd zijn.

Keuze (open) standaarden, deze zijn veelal gebaseerd op syntactisch in detail uitgewerkte informatiemodellen en kunnen daardoor goed gevalideerd worden door bijvoorbeeld de bovengenoemde validatiecomponenten. Daarnaast bieden deze standaarden zeker bij organisatie overstijgende integratie om deze validatie op een centrale plaats uit te voeren. Bijvoorbeeld in een sectoraal knooppunt of een compliance voorziening.

Inzet van overheidscomponenten hebben eveneens een nauwe relatie met tijdigheid. Met name bij een keten van overheidscomponenten zal veelal een negatieve uitwerking hebben op de tijdigheid. Bij het uitwerken van een integratieketen zal een risico analyse plaats moeten vinden per component op onder andere het aspect van tijdigheid.

Inzet validatiecomponenten. Voor validatie van bijvoorbeeld berichten zijn componenten en agents beschikbaar die berichten eenvoudig kunnen valideren op syntactisch niveau. Deze kunnen ingezet worden op verschillende plekken in integratieketens indien dit gewenst is. Houdt rekening met de effecten die dit kan hebben op met name de performance binnen een keten.

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

Gebruik van beveiligingsmaatregelen binnen de data integratie om zorg te dragen voor de beveiligde uitwisseling van data in berichtenverkeer tussen informatiesystemen en organisaties.

Mate van detail waarin een data entiteit de werkelijkheid weergeeft. Dit heeft bijvoorbeeld betrekking op de precisie van getallen e.d. Opslag van getallen en datums kunnen onvoldoende nauwkeurig zijn omdat afronding bij opslag of integratie nodig is.

Keuze en inzet integratietechnologie, hierbij moet rekening gehouden worden met de gewenste- en realiseerbare precisie. Dat kan tot gevolg hebben dat een integratievorm ongeschikt is voor een specifieke implementatie. Houdt hierbij ook rekening met het feit dat structuren op basis van de precisie opnieuw opgebouwd moeten kunnen worden, bijvoorbeeld bij het verwerken van object georiënteerde datastructuren.

Beslisproces voor beveiliging bij integratie, dit punt sluit aan bij de voorgaande punten. Introduceer een beslisproces om zorg te dragen dat op eenvoudige wijze bepaald kan worden. Inrichten van beheerprocessen rond informatiebeveiliging. Denk bijvoorbeeld aan het monitoren van beveiligingsaspecten maar ook toetsingsmechanismen zoals checklists inzetten binnen projecten of het doen van beveiligingsaudits.

Infrastructurele inrichting, data integratie stelt bij een aantal integratievormen hoge eisen aan de infrastructurele inrichting. Bijvoorbeeld op het vlak van performance, beschikbaarheid en capaciteit. Bij de infrastructurele inrichting dient rekening gehouden te worden met de eisen die vanuit de redelijkheid gesteld worden. Dit brengt een bepaalde configuratie met zich mee per integratievorm. Daarnaast kan de inzet van specifieke componenten noodzakelijk zijn.

Inzet van (overheids)componenten. Hierbij dient terdege rekening gehouden te worden met de eisen die vanuit redelijkheid gesteld worden. Veel overheidscomponenten kennen een inrichting die bepaalde integratievormen in combinatie met redelijkheid niet mogelijk maken. Denk bijvoorbeeld aan de inzet van digikoppeling en digipoort in combinatie met de wens voor synchrone (redelijke) interactie.

Inrichten integratievorm, bij verschillende vormen van integratievormen kan de wijze van inrichting een negatief effect hebben op de referentiele integriteit. Bijvoorbeeld bij integratie op basis van berichten kunnen aanvullende eisen gesteld worden aan de in te zetten componenten, verbindingen en protocollen. Bij de inzet van generieke integratievoorziening dient rekening gehouden te werken met de strengste eisen van integriteit zoals deze binnen deze voorziening ingezet zal worden. De technische voorzieningen moeten voldoende oplossingen te hebben voor het handhaven van referentiele integriteit. Denk bijvoorbeeld aan voorzieningen als het genereren van unieke sleutels het werken met transacties en rollback mechanismen. Met name in een sterk gedistribueerde omgeving zoals een SOA omgeving is dit een uitdaging.

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

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

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

Selectieproces integratievorm, bij het uitwerken van de integratievormen kan beschreven worden wat de effecten zijn van een specifieke integratievorm op het vlak van precisie. Vervolgens kan dit vertaald worden in beslisbomen en –documenten rond het selecteren van integratievormen binnen een project.

Integratievorm keuze, vanuit het perspectief van redelijkheid is de keuze van bepaalde integratievormen wel of niet mogelijk. Vanuit architectuur en beheer kunnen beslisbomen en dergelijke ingezet worden om zorg te dragen dat de juiste vorm in relatie tot redelijkheid gekozen worden.

Inzet syntactische validaties, met name bij berichtenverkeer op basis van XML kunnen berichten binnen de integratieketen op één of meerdere plaatsen gevalideerd worden. Deze validaties zorgen ervoor dat de berichtinhoud gecontroleerd wordt op correctheid op basis van definitiebestanden waarmee voorkomen wordt dat invalide gegevens opgeslagen worden of dat bij verder gebruik problemen in de verwerking van de gegevens ontstaan.

Inzet servicecontract of gegevensleveringsovereenkomst. Deze documenten met afspraken kunnen tijdigheid als verbijzondering van redelijkheid formaliseren en op deze wijze een bijdrage leveren aan een realistische uitwerking van vraag en aanbod op aspecten van tijdigheid bij data integratie. Gebruiksafspraken maken met gebruikers en beheerders om zo voor een betere verdeling van het gebruik te bereiken (zie ook redelijkheid), bijvoorbeeld door contractafspraken te maken omtrent het gegevensgebruik en het uitvoeren van beheeractiviteiten.

Transformeren van data tbv ETL. Extract functie haalt de data op uit de bronwaarna de tranformatie functie de data omzet naar het model wat in het DWH geladen wordt. onderliggende functies zijn:

• Opslaan in een staging omgeving
• Validatie van data
• Transformeren van datatypes en waardes.
• Versleuteling
• integratie met andere datastromen
• Agrregatie van feiten en dimensies

Service oriëntatie is bij veel organisaties het fundament van hun data integratie. Inzetten van data integratie kan veel redenen hebben, echter vrijwel altijd dient er een antwoord gevonden te worden op problemen rond de wendbaarheid van een organisatie door het ontstane ICT landschap. Binnen de service oriëntatie speelt data modellering een belangrijke zo niet centrale rol. 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 een SOA. In dit whitepaper hebben we een combinatie van modelleervormen beschreven die een (minimale) set is van notatiewijzen op basis waarvan data stromen in een SOA gemodelleerd kunnen worden.

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.

Doel: Inzicht geven in koppelingen tussen de applicatie en de daarbij gebruikte patronen uit de referentie architectuur Systeemintegratie. Verplicht: Alleen in het geval dat er een koppeling tussen applicatie gerealiseerd moet worden en dit niet past in de eerder genoemde applicatieview. Als een aparte integratieview vereist is deze altijd van detail niveau 2 (zie 5.6 voor meer informatie over de niveau’s) Een integratieview is te realiseren door het gekozen integratiepatroondiagram uit de referentie architectuur te kopiëren en vervolgens te voorzien van de implementatie in applicatiecomponenten, interfaces etc.

Doel: Inzicht geven in koppelingen tussen de applicatie en de daarbij gebruikte patronen uit de referentie architectuur Systeem integratie. Verplicht: Alleen in het geval dat er een koppeling tussen applicatie gerealiseerd moet worden en dit niet past in de eerder genoemde applicatie view. Een integratie view is te realiseren door het gekozen integratie patroon uit de referentie architectuur te kopiëren en vervolgens te voorzien van de implementatie in applicatie componenten, interfaces etc.

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

Primaire concepten In de applicatielaag zijn de drie specialisaties van de bouwblokken relatief eenvoudig te relateren aan een ArchiMate element, namelijk:

• Service <-> Application_Service
• ABB <-> Application_Function, zoals reeds genoemd kan hier ook een ander behavioural element gebruikt worden
• SBB <-> Application_Component

Tussen de elementen kunnen ArchiMate relaties gedefinieerd worden:

• Service <-> ABB: Realisation
• SBB <-> ABB: Assignment
• xBB <-> xBB: Aggregation

Met name de laatste associatie de aggregatie is van belang omdat hiermee samengestelde bouwblokken samengesteld kunnen worden. Naast de genoemde associaties zijn meerdere typen associaties te kiezen zoals de dynamische associaties. Bij het uitwerken van de views binnen dit viewpoint staat het je vrij deze extra associaties toe te passen, mits uitgewerkt in de reeds aanwezige algemene viewpoints. Secundaire concepten Naast de primaire elementen en associaties zijn er een tweetal elementen en associaties relevant, echter niet in alle architectuur domeinen. Dit zijn:

• Data_Object, binnen bijvoorbeeld de integratie architectuur zijn data objecten noodzakelijk voor het beschrijven van bijvoorbeeld herbruikbare bericht definities binnen een bouwblok.
• Applicatie_Interface, eveneens binnen de integratie architectuur is voor de implementatie van bijvoorbeeld een webservice dit concept noodzakelijk als extra ArchiMate element binnen de xBB modellering.

Primaire concepten In de technische laag zijn de drie specialisaties van de bouwblokken relatief eenvoudig te relateren aan een ArchiMate element, namelijk:

• Service <-> Technology_Service
• ABB <-> Technology_Function, zoals reeds genoemd kan hier ook een ander behavioural element gebruikt worden
• SBB <-> System_Software, Node, Network, Device, Path en andere technische actieve structuur elementen.

Tussen de elementen kunnen ArchiMate relaties gedefinieerd worden:

• Service <-> ABB: Realisation
• SBB <-> ABB: Assignment
• xBB <-> xBB: Aggregation

Met name de laatste associatie de aggregatie is van belang omdat hiermee samengestelde bouwblokken samengesteld kunnen worden. Naast de genoemde associaties zijn meerdere typen associaties te kiezen zoals de dynamische associaties. Bij het uitwerken van de views binnen dit viewpoint staat het je vrij deze extra associaties toe te passen, mits uitgewerkt in de reeds aanwezige algemene viewpoints. Secundaire concepten Naast de primaire elementen en associaties is er element en associatie relevant, echter niet in alle architectuur domeinen. Dit zijn:

• Technology_Interface, eveneens binnen de integratie architectuur is voor de implementatie van bijvoorbeeld een webservice dit concept noodzakelijk als extra ArchiMate element binnen de xBB modellering.
• Een introductie van een artefact is in deze alleen in bepaalde deelgebieden relevant (geo). In andere gevallen zal worden uitgeweken naar een taal met meer detail zoals UML klasse diagram of XSD modellen. In dat laatste geval wordt er via een trace associatie gelegd tussen de modelleertaal concepten.