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.

Wat zijn de relevante applicatiefuncties ter ondersteuning van de benoemde werkprocessen. Deze kunnen vervolgens gekoppeld worden aan modulen in het architectuurtool of aan requirements (bij een selectie traject).

De Architectuur requirements en -eisen collectie biedt een overzicht van alle geautoriseerde architectuur requirements en eisen die zijn overeengekomen met de stakeholders binnen de architectuurraad (architectuur board).

Bij met name project architecturen is de inventarisatie van de baseline, impact van het project, de requirements van de verschillende stakeholders en de te selecteren oplossingsrichtingen een belangrijk werkproces.

Generieke en specifieke requirements bij inzet van een architectuur repository in de organisatie.

The Big Data pipeline compound pattern generally comprises multiple stages whose objectives are to divide complex processing operations into down into modular steps for easier understanding and debugging and to be amenable to future data processing requirements.

The Big Data pipeline compound pattern generally comprises multiple stages whose objectives are to divide complex processing operations into down into modular steps for easier understanding and debugging and to be amenable to future data processing requirements.

The Big Data Processing Environment represents an environment capable of handling the range of distinct requirements of large-scale dataset processing.

The Big Data Processing Environment represents an environment capable of handling the range of distinct requirements of large-scale dataset processing.

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.

In dit onderdeel wordt een logisch model beschreven van de boom- en een netwerk of graafstructuur. Daarbij worden een aantal requirements uitgewerkt op basis waarvan een keuze voor een fysieke implementatie gemaakt kan worden

Requirements for consumers when connection to a service or service implementation (interface)

Dit is een weergave van alle elementen in het data management model dat de uiteindelijke inrichting vormt. Zij realiseren of beinvloeden dan ook de principes en de requirements. Met requirementis dit positief met beinvloeden is dit negatief

Datakwaliteit conform het raamwerk van DMBoK

Datakwaliteit dimensie conform het raamwerk van DMBoK.

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.

Data object is an ArchiMate concept that on the one hand can be linked to a number of ArchiMate concepts so that aspects such as quality, requirements. But also where is the dataset used and by whom, which application has a relation with this dataset etc. If necessary, you could link to the infrastructure from the data object. At this moment, this is not yet chosen in this example. As soon as there is a need in the community for this, this will be worked out further

Description of the data sources in general. Is an aggregation of specific data source types. This generic datasource is added to the model to make associations possible with generic requirements and principles

Distinguish and decouple classic BI, near real-time BI (Business Intelligence), and real-time OI (Operations Intelligence) and prioritize OI real-time requirements.

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.

Dit is de vastgestelde architectuur van organisatie. Het omvat veelal de uitwerking van de baseline architectuur en soms ook van de target architectuur. Belangrijk is dat de indeling gebaseerd dient te zijn op een raadpleeg functie. Architecten gebruiken dit als een register van de architectuur bij inventarisaties van requirements maar ook voor het raadplegen van de architectuur landschappen en de kaders binnen de architectuur.

External consumers of the (standardized) data and master data produced by the TDP solutions. For external consumers extra requirements are necessary for example with aspects like security, privacy and governance.

Gebruiksorganisatie geeft aan welke requirements, wensen en beperkingen er zijn rond de binnen de architectuur te ontwikkelen artefacten en daaruit voortvloeiende implementaties naar de target architectuur.

Description of generic requirements for all the transformation functionalities

Ontwikkelen en beheer van een kaders en richtlijnenregister zoals een lijst van data principes, standaarden en eventueel data requirements gerelateerd aan de enterprise principes.

Ontwikkelen en beheer van een kaders en richtlijnen register zoals een lijst van data principes, standaarden en eventueel data requirements gerelateerd aan de enterprise principes.

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)

Voor de functionaliteiten in een architectuur repository kunnen gestandaardiseerde non functionele requirements, kwaliteiten genaamd, uitgewerkt worden.

Voorbeeld van een logisch architectuur model voor een register of MDM module. Geeft een voorbeeld van hoe je applicatie functies, interfaces en services in ArchiMate kunt combineren om een beschrijving te geven van de gewenste requirements. Als je een architectuur repository vanuit het perspectief van master data beschouwd dan kun je feitelijk een aantal bouwblokken inzetten om functionaliteiten, applicatie services en -interfaces op generieke wijze beschrijven.

Beschrijving van de doelen en drivers van de organisatie. Desgewenst uitgebreid met een model van principes en/of requirements.

Overzicht in de vorm van een collectie van de requirements van de verschillende stakeholders binnen en buiten de organisatie. Veelal uitgewerkt op basis van de motivation extensie binnen ArchiMate. De opsomming kan gedaan worden in de vorm van een lijst, een matrix of een aantal grafische representaties van de requirements. Zie ook de uitwerking van de solution architectuur repository in een voorgaand hoofdstuk voor een aantal voorbeelden.

This characteristic refers to how well the software can adopt to changes in its environment or with its requirements. The subcharacteristics of this characteristic include adaptability. Object oriented design and implementation practices can contribute to the extent to which this characteristic is present in a given system.

For some data entities access control (authorisation and authentication) or monitoring of use is needed. Take for example requirements that are placed on the access of confidential data. In the GBA there are multiple levels of confidentiality. As such queries of officials are logged and displayed to the civilian yet for investigating officers they are logged and not displayed.

Function for the registration and extractions of governance aspects of the datasets published over the logical services. For example data qualities, connection requirements and the standardized object or information model

Leg verbanden tussen requirements en doelen.

Naamgevingsconventies Gebruik: Korte titel Code in attribuut Alias Bijvoorbeeld: 24/7 beschikbaar.

Functionele en non functionele requirements

Een verbijzondering van een inventarisatie binnen de architectuur is het opstellen van de requirements voor de target architectuur voor de verschillende stakeholders binnen en buiten de organisatie waarbinnen de architectuur opgesteld wordt.

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.

Specific requirments for specific application functions like specific transformations

Een lijst van voorstellen, in de vorm van requirements en eisen ten behoeve van de op te stellen architectuur. Maar ook voor het metamodel of de modelleerconventies van de uit te werken architecturen.

Score matrix is een datamodellering notatie waarmee een score, bijvoorbeeld van 0 - 10 worden gecombineerd met Data entiteiten en eisen, requirements of kwaliteiten. De notatie wordt toegepast op met name de conceptuele datamodellering. Naast toepassingen in de datamodellering wordt de score matrix met name gebruikt binnen data management, data kwaliteiten, data security en data privacy. Hierbij gaat het veelal om twee perspectieven, bijvoorbeeld de huidige en de gewenste situatie.

Beschrijving van tools en requirements voor service repositories

Veranderingen in en rond organisatie zijn van invloed op de rol van de data-architect. Door deze veranderingen wisselen stakeholders en hun concerns. Dit whitepaper gaat in op de belangrijkste stakeholders, hun belangen en hoe de architect dit kan gebruiken bij het uitvoeren van zijn rol. Naast de concerns en requirements wordt ingegaan op een aantal andere concepten zoals kwaliteiten, principes en patronen. Deze worden uitgewerkt gericht op het invullen van de drie data functies en worden gerelateerd aan de genoemde concerns

Basic diagram for an AIC classification, for a project this diagram can be extended with the implication for the project of these security requirements

Eenvoudige uitwerking van de Google cloud diensten ter ondersteuning van de verschillende applicatie functies ook hier geldt weerdat een analyse van de requirements en de functionaliteiten binnen de services de geschiktheid bepaald moet worden

Sharepoint en office 365 bieden een palet aan functies die inzetbaar zijn bij de ondersteuning van een expertise netwerk. Daarbij is het mooi om te zien dat er voor elke logische functie een component lijkt te zijn die inzetbaar is. Een andere analyse van de functionele requirements en een mapping naar de componenten is vanzelfsprekend gewenst.

Bij het ontwikkelen en beheren van de architectuur in de modellen en documenten is het consistent houden van de repository een uitdaging binnen een repository. Bij een document gedreven aanpak is het consistent houden feitelijk onmogelijk. Bij het werken met een architectuur repository en de inzet van tooling ontstaan er mogelijkheden om, met name iteratieve, taken te automatiseren of grotendeels te ondersteunen. Hierbij zijn voor architectuurteams belangrijke voordelen te behalen. Het is dan ook aan te bevelen dat goed wordt nagedacht welke activiteiten geautomatiseerd kunnen worden en welke requirements er zijn bij het modelleerteam.

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

This viewpoint connects three archimate concepts. These are the information entities and a requirement that is subdivided into a number of data qualities. In the example, the DAMA data quality list is used. Within the associations, a score is given to the data within the entities (business object and data object). Keep in mind that this score can be an ist but also a soll or desired score. This can be further elaborated in the matrix by including a double score. In this viewpoint an example of the matrix is included including the example qualities of DaMa

Dit is een lijst van veelkomende requirements voor een architectuur repository. Zijn er organisatie specifieke requirements, voeg deze dan toe aan dit model. Zijn er requirements in dit overzicht die niet relevant zijn voor de organisatie verwijder die dan van dit diagram.

In this scenario data is collected form the various data producing applications and combined and standardized in the master data register. This means that data is modified in one of the data producing applications and eventually enriched in the data register. The data register is mainly a data replication with a standardized data model of the other data producers. An example is a datawarehouse Advantages - All data directly integrated at hand. - Standardization of data is possible within the Data Register - There is a possibility to enhance data by intelligently combing it to new information. - High availability only for the data register when consumers need a high availability - Data validation can be implemented in the system where it is most advantageous/efficient - Reuse of screens, validations, existing data integrations and workflows - Supports a iterative migration to a more centralized (register) scenario Disadvantages - When integration of data is asynchronous the data is not the same as in source systems on every moment. This will not be a problem if timing is not an issue. - When synchronization of data is synchronous high availability requirements for the registry systems is necessary - Data replication and need for extra storage - Fetching and distributing data back and forth is equally much work as with an MDM solution - Possible very complex data transformations necessary

In this scenario there is only one master data producing application. That is the data register. It can also be one of the existing source systems. All other applications are consuming this data from the data register and use this in their application processes. This includes the application functions for ERP and geo etc. Advantages - The service design is directly mapped in the data register. - Possibility to standardize the information model and service interfaces - Verification and business rules are implemented only in the dasset data register. - Real time alignment of the data only upon read/request - High availability only necessary for the data register. - Eventually no replication of data (depends on the maturity of the consuming systems) Disadvantages - Any change in data model in consumers leads to change in service, this should be aligned or require a large standardized datamodel in the service interface. - Information provisioning to applications needs to be redesigned which is a lot of work - Redesign of the full application landscape - High demand in performance and availability for the data register - Introduction of a single point of failure so extra non functional requirements in AIC

Een aantal generiek benoemde stakeholders. Stakeholders hebben concerns en requirements voor de inzet van een architectuur repository. Echter ze hoeven niet perse deelnemer te zijn in het project dat de architectuur repository introduceert. Houd er rekening mee dat dit veelal een organisatie specifiek karakter heeft. In dit model worden alleen een aantal generieke stakeholders benoemd. Pas daarom dit model gerust aan naar de eigen context aan zodat dit overeenkomt met de stakeholder relevant binnen jouw organisatie.

Belangrijke extra dimensie bij het beschrijven van de xBB zijn de kenmerken die bij de communicatie tussen aanbieder van het xBB en de afnemer relevant zijn. Deze extra dimensie richt zich met name op de kenmerken waaraan een xBB wel of niet voldoet. Dit kunnen beperkingen, regels of principes zijn. In het viewpoint worden een drietal ArchiMate concepten gebruikt uit de motivation extensie:

• Principe, veelal afkomstig van de landelijke overheidsreferentie architecturen.
• Requirements, eisen en (non functionele) kwaliteitsaspecten.
• Beperkingen, zijn vereisten welke meestal gelden voor de SBB, bijvoorbeeld gericht op bepaalde programmeerparadigma's of talen.

Voor de associaties tussen de motivation elementen en de andere elementen kan gebruikt gemaakt worden van de associatie, influence en realisation. Hierbij kun je met realisatie een positieve relatie leggen tussen de core elementen en de motivation elementen. Influence is dan voorbehouden voor een negatieve invloed vanuit de core elementen naar de motivatie elementen. In dit model is alleen een uitwerking gemaakt van het bouwblokken viewpoint binnen de applicatie laag. Vanzelfsprekend geldt hetzelfde als hierboven beschreven voor de viewpoint op de technische laag.

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

In dit onderdeel wordt een logisch model beschreven van de boom- en een netwerk of graafstructuur. Daarbij worden een aantal requirements uitgewerkt op basis waarvan een keuze voor een fysieke implementatie gemaakt kan worden

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.

Dit is de vastgestelde architectuur van organisatie. Het omvat veelal de uitwerking van de baseline architectuur en soms ook van de target architectuur. Belangrijk is dat de indeling gebaseerd dient te zijn op een raadpleeg functie. Architecten gebruiken dit als een register van de architectuur bij inventarisaties van requirements maar ook voor het raadplegen van de architectuur landschappen en de kaders binnen de architectuur.

Voorbeeld van een logisch architectuur model voor een register of MDM module. Geeft een voorbeeld van hoe je applicatie functies, interfaces en services in ArchiMate kunt combineren om een beschrijving te geven van de gewenste requirements. Als je een architectuur repository vanuit het perspectief van master data beschouwd dan kun je feitelijk een aantal bouwblokken inzetten om functionaliteiten, applicatie services en -interfaces op generieke wijze beschrijven.

Overzicht in de vorm van een collectie van de requirements van de verschillende stakeholders binnen en buiten de organisatie. Veelal uitgewerkt op basis van de motivation extensie binnen ArchiMate. De opsomming kan gedaan worden in de vorm van een lijst, een matrix of een aantal grafische representaties van de requirements. Zie ook de uitwerking van de solution architectuur repository in een voorgaand hoofdstuk voor een aantal voorbeelden.