Een beschrijvende data architectuur is een belangrijk kennisgebied van data management en daarmee relevant voor data gedreven organisaties. Ten behoeve van data-architectuur modelleren zijn er diverse data-architectuur tools beschikbaar. Denk hierbij aan Collibra, The Essential Project of Talend. Echter bij organisaties zijn vaak reeds generieke modelleringstalen en tools beschikbaar voor modelleren van software, enterprise architectuur of requirements. In dit hoofdstuk gaan we in op het inzetten van een framework voor inrichting van een generiek tool gebaseerd op een aantal open modelleertalen. De voorbeelden die we hier gebruiken zijn uitgewerkt in Sparx Enterprise Architect. Een voorbeeld van een dergelijk generiek tool. Hieronder is daartoe een metamodel uitgewerkt voor hoe een data-architectuur gemodelleerd kan worden. De data-architectuur kent meerdere gezichtspunten om data in een organisatie te beschrijven. Zo wordt er op verschillende niveaus in een organisatie gekeken. Daarnaast kan de mate van detail vanuit verschillende gezichtspunten verschillen. We introduceren data-architectuur modelleren op basis van een uitwerking met behulp van een aantal modelleertechnieken. De belangrijkste modelleertechnieken hier gebruikt zijn:

• ArchiMate
• Unified Modeling Language
• Entity Relationship
• XML Schema Definition

Reden om voor deze modelleertalen te kiezen is dat ze een open standaard zijn, een breed toepassingsgebied hebben, goed met elkaar te integreren zijn en reeds veel toegepast worden binnen de aanpalende domeinen van data-architectuur. Hiermee kun je in je eigen organisatie data-architectuur modelleren introduceren op een natuurlijke manier. Dat doe je door die delen relevant voor de situatie binnen de organisatie stapsgewijs te introduceren op basis van de reeds toegepaste modelleertalen. Daarnaast worden er meerdere verschijningsvormen van de data-architectuur gebruikt. De grafenweergave en de matrix zijn in dit metamodel de meestgebruikte verschijningsvormen. Voor het uitwerken van het metamodel worden er twee data-architectuur niveaus uitgewerkt, namelijk:

• Domein data-architectuur: dit is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur
• Solution data-architectuur: architectuur voor het beschrijven van een data gedreven verandering binnen een project of oplossing.

Beide vormen worden hieronder nader toegelicht.

De domein data-architectuur is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur. Het beschrijft de data gerelateerde architectuurconcepten voor de gehele organisatie en haar omgeving. De domein architectuur volgt het raamwerk dat beschreven is op basis van het raamwerk voor de beschrijvende architect. De navigatie is op deze manier uitgewerkt. Binnen het uitwerken van de domein architectuur wordt in deze uitwerking geen rekening gehouden met een baseline en een target architectuur. Als dit relevant is kun je hiervoor in de naamgevingsconventie van de packages of de diagrammen de plateaus van de architectuur opnemen. Zie verder de voorbeelden binnen de Architectuur Repository sectie.

Dit is een voorbeeld case waarin we data modellen uitwerken voor Alberto een keten van Italiaanse ijssalons. Op basis van deze uitwerking krijg je een overzicht van de modelleermethoden zoals die toegelicht worden in het boek "Grip op data modelleren. Daarbij zijn in de uitwerking de modellen onderling aan elkaar gerelateerd. Er zijn op basis van drie domeinen in de Alberto case domeinmodellen uitgewerkt:

• Vestiging, registratie van de vestiging gegevens.
• Tijdregistratratie, tijjdschrijven door medewerkers en accordering door vestigingsmanagers
• Thuisbezorging, data benodigd voor het bezorgen van ijs- en koffie producten op locaties van klanten.

De uitwerking is gebaseerd op een aantal deelgebieden rond modelleren en deze deelgebieden zijn gebaseerd op het DM-BoK raamwerk. Hierbij zijn de belangrijkste domeinen uitgewerkt vanuit het perspectief van data modelleren.

Hierr worden de viewpoints beschreven voor met name solution architecturen. Belangrijk hierbij is dat we het aantal concepten relatief beperkt houden en dat de verschillende viewpoints gerelateerd zijn aan het project template voor project architecten.

Hier worden de viewpoints beschreven voor met name solution architecturen op basis van een andere aanpak dan de werkwijze met Viewpoints zoals beschreven in de ArchiMate documentatie. Dit is een uitwerking van een organisatie die een aantal viewpoints heeft bepaald voor de eigen context. Belangrijk daarbij is wel dat de viewpoints met elkaar samenhangen. Binnen de viewpoints wordt gewerkt met:

• Primaire elementen (groene rand), dat zijn elementen die in principe in deze diagrammen uitgewerkt moeten zijn.
• Secundaire elementen (oranje rand) zijn elementen die in deze diagrammen gebruikt mogen worden

Belangrijk hierbij is dat we het aantal concepten relatief beperkt houden en dat de verschillende viewpoints gerelateerd zijn aan het project package sjabloon voor project of solution architecturen.

In deze paragraaf wordt een voorstel gedaan voor een aantal ArchiMate viewpoints voor het modelleren van de verschillende bouwblokken en hun onderlinge relaties. In de diagrammen worden de viewpoints alleen uitgewerkt op basis van de elementen en de relevante onderlinge associaties. Een beschrijving van de concepten zelf wordt niet gedaan. Hierbij nemen we definities en mogelijke associaties over zoals die gedefinieerd zijn binnen de modelleertaal ArchiMate zelf. ArchiMate kent in het core model drie lagen, namelijk Business, Applicatie en Technologie laag. xBB kunnen toegepast worden in de drie hierboven genoemde lagen. Echter omdat het perspectief in dit document voor de xBB voornamelijk ligt op applicatie en infrastructuur zijn de viewpoints alleen voor deze twee lagen uitgewerkt. Voor de ABB wordt in ArchiMate gebruik gemaakt van de Behaviour kolom. Sinds ArchiMate 3 bestaan binnen deze kolom meerdere elementen. Bij de uitwerking in de viewpoints worden alleen de Applicatie_Functie en Technologie_Functie gebruikt. Is een ander concept bijvoorbeeld een Applicatie_Process of Technologie_Process relevant bij een uitwerking dan kan dit vanzelfsprekend ook toegepast worden. Voor de SBB wordt in ArchiMate gebruik gemaakt van de Active Structure kolom. Met name binnen de technologie laag zijn veel verschillende concepten beschikbaar. Bij de uitwerking in de viewpoints wordt alleen de System_Software gebruikt. Is een ander concept relevant bij een uitwerking in deze dimensie dan kan dit vanzelfsprekend ook toegepast worden.

Beschrijving Alberto’s is een keten van Italiaanse ijssalons in een aantal plaatsen Verkoop van schepijs, ijstaarten en koffieproducten Sterk seizoensgebonden (zomer en feestdagen) Historisch gezien hebben de filialen een grote mate van autonomie:

• Eigen leveranciers, inkoop, recepten en marketing
• Eigen ICT beleid en budget
• Eigen applicatie en data landschap

Stafafdeling voor:

• P&O en salarisverwerking
• Facilitaire zaken inclusief een ICT afdeling ter ondersteuning van de filialen
• Gezamenlijke financiële verwerking en rapportage
• Centrale prijs- en productbepaling

Knelpunten  

• Toenemende concurrentie van prijsvechters zoals Starbucks en Swirl
• Verschil in kwaliteit van de verschillende producten tussen filialen en tussen verschillende periodes
• ICT afdeling kan door diversiteit van inrichting steeds minder ondersteuning bieden en ICT wordt steeds duurder
• Kostprijs van de producten te hoog
• Veel flexmedewerkers. Salarisverwerking is een knelpunt door grote verschillen in gegevensleveringen in tijd en formaat vanuit de filialen
• Aanlevering van gegevens voor rapportages hebben lage kwaliteit waardoor rapportages weinig betrouwbaar.

Acties  

• Alberto besluit om een aantal knelpunten op te pakken
• Dat wil hij doen door de op het vlak van de informatievoorziening een aantal projecten te starten
• Projecten dienen een oplossing te bieden voor de knelpunten
• Voor projectbegeleiding trekt hij een architect aan: Giovanna
• Giovanna krijgt invloed in de opzet van de projectagenda

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.

Beschrijving van de architectuur viewpoints van de organisatie. Zie hiervoor de paragraaf architectuur viewpoints in dit hoofdstuk.

Beschrijving van de bedrijfsarchitectuur voor een werkwijze met een architectuur repository. Hierbij worden daartoe een aantal bedrijfsprocessen en -rollen uitgewerkt. Omdat het werken met een architectuur repository een transitie is naar een andere werkwijze binnen het architectuurteam is de bedrijfsarchitectuur daarom een belangrijk onderdeel om in detail uit werken. Reden is dat een succesvolle bedrijfsarchitectuur het succes of het mislukken van de introductie van een architectuur repository kan bepalen.

Het bedrijfsdatalandschap verbindt data objecten in een conceptueel data model en legt daarbij een verbinding naar bedrijfsactiviteiten en de - actoren betrokken bij de uitvoering van deze bedrijfsactiviteiten. Hiervoor worden een aantal diagrammen uitgewerkt op basis van ArchiMate.

In de detailprocessen worden bedrijfsprocesmodellen uitgewerkt op basis van Business Process Modeling Notation (BPMN). Hiermee is het mogelijk om een gedetailleerde modellering uit te werken van processen. Vanuit het perspectief van de data modellering voegen wij hier data objecten en data stores aan toe om inzichtelijk te maken hoe data van de ene proces activiteit naar de andere stroomt

Op basis van een aantal eenvoudige processtappen en bijbehorende rollen kun je een aantal gewenste functies van het expertise netwerk definieren. Hieraan kun je vervolgens beheerprocessen en applicatiefuncties koppelen. Daarmee ontstaande contouren van het expertise netwerk

Begrippenlijsten en -bomen zijn een uitwerking van de data elementen op een relatief hoog abstractieniveau. Het geeft een organisatiebreed beeld welke data elementen relevant zijn in de organisatie. Zo ook in de onderstaande diagrammen.

Fysiek datamodel voor het definieren van berichten op basis van XML Schema Definition.

Voorbeeld van een persoonlijk package van een modelleur.

De beschrijvende architectuur zoals de naam al zegt beschrijft de architectuur. Dat is op basis van de target architectuur en de baseline architectuur. Veelal zie je binnen deze package een uitwerking van de verschillende dimensies van de organisatie op basis van subpackages om de beschrijvende architectuur te structureren naar domein, lagen en andere organisatie specifieke indelingen. In dit boek een indeling op basis van een lagen indeling voor de organisatie

In het beschrijvend model worden een aantal data modellen uitgewerkt van abstract (conceptueel model) naar technisch platform specifiek (fysiek model). Dit model is feitelijk het centrale model voor metadata waaraan de andere domeinen gekoppeld zijn.

In het beschrijvend model worden een aantal data modellen uitgewerkt van abstract (conceptueel model) naar technisch platform specifiek (fysiek model). Dit model is feitelijk het centrale model voor metadata waaraan de andere domeinen gekoppeld zijn.

Een beschrijvende data architectuur is een belangrijk kennisgebied van data management en daarmee relevant voor data gedreven organisaties. Ten behoeve van data-architectuur modelleren zijn er diverse data-architectuur tools beschikbaar. Denk hierbij aan Collibra, The Essential Project of Talend. Echter bij organisaties zijn vaak reeds generieke modelleringstalen en tools beschikbaar voor modelleren van software, enterprise architectuur of requirements. In dit hoofdstuk gaan we in op het inzetten van een framework voor inrichting van een generiek tool gebaseerd op een aantal open modelleertalen. De voorbeelden die we hier gebruiken zijn uitgewerkt in Sparx Enterprise Architect. Een voorbeeld van een dergelijk generiek tool. Hieronder is daartoe een metamodel uitgewerkt voor hoe een data-architectuur gemodelleerd kan worden. De data-architectuur kent meerdere gezichtspunten om data in een organisatie te beschrijven. Zo wordt er op verschillende niveaus in een organisatie gekeken. Daarnaast kan de mate van detail vanuit verschillende gezichtspunten verschillen. We introduceren data-architectuur modelleren op basis van een uitwerking met behulp van een aantal modelleertechnieken. De belangrijkste modelleertechnieken hier gebruikt zijn:

• ArchiMate
• Unified Modeling Language
• Entity Relationship
• XML Schema Definition

Reden om voor deze modelleertalen te kiezen is dat ze een open standaard zijn, een breed toepassingsgebied hebben, goed met elkaar te integreren zijn en reeds veel toegepast worden binnen de aanpalende domeinen van data-architectuur. Hiermee kun je in je eigen organisatie data-architectuur modelleren introduceren op een natuurlijke manier. Dat doe je door die delen relevant voor de situatie binnen de organisatie stapsgewijs te introduceren op basis van de reeds toegepaste modelleertalen. Daarnaast worden er meerdere verschijningsvormen van de data-architectuur gebruikt. De grafenweergave en de matrix zijn in dit metamodel de meestgebruikte verschijningsvormen. Voor het uitwerken van het metamodel worden er twee data-architectuur niveaus uitgewerkt, namelijk:

• Domein data-architectuur: dit is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur
• Solution data-architectuur: architectuur voor het beschrijven van een data gedreven verandering binnen een project of oplossing.

Beide vormen worden hieronder nader toegelicht.

Bouwsteen voor transformatie van op bestanden gebaseerde gegevens naar het gestandaardiseerde gegevensdoel (model)

De domeinschets geeft in een aantal ArchiMate diagrammen een beschrijving wat de relevante aspecten zijn voor het kennisgebied van business intelligence en datawarehouses. Denk hierbij aan de aspecten, doelen, definities, processen en betrokkenen.

Score matrix voor het bepalen van de huidige en gewenste score niveaus voor Beschikbaarheid, Integriteit en Vertrouwelijkheid en soms ook Privacy (BIVP).

Dit is een voorbeeld van een data landschap van de verwerkende functionaliteiten en diensten die in een organisatie noodzakelijk zijn om data vanuit bronsystemen te verwerken tot data in een informatieproduct. Modellen zijn grotendeels uitgewerkt door Yorrick Tillemans.

De domeinschets geeft in een aantal ArchiMate diagrammen een beschrijving wat de relevante aspecten zijn voor het kennisgebied van business intelligence en datawarehouses. Denk hierbij aan de aspecten, doelen, definities, processen en betrokkenen.

Conceptueel model beschrijft de data entiteiten op een hoog abstractie niveau ter ondersteuning van de organisatie omtrent de semantiek en het toepassen van de data entiteiten in de organisatie.

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

Concerns zijn de belangen en "zorgen" die de verschillende stakeholders hebben bij de introductie van data gedreven werken en de introductie van een data platform. Hieronder worden een aantal algemeen geldende concerns beschreven die voor vrijwel alle data gedreven toepassingen gelden. Houdt er echter rekening mee dat de specifieke situatie van de eigen organisatie bepalend kan zijn voor een aantal concerns en requirements. Breng daarom de specifieke concerns voor de organisatie en voor de solutions of data gedreven toepassingen in kaart en gebruik deze om de voorgestelde oplossing in te kaderen.

CRUD staat voor Create, Read, Update en Delete en de matrix geeft aan wie deze bewerkingen op een data entiteit mag uitvoeren. Het is daarmee een eenvoudig hulpmiddel om inzichtelijk te maken wat enerzijds de autorisaties zijn van bepaalde entiteiten zoals rollen, actoren maar ook bedrijfsfuncties en -processen. Anderzijds kan de matrix gebruikt worden welke bewerking door een bepaalde entiteit wordt uitgevoerd, waarbij het niet de autorisatie aspecten belicht maar meer ingaat op de dynamische kenmerken van gedragsentiteiten op de gegevensentiteiten CRUD matrices zijn voor verschillende doeleinden te gebruiken, waarbij opvallend is dat dit zowel in de ontwikkelfase als in de beheerfase hulp biedt. Als laatste is te noemen dat de CRUD matrix op meerdere abstractieniveaus toegepast kan worden.

Data architectuur van een architectuur repository. Dit is in dit document relatief eenvoudig van opzet en omvat alleen een conceptueel datamodel. Echter in het conceptueel datamodel wordt wel een overzicht gegeven van relevante concepten binnen een architectuur repository.

Data architectuur is een van de kennisgebieden binnen het DMBoK en modellen uitwerken rond dit kennisgebied zijn kaderstellend voor veranderingen in de organisatie vanuit data management perspectief.

Dit is de navigatie voor de domein architectuur. Op basis van het raamwerk om de beschrijvende data-architectuur zijn in deze sectie links opgenomen naar de onderliggende diagrammen voor de verschillende secties in het raamwerk.

Beschrijving van de relatie tussen het applicatie- en het datalandschap op basis van een ArchiMate model.

Rond data gedreven werken is een algemene grondplaat te gebruiken gebaseerd op een big data patroon de data pipe. Dit raamwerk is afkomstig van Arcitura en is een detaillering van de datalevensloop en wordt veel toegepast in (big) data integratie projecten. Het is feitelijk een grondplaat waarin je verschillende projectactiviteiten, deliverables en modelleervormen kunt afbeelden. Dit helpt om de complexiteit op eenvoudige wijze in kaart te brengen. Onderstaande afbeelding toont de data pipe grondplaat waarmee je een data gedreven toepassing kunt realiseren.

Beschrijving van een data gedreven procesmodel bestaande uit activiteiten voor het tot stand komen van een data gedreven toepassing.

Veel organisaties onderkennen de waarde van data en willen deze data inzetten om meerwaarde te realiseren. Vaak wordt hiervoor de term data gedreven werken gebruikt. Bij data gedreven werken kunnen bouwblokken en patronen van grote hulp zijn. Vandaar dat we hier uitgebreid kijken naar op welke wijze we data gedreven werken kunnen standaardiseren met bouwblokken en patronen. We kijken naar data gedreven toepassingen waarin we vanuit data waarde creëren. Vervolgens onderzoeken we of data een productiemiddel is en hoe we op die wijze data kunnen inzetten. Als we data als een productiemiddel zien dan kunnen vervolgens kijken hoe we een productiemiddel dienen te managen om waarde te creëren. Dit doen we door een aantal eenvoudige voorbeelden van data gedreven use cases te demonstreren.

Data governance is een van de kennisgebieden binnen het DMBoK en modellen uitwerken rond dit kennisgebied is ondersteunend voor de gehele data management functie.

Data integratie is een data werkveld waar architectuur patronen veel waarde kunnen leveren aan de inrichting van een landschap met generieke en gestandaardiseerde koppelvlakken.

Zandloperarchitectuurpatroon voor het modelleren van implementatie specifieke functies en entiteiten in een gestandaardiseerd architectonisch model.

Het kennisgebied data kwaliteit gaat in op welke wijze een organisatie kan zorgdragen voor data met voldoende kwaliteit afhankelijk van de context. Dit heeft daarmee raakvlakken met onder andere data modelleren, - governance en - architectuur.

Uitwerken van mogelijke kwaliteitsverhogende maatregelen voor de data entiteiten binnen de organisatie. Hierbij wordt een samenvatting gegeven van de maatregelen. Op de data-docent website is een gedetailleerde uitwerking te vinden van het maatregelenmodel.

Baseline en Target bepalen voor data entiteiten waarbij een score wordt gegeven voor de dimensies van data kwaliteit op basis van de conceptuele data entiteiten binnen de organisatie.

Binnen de Alberto case werken we een aantal kennisgebieden uit zoals die ingedeeld zijn in de DaMa Body of Knowledge DMBoK (2.0). Voor de Alberto case werken we niet alle kennisgebieden van de DMBoK uit. Reden daarvoor is dat we vanuit het perspectief van data modelleren naar data management kijken. In dit hoofdstuk werken we daarom een aantal algemene aspecten uit van data management die in de specifieke kennisgebieden niet of beperkt aan de orde komen. Hier besteden we alleen aandacht aan de algemene aspecten.

Naast de datamodellen en de kaders rond data management wordt data ook op allerlei plaatsen geproduceerd en gebruikt binnen en buiten de organisatie. Ook hierover willen we graag metadata verzamelen. In dit hoofdstuk gaan we daarom in op databronnen, datagebruik en eigenaren en stewards van data.

Naast de datamodellen en de kaders rond data management wordt data ook op allerlei plaatsen geproduceerd en gebruikt binnen en buiten de organisatie. Ook hierover willen we graag metadata verzamelen. In dit hoofdstuk gaan we daarom in op databronnen, datagebruik en eigenaren en stewards van data.

Data modelleren is een van de kennisgebieden binnen het DMBoK en modellen uitwerken rond dit kennisgebied beschrijft de data requirements vanuit de organisatie en ondersteunt daarmee de data management functie.

Organogram van de organisatie op basis van ArchiMate bedrijfsrollen.

Data wordt veelal als een waardevol productiemiddel gezien en wordt daarom gemanaged. Dit managen zal op meerdere enterprise niveaus vorm krijgen. In de bedrijfslaag wordt gekeken in welke bedrijfsprocessen en organisatie onderdelen welke data wordt gebruikt voor het uitvoeren van de diverse activiteiten. Daarnaast wordt op dit niveau data ontsloten voor diverse (interne en externe) stakeholders. Deze laag zal daartoe ondersteund worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur meerwaarde geboden kan worden op het moment dat er behoefte is aan veranderingen binnen het data platform en de data-toepassingen. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Data wordt veelal als een waardevol productiemiddel gezien en wordt daarom gemanaged. Dit managen zal op meerdere enterprise niveaus vorm krijgen. In de bedrijfslaag wordt gekeken in welke bedrijfsprocessen en organisatie onderdelen welke data wordt gebruikt voor het uitvoeren van de diverse activiteiten. Daarnaast wordt op dit niveau data ontsloten voor diverse (interne en externe) stakeholders. Deze laag zal daartoe ondersteund worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur meerwaarde geboden kan worden op het moment dat er behoefte is aan veranderingen binnen het data platform en de data-toepassingen. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Deze laag zal vanuit de solution aangepast of uitgebried worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap dat in de solution wordt uitgewerkt. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er binnen de soltion data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur voor en na de implementatie van de solution. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data na deze solution implementatie opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Data architectuur principes zijn een belangrijk hulpmiddel voor de data architect. Hiermee heeft de data architect de mogelijkheid om kaders te stellen aan de verandering die plaatsvindt in organisaties. Zoals bij data gedreven werken initiatieven. De data principes zijn gebaseerd (of een specialisatie van) op sectorale, organisatorische of data management principes. Daarnaast kunnen de data architectuur principes gerelateerd worden aan de doelen van de organisatie waarmee de principes een uitwerking zijn van de generieke missie en visie van de organisatie.

Data principes voor het stellen van kaders aan de verandering op basis van data principes die veelal worden afgeleid van de algemene enterprise architectuur principes.

Data security is een van de kennisgebieden binnen het DMBoK en modellen uitwerken rond dit kennisgebied is kaderstellend voor de beveiliging van de data vanuit informatie beveiliging en privacy perspectief.

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.

Data-architecten hebben te maken met allerlei stakeholders. Al deze stakeholders hebben behoeften aan producten waarmee zij zich een beeld kunnen vormen van hoe data ingezet wordt in de organisatie en welke eisen en kaders daaraan gesteld worden. Daarom zal de data-architect afhankelijk van de wensen en behoeften van de stakeholders verschillende architectuur producten uitwerken. Met deze architectuur producten kan iedere stakeholder afhankelijk naar hun gezichtspunt zich op efficiënte wijze een beeld vormen van de data-architectuur

Fysieke datamodellen voor een relationele database uitgewerkt in een Microsoft SQL-Server database.

Data kwaliteit is een van de drijfveren van data management en daarmee een belangrijk kennisgebied vanuit het data management perspectief. Zeker in relatie tot datamodelleren zijn datakwaliteiten een centraal thema. Het datamodel is essentieel om in kaart te kunnen brengen of de kwaliteit van voldoende niveau is.

Datastromen is een modelleerwijze waarbij de activiteiten die plaatsvinden in combinatie met de data elementen met elkaar gecombineerd zijn. De notatiewijze die daarbij hoort zijn Data Flow Diagrammen of DFDs. Daarmee ondersteunt deze notatie het conceptuele data model met de activiteiten en processen binnen een organisatie.

• Alberto’s is een keten van Italiaanse ijssalons in een aantal plaatsen
• Verkoop van schepijs, ijstaarten en koffieproducten
• Sterk seizoensgebonden (zomer en feestdagen)
• Historisch gezien hebben de filialen een grote mate van autonomie:
• Eigen leveranciers, inkoop, recepten en marketing
• Eigen ICT beleid en budget
• Eigen applicatie en data landschap
• Stafafdeling voor:
• P&O en salarisverwerking
• Facilitaire zaken inclusief een ICT afdeling ter ondersteuning van de filialen
• Gezamenlijke financiële verwerking en rapportage
• Centrale prijs- en productbepaling

Dit sjabloon is een package en diagram structuur voor een architectuurdocument, bijvoorbeeld een solution - of project start architectuur. Hierbij is in de diagrammen een koppeling gemaakt naar een viewpoint uitwerking zodat modelleurs ondersteuning krijgen bij het uitwerken van het model. Desgewenst kan dit package gekopieerd worden in EA om het projectspecifiek te maken. Vervolgens kan er een document van gegenereerd worden. Maak daarbij gebruik van de IDEA AddOn waarin je in de package helper een zoek en vervang actie kunt uitvoeren

Extra maatregelen vanuit een bepaalde technische scope zoals databases software user interfaces etc

Dimensioneel modelleren is een techniek bij het opstellen van een fysiek datamodel binnen relationele databases. Er zijn drie doelen voor dimensioneel modelleren : het classificeren van data in dimensies en facts. Dimensies zijn voor het bieden van hiërarchie in de data voor inzicht. Facts zijn voor vastleggen van de feiten in de werkelijk op een chronologische wijze. Dimensies bieden een vertaling van de datastructuren naar een voor de kenniswerker logische indeling die daardoor sterk kan afwijken van het genormaliseerde OLTP model. Daarnaast bieden facts de mogelijkheid om inzicht te krijgen op basis van data bevroren in de tijd.

Dimensioneel modelleren is een techniek bij het opstellen van een fysiek datamodel binnen relationele databases. Er zijn drie doelen voor dimensioneel modelleren : het classificeren van data in dimensies en facts. Dimensies zijn voor het bieden van hiërarchie in de data voor inzicht. Facts zijn voor vastleggen van de feiten in de werkelijk op een chronologische wijze. Dimensies bieden een vertaling van de datastructuren naar een voor de kenniswerker logische indeling die daardoor sterk kan afwijken van het genormaliseerde OLTP model. Daarnaast bieden facts de mogelijkheid om inzicht te krijgen op basis van data bevroren in de tijd.

Architectuur modellen voor de uitwerking van stakeholders, doelen, behoeften en principes rond de introductie van een architectuur repository binnen een architectuur team.

De domein data-architectuur is een referentie architectuur voor het aspect data binnen de enterprise referentie architectuur. Het beschrijft de data gerelateerde architectuurconcepten voor de gehele organisatie en haar omgeving. De domein architectuur volgt het raamwerk dat beschreven is op basis van het raamwerk voor de beschrijvende architect. De navigatie is op deze manier uitgewerkt. Binnen het uitwerken van de domein architectuur wordt in deze uitwerking geen rekening gehouden met een baseline en een target architectuur. Als dit relevant is kun je hiervoor in de naamgevingsconventie van de packages of de diagrammen de plateaus van de architectuur opnemen. Zie verder de voorbeelden binnen de Architectuur Repository sectie.

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.

Data uit verschillende informatiesystemen aangeduid als databronnen dienen omgezet te worden naar data in dimensionele datamodellen. Extract Transform Load zijn die bewerkingen op de data die de data structuren omzetten naar het gewenste model voor gebruik door kenniswerkers.

Data uit verschillende informatiesystemen aangeduid als databronnen dienen omgezet te worden naar data in dimensionele datamodellen. Extract Transform Load zijn die bewerkingen op de data die de data structuren omzetten naar het gewenste model voor gebruik door kenniswerkers.

Dit is een wat vreemde eend in de bijt omdat het een relatief klein onderdeel is van de gehele gewenste functionaliteit. Het is echter een specifiek project waarvoor subsidie aangevraagd is. Het heeft wel direct raakvlakken met het expertise netwerk omdat het een ontsluitingsvorm is. Bijkomend voordeel is dat het kan aansluiten op bestaande nderdelen in het applicatielandschap en alleen een extra functie is voor het transformeren van vrije tekst naar een onderwerpenboom en de relatie terug naar de brondocumenten

Het expertise netwerk is een uitbreiding van de functionaliteit van drie onderdelen namelijk:

• onderwerpenboom (T2T)
• het samenwerken van experts om tot expertise te komen (O365)
• zichtbaar maken van expertise in de TFG Academy.

Het TFG expertise netwerk is een mooi voorbeeld van hoe verschillende initiatieven van maten samenkomen en hoe we daarmee een extra propositie naar de markt kunnen doen. In dit model is een uitwerking gemaakt dat dient als discussiestuk omtrent deze propositie van een expertise netwerk.

Sommige diagrammen zijn bij het uitwerken van de kaderstellende solution architectuur optioneel. Deze optionele modelleervormen worden hieronder uitgewerkt.

Sommige diagrammen zijn bij het uitwerken van de kaderstellende solution architectuur optioneel. Deze optionele modelleervormen worden hieronder uitgewerkt.

Sommige diagrammen zijn bij het uitwerken van de solution data platform architectuur optioneel. Deze optionele modelleervormen worden hieronder uitgewerkt.

Sommige diagrammen zijn bij het uitwerken van de solution data platform architectuur optioneel. Deze optionele modelleervormen worden hieronder uitgewerkt.

Het fysieke datamodel beschrijft de manier waarop gegevens in een databank zijn opgeslagen of in een bericht worden uitgewisseld. De verbinding tussen het logische en het fysieke datamodel wordt gelegd door het omzetten van de logische gegevensobjecten in database-definitie instructies conform een bepaalde Data Definition Language (DDL). Na uitvoeren van de DDL op een fysieke database, liggen de definities van de database-objecten vast in de data dictionary van die database. Of voor berichten in een schema definitie dat vastligt in een XSD. Fysieke modellering richt zich voornamelijk op het technische aspect.

Fysiek datamodel voor het definiëren van berichten op basis van XML Schema Definition.

Fysieke datamodellen voor een relationele database uitgewerkt in een Microsoft SQL-Server database.

Het lijkt vreemd om de database structuur van een Sparx Enterprise Architect repository in een boek over repositories te behandelen. Echter het werken met een architectuur repository zal ook betekenen dat de content benadert moet worden op een wijze die niet beschikbaar is in de ontsluitingsvormen reeds aanwezig in de tooling. Daarom behandelen we hier de tabellen die de meest essentiële data omvatten voor het benaderen van de repository inhoud. Hou er rekening mee dat het aantal tabellen in een Sparx Enterprise Architect veel meer tabellen omvat.

Binnen fysieke datamodellen zijn volop data patronen beschikbaar. Veelal worden ze ook ingezet in modelleertools om het werk van de fysieke datamodelleur te vereenvoudigen met geautomatiseerde toepassingen. Daarnaast zijn er volop datamodellen die beschikbaar zijn om een start te maken met datamodellen voor een bepaald werkveld. Zoals bijvoorbeeld order registratie of gestandaardiseerde werkprocessen. In dit voorbeeld een eenvoudig voorbeeld van een fysiek model dat een transformatie is in een relationeel database management systeem op basis van een standaard modelleer concept in een logisch datamodel.

De gewenste situatie beschrijft een punt aan de horizon voor de logging architectuur. Het sluit daarbij aan bij de discussies rond de doelarchitectuur, met name op het vlak van service orientatie en bedrijfsregels

Bij een meer omvangrijke enterprise architectuur is het aanbrengen van hierarchie voor het categoriseren van de verschillende architecturen noodzakelijk. Veelal bestaat de hierarchie uit een aantal diagrammen die de enterprise architectuur op basis van verschillende classificaties en navigatiepaden.

In de voorgaande hoofdstukken zijn we ingegaan op de verschillende dimensies van het introduceren van een Architectuur Repository. In dit hoofdstuk gaan we in op een aantal hulpmiddelen die het introduceren van een architectuur repository ondersteunen en vereenvoudigen. We werken dit uit op basis van Sparx Enterprise Architect een modelleertool voor diverse modelleertalen. Daardoor is het ook uitermate geschikt om Sparx Enterprise Architect in te richten als architectuur repository. De uitwerkingen van deze hulpmiddelen zijn allemaal uitgewerkt op basis van Sparx Enterprise Architect.

Samenstelling van datamodellering voor de drie gedefinieerde lagen waarbij een combinatie van datamodelleertalen gecombineerd wordt tot een hybride datamodel.

Beschrijving van de verschillende big data technieken die ingezet kunnen worden bij een big data oplossing

Beschrijving van de aspecten van de tooling bij het werken met een architectuur repository. Enerzijds de benodigde functionaliteiten anderzijds een opsomming van diverse beschikbare tools.

De kaderstellende architectuur is van groot belang voor het sturen van de verandering in een organisatie om van de baseline architectuur te transformeren naar de target architectuur. Het stellen van kaders wordt veelal uitgewerkt op basis van architectuur principes of tegenwoordig ook wel bindende architectuur afspraken genoemd. Daarnaast kun je ook de beschrijving van de viewpoints terugvinden omdat die ook beschouwd kunnen worden als kaderstellend.

Vanuit diverse werkvelden kunnen kaders gesteld worden aan de productie en het gebruik van data. Denk bijvoorbeeld aan data architectuur, security en privacy maar ook aan het stellen van kwaliteitseisen aan data. Kenmerkend hierbij is, dat de kaders richting geven aan het gebruik van de data, maar ook aan andere aspecten zoals de opslag, het gebruik en incidenteel ook aan de wijze waarop de data geproduceerd wordt. Kaders kunnen op meerdere wijzen beschreven worden bijvoorbeeld als risico, eis of beperking. In dit whitepaper sluiten we aan op de modelleerwijze van ArchiMate en werken we de kaders uit op basis van requirements en principes. Waarbij we principes beschouwen als generalisaties van de requirements. Naast de kaders zul je binnen een metadata management model ook een uitwerking zien van de maatregelen die genomen kunnen worden om de gestelde kaders te realiseren. We zullen hierbij een aantal eenvoudige voorbeelden uitwerken in de volgende paragrafen.

Vanuit diverse werkvelden kunnen kaders gesteld worden aan de productie en het gebruik van data. Denk bijvoorbeeld aan data architectuur, security en privacy maar ook aan het stellen van kwaliteitseisen aan data. Kenmerkend hierbij is, dat de kaders richting geven aan het gebruik van de data, maar ook aan andere aspecten zoals de opslag, het gebruik en incidenteel ook aan de wijze waarop de data geproduceerd wordt. Kaders kunnen op meerdere wijzen beschreven worden bijvoorbeeld als risico, eis of beperking. In dit whitepaper sluiten we aan op de modelleerwijze van ArchiMate en werken we de kaders uit op basis van requirements en principes. Waarbij we principes beschouwen als generalisaties van de requirements. Naast de kaders zul je binnen een metadata management model ook een uitwerking zien van de maatregelen die genomen kunnen worden om de gestelde kaders te realiseren. We zullen hierbij een aantal eenvoudige voorbeelden uitwerken in de volgende paragrafen.

Het logisch model wordt uitgewerkt op basis van de modelleertaal UML en dan met name het klassediagram. Het biedt daarmee de mogelijkheid om de data in detail te modelleren maar het staat nog steeds los van de fysieke implementatie.

Het logische datamodel beschrijft de structuur van en de referenties tussen de logische gegevensobjecten, genaamd objecten of tabellen. Het conceptuele model is verbonden aan het logische model doordat entiteiten worden omgezet in objecten of tabellen (of preciezer: -definities), en doordat er een detaillering plaatsvindt van de relaties en attributen. Het logische datamodel focust op semantisch- en syntactisch vlak.

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.

Uitwerking van het model op basis van logische applicaties inclusief de uitwerking van de deelfuncties

Het logisch model wordt uitgewerkt op basis van de modelleertaal UML en dan met name het klassediagram. Het biedt daarmee de mogelijkheid om de data in detail te modelleren maar het staat nog steeds los van de fysieke implementatie.

Logische datamodellering is een model uitgewerkt zonder de implementatie aspecten van de onderliggende technische platformen. Binnen logische datamodellering zijn patronen veel toegepast. Er zijn dan ook veel catalogi te vinden met logische datamodelleer patronen. Hier behandelen we een viertal voorbeelden van dergelijke logische datamodel patronen.

Master en Referentie Data zijn de werkprocessen gericht op het realiseren van generieke data entiteiten relevant voor een grote groep van stakeholders. Dit stelt bijzondere eisen aan de inrichting vanuit het perspectief van data kwaliteit. Daarmee ontstaat er een nauwe relatie tussen deze kennisdomeinen.

Master en referentie data gericht op het realiseren van data kwaliteiten voor generieke data in de organisatie het is daarmee een belangrijk kennisgebied vanuit het data kwaliteit, data governance en data management perspectief.

Welke data entiteiten zijn relevant voor de gehele organisatie of daarbuiten en dienen daarom met bijzonder kwaliteitsmaatregelen op voldoende hoog niveau gehouden te worden.

Binnen dit onderdeel zijn een aantal matrices opgenomen om op eenvoudige wijze verbanden te zien tussen de verschillende views op de architectuur van een repository. Deze matrices zijn gebaseerd op ArchiMate concepten waarmee de verbanden op basis van ArchiMate elementen en connectoren in een tweedimensionale matrix worden gepresenteerd.

Data patronen zijn generieke oplossingen voor frequent terugkerende meta data problemen. Voor dataverwerking en -vergaring is dit kenmerkend rond meta data. Dataverwerking en -transformatie is van zichzelf al een uitdaging. De behoefte om op adequate wijze ook de meta data te verzamelen en te registreren is daarmee een extra complicerende factor. In onderstaande paragrafen worden daarom een aantal kenmerkende meta data patronen beschreven.

Metamodel bestaat uit een opsomming van verschillende voor architectuur relevante modelleertalen inclusief een aantal submodellen en talen. Op basis hiervan kan door de organisatie een selectie gemaakt worden van de voor hen relevante architectuurtalen en -subtalen. In de uitwerking van de hulpmiddelen wordt een dergelijk metamodel op basis van vereenvoudigde viewpoints in ArchiMate als voorbeeld uitgewerkt.

Het metamodel in combinatie met modelleer- en naamgevingsconventie is een belangrijk onderdeel van datamodelleren. Met name als er gemodelleerd wordt door een team van verschillende modelleurs in de organisatie. Het is dan essentieel dat er een aantal afspraken gemaakt wordt over hoe er gemodelleerd wordt en wat de naamgevingsconventie is die gebruikt wordt. Het metamodel wordt hier uitgewerkt in de voorbeeld van een diagram. Op dit diagram is het metamodel afgebeeld met alle elementen, relaties en attributen etc die gebruikt kunnen worden binnen een diagram ten behoeve van dit metamodel. Daarmee worden dus in een aantal gevallen meerdere relaties weergegeven op een element. Dit toont daarmee aan hoe meerdere elementen van hetzelfde stereotype met elkaar vereenvoudigd kunnen worden. Daarnaast wordt er op het diagram van het metamodel een checklist getoond die puntsgewijs de condities binnen het metamodel beschrijven. Het kan dus desgewenst bij uitwerkingen van diagrammen gebruikt worden of een modelleur op de juiste wijze het metamodel heeft toegepast. Deze werkwijze is daarmee wat eenvoudiger dan het uitwerken van metamodellen op basis van een UML klassemodel. Nadeel is daarmee dat niet elke regel in het metamodel volledig uitgemodelleerd kan worden. In deze context is echter de gekozen aanpak meer dan voldoende. Gebruik de uitwerkingen van de metamodellen als een startpunt voor het toepassen van de metamodellen in de context van de eigen organisatie. Het model is eenvoudig uit te breiden met nieuwe elementen en relaties en met nieuwe condities binnen de checklists.

Dit is een voorbeeld van modelleer- en naamgevingsconventies die ingezet kan worden binnen een architectuur repository. Deze uitwerking is een voorbeeld hoe je een metamodel en de conventies kunt uitwerken. In dit geval voor een data architectuur uitwerking. Het metamodel is uitgewerkt op basis van het DMBoK raamwerk. Dit houdt in dat een deel van het raamwerk wel uitgewerkt is en de anderen nog niet. Hier is met name vanuit het gezichtspunt van de data architect een uitwerking van modelleerconventies en architecturele modellen. Voor het werken met meta data geldt een whitepaper over de modelleerwijzen rond metadata.

Kenmerken, eisen, vereisten die behoren bij Big Data

Dit is een pakket met vier logische scenario's voor de implementatie van een Master Data-oplossing. Deze logische modellen hebben geen relatie met enige fysieke implementatie. Daarom is de lange lijst met alternatieven relevanter. Deze scenario's kunnen helpen in de volgende situaties:

• Functionele vereisten toewijzen aan scenario's
• Het in kaart brengen van niet-functionele eisen en kwaliteiten aan scenario's
• Complexiteitsanalyse van scenario's
• Mogelijke oplossingen en componenten toewijzen aan scenario's

Verschillende conceptuele data modellen met een hiërarchie van conceptuele data entiteiten voor referentie en master data

Logische datamodellen met een uitwerking voor verschillende referentie data logische structuren met data entititeiten, attributen en assoociaties.

In het logische applicatie model beschrijven we alleen welke logische applicatiefuncties nodig zijn binnen de oplossing zonder te kijken naar de beschikbare componenten en informatiesystemen. Dit helpt bij het maken van een technisch onafhankelijk applicatie model dat later kan worden gebruikt om verschillende oplossingsscenario's en componentstapels te modelleren. Deze stapels worden geanalyseerd en met elkaar vergeleken op basis van de functionele en niet functionele eisen.

Wordt het project dat een solution oplevert afgerond dan zal de baseline architectuur binnen de enterprise architectuur gaan veranderen, dat is het uiteindelijke eindresultaat van een solution of project. Daarom zullen de concepten aanwezig in de modellen van de solution architectuur na oplevering uitgewerkt moeten worden in de baseline architectuur. De modellen moeten op basis daarvan aangepast worden naar de nieuwe situatie ofwel de nieuwe baseline architectuur. Dit dient uitgevoerd te worden in een gecontroleerde processtap in het architectuurproces waarbij veelal de modelmanager of custion bij betrokken is. Deze package is daarmee een soort van doorgeefluik waar in de solutions worden geplaatst waarmee aangegeven wordt dat deze kunnen worden geintegreerd met de baseline architectuur in de enterprise architectuur packages.

Net als bij de solution architecturen is het mogelijk dat deelmodellen uitgewerkt in de persoonlijke packages onderdeel gaan uitmaken van een solution architectuur of van de enterprise architectuur. Ook hierbij een map om een gecontroleerd architectuurproces te realiseren waarmee deelarchitecturen onder verantwoording van de modelmanager worden overgebracht naar de architecturen met een ander (vastgestelde) status.

Dit is de navigatie voor de domein architectuur. Op basis van het raamwerk om de beschrijvende data-architectuur zijn in deze sectie links opgenomen naar de onderliggende diagrammen voor de verschillende secties in het raamwerk.

In het samenvattende model is de metadata uitgewerkt op basis van een vereenvoudigd model. Dit geldt als een soort startpunt voor metadata uitwerking op basis van een aantal aanwezige modelleertalen relevant in het werkveld van data management

Opsomming van alle objecten binnen de architectuur gesorteerd op type en naam.

Het wordt gezien als een good practice om de elementen te scheiden van de diagrammen in een omvangrijke enterprise architectuur. Het is mogelijk om de objecte te scheiden in de verschillende subpackages van de enterprise architectuur. Hier is ervoor gekozen dit te doen in de root package van de enterprise architectuur. In dit voorbeeld is een indeling gemaakt voor subpackages per ArchiMate laag en of elementtype. Hierbij zijn er verschillende andere indelingen mogelijk. Bepaal hier de indeling die in de context van de eigen organisatie goed werkt. Ook het sorteren van de elementen op elementtype in een allesomvattende collectie werkt bij sommige organisaties goed.

Objectmodellen zijn diagrammen waarbij instanties worden gemaakt van een aantal klassen in het logisch klassemodel. Het kan gebruikt worden om voorbeelden te presenteren aan eindgebruikers met voor hen herkenbare objecten binnen het klassemodel.

Het objectmodel beschrijft het concept bouwblok zoals dat gedefinieerd is binnen het architectuurproces. Bouwblokken zijn communicatieve concepten tussen architecten onderling en tussen architectuur en de verschillende stakeholders zoals ontwikkelaars en beheerders. Daarnaast ook interne diensten en eventueel externe stakeholders zoals leveranciers of ketenpartners. Het model bestaat uit een beperkte set aan concepten met onderlinge relaties. Dit model is uitgewerkt in een ArchiMate business objecten diagram. De concepten in het objecten en definitie diagram zijn vervolgens in detail uitgewerkt en beschrijven hiermee de kaders van de bouwblokken.

Sommige diagrammen zijn bij het uitwerken van de domein governance architectuur optioneel. Deze optionele modelleervormen worden hieronder uitgewerkt.

Sommige diagrammen zijn bij het uitwerken van de domein governance architectuur optioneel. Deze optionele modelleervormen worden hieronder uitgewerkt.

Sommige diagrammen zijn bij het uitwerken van de solution architectuur optioneel. Deze optionele modelleervormen worden hieronder uitgewerkt.

Sommige diagrammen zijn bij het uitwerken van de solution architectuur optioneel. Deze optionele modelleervormen worden hieronder uitgewerkt.

In veel architecturen zijn bouwblokken een belangrijk onderdeel bij de introductie van standaardisatie en hergebruik. Ook hierbij daarom een inrichting in de enterprise architectuur in de vorm van een aantal collecties van bouwblokken die een architect kan inzetten bij het uitwerken van solutions om een solution te laten bijdragen aan de weg naar de target architectuur. Ook deze package zal een indeling kennen in de vorm van subpackages en/of het gebruik van diagrammen voor de binnen de organisatie aanwezige bouwblokken. Hierbij zal veelal ook gebruik gemaakt worden van navigatie en overzichtsdiagrammen. Zie ook de paragraaf over het toepassen van bouwblokken binnen een architectuur.

Overzicht van de architectuurlandschappen die uitgewerkt zijn. Veelal gebaseerd op meerdere diagrammen en daarbij ingedeeld op basis van de lagen in het core model van ArchiMate desgewenst verder opgesplitst naar domeinen in een organisatie of architectuur. In dit document is het overzicht van de landschappen gerubriceerd en ingedeeld. Dit kan op basis van packages en daarbinnen een of meerdere diagrammen, maar ook het gebruik van een naamgevingsconventie voor de diagrammen is ook een adequate werkwijze. Noodzakelijk in deze is dat de architecten hierin de concepten binnen de vastgestelde architectuur eenvoudig kunnen terugvinden. Enerzijds in de package structuur anderzijds ook door gebruik te maken van zoek en sorteer functionaliteiten.

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.

In dit pakket staan de geïmplementeerde bouwstenen voor dit project vermeld. In een latere fase zullen deze met oplossingsbouwstenen worden overgebracht naar de architectuurwiki

Voorbeeld van een project structuur gebaseerd op de status van verschillende deelmodellen. Kenmerkend hierin is dat per fase een andere indeling geldt voor de repository. Deze aanpak geeft aan dat de package structuur geen beperking hoeft te zijn. Over de package structuur kan bij de introductie van een architectuur repository een discussie ontstaan over wat de juiste indeling is. Houd hierbij de volgende suggesties aan als startpunt:

• Per onderdeel van de architectuur repository kan de package indeling veranderen
• De package structuur kan eenvoudig gewijzigd worden als bij ontwikkeling van de werkwijze de inzichten veranderen
• Het bepalen van de indeling wordt veelal beheerd door de model manager of custodian voor de generieke architectuur onderdelen
• In werk of project package structuren hebben de modelleurs meer vrijheid in de inrichting.
• Gebruik voor solution architecturen een sjabloon als startpunt.
• Houd in de package indeling rekening met de transfer van architectuur concepten in een fasering en levensloop.

De package structuur dient gericht te zijn op de modelleurs die werken met de architectuur modellen. Gebruikers van deze modellen dienen op andere wijze ondersteund te worden bijvoorbeeld door navigatie diagrammen.

Uitwerking van een RASCI matrix waarbij RASCI staat voor Responsible, Accountable, Supportive, Consulting, Informing omtrent de betrokkenheid bij bepaalde data entiteiten in de organisatie. We stellen de RASCI de matrices op op basis van ArchiMate concepten en realiseren daarmee een andere weergave op basis van hetzelfde onderliggende ArchiMate model.

Referentiedata is data die wordt gebruikt om andere data te classificeren of te categoriseren. Deze data is meestal statisch of verandert slechts langzaam over tijd. Een belangrijk kenmerk van referentiedata is dat ze vaak worden gebruikt als een soort "ankerpunten" binnen verschillende systemen en processen.

Transformatie van een relationele databasegegevensbron naar het gestandaardiseerde gegevensdoel

SIPOC is een krachtige notatiewijze om de data elementen, de bedrijfsprocessen en de omgeving van een bedrijfsproces met elkaar in verband te brengen en te visualiseren. SIPOC staat voor supplier, input, process, output en consumer en laat zien welke data door de organisatie stroomt van producers naar consumers via een proces.

SIPOC is een eenvoudige modelleerwijze voor het modelleren van bedrijfsprocessen, objecten en rollen. Er zijn een aantal voorbeelden gegeven. Kopieer een van de diagrammen en pas het aan naar de nieuwe SIPOCs voor een bedrijfsspecifieke uitwerking..

In deze packages worden de solution uitgewerkt die momenteel de verandering van de organisatie van de baseline naar de target architectuur implementeren. Afhankelijk van de omvang van de organisatie zul je hier meerdere beschrijvingen van solution architecturen terugvinden.

Architectuur model voor een aanpak op basis van een architectuur repository. In dit model zijn een aantal generieke architectuur onderdelen uitgewerkt. Dit dient enerzijds als voorbeeld voor een architectuur uitwerking. Anderzijds kan het uitgebreid worden met organisatie specifieke organisatie onderdelen van de architectuur. Daarmee wordt het een startpunt voor een organisatie brede architectuur. Dit hoofdstuk is uitgewerkt op basis van een aantal architectuuronderdelen die relevant zijn in een solution architectuur. Voor de introductie van een werkwijze met een architectuur repository is eenzelfde werkwijze gevolgd. Feitelijk passen we hier een "eat your own dogfood" aanpak toe.

Dit sjabloon is een package en diagram structuur voor een architectuurdocument, bijvoorbeeld een solution - of project start architectuur. Hierbij is in de diagrammen een koppeling gemaakt naar een viewpoint uitwerking zodat modelleurs ondersteuning krijgen met de viewpoint diagrammen bij het uitwerken van het model. Desgewenst kan dit package gekopieerd worden in EA om het projectspecifiek te maken. Vervolgens kan er een document van gegenereerd worden. Maak daarbij gebruik van de IDEA AddOn waarin je in de package helper een zoek en vervang actie kunt uitvoeren Dit package en de subpackages en diagrammen is uitgewerkt op basis van een package structuur dat een sjabloon van een solution omvat. Dit kan eenvoudig gekopieerd worden als een startpunt voor het uitwerken van een nieuwe solution. Het uitgewerkt voorbeeld van een dergelijk sjabloon is terug te vinden als een resource in de aanwezige voorbeeld architectuur repository.

In de uitwerking van de beschrijvende data architectuur zul je een aantal diagrammen zien die het drielaagsdatamodel voor deze solution weergeven. Hier worden dus deelmodellen van het datamodel getoond. Vaak zal dit bestaan uit een baseline en target drielaagsmodel voor de scope van de solution.

In de uitwerking van de beschrijvende data architectuur zul je een aantal diagrammen zien die het drielaagsdatamodel voor deze solution weergeven. Hier worden dus deelmodellen van het datamodel getoond. Vaak zal dit bestaan uit een baseline en target drielaagsmodel voor de scope van de solution.

De solution architectuur is gericht op het beschrijven van de verandering die in een data gedreven organisatie wordt uitgevoerd. In de meeste organisaties worden veranderingen met behulp van projecten en programma's geintroduceerd. Om grip te krijgen op deze veranderingen in de organisatie zal de data-architect daarom een architecturele beschrijving gaan maken van wat deze verandering precies inhoudt. Daarnaast wordt beschreven met welke architecturele kaders deze verandering gebaseerd is. Afhankelijk van de complexiteit van de verandering kan de data-architect ervoor kiezen om meerdere plateau architecturen uit te werken. Bijvoorbeeld de baseline en de target architectuur en desgewenst tussen architecturen.

Vanuit de domein architectuur worden een aantal kaders gesteld aan de verandering in een organisatie. Daarom worden er een aantal diagrammen getoond op welke wijze dit project invloed heeft op de kaders die vanuit de data-architect zijn uitgewerkt in de kaderstellende domeinarchitectuur.

Deze laag zal vanuit de solution aangepast of uitgebried worden vanuit een dataplatform dat is opgebouwd uit één of meerdere datatoepassingen. Dit data platform en de datatoepassingen worden uitgewerkt in de vorm van een data- en applicatielandschap dat in de solution wordt uitgewerkt. Dit landschap wordt gemodelleerd zodat de data gemanaged kan worden in een combinatie van applicatiecomponenten. Daarnaast zal er binnen de soltion data uitgewisseld worden tussen diversie informatiesystemen binnen de organisatie en er zal data uitgewisseld worden vanuit deze toepassingen met externe partijen, veelal bestaande uit informatiesystemen bij externe stakeholders. Vanuit data-architectuur is er behoefte om dit datalandschap te beschrijven zodat vanuit data-architectuur voor en na de implementatie van de solution. Onder dit data- en applicatielandschap kan vervolgens een infrastructurele inrichting beschreven worden vanuit het perspectief van de data-architect. Waar wordt de data na deze solution implementatie opgeslagen in de infrastructuur. Hoe zijn de fysieke datastromen binnen de infrastructuur. Via welke technische interfaces en infrastructurele toepassingen. Daarnaast is het van belang om hier bij cloud gebaseerde toepassingen hoe de data tussen cloud en on premise voorzieningen worden uitgewisseld.

Dit is een globlale uitwerking van welke oplossing de solution gaat introduceren. Het is een samenvattende weergave van de oplossing. Echter wel vanuit meerdere data gedreven gezichtspunten zoals governance, stakeholders en de producten die gerealiseerd worden door het project.

De solution architectuur is gericht op het beschrijven van de verandering die in een data gedreven organisatie wordt uitgevoerd. In de meeste organisaties worden veranderingen met behulp van projecten en programma's geintroduceerd. Om grip te krijgen op deze veranderingen in de organisatie zal de data-architect daarom een architecturele beschrijving gaan maken van wat deze verandering precies inhoudt. Daarnaast wordt beschreven met welke architecturele kaders deze verandering gebaseerd is. Afhankelijk van de complexiteit van de verandering kan de data-architect ervoor kiezen om meerdere plateau architecturen uit te werken. Bijvoorbeeld de baseline en de target architectuur en desgewenst tussen architecturen.

Vanuit de domein architectuur worden een aantal kaders gesteld aan de verandering in een organisatie. Daarom worden er een aantal diagrammen getoond op welke wijze dit project invloed heeft op de kaders die vanuit de data-architect zijn uitgewerkt in de kaderstellende domeinarchitectuur.

Dit is een globlale uitwerking van welke oplossing de solution gaat introduceren. Het is een samenvattende weergave van de oplossing. Echter wel vanuit meerdere data gedreven gezichtspunten zoals governance, stakeholders en de producten die gerealiseerd worden door het project.

Model van de stakeholders betrokkenheid rond data gedreven werken. Waarbij er over twee dimensies wordt gekeken naar de macht en de interesse van data gedreven werken.

Een stakeholder is een persoon, groep of organisatie die belang heeft bij een bepaalde verandering. Meestal in de vorm van veranderingen in een project, besluit of bedrijf, omdat hij of zij wordt beïnvloed door de uitkomst ervan of er zelf invloed op kan uitoefenen. Stakeholders kunnen zowel intern als extern zijn en hebben vaak uiteenlopende belangen. Stakeholders spelen een belangrijke rol in het succes van verandering, en het begrijpen en beheren van hun behoeften is vaak cruciaal voor de data-architect. Vanuit een data-architectuurperspectief zijn er enkele belangrijke bijzonderheden met betrekking tot stakeholders: Verschillende belangen: Stakeholders in data-architectuur hebben vaak uiteenlopende belangen. Bijvoorbeeld:

• Business stakeholders: Gericht op hoe data waarde kan toevoegen aan bedrijfsprocessen.
• Technische stakeholders: Gefocust op de implementatie en technische haalbaarheid.
• Regelgevende stakeholders: Bezorgd over naleving van wet- en regelgeving, zoals GDPR.

Complexiteit van concerns: Stakeholders hebben vaak specifieke zorgen, zoals datakwaliteit, beveiliging, schaalbaarheid en interoperabiliteit. Het is de taak van de data-architect om deze zorgen te begrijpen en te adresseren. Viewpoints en modellen: Data-architecten gebruiken vaak verschillende modellen en visualisaties om de behoeften van diverse stakeholders te communiceren. Dit kan variëren van technische blauwdrukken tot strategische dashboards. Veranderende rollen: De rol van stakeholders kan veranderen naarmate de organisatie evolueert. Dit vereist flexibiliteit in de aanpak van de data-architect.

In dit document wordt nadat de solution voor het werken met een architectuur repository is uitgewerkt een aantal generieke stappenplannen uitgewerkt. Deze stappenplannen geven een team een leidraad welke activiteiten uitgevoerd dienen te worden om de transformatie van een document gedreven werkwijze naar een repository gedreven werkwijze te realiseren. De stappenplannen in dit document bestaan uit een aantal generieke activiteiten voor de introductie van een architectuur repository. Echter deze stappen kunnen eenvoudig worden uitgebreid in de specifieke context van de eigen organisatie. Uitwerking is op basis van de volgorde van uitwerken van de architectuur en vervolgens een stappenplan voor het introduceren van de tooling van de architectuur repository.

Beschrijving van de infrastructurele aspecten van een data gedreven en big data architectuur

Inleiding Toepassen bouwblokken beschrijft de opzet en de definitie van bouwblokken. Bouwblokken worden bij een organisatie geïntroduceerd vanuit het perspectief van:

• Hergebruik.
• Ontkoppeling
• Generalisatie en specialisatie.
• Standaardisatie.
• Interactie tussen aanbieders en afnemers van informatievoorziening. concepten (op dit moment applicaties en infrastructuur maar dit moet ook toepasbaar zijn op bedrijfsarchitectuur).
• Specificatie van kosten en opbrengsten.
• Verbeteren (versnellen) van de dienstverlening.
• Informatiebeveiliging.

Dit document bestaat uit de volgende delen:

• Model: beschrijft de definitie, kenmerken en verbanden van het concept bouwblok en de bijbehorende specialisaties
• ArchiMate viewpoints: uitwerking van de viewpoints voor de bouwblokken. Deze viewpoints zijn opgebouwd uit een beperkte set aan ArchiMate elementen en associaties.
• Voorbeelden van uitwerking van de verschillende bouwblokken binnen de hierboven gedefinieerde ArchiMate viewpoints
• Sparx implementatie, wijze waarop dit geïmplementeerd wordt in Sparx en hoe het gecommuniceerd/gepubliceerd wordt naar de verschillende stakeholders.

Goede data-architecten kunnen het verschil maken bij de introductie van data gedreven werken in een organisatie. Ze kunnen ook helpen om problemen op te lossen zonder overhaaste conclusies te trekken. De data-architect zal complexe situaties tot in detail analyseren modellen opstellen van het data aspect in grote veranderingen. Daarnaast worden kaderstellende architecturen opgesteld om veranderingen in de organisatie te laten bijdragen aan data gedreven werken. Maar wat is een goede data-architect precies en over welke competenties moet een goede architect beschikken? In dit hoofdstuk worden deze vragen behandeld door de reeks vaardigheden en competenties te identificeren en te beschrijven die data-architecten nodig hebben om effectief te zijn in de huidige data intensieve omgevingen. Hier wordt de definitie van een competentie gedefinieerd als: 'een vermogen dat nodig is om de rol van data-architect effectief uit te voeren'.

In deze voorbeelden worden een aantal aspecten van het modelleren op basis van bouwblokken uitgewerkt. Beschouw dit voorbeeld zonder dat er is nagedacht over de inrichting van de catalogi en de granulariteit van de bouwblokken. Daarnaast wordt alleen een toelichting gegeven bij de diagrammen, niet bij de daarin uitgewerkte concepten.

Verzameling van werkinstructies voor de modelmanager rond de inrichting van de repository en het gebruik van Sparx Enterprise Architect

Package waarin modelleurs of teams eigen uitwerkingen kunnen maken van deelmodellen, of deeluitwerkingen van een solution. Binnen deze packages hebben de modelleurs een persoonlijke package waarin ze vrij zijn om een eigen indeling te kiezen en elementen en diagrammen uit te werken. Let op: het is belangrijk dat er afspraken worden gemaakt over het hergebruik van elementen die aanwezig zijn. Het is veelal niet toegestaan om elementen aanwezig in deze persoonlijke packages her te gebruiken in bijvoorbeeld solution architecturen en helemaal niet in enterprise architectuur modellen.