Gemeentelijke Applicatiearchitectuur Omgevingswet


Hoofdstuk: Requirements Omgevingsbeleidscomponenten

Gemeentelijke Applicatiearchitectuur Omgevingswet
  1. Inleiding
  2. Uitgangspunten en principes
  3. De referentiecomponenten voor de Omgevingswet
  4. Requirements Omgevingsbeleidscomponenten
  5. Requirements Regelbeheercomponenten
  6. Requirements Vergunning-, Toezicht- en Handhavingcomponenten
  7. Standaarden voor de Omgevingswet
  8. Koppelingen voor de Omgevingswet

Deze pagina is een onderdeel van Gemeentelijke Applicatiearchitectuur Omgevingswet compleet: Hele document bekijken - Exporteren - Definitie

Introductie

Op deze bladzijde bieden we in tabelvorm en ter download de requirements (specificaties) aan voor de planvormingssoftware per 2021. Requirements geven inzicht in de wensen en eisen die we stellen aan software. Het betreft hier de software die nodig is voor het maken en wijzigen van omgevingsvisie, programma en omgevingsplan. De requirements zijn bedoeld voor gemeenten die zich oriënteren op nieuwe software voor planvorming dan wel een aanbesteding gaan doen. Ze helpen de inhoudelijk specialisten (o.a. plan juristen) , medewerkers van ICT (functioneelbeheerders en informatiemanagers) en specialisten van inkoop en aanbesteding om gezamenlijk een beeld te vormen van de aan te besteden software. Binnen de Gemeentelijke Model Architectuur (GEMMA) wordt deze groep componenten (applicaties) ook wel omgevingsbeleidcomponenten genoemd, of te wel de applicaties die het maken van beleid voor de Omgevingswet ondersteunen.


Iteratief: Nu een 1.0 versie, straks een 1.1

De requirements worden met input van gemeenten en softwareleveranciers iteratief opgesteld. De onderstaande versie betreft de 1.0 versie. Dit is een voorlopig stabiele versie die een gemeente kan gebruiken bij het selecteren van software voor planvorming. Het betreft hier nadrukkelijk niet de definitieve versie van de requirements. Gezien de ontwikkelingen binnen het Digitaal Stelsel Omgevingswet, weten we dat de eisen die we aan de software stellen nog worden aangepast. Denk hierbij aan de ontwikkeling van STOP-TPOD of de samenwerkingsruimte. Beide onderwerpen zijn nog in beweging en gaan zorgen voor aanpassingen in de requirements.

Requirements en aanbesteding

Wil een gemeente in de zomer van 2019 starten met een aanbesteding, dan bieden deze requirements een goede basis voor die aanbesteding. Wil je meer weten over de verschillende manieren van aanbesteden en op welke wijze je de daarbij requirements gebruikt? VNG komt deze zomer met zowel een masterclass aanbesteden van Omgevingswet software als met een Handreiking Aanbesteden.

Naar verwachting zullen de meeste leveranciers aan de belangrijkste requirements gaan voldoen (zie ook onderstaande indeling in categorieën). Dit zorgt er voor dat je qua functionaliteit als gemeente niet snel een "foute" keuze kan maken. Toch zullen de leveranciers op onderdelen gaan verschillen. Om hier inzicht in te verkrijgen zullen op deze site en in de handreiking ook vragen verschijnen waarmee een gemeente die inzicht kan verkrijgen. Denk hierbij aan vragen als: Op welke manier zal de leverancier de workflow voor het opstellen van een omgevingsplan ondersteunen? Of op welke manier gaat de leverancier ondersteuning bieden aan het koppelen van juridische en toepasbare regels?

Uniforme manier van uitvragen

Met de requirements en de nog te verschijnen leveranciersvragen biedt VNG aan gemeenten een uniforme manier van uitvragen van de plansoftware. Een uniforme manier van uitvragen is essentieel om komende periode van implementatie succesvol te laten verlopen. Softwareleveranciers op gebied van planvorming staan al onder druk om op 1 januari 2021 werkende software te kunnen leveren. Als iedere gemeente op haar eigen manier met eigen requirements de software gaat aanbesteden, levert dit voor de softwareleveranciers veel werk op. De tijd die ze daarmee besteden aan het meedoen met de aanbesteding, kunnen ze niet gebruiken om de software te ontwikkelen. Door op een als gemeenten op een uniforme wijze aan besteden, zorgen we er voor dat leveranciers kunnen focussen de ontwikkeling van software.

Wettelijkverplicht, basis en plus

Wat is nu echt softwarefunctionaliteit die een gemeente per 1 januari 2021 nodig heeft? Welke is nodig, maar kan ook eventueel na 1 januari? En welke functionaliteit is niet essentieel en kan iedere gemeente voor zich zelf besluiten of ze deze functionaliteit wil gebruiken. Hiervoor hanteren we de onderstaande driedeling. Per component is aangeven in welke categorie deze bij benadering valt. Daarnaast worden op korte termijn de categorieën ook gekoppeld aan de individuele requirements.

  • Wettelijk verplicht: requirements op basis van de wet
  • Basis: requirements die nodig zijn om Omgevingswet goed te ondersteunen en dienstverlening op zelfde niveau te houden
  • Plus: functionaliteit bovenop de basis, bijvoorbeeld ten behoeve van innovatie

Doorontwikkeling applicaties: Na 1 januari 2021 zal de software voor planvorming zich verder ontwikkelen. Gemeenten hebben hierbij aangegeven dat ze graag zien dat de software gaat voldoen aan Common Ground en dat de gehele beleidscyclus (van visie, naar plan, vergunning verlening, toezicht, handhaving en evaluatie) wordt ondersteund met integrale software. Komende periode zal deze doorontwikkeling verder in beeld worden gebracht.

Overzicht Omgevingsbeleidcomponenten

De Omgevingsbeleidcomponenten vormen gezamenlijk de software die benodigd is voor het opstellen van beleid voor de Omgevingswet. Denk hierbij aan het wijzigen van het omgevingsplan of het maken van een omgevingsvisie. Onder de Omgevingsbeleidcomponent vallen een aantal subcomponenten.

Component voor het ontwikkelen, beheren en digitaal beschikbaar stellen van omgevingsdocumenten (omgevingsplan, omgevingsvisie en programma) conform de Omgevingswet standaarden. Hiermee is de Omgevingsbeleid component de opvolger van de GEMMA WRO-component. De Omgevingsbeleidcomponent bevat diverse functionalteiten voor omgevingswetbesluiten (voorbereidingsbesluiten). (ApplicationComponent) Omgevingsbeleidcomponent Deze applicatiefunctie is een verzamelling van functies die niet specifiek door een aparte functie wordt uitgevoerd. De requirements die onder deze functie vallen, gelden voor alle applicatiefuncties die bij de omgevingsbeleidcomponent horen. (ApplicationFunction) Ondersteunen van generieke OB-functionaliteit Functie voor het beheren van regelingen met tekst, werkingsgebied en annotaties. (ApplicationFunction) Beheren van regelingen Functie voor het aanleveren van besluiten en documenten (Omgevingsvisie, programma, omgevingsplan, voorbereidingsbesluit en kennisgeving voorgenomen besluit). (ApplicationFunction) Aanleveren van besluiten en documenten Functie voor het weergeven van omgevingsbeleid (omgevingsvisie, programma, omgevingsplan en voorbereidingsbesluit) in tekst en kaart. De functie ondersteunt het inzien van regelingen van meerdere organisaties waarvoor een regeling wordt beheerd (bijvoorbeeld door planbureaus). (ApplicationFunction) Inzien van regelingen Functie voor het kunnen samenwerken aan besluiten tussen organisaties. (ApplicationFunction) Samenwerken aan besluiten Component voor het weergeven van omgevingsbeleid (omgevingsplan, omgevingsvisie en programma) in tekst en kaart onder andere bedoeld voor het ondersteunen van besluitvorming. Deze component is onderdeel van omgevingsbeleidcomponent, maar kan ook als individuele component door een organisatie worden verworven. (ApplicationComponent) Omgevingsdocumentviewercomp- onent Functie voor het weergeven van omgevingsbeleid (omgevingsvisie, programma, omgevingsplan en voorbereidingsbesluit) in tekst en kaart. De functie ondersteunt het inzien van regelingen van meerdere organisaties waarvoor een regeling wordt beheerd (bijvoorbeeld door planbureaus). (ApplicationFunction) Inzien van regelingen AggregationRelationship Deze svg is op 19-04-2023 15:13:39 CEST gegenereerd door ArchiMedes™ © 2016-2023 ArchiXL. ArchiMedes 19-04-2023 15:13:39 CEST

Overzicht Omgevingsbeleidcomponenten (uit model: Omgevingswet) - Toon SVG - Download als csv


Modulaire opzet: De omgevingsbeleidcomponent is modulair opgezet. Iedere subcomponent is of een module binnen een grotere softwaresuite of een apart aan te schaffen applicatie. Het is aan de gemeente om te kiezen op welke manier zij de applicaties willen aanschaffen. Kiest de gemeente voor één pakket van één leverancier of gaat ze voor een "best of breeds" aanpak waarbij verschillende applicaties van verschillende leveranciers samenwerken. Een gemeente kan dan bijvoorbeeld kiezen voor de tekstcomponent van leverancier X en de geometriecomponent van leverancier Y terwijl de viewercomponent weer afgenomen wordt bij leverancier Z. Het geheel van componenten kan in de Common Ground gedachte worden ondersteund met een omgevingsbeleidregistratiecomponent, of te wel een aparte component waarin de gegevens uit de andere componenten worden opgeslagen en kunnen worden ontsloten.

Onderstaande geeft een overzicht van de component met sub-componenten. Van iedere component kunnen de requirements als CSV worden gedownload.

Omgevingsbeleidcomponent (download als CSV) waarbinnen vallen de:

Omgevingsbeleidcomponent

Omschrijving: Component voor het ontwikkelen, beheren en digitaal beschikbaar stellen van omgevingsdocumenten (omgevingsplan, omgevingsvisie en programma) conform de Omgevingswet standaarden. Hiermee is de Omgevingsbeleid component de opvolger van de GEMMA WRO-component. De Omgevingsbeleidcomponent bevat diverse functionalteiten voor omgevingswetbesluiten (voorbereidingsbesluiten).
Hieronder staan de generieke requirements die voor alle omgevingsbeleidcomponenten (visie, programma en plan) gelden. De drie componenten zijn specialisaties van de Omgevingsbeleid- en regelbeheercomponent en overerven daarmee dus de generieke functies.

De procesondersteunende systemen zullen na publicatie (van de visie, programma of plan) voor hun opslag aangewezen zijn op de landelijke voorzieningen (LVBB, DSO-LV Register Toepasbare Regels etc). Echter, voor de wijzigingsfase binnen de gemeenten is er wel een eigen registratie nodig. Evenals in de conceptfase waarin wordt samengewerkt met ketenpartners, waarbij tevens een koppeling nodig is met de DSO-LV samenwerkingsruimte die in deze fase gebruikt kan worden.

Dat leveranciers na publicatie voor een optimalisatie kiezen om kopie-gegevens te hebben in hun oplossingen is een keuze, zolang ze maar de brongegevens tijdig van de juiste voorziening halen.

Functionele requirements
Aantal: 0
Requirement Toelichting Categorie
  • Download als CSV


Regelingcomponent

Omschrijving:

Functionele requirements
Aantal: 0
Requirement Toelichting Categorie
  • Download als CSV


Tekstcomponent (categorie: wettelijk verplicht)

Omschrijving:

Functionele requirements
Aantal: 0
Requirement Toelichting Categorie
  • Download als CSV


Geometriecomponent (categorie: basis)

Omschrijving:

Functionele requirements
Aantal: 0
Requirement Toelichting Categorie
  • Download als CSV


Werkprocescomponent (categorie: plus)

Omschrijving:

Functionele requirements
Aantal: 0
Requirement Toelichting Categorie
  • Download als CSV


Publicatiecomponent (categorie: wettelijk verplicht)

Omschrijving:

Functionele requirements
Aantal: 0
Requirement Toelichting Categorie
  • Download als CSV


Viewercomponent (categorie: basis)

Omschrijving: Component voor het weergeven van omgevingsbeleid (omgevingsplan, omgevingsvisie en programma) in tekst en kaart onder andere bedoeld voor het ondersteunen van besluitvorming. Deze component is onderdeel van omgevingsbeleidcomponent, maar kan ook als individuele component door een organisatie worden verworven.

Functionele requirements
Aantal: 0
Requirement Toelichting Categorie
  • Download als CSV




Deze pagina is het laatst bewerkt op 5 okt 2023 om 02:22.