Gestandaardiseerde interface op basis van een database artifact een materialized view. Een combinatie van een abstract sql statement met buffering van de achterliggende data voor performance winst

Verschillende rollen in de organisatie die gebruik maken van de artifacten geproduceerd door de architecten en afkomstig uit de architectuur repository.

Producent van artifacten, data en informatie die gelden als input voor het opstellen van architect artifacten (in de architectuur repository).

Artifact is een infrastructureel data element dat in de technische infrastructuur wordt opgeslagen en bewerkt. Denk hierbij aan tabellen en schema's in databases, bestanden met data op het filesysteem zoals XML en Json bestanden en andere vormen van data opgeslagen in de infrastructuur

Een artefact vertegenwoordigt een stukje data dat wordt gebruikt of geproduceerd in een softwareontwikkelingsproces, of door de implementatie en werking van een IT-systeem. Een artefact vertegenwoordigt een tastbaar element in de IT-wereld. Het wordt doorgaans gebruikt om (software)producten te modelleren, zoals bronbestanden, uitvoerbare bestanden, scripts, databasetabellen, berichten, documenten, specificaties en modelbestanden.
Gebruik: zelfstandig naamwoord op basis van de organistie naamgeving van de organisatie van tabellen in databases, xml files etc.

Beheer organisatie is vanuit architectuur perspectief belangrijk voor het aanleveren van kaders en richtlijnen omtrent het in beheer nemen van de diverse artifact en beschreven in de diverse architecturen.

Rollen die betrokken zijn bij het ontwikkelen, beheren en inzetten van datamodellen voor het genereren van data artifacten. Veelal datamodellen ingedeeld naar een drielaagsdatamodel.

• Tabel - en kolomnamen worden met Hoofdletter en kleine letters geschreven
  Hierbij wordt ieder nieuw woord in de naam of codering een hoofdletter gebruikt.


• De _ wordt gebruikt in de naamgeving ipv een spatie
  Spatie kan problemen geven bij implementatie in artifacten en dus wordt de spatiev vervangen door een _.


• Zijn er kolommen met een bijzonder kenmerk dan wordt dit voorafgegaan met XX_ bijv DW_
  Codering kan gebruikt worden voor een extra classificatie in de kolomnamen.


• Primary key heeft een vaste opbouw bestaande uit tabelnaam_Id
  Hiermee wordt een naamgevingsconventie geintroduceerd wordt zodat in het model de relaties ook in de primary key namen af te leiden zijn bij een enkelvoudige relatie tussen de tabellen.


• Foreign key heeft een vaste naam bestaande uit Tabelnaam_Id
  Naam van de primaire sleutel in de verwijzende sleutel heeft dezelfde naam, Zijn er meerdere foreign keys naar een tabel dan is de opbouw van de kolomnaam Tabelnaam_Rol_id. Behalve als er meer relaties zijn tussen de elementen dan krijgt de extra verwijzende sleuitel de naam van de tabel en de rolnaam van de relatie.


• Primary key constraints voldoen aan de naamgevingsconventie PK_Table_A
  Naamgevingsconventie van de primaire sleutels op basis van de kolomnamen.


• Foreign key constraints voldoen aan de naamgevingsconventie FK_Table_C_TableA (FK_Kind_Ouder)
  Opbouw van de FK naam zodat uit de naam blijkt welke relatie geimplementeerd wordt. Reden is dat ook zonder datamodel in de database de relaties inzichtelijk gemaakt kan worden.


• Tabel en kolomnaam zijn in het Nederlands
  Dit geldt voor de tabellen die door de organisatie zelf gedefinieerd kunnen worden. In andere gevallen bepaald de leverancier van de database de naamgevingsconventie.


• Bij voorkeur bij de tabellen en kolommen een description voor documentatie in de gegenereerde code
  Afhankelijk van het database platform genereren we de omschrijvingen als documentatie mee in de DDL SQL scripts.


• Voor Tabellen met een bijzonder karakter wordt een X_ prefix gebruikt bijvoorbeeld voor Fact (F_) of Dimension (D_) tabellen
  Ook voor tabellen kan er met een letter codering een extra classificatie of domeindefinitie worden gebruikt in de tabelnamen.

• Tabel - en kolomnamen worden met Hoofdletter en kleine letters geschreven
  Hierbij wordt ieder nieuw woord in de naam of codering een hoofdletter gebruikt.


• De _ wordt gebruikt in de naamgeving ipv een spatie
  Spatie kan problemen geven bij implementatie in artifacten en dus wordt de spatiev vervangen door een _.


• Zijn er kolommen met een bijzonder kenmerk dan wordt dit voorafgegaan met XX_ bijv DW_
  Codering kan gebruikt worden voor een extra classificatie in de kolomnamen.


• Primary key heeft een vaste opbouw bestaande uit tabelnaam_Id
  Hiermee wordt een naamgevingsconventie geintroduceerd wordt zodat in het model de relaties ook in de primary key namen af te leiden zijn bij een enkelvoudige relatie tussen de tabellen.


• Foreign key heeft een vaste naam bestaande uit Tabelnaam_Id
  Naam van de primaire sleutel in de verwijzende sleutel heeft dezelfde naam, Zijn er meerdere foreign keys naar een tabel dan is de opbouw van de kolomnaam Tabelnaam_Rol_id. Behalve als er meer relaties zijn tussen de elementen dan krijgt de extra verwijzende sleuitel de naam van de tabel en de rolnaam van de relatie.


• Primary key constraints voldoen aan de naamgevingsconventie PK_Table_A
  Naamgevingsconventie van de primaire sleutels op basis van de kolomnamen.


• Foreign key constraints voldoen aan de naamgevingsconventie FK_Table_C_TableA (FK_Kind_Ouder)
  Opbouw van de FK naam zodat uit de naam blijkt welke relatie geimplementeerd wordt. Reden is dat ook zonder datamodel in de database de relaties inzichtelijk gemaakt kan worden.


• Tabel en kolomnaam zijn in het Nederlands
  Dit geldt voor de tabellen die door de organisatie zelf gedefinieerd kunnen worden. In andere gevallen bepaald de leverancier van de database de naamgevingsconventie.


• Bij voorkeur bij de tabellen en kolommen een description voor documentatie in de gegenereerde code
  Afhankelijk van het database platform genereren we de omschrijvingen als documentatie mee in de DDL SQL scripts.


• Voor Tabellen met een bijzonder karakter wordt een X_ prefix gebruikt bijvoorbeeld voor Fact (F_) of Dimension (D_) tabellen
  Ook voor tabellen kan er met een letter codering een extra classificatie of domeindefinitie worden gebruikt in de tabelnamen.

Beheer teams voor de verschillende artifacten in het data landschap.

Binnen steeds meer organisaties wordt voor de inrichting van de diverse architecturen gekozen voor standaard oplossingen. In dit geval is de betrokken leverancier van deze oplossingen een stakeholder vanuit perspectief van aanleveren van bepaalde oplossingen en afnemer van de architectuur artifacten.

Het architectuurproces en de -producten zijn in een gezamenlijke omgeving ook gezamenlijk. Daarom dient er overeenstemming te zijn over deze artifacten binnen de modelleurscommunity.
Hiertoe dienen er overlegvormen ingericht te worden om die overeenstemming te verkrijgen en te borgen.

Het metamodel en de gekozen modelleertalen zijn in een gezamenlijke omgeving ook gezamenlijk. Daarom dient er overeenstemming te zijn over deze artifacten binnen de modelleurscommunity.
Hiertoe dienen er overlegvormen ingericht te worden om die overeenstemming te verkrijgen en te borgen. Daarnaast moet het metamodel raadpleegbaar te zijn door de gehele community.

Indien architecturen geïmplementeerd worden in maatwerk oplossingen dan zullen de ontwikkelaars van deze maatwerk oplossingen enerzijds kaders en richtlijnen geven aan de architectuur en anderzijds afnemer zijn van de architectuur artifacten en deze implementeren in functionerende oplossingen.

Veranderingen in de organisatie worden veelal projectgewijs geïntroduceerd in de organisatie. Projecten bepalen de planning en uitvoering van de architectuur werkzaamheden en maken gebruik van de architectuur artifacten. Daarbij worden vanuit de projecten eisen gesteld aan de ondersteuning vanuit architectuur en de door de architectuur op te leveren producten.

Naast het opstellen van architecturen zijn er ook rollen die de architectuur artifacten reviewen en goedkeuren. Bijvoorbeeld door te toetsen op kwaliteit, haalbaarheid maar ook op het toepassen van de modelleerconventies en het organisatie metamodel.

Afhankelijk van de scope van de data-architectuur kan het wenselijk zijn om ook de onderliggende infrastructurele inrichting te modelleren. Daarbij kun je inzichtelijk maken hoe het data en applicatielandschap wordt ondersteund door de onderliggende technische infrastructuur.
Bij de cloud situatie waar de infrastrctuur wordt beheerd door de cloud provider is er minder detaillering van het infrastructuur landschap. Dit komt doordat je als gebruiker van een cloud platform geen kennis hebt van de onderliggende inrichting. Alleen de diensten en de artifacten gebruikt dienen hierbij in het model te worden uitgemodelleerd.

Afhankelijk van de scope van de data-architectuur kan het wenselijk zijn om ook de onderliggende infrastructurele inrichting te modelleren. Daarbij kun je inzichtelijk maken hoe het data en applicatielandschap wordt ondersteund door de onderliggende technische infrastructuur.
Bij de cloud situatie waar de infrastrctuur wordt beheerd door de cloud provider is er minder detaillering van het infrastructuur landschap. Dit komt doordat je als gebruiker van een cloud platform geen kennis hebt van de onderliggende inrichting. Alleen de diensten en de artifacten gebruikt dienen hierbij in het model te worden uitgemodelleerd.