Statement Een architectuur bouwblok is de logische definitie van een functionaliteit Omschrijving Voor een architectuur bouwblok wordt de afkorting ABB gebruikt. Een architectuur bouwblok beschrijft de functionaliteiten die aangeboden worden aan een hoger liggende entiteit. Een ABB beschrijft WAT er nodig is, zonder te schrijven naar een specifieke oplossing. De hoger liggende entiteit kan een service of een samengestelde ABB zijn. Een ABB kan samengesteld zijn uit één of meerdere SBB. Deze SBB zijn de implementatie van de functionaliteit. Met andere woorden de SBB realiseert de ABB. Kenmerken

• Beschrijving van een functionaliteit
• Beschrijving van het gedrag van informatievoorziening elementen zonder kenmerken van fysieke implementatie
• ABB is logisch, zonder technische specificatie of merknamen
• Infrastructurele- en applicatie laag zijn in de huidige fase van dit model het belangrijkste toepassingsgebied.
• Architectuur bouwblokken zijn gerelateerd aan kwaliteiten, constraints en principes.
• Dit is het kader waarbinnen bijv. een productmanager een product kan selecteren.
• Wanneer een product aan het einde van de LCM is, kunnen de kaders in het ABB opnieuw worden gebruikt om een nieuw product te selecteren.
• Uitgangspunt is het voorkomen dat een ABB wordt geschreven naar een beschikbare oplossing. Deze dient daarom oplossing- en technologie neutraal te zijn.

Overzicht van de architectuur principes en eventueel constraints. Bij omvangrijke collecties van principes kan hier een hierarchie geintroduceerd worden bijvoorbeeld op basis van basis en afgeleide principes. In het geval van omvangrijke collecties worden de principes veelal visueel gerepresenteerd in de vorm van een aantal diagrammen.

Check constraints zijn extra functionaliteit in een database waarin je op basis van een statement extra condities kunt toevoegen aan een of meerdere kolommen. Dit extra controles toe te voegen aan deze kolommen.

Beperkingen, regels etc

Naamgevingsconventies Gebruik: Korte titel Code in attribuut Alias Bijvoorbeeld: Gebruik JAVA voor maatwerk software

Data management is mainly focused on the business aspects of the data. The elaboration is based on the DMBoK framework of Dama.org. Three viewpoints have been elaborated on ownership, use and quality. Here too, an extension is possible once the community needs it. The DMBoK includes a wealth of viewpoints in this. For the modeling we use ArchiMate concepts like stakeholder and requirements or constraints in combination with matrices.

Definitie en model van de stakeholders en constraints van de organisatie op het gebied van data gedreven werken. Inclusief een model voor de roadmap van huidige situatie naar een gewenste situatie van data gedreven werken.

Eisen zijn de beschrijvende kenmerken die vanuit de aanbieder in het bouwblok worden geleverd of door de aanbieder worden gevraagd. Denk hierbij aan:

• Requirements.
• Principes.
• Constraints.
• Functionele kwaliteiten.
• Non functionele kwaliteiten.

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

Qualities are worked out in the IDEA project as a requirement (that is a relatively arbitrary choice because a constraint is of course also an option)

Bepaal de eisen voor referentiele integriteit en kies op basis daarvan het opslagplatform. Richt dit platform op dusdanige wijze in dat de referentiele integriteit maximaal wordt gerealiseerd. Dus als er constraints mogelijk zijn richt deze ook in.

Statement Services zijn de beschrijving van een combinatie van functionaliteiten en diensten tussen aanbieder(s) en afnemer(s). Omschrijving Services zijn een vorm van inkapseling van de functionaliteit en implementatie van een samenstelling van bouwblokken. Services worden, net als ABB en SBB, gebruikt als communicatiemiddel om tussen aanbieder en afnemer aan te geven welke dienst door de aanbieder aan de afnemer geleverd gaat worden. Services kunnen ook intern binnen de organisatie gedefinieerd zijn (ook in aanbieder en afnemer verband), bijvoorbeeld infrastructurele services voor een applicatieve service of afnemer. Een service kan een samenstelling zijn van een bouwblok dat functionaliteit implementeert binnen het ICT landschap. Daarnaast kan een service bestaan uit het leveren van een meer ingerichte (ICT) werkprocessen in relatie met de bovengenoemde ICT landschappen, bijvoorbeeld een servicedesk. In dit document hebben we de scope beperkt gehouden tot die van de ICT architectuur, ICT werkprocessen worden hier niet uitgewerkt maar zijn binnen andere delen van de organisatie zeker relevant (service management). Dit bouwblokken model kan desgewenst op meerdere manieren toegepast worden en niet alleen in het ICT werkveld. Hier beperken we ons tot ICT architectuur. Services kunnen samengesteld zijn uit onderliggende services. Daarnaast kunnen zij opgebouwd zijn uit een of meerdere architectuur bouwblokken. Door deze samenstellingen kunnen constellaties ontstaan van bouwblokken die zorgdragen voor standaardisatie van herbruikbare toegepaste services. Denk hierbij aan een standaard ingerichte applicatieserver met services (zoals back-up en restore) en ABB (bijvoorbeeld relationele opslag) Services zijn gerelateerd aan requirements, constraints en principes. Dit is bij voorkeur uitgewerkt om aan te geven aan welke behoeften vanuit afnemersperspectief een invulling wordt gegeven en aan welke niet. Rond de term service bestaat veel verwarring. Om te voorkomen dat bij iedere samenstelling van personen een discussie over de definitie ontstaat wordt gekozen voor de term service welke gebaseerd is op onderstaande kenmerken. Daarnaast is er een lijst van synoniemen geformuleerd die verwijzen naar dezelfde onderstaande kenmerken. Kenmerken

• Een herhaalbare activiteit of gedrag die wordt gevraagd te worden uitgevoerd.
• Een service biedt een of meerdere voor de afnemer begrijpelijke invulling van ICT behoeften.
• Combinatie van een implementatie van een functionaliteit in een of meerdere ABBs.
• Eventueel in combinatie met een of meer ICT werkprocessen als service.
• Services worden aangeboden aan afnemers vanuit aanbieders.
• Services hebben een commercieel en een financieel (kosten) aspect.
• Services kennen voorwaarden voor gebruik cq implementatie.

Statement Een solution bouwblok is de fysieke implementatie van een functionaliteit uitgewerkt in één of meerdere ABB. Omschrijving Voor een solution bouwblok wordt de afkorting SBB gebruikt. Een SBB beschrijft de implementatie waarmee een functionaliteit gerealiseerd wordt. Een SBB biedt deze implementatie aan een hoger liggende entiteit. In ons model is een SBB implementatie van ABB of van een samengestelde SBB. Hierbij is het relevant dat er een onderscheid gemaakt wordt in architecturele lagen. Voor ons zijn de infrastructurele- en de applicatie laag het belangrijkste toepassingsgebied. Een SBB op applicatieniveau kan hiermee een samenstelling zijn van SBBs op zowel de applicatie- als de infrastructurele laag. SBB zijn gerelateerd aan kwaliteiten, constraints en principes. Dit is bij voorkeur uitgewerkt om aan te geven aan welke vereisten vanuit implementatie perspectief een invulling wordt gegeven en aan welke niet. Dit in combinatie met het model van kwaliteiten binnen de ABB en de requirements zoals op serviceniveau zijn uitgewerkt biedt een complete beschrijving van de kenmerken die door een service worden aangeboden. Kenmerken

• SBB is een fysieke implementatie van een (deel van) of meerdere ABBs cq functies.
• Technische en productspecificatie zijn bekend.
• Merk- en leveranciersnamen zijn bekend.
• Een SBB is veelal vervangbaar door een ander product of implementatie.

The physical table is an implementation within a relational database and is linked via a trace to the logical data model. Physical tables are converted to table structures in (relational databases). That is why columns and associations are worked out for these tables. Multiple types of constraints or rules can be added to the tables, columns and associations. Think of primary and foreign keys, check constraints and the like.

Maak gebruik van voorzieningen bij data opslag, bijvoorbeeld in relationele databases die de validiteit van gegevens bij de opslag controleren. Denk bijvoorbeeld aan check constraints, foreign key en domein constraints etc.

Dit diagram is een viewpoint voor het uitwerken van een fysieke datamodel voor SQL-Server RDBMS.Dit viewpoint geeft aan welke tabellen, constraints en kolommen gebruikt kunnen worden binnen het opstellen van een RDBMS data model. Voor het RDBMS datamodel gelden een paar uitgangspunten:

• Fysiek datamodel is voor de ICT (Database specialisten)
• Van het Fysiek datamodel kunnen SQL DDL statements gegenereerd worden
• Naamgevingsconventies voor het database platform (SQL Server/Oracle) gelden als basis voor de Naamgevingsconventies
• Op de associaties worden de database details voor de verwijzende en primaire sleutels getoond.

Dit diagram is een metamodel voor het uitwerken van een fysiek datamodel voor SQL-Server RDBMS.Dit metamodel geeft aan welke tabellen, constraints en kolommen gebruikt kunnen worden binnen het opstellen van een RDBMS data model. Voor het RDBMS datamodel gelden een paar uitgangspunten:

• Fysiek datamodel is voor de ICT (Database specialisten)
• Van het fysiek datamodel kunnen SQL DDL statements gegenereerd worden
• Naamgevingsconventie voor het database platform (SQL Server/Oracle) gelden als basis voor de naamgevingsconventie.
• Op de associaties worden de database details voor de foreign en primary keys getoond.

Doel: Inzicht te geven in de betrokkenen en de motivation elementen gerelateerd aan core) elementen om uiteindelijk het bestaansrecht van deze elementen te herleiden. Daarnaast biedt het inzicht in welke oplossingen requirements worden gebruikt. Deze wordt gebruikt bij minder omvangrijke trajecten. Bij omvangrijke trajecten maak bij voorkeur gebruik van de meer gedetailleerde motivation viewpoints. Niet verplicht Gebruik hiervoor de motivation elementen van Archimate. Daar is het requirement element opgenomen. Dit kan eventueel aangevuld worden met constraints. Daarnaast kan, als dat wenselijk is, de volledige motivatie in principes, drivers etc. uitgewerkt worden.

Doel: Inzicht te geven in de principes gerelateerd aan elementen om uiteindelijk het bestaansrecht van deze elementen te herleiden. Daarnaast biedt het inzicht in welke oplossingen dezelfde principes invullen. Niet verplicht Gebruik hiervoor de motivation elementen van Archimate. Daar is het principe element opgenomen. Dit kan eventueel aangevuld worden met constraints. Daarnaast kan, als dat wenselijk is, de volledige motivatie in principes, drivers etc. uitgewerkt worden.

Doel: Inzicht te geven in de requirements gerelateerd aan elementen om uiteindelijk het bestaansrecht van deze elementen te herleiden. Daarnaast biedt het inzicht in welke oplossingen dezelfde requirements invullen. Niet verplicht Gebruik hiervoor de motivation elementen van Archimate. Daar is het requirement element opgenomen. Dit kan eventueel aangevuld worden met constraints. Daarnaast kan, als dat wenselijk is, de volledige motivatie in principes, drivers etc. uitgewerkt worden.

Doel: Inzicht te geven in de principes gerelateerd aan elementen om uiteindelijk het bestaansrecht van deze elementen te herleiden. Daarnaast biedt het inzicht in welke oplossingen dezelfde principes invullen. Niet verplicht Gebruik hiervoor de motivation elementen van Archimate. Daar is het principe element opgenomen. Dit kan eventueel aangevuld worden met requirements/ constraints om de implicaties aan te geven. Het principe kan worden gekoppeld aan een Outcome, waarbij de rationale in de associatie van principe naar Outcome wordt beschreven. Daarnaast kan, als dat wenselijk is, de volledige motivatie in principes, drivers etc. uitgewerkt worden.

Dit voorbeeld laat op eenvoudige wijze zien hoe de kenmerken/eisen op basis van requirements, constraints, kwaliteiten en principes inzichtelijk gemaakt kunnen worden. In dit voorbeeld is te zien hoe de kenmerken van de verschillende xBB op basis van ArchiMate concepten in kaart gebracht kunnen worden. Dit wordt straks een belangrijk mechanisme in de verschillende xBB catalogi. Naast deze aanpak kunnen de kenmerken ook uitgewerkt worden via de interne kenmerken van de entiteiten in EA. Zoals requirements, constraint en scenario. Als laatste is er de mogelijkheid om tagged values te gebruiken. In de werkgroep is bepaald dat hierbij het leggen van associaties tussen ArchiMate concepten de voorkeur verdiend. Is een uitwerking met ArchiMate concepten onvoldoende en wil men uitwijken naar interne eigenschappen of tagged values dan dient dit kortgesloten te worden

Overzicht van de architectuur principes en eventueel constraints. Bij omvangrijke collecties van principes kan hier een hierarchie geintroduceerd worden bijvoorbeeld op basis van basis en afgeleide principes. In het geval van omvangrijke collecties worden de principes veelal visueel gerepresenteerd in de vorm van een aantal diagrammen.

Data management is mainly focused on the business aspects of the data. The elaboration is based on the DMBoK framework of Dama.org. Three viewpoints have been elaborated on ownership, use and quality. Here too, an extension is possible once the community needs it. The DMBoK includes a wealth of viewpoints in this. For the modeling we use ArchiMate concepts like stakeholder and requirements or constraints in combination with matrices.

Definitie en model van de stakeholders en constraints van de organisatie op het gebied van data gedreven werken. Inclusief een model voor de roadmap van huidige situatie naar een gewenste situatie van data gedreven werken.