Zoek trefwoord in element

Architectuur Bouwblok

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.

Architectuur principes

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.

Constraint

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

Constraint

Constraint

Beperkingen, regels etc

Data Management viewpoints

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.

Eis

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.

Kwaliteit

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)

Service

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.

Solution Bouwblok

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.

t_attributeconstraints

t_connectorconstraint

t_constrainttypes

t_objectconstraint

t_roleconstraint

Table

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.

Conventie RDBMS datamodel

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.

MeDM Fysiek RDBMS Datamodel

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

Motivation overzicht viewpoint

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.

Motivation Principe viewpoint

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.

Motivation Requirement viewpoint

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.

Motivation viewpoint

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.

Voorbeeld XBB Requirements en eisen PIM

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

Architectuur principes

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 viewpoints

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.