nyuuzyou/wikis huggingface dataset:
Bedrijfsobjecten

Category:Data
Category:Bedrijfsarchitectuur
Bedrijfsobjecten zijn concepten met een bepaalde betekenis waarmee gemeenten te maken hebben (bijvoorbeeld 'paspoort' of 'uitkering'). Het GEMMA Bedrijfsobjectenmodel toont de belangrijkste gemeentelijke bedrijfsobjecten. Omdat over objecten gegevens worden vastgelegd wordt het bedrijfsobjectenmodel ook wel een 'conceptueel gegevensmodel' genoemd. Daarin worden de grotere eenheden van gegevens beschreven in een taal die breed in de organisatie herkenbaar is. Het is nadrukkelijk geen logisch gegevensmodel en het bevat geen beschrijving van de gewenste gegevensstructuur.
Bedrijfsobjecten zijn onafhankelijk van de inrichting van organisatie en IT en zijn langere tijd bruikbaar. Voor de GEMMA als referentiearchitectuur voor alle gemeenten vormen ze daardoor een stabiel referentiekader. Het model is bijvoorbeeld bruikbaar voor het inrichten van beheer, gebruik en beveiliging van data door per bedrijfsobject te benoemen wie eindverantwoordelijk is voor de kwaliteit van object gerelateerde data, welk systeem geldt als bron (“system of record”) en welk niveau van beschikbaarheid, integriteit en vertrouwelijkheden nodig is.
=== Lijst met bedrijfsobjectmodellen ===
Het Gemeentelijk Gegevensmodel maakt voor ieder beleidsdomein 1 of meerdere informatiemodellen. De beleidsdomeinen zijn gebaseerd op de Iv3-taakvelden en uitgebreid met enkele extra domeinen voor gegevensdefinities die over de beleidsdomeinen heen gebruikt worden.
De GEMMA heeft voor ieder beleidsdomein 1 bedrijfsobjectmodel gemaakt:
Bedrijfsobjecten omgevingswet

Category:Omgevingswet
==Inleiding==
Een onderdeel van de bedrijfs- en informatie-architectuur is de globale gegevensarchitectuur. De projectkaart (van het werkpakket BIA) omschrijft dit nader als een bedrijfsobjectenmodel. Hier treft u het bedrijfsobjectenmodel aan van het gemeentelijk domein dat betrokken is bij de uitvoering van de Omgevingswet.
===Bedrijfsobjectenmodel===
Hieronder verstaan we de representatie van de concepten (‘dingen’, ‘onderwerpen’) en hun relaties (rollen t.o.v. elkaar) zodanig dat informatie daarover een organisatie (‘de business’) in staat stelt haar doelen te bereiken (cq. haar taken uit te voeren). Anders gezegd: objecten waarvan de organisatie informatie nodig heeft om haar taken uit te kunnen voeren. 
===Afbakening===
In de opdrachtbeschrijving komt de term ‘globaal’ voor. De uitwerking van het bedrijfsobjectenmodel gaat dan ook niet verder dan dat nodig is voor het minimaal gewenste inzicht in de clusters aan informatie die:
* benodigd zijn voor de uitvoering van ‘Omgevingswet-processen’, 
* beheerd en verschaft moeten worden door de referentiecomponenten van de informatie-architectuur (ter ondersteuning van de uitvoering van de Omgevingwet),
* het mogelijk maken om de context van informatiestromen, tussen die referentiecomponenten, te kunnen analyseren. 
===Aanpak===
Het bedrijfsobjectenmodel is tot stand gekomen door middel van:
* Informatieanalyse van de tekst van de Omgevingswet;
* Informatieanalyse van de meest kenmerkende processen voor de uitvoering van de Omgevingswet;
* Beschouwing van het bedrijfsobjectenmodel zoals dat in GEMMA is opgenomen;
* Reviews en besprekingen van concept-versies.
Nog niet beschouwd zijn de informatieobjecten zoals benoemd bij de zaaktypen in de Zaaktypecatalogus Omgevingswet. Dit volgt in een volgende versie. 
===Bedrijfsobjecten===
De bedrijfsobjecten en onderlinge relaties en daarmee het bedrijfsobjectenmodel visualiseren en specificeren we in verschillende views, zoals op de fysieke leefomgeving, betrokkenen, wet- en regelgeving, vergunningverlening en toezicht en handhaving:
Bedrijfsprocessen omgevingswet

category:Procesarchitectuur
Category:Omgevingswet
Category:Bedrijfsprocessen Omgevingswet__NOEDITSECTION__
==Processenmodel==
Door de invoering van de Omgevingswet zal een groot aantal gemeentelijke bedrijfsprocessen aangepast moeten worden. Ter ondersteuning is een interbestuurlijk afgestemd processenmodel beschikbaar waarin deze processen en hun onderlinge samenhang worden weergegeven. Onderstaande figuur toont het processenmodel. Klik op een (blauw) proces voor meer informatie.
==Download als ArchiMate-bestand==
De bedrijfsprocessen voor de omgevingswet zijn gemodelleerd in ArchiMate en met behulp van het Open Group ArchiMate Exchange format ingelezen in GEMMAonline. 
Wil je het Omgevingswet ArchiMate-model gaan gebruiken in je eigen architectuurtool, dan kunt je hier de Omgevingswet ArchiMate-repository (AMEFF) downloaden (Let op: download met rechter muisklik en kies 'Koppeling opslaan als'). Op de site van de Softwarecatalogus vindt je een Handleiding koppeling architectuurtools. Daarin is beschreven hoe je een AMEFF-bestand kunt importeren in de open source architectuurtool Archi.
Terug naar Overzicht project Omgevingswet.
Beschikbaar stellen managementinformatie

Category:GEMMA Patronen
Managementinformatie bestaat uit de gegevens die nodig zijn voor de besturing en beheersing van de organisatie alsmede de gegevens die nodig zijn om horizontale en verticale verantwoording over het functioneren van de organisatie af te leggen. In het kort gaat het dus om stuur- en verantwoordingsinformatie. In dit patroon wordt beschreven op welke manier het beschikbaar stellen van managementinformatie ingericht kan worden gebruik makend van de GEMMA referentiecomponenten.
=== Beschrijving GEMMA patroon ===
Aan het patroon voor het beschikbaar stellen van managementinformatie wordt invulling gegeven door de data-warehousecomponent en de managementinformatiecomponent. Gegevens worden aan de data-warehousecomponent aangeleverd door basisregistraties, kernregistraties, taakspecifieke informatiesystemen en eventuele andere bronnen. Deze aanleverende bronnen gebruiken hiervoor meestal een techniek die op de bestandsuitwisseling integratiestijl gebaseerd is. Denk hierbij aan ETL-processen die periodiek worden uitgevoerd. Aangeleverde gegevens worden door de data-warehousecomponent ingelezen, getransformeerd en opgeslagen in het de eigen gegevensopslag. Via datamarts geeft de managementinformatiecomponent toegang tot een deelverzameling van de gegevens binnen de data-warehousecomponent. Datamarts zijn meestal specifiek voor een bepaald domein of thema.
Het is het uitdrukkelijke advies om nooit managementrapportages te genereren vanuit bronsystemen gezien de potentiële impact die deze rapportages heeft op performance en beveiligingsproblemen van die bronsystemen.
=== Aandachtpunten ===
Gegevens worden in de regel via ETL-processen aan een data-warehousecomponent aangeleverd door de verschillende bronnen. Deze processen worden periodiek uitgevoerd. De gegevens in de data-warehousecomponent kunnen daardoor gedateerd zijn. Per managementinformatierapportage moet bepaald worden of de gegevens in de data-warehousecomponent voldoen aan de kwaliteitseisen die vanuit de rapportage vereist zijn. Indien niet aan de gestelde eisen voldaan kan worden zullen de aanleverprocessen, of de periodiciteit waarmee gegevens aangeleverd worden aangepast moeten worden. De data-warehousecomponent bevat enkel kopieën van gegevens. Eventuele inhoudelijke aanpassing van gegevens dient plaats te vinden in de broncomponent en niet in de data-warehousecomponent.
=== Standaarden ===
Op het gebied van de inrichting van een data-warehousecomponenten, en wijze waarop gegevens aangeleverd worden aan data-warehousecomponenten, zijn geen gemeentelijke standaarden gedefinieerd.
Bespreek je informatievoorziening met de gemeente Nederland plaat

Categorie:Werken met GEMMA
Op initiatief van gemeente Zwolle is de plaat "De Gemeente Nederland” gemaakt. Voor de visualisatie is input geleverd in een serie workshops met afgevaardigden van de gemeenten Zwolle, Hilversum, Deventer, Kampen, Utrecht en de VNG. De visualisatie is gemaakt door ICTU met de idEA-methode.
De visualisatie biedt IV-collega’s binnen Nederlandse gemeenten een hulpmiddel om het gesprek aan te gaan met bestuurders en beslissers. Het geeft inzicht in de samenhang tussen:
* Dienstverlening en wettelijke taken van een gemeente
* De processen die nodig zijn om deze taken uit te voeren
* De informatie die in die processen wordt gebruikt
* De applicaties die het werk ondersteunen
* De benodigde infrastructuur
Daarnaast maakt de visualisatie het eenvoudiger om gebreken in de informatievoorziening (IV) bespreekbaar te maken en in kaart te brengen welke verbeteringen of ontwikkelingen nodig zijn.
In de Kijkwijzer IdEA Gemeente Nederland vind je een toelichting op de visualisatie en aanwijzingen hoe je deze kunt gebruiken.
Bekijk de plaat De gemeente Nederland in groot formaat.
Let op: in chrome, edge en andere op chrome gebaseerde browser, rechts klikken en bestand opslaan als. Firefox opent wel direct de plaat.
Lees hoe andere gemeenten de plaat gebruiken:
* Gemeente Zwolle bespreekt ...
Betrouwbaarheidscriteria van referentiecomponenten

Categorie:Privacy en Informatiebeveiliging
Gemeenten moeten zorgen dat informatie betrouwbaar is en de systemen die informatie verwerken betrouwbaar functioneren. In de context van informatiebeveiliging worden daarbij vaak 3 criteria gebruikt: 
* Beschikbaarheid: systemen en gegevens moeten beschikbaar zijn voor geautoriseerde gebruikers op het moment dat zij informatie nodig hebben.
* Integriteit: gegevens moeten in overeenstemming zijn met de werkelijkheid; ze mogen alleen worden gewijzigd bij voldoende autorisatie en wijzigingen moeten traceerbaar zijn.
* Vertrouwelijkheid: gegevens moeten worden beschermd tegen ongeoorloofd muteren, kopiëren, toevoegen, vernietigen of raadplegen. 
Deze betrouwbaarheidscriteria, aangeduid als de 'BIV-criteria', zijn bruikbaar als leidraad bij het ontwerpen, implementeren en handhaven van beveiligingsmaatregelen binnen een organisatie. 
Onderstaand diagram toont voor de GEMMA referentiecomponenten een score voor ieder van de 3 BIV-criteria. Een score geeft het niveau van een te beschermen belang aan, om op basis daarvan het vereiste beschermingsniveau te kunnen bepalen. Mogelijke scores voor ieder van de 3 aspecten zijn: 1 (laag), 2 (midden) en 3 (hoog). 
Het diagram is bijvoorbeeld bruikbaar:
* Om duidelijk te maken welke referentiecomponenten extra aandacht verdienen, omdat zij hoog scoren op 1 of meer betrouwbaarheidsaspecten. 
* Om voor iedere component in beeld te brengen waar het zwaartepunt in het te beschermen belang ligt. 
* Als startpunt voor een gemeente om BIV-scores voor aanwezige applicaties te bepalen
* Als hulpmiddel bij het uitvoeren van een, door de Informatiebeveiligingsdienst ontwikkelde, Baselinetoets BBN BIO.
Onder het diagram staat een tabel met per referentiecomponent de score op de 3 BIV-criteria, met daarachter een korte motivatie. 
== Diagram betrouwbaarheidscriteria ==
 
== Tabel betrouwbaarheidscriteria ==
De tabel toont alle referentiecomponenten en de betrouwbaarheidscriteria. Achter iedere BIV-score staat de belangrijkste reden om tot de score te komen. De tabel kan worden gefilterd op de een of meerdere scores van de criteria.
Bijlage 1. Redenen voor de opname van specifieke resultaten

Categorie:Duurzame toegankelijkheid
 __NOTOC__
A) wet- en regelgeving een andere bewaartermijn vereist dan het generieke resultaat. Zo stellen bijvoorbeeld de Wet basisregistraties adressen en gebouwen in artikel 10 en 13 en het Besluit basisregistraties adressen en gebouwen in artikel 7 en 8 dat brondocumenten voor de Basisregistratie Adressen en Gebouwen (BAG) permanent bewaard dienen te worden. Daarmee wordt een specifiek resultaat (11.1.5) gecreëerd ten opzichte van het generieke resultaat (11.1).
B) de trendanalyse bepaalt dat bepaalde archiefbescheiden of procesuitkomsten voor bewaring in aanmerking komen.
C) de risicoanalyse bepaalt dat een resultaat een andere bewaartermijn vereist dan het generieke resultaat. Zie hiervoor de Risicoanalyse zoals beschreven in hoofdstuk 7.
D) de procestermijn (zie bijlage 2) wijkt af waardoor de totale bewaartermijn verschilt van het generieke resultaat. Zo kan een toestemming worden verleend voor een éénmalige gebeurtenis (bijvoorbeeld een evenementenvergunning resultaat 11.1.1), voor een vastgestelde periode (bijvoorbeeld een ontheffing verkeersbesluit, resultaat 11.1.2) of voor een doorlopende termijn (bijvoorbeeld een doorlopende collectevergunning, resultaat 11.1). Het procesobject bij het selectielijstprocestype (toestemming verlenen) is de verleende toestemming. Aangezien de toestemming bij de drie voorbeelden een andere duur heeft is de relatie tussen het procesobject en de procestermijn anders. Eén voorbeeld is daarom als generiek resultaat aangewezen en voor de twee andere voorbeelden is een specifiek resultaat opgenomen.
Common Ground informatiearchitectuurprincipes

Category:Common Ground
De informatiekundige visie Common Ground beschrijft de informatiekundige uitgangspunten voor realisatie van de Common Ground doelstellingen. De informatiearchitectuurprincipes vertalen die naar 'kwalitatieve intentieverklaringen waaraan de architectuur moet voldoen'. Doel hiervan is om bij nieuwe ontwikkelingen goede keuzes te kunnen maken zodat stapsgewijs in de juiste richting wordt gewerkt. 
De principes zijn bedoeld voor informatiemanagers, adviseurs en architecten bij gemeenten, leveranciers en andere partijen die betrokken zijn bij vernieuwing van het gemeentelijke informatielandschap.
De hiernaast getoonde infographic toont de 6 principes die kernachtig de kenmerken van de voor Common Ground gewenste informatiearchitectuur beschrijven. Er wordt gewerkt met los gekoppelde componenten die door middel van moderne open standaarden samenwerken. Daarbij maken ze gebruik van eenmalig vastgelegde data die op een veilige en verantwoorde manier wordt ontsloten. Er wordt daarbij vastgelegd wie welke data waarom heeft gebruikt zodat inzicht in datagebruik is te bieden. 
De thema-architectuur Common Ground is in lijn met deze principes uitgewerkt. 
De principes en de daarbij behorende rationale en implicaties zijn meer in detail uitgewerkt op de pagina Informatiearchitectuurprincipes.
Common Ground vijflaagsmodel

Category:Common Ground
__NOTOC__
De thema-architectuur Common Ground maakt veelvuldig gebruik van het Common Ground vijflaagsmodel. Het model is een hulpmiddel om de informatiearchitectuur te beschrijven die nodig is voor realisatie van de Informatiekundige visie Common Ground. Het beschrijft een informatielandschap waarin dienstenafnemers elektronische diensten afnemen bij dienstenaanbieders. Een belangrijk doel daarvan is om te zorgen dat afnemers via gestandaardiseerde API's gebruik kunnen maken van data uit bronregistraties. 
Onderstaande afbeelding toont het volledige vijflaagsmodel met daarin de benoemde generieke functies. Generieke functies zijn de bekwaamheden of vermogens waarover aanbieders en afnemers moeten (gaan) beschikken bij het inrichten van hun informatievoorziening. Toelichting gelaagde architectuur beschrijft in zijn algemeenheid de voordelen van gelaagde architectuurmodellen. Common Ground vijflaagsmodel opbouw en gebruik licht de opbouw en het gebruik van het vijflaagsmodel toe. Common Ground generieke functies beschrijft alle getoond generieke functies meer in detail. 
 
==Generieke functies (capabilities)==
== Rollen==
==Lagen==
Contact

Categorie:Layout Elements
VNG Realisatie is van, voor en door gemeenten. Onze producten ontwikkelen we daarom voor en in samenwerking met gemeenten. Dit gebeurt met de grootst mogelijke zorg. We streven er naar om onze documenten en andere producten blijvend te verbeteren en te versterken. Dit lukt niet zonder gemeenten. Hebt u aanvullingen, suggesties, vragen of opmerkingen rondom dit of andere VNG Realisatie producten, aarzel dan niet en laat het aan ons weten. Alleen zo kunnen we samen onze producten nog beter maken. 
Voor vragen over GEMMA referentiearchitectuur, stuur een bericht naar gemmaonline@vng.nl of stel direct een vraag in de groep Regie op ICT op het forum van VNG.
== VNG Realisatie ==
VNG Realisatie is een bedrijfsonderdeel van VNG.
Telefoon: 070-373 83 93 (op werkdagen van 8.30 tot 17.00 uur).
Bezoekadres
VNG Realisatie
Nassaulaan 12
2514 JS Den Haag
Postadres
Postbus 30435
2500 GK Den Haag
Definiëren van gebeurtenistypes

Category:Eventorientatie
__NOTOC__
Om effectief notificeren mogelijk te maken is een van de eerste stappen het onderkennen van belangrijke gebeurtenissen die binnen het domein van een publisher plaatsvinden. 
Hieronder staat een 3-staps aanpak voor het bepalen en beschrijven van gebeurtenistypes waarvoor notificaties verstekt gaan worden. 
== Stap 1: Inventariseren van gebeurtenissen ==
De eerste stap is het identificeren van plaatsvindende gebeurtenissen binnen het domein, of een deel daarvan, bij de aanbieder. Daarbij is onderscheid te maken in 
* 'business gebeurtenissen' die herkenbaar zijn voor zakelijke vertegenwoordigers, zoals 'Offerte ontvangen' of 'Factuur betaald', ,en 
* 'technische gebeurtenissen' die herkenbaar zijn voor IT'ers, zoals 'Gebouwgegevens gewijzigd' of 'Klantrecord toegevoegd'. 
Vanwege de bredere herkenbaarheid is het meestal wenselijk om gebeurtenissen uit de eerste categorie te bepalen, maar in bepaalde gevallen kunnen ook meer technische gebeurtenissen meerwaarde hebben. Hierbij kan gebruik worden gemaakt van een techniek als '[event storming]' waarbij via workshops alle gebeurtenissen die binnen een specifiek domein worden geïnventariseerd en geordend. 
== Stap 2: Bepalen van relevante gebeurtenistypes ==
Bij deze stap wordt bepaald welke soorten gebeurtenissen het meest relevant zijn voor derden om notificaties over te ontvangen. Hierbij is het van belang dat consumers hun wensen kunnen inbrengen op basis waarvan een producer kan besluiten voor welke gebeurtenistypes hij events gaat publiceren. Ook bij deze stap is het van belang dat zowel domein-experts als technici zijn vertegenwoordigd en zij zoveel mogelijk dezelfde taal spreken. 
== Stap 3: Documenteren van gebeurtenistypes ==
De laatste stap is het gedetailleerd beschrijven van de benoemde soorten gebeurtenissen. Dit omvat het definiëren van algemene kenmerken zoals de naam, korte omschrijving, en specifieke attributen die altijd aanwezig moeten zijn in notificaties. Het belang van een goede beschrijving is groot, omdat consumers verstrekte notificaties correct moeten interpreteren en op basis daarvan gaan verwerken. Bij voorkeur is de betekenis van de gebeurtenistypes zodanig vastgelegd dat hij opvraagbaar is voor zowel mensen als applicaties.
Doelgroepen

Category:Over GEMMA
De GEMMA is een hulpmiddel voor het inrichten van de gemeentelijke informatievoorziening en het aansluiten op gemeenschappelijke voorzieningen. Het biedt een referentiekader voor gemeenten die onder architectuur willen (samen)werken.
De belangrijkste doelgroepen van de GEMMA zijn medewerkers in verschillende rollen bij gemeenten, softwareleveranciers en ketenpartners. Afhankelijk van hun rol, zoals beleidsmaker, architect, of beheerder, hebben zij toegang tot een specifieke landingspagina met gerichte verwijzingen naar voor hen relevante onderdelen van de GEMMA.
Domeinarchitecturen

Category:Domeinarchitecturen
GEMMA is de referentiearchitectuur voor Nederlandse gemeenten. Waar mogelijk beschrijft GEMMA zaken generiek, maar gezien de breedte en diversiteit van gemeentelijke taken is het soms nodig om specifiek te zijn. Binnen de GEMMA-architectuur zijn daarom een aantal 'domeinen' gedefinieerd. Voor ieder domein is er een domeinspecifieke architectuuruitwerking. Bijvoorbeeld door te beschrijven welke bedrijfsfuncties binnen een bepaald domein het belangrijkst zijn. 
==Wat is een domeinarchitectuur?==
Een groot deel van de GEMMA beschrijft architectuur die voor de hele gemeente van belang is. Bijvoorbeeld als het gaat om bedrijfsfuncties of referentiecomponenten die binnen de hele gemeente relevant zijn. Deze 'generieke architectuur' is voor ieder domein van belang. Maar omdat domeinen inhoudelijk van elkaar verschillen is er daarnaast ook behoefte aan aanvullende architectuur. We noemen de architectuur die specifiek is voor een bepaald deel van de gemeente domeinarchitectuur. Bijvoorbeeld een domeinarchitectuur voor het domein Fysieke Leefomgeving waar het gaat om ruimtelijke ordening, infrastructuur en milieu en een domeinarchitectuur Sociaal Domein waarbij zorg, welzijn en participatie centraal staan. 
Door in de GEMMA bepaalde architectuurelementen per domein te groeperen ontstaat meer overzicht van en inzicht in een domein. Bijvoorbeeld als wordt beschreven welke referentiecomponenten en applicatieservices nodig zijn om bedrijfsfuncties binnen het domein goed uit te voeren. Het wordt daarmee mogelijk om functies, processen en applicaties binnen een domein effectiever en efficiënter in te richten. 
== Indeling van domeinen == 
De binnen de GEMMA onderscheiden domeinen zijn: 
Deze indeling is bruikbaar binnen de (architectuur)context van de GEMMA en is herkenbaar voor gemeenten. Bij gebruik van een andere indeling (bijvoorbeeld de op IV3-gebaseerde indeling die het Gemeentelijk Gegevensmodel (GGM) gebruikt) is toegelicht hoe deze zich tot deze domeinindeling verhoudt.
==Modellen per domeinarchitectuur==
Domeinarchitectuur bestuur

Category:Bedrijfsarchitectuur
Het domein "bestuur" omvat functies die te maken hebben met (het ondersteunen van) gemeentelijk bestuur.
Op deze pagina vindt u architectuurmodellen die voor dit domein zijn ontwikkeld. De modellen zullen stapsgewijs verder worden ontwikkeld. Er is ruimte voor vragen, opmerkingen en suggesties via gemmaonline@vng.nl
===Bedrijfsarchitectuurmodel===
De primaire doelgroep van deze modellen zijn bestuurders, afdelingsmanagers, de beleidsmedewerkers en projectmanagers/-leiders die binnen dit domein actief zijn. Op Bedrijfsfuncties wordt nader toegelicht wat een bedrijfsfunctiemodel is en hoe het kan worden gebruikt.
View
Toelichting
View met bedrijfsfuncties en subbedrijfsfuncties.
View met bedrijfsfuncties en de referentiecomponenten die worden gebruikt ter ondersteuning.
===Applicatiearchitectuurmodel===
De primaire doelgroep van deze views zijn informatiearchitecten, informatiemanagers, applicatiebeheerders en projectleiders. De Informatie-architectuur licht nader toe wat een applicatieservicesmodel is en hoe het kan worden gebruikt.
View
Toelichting
View met applicatiefuncties en de referentiecomponenten die deze functies leveren.