Ondanks het feit dat architectuur modelleren een zeer creatief proces is neemt dat niet weg dat repeterende taken zoals modelvalidatie maar ook het gebruik van sjablonen geautomatiseerd kunnen worden. Wat en hoe deze automatisering geïntroduceerd wordt is een werkproces.

Maak gebruik van berichtvalidatie bij het gebruik van services. Denk hierbij aan de inzet van XSD validatie voor het syntactisch testen van berichten voordat de database opslag plaatsvindt. Laat berichtenverkeer waar mogelijk via de bovengenoemde business laag lopen.

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

Bij invoerelementen kunnen near realtime validaties worden toegevoegd. Denk bijvoorbeeld aan, getal en datum tijd validaties of email patroon controls bij invoer

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.

Machine gebaseerde validatie van de gegevens die in het systeem zijn ingevoerd, maar ook op basis van tijdige intervallen binnen de opgeslagen gegevens. Dit wordt geïmplementeerd in een soort regelmachine.

Machinegebaseerde validatie van de gegevens die in het systeem zijn ingevoerd, maar ook op basis van tijdige intervallen binnen de opgeslagen gegevens. Dit wordt geïmplementeerd in een soort regelmachine.

Datatypes in de verschillende database platformen maken het mogelijk om op basis van datatypen beperkingen in te bouwen in verschillende datatypen. Zo kun je verschillende numerieke dataypen kiezen zoals integer, decimalen (met het aantal cijfers voor of achter de komma, float, etc. Hiermee zijn extra validaties mogelijk op basis van deze datatypen.

Unieke indexen aanleggen kan worden gedaan op basis van de sleutel (de primary keys bijvoorbeeld). Echter als je dat zou willen dan kan dat ook op een combinatie van kolommen voor extra duplicatie validatie checks.

Validaties van data via invoerschermen door gebruikers

Validaties van data via invoerschermen door gebruikers

Richt indien mogelijk een compliance voorziening in voor gangbare validaties etc.

Zorg dat bij een validatiestap van de data kwaliteiten in een proces dat er een feedback loop plaatsvindt naar de activiteit waar het issue ontstaan is. Houd er rekening mee dat dit ook mogelijk is naar metadata, datamodel of data architectuur activiteiten in de feedback

Zorg dat data die geproduceerd of getransformeerd wordt, zeker bij handmatige verwerking van data in een validatie activiteit beoordeeld wordt. Dit biedt een punt in het proces waar issues gesignaleerd kunnen worden, maatregelen genomen kunnen worden of waar signalen zijn dat er in andere data management processen aandachtspunten zijn rond de data kwaliteit.

Inzetten van invoerformulieren die op basis van gestandaardiseerde services zorgdragen voor een correcte, complete en actuele weergave en verwerking van de gegevens ter ondersteuning van een activiteit binnen een werkproces.

Invoercontroles voor combinaties van invoervelden, controle validaties en check controles

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.

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.

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

van schema's voor het valideren van data verzamelingen binnen een XML of JSoN gebaseerd bericht of bestand. Hiermee wordt afgedwongen dat de data voldoet aan de regels in het validatieschema.

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

Beschrijf de validatieregels van de attributen van data objecten en communiceer deze regels met ontwikkelpartijen. Regel daarnaast een voorziening in voor de ontsluiting van deze regels en draag zorg voor de toetsing.

• SIPOC staat voor Supplier, Input, Process, Output en Consumer Een weergave waarmee inzichtelijk wordt gemaakt hoe data elementen door de organisatie stroomt.
• Participant, Supplier en Consumer worden gemodelleerd met ArchiMate Business Roles Omdat business role ook in andere modellen wordt gebruikt ook hier een uitwerking op basis van business roles zodat deze kunnen worden hergebruikt.
• Input en Output worden gemodelleerd als ArchiMate Business Object Hiermee zorgen we ervoor dat er een andere weergave van het CDM en de business objecten en is daarmee een validatie van het CDM.
• Proces wordt gemodelleerd als een business process Processen zijn gebaseerd op ArchiMate Business Process als centraal element in het SIPOC.
• SIPOC elementen worden verbonden met een access in lezen en schrijven richting. ArchiMate Access relatie met een richting (lezen en schrijven) om inzichtelijk te maken hoe de data door de organisatie stroomt.
• ArchiMate elementen uit andere modellen worden hier hergebruikt en gevalideerd Weergave met hergebruik van elementen uit andere modellen om hiermee een metadata repository te introduceren.

Naast review dienen de modellen te worden gevalideerd. Dit houdt in dat gecontroleerd wordt of de modelleerconventies en metamodellen op correcte wijze zijn toegepast.

Het metamodel bepaalt de grenzen aan een architectuur. (Geautomatiseerde) validatie of een (deel)architectuur aan het metamodel voldoet is daarbij wenselijk.

Gebruik van reguliere expressie validaties in invoervelden om te voorkomen dat er invoerfouten worden gemaakt.

Validaties in teksten op basis van reguliere expressies. Denk bijvoorbeeld aan het format van een postcode of een emailadres

Binnen architectuur repositories kunnen eenvoudige meerdere weergaven worden gemaakt van een architectuur. Deze weergaven kunnen specifiek gemaakt worden voor verschillende stakeholders in het reviewproces. Daarnaast zijn er functionaliteiten aanwezig in een repository ter ondersteuning van het reviewproces. Dit maakt het reviewproces eenvoudiger voor zowel de modelleurs als de reviewers

Door gebruik van diverse repository standaarden zoals inzet van sjablonen, modelvalidatie, beperken van gebruik op basis van metamodellen wordt standaardisatie beter mogelijk. Feitelijk biedt een repository meer mogelijkheden om de vrijheden van de modelleur in te perken.

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.

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

Deze functie verzorgt het valideren van de datastructuren tegen die van de bron aan. Dit vlevert een extra controlle slag om te bepalen of de data wel juist uit de bron is opgehaalt.

Validatie van de modellen op basis van de referentie modellen en de aanwezige viewpoints voor de organisatie.

Invoervalidatie op verplichte invoer in het invulformulier in een vroeg stadium

Bij het werken met een architectuur repository is het valideren van modellen een stap in het werkproces. Een duplicaat is namelijk eenvoudig geintroduceerd, zeker in een architectuur repository van enige omvang. Duplicaten voorkomen en dedupliceren achteraf bij de aanwezigheid van duplicaten is daarom een functionaliteit die wenselijk is in een modelleertool ter ondersteuning van de modelvalidatie.

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