Programma van eisen WRO_DURP_WRO architectuur v3

1. Aanvullende Architectuur eisen voor de WRO
De gemeente heeft een eigen ICT omgeving waarbinnen de applicatie moet werken.
Naast de technische architectuur is er ook een beschrijvende informatiearchitectuur waarbinnen de
toepassing moet werken. Dit betekent dat er een open datamodel verwacht wordt waarbij het leggen
van verbindingen en koppelingen geen probleem vormt en de applicatie volgens de eigen processen
ingedeeld kan worden. De gemeente moet dan ook kunnen beschikken over de (systeem)modellen
van de applicatie.
In dit document staan de functionele eisen nogmaals opgesomd en de daarbij behorende
architecturale eisen.
1.1 Algemene Eisen
 Najaar 2008 beschikken over pakket
 31 maart 2009 acceptatie toepassing en proefdraaien, trainingen
 Aan de nieuwe applicatie stellen wij dat deze op een gebruikersvriendelijke en zo integraal
mogelijke wijze in staat moet zijn het proces van digitale ruimtelijke plannen, dat wil zeggen
het opstellen controleren, presenteren, uitwisselen en beheren uit te voeren.
 Zelf kleine planherzieningen kunnen opstellen
 Gebruikersvriendelijke applicatie voor codering
Een volledig overzicht van de functionele eisen staan verder vermeld in het functioneel ontwerp.
1.2 De Wereld van WRO en gemeente Sneek











Burgers
Ingenieursbureaus
Inter Provinciaal Overleg (IPO)
VNG
Ministeries van VROM, LNV, VenW, EZ, OC&W en Defensie
Andere overheden
Kadaster
Afdeling Ontwikkeling
Automatisering (beheer)
DIV
Stedenbouwkundige bureaus
1
1.3 Applicatie Criteria
Applicatie criteria kunnen vanuit verschillende views opgesteld worden. In het document WRO vinden
we de functionele eisen terug.
De eisen vanuit de architectuur zijn toegepast op de situatie voor de WRO. Er is ook een nota
opgesteld met alle principes voor de ICT omgeving. Deze nota geldt als aanvulling op de functionele
en technische eisen. Dit doen we om er zeker van te zijn dat de applicatie aansluit bij de ICT
omgeving zoals wij die wenselijk achten. Op verzoek kan deze nota toegezonden worden.
Onderstaand volgen de regels voor applicaties:
Applicatie Principe 1: De stijl service oriëntatie betekent op applicatieniveau een scheiding tussen
database, logica en presentatie, wat leidt tot een betere beheersbaarheid en ontsluiting van
informatie. Voor de WRO hebben wij onderscheid gemaakt tussen een beheerapplicatie en een
viewer. De GIS-viewer valt buiten deze aanvraag.
Regels:
 Alle nieuwe applicaties en services dragen bij aan de verdere digitalisering van de
dienstverlening.
 Alle nieuwe applicaties zijn open applicaties (service georiënteerd, hergebruik functies,
transparantie etc).
 Gesloten applicaties worden gezien als legacy en dienen uitgefaseerd te worden.
 In 2010 zijn er geen applicaties meer die dezelfde functie hebben
 Een applicatie mag niet over informatiedomeinen heen gaan
 Elke applicatie heeft maximaal 1 functie
 Juridische consequenties zoals hergebruik / intellectueel eigendom moet van tevoren duidelijk
zijn.
Applicatie Principe 2: een applicatie voorziet in één functionaliteit welke ontsloten kan worden via
services, wat bijdraagt aan de kwaliteit van de informatievoorziening
Regels:
 Elke applicatie moet met de basisregistraties GBA, BAG en WOZ samenwerken en deze
als bron gebruiken
 Elke applicatie maakt gebruik van de centrale autorisatie service active directory
 Elke applicatie kan overweg met een externe management rapportage tool.
Van elke applicatie is duidelijk:
- welke gegevens het verwacht en opslaat (integriteit)
- welke functie het vervult (welke processen ondersteunt het)
- welke interactie het heeft met de omgeving
- welke handmatige acties vereist zijn
- welke randvoorwaarden er zijn
- wat het procesmodel is
- wat het datamodel is
- in welk domein het functioneert
 Elke applicatie is opgebouwd uit drie lagen (presentatie, logica, infra/data)
 Er wordt gestreefd naar leveranciersonafhankelijkheid (open source is hier een optie).
 Naast leveranciers onafhankelijkheid wordt gestreefd naar het minimaliseren van de
technische diversiteit. Diversiteit in middleware, database management systemen, (netwerk)
operating systemen, transactiebehandeling enz. dient geminimaliseerd en beheerst te worden.
Standaarden:
De referentiële integriteit van gegevens is gewaarborgd. Alle databases voldoen aan de
standaard ANSI SQL 2.
2
Informatiemodel principe: Het informatiemodel geeft de verschillende unieke informatiegebieden
binnen de gemeente weer en de onderlinge relaties. Door het informatiemodel als basis voor de
informatiehuishouding te hanteren weten we precies waar welke informatiebehoefte en ondersteuning
daaraan benodigd is. Tevens vermijden we redundantie en zorgen we ervoor dat pakketten en
applicaties niet over informatiegebieden heen gaan.
Regels:
 Er is een applicatiemodel waarin aangegeven wordt welke applicaties er binnen de organisatie
onderkend worden, inclusief de onderlinge interfaces, eigenaarschap en richtlijnen voor
communicatie.
 De kern van het gemeentelijk informatiemodel wordt gevormd door het geïntegreerd stelsel
van zes basisregistraties en straks zeven: Personen, Bedrijven, Adressen, Gebouwen,
Percelen en Topografie en binnenkort WOZ. Elk van deze registraties is een weergave van
een register. Ze vormen een samenhangend stelsel en worden landelijk uitgewisseld.
Data Consistentie Principe: Door database consistentie middels standaarden zal de snelheid en
kwaliteit van de informatievoorziening, en met name die van primaire bedrijfsapplicaties fors omhoog
gaan en zullen de beheerinspanningen en kosten verlagen.
Regels:
Gegevens moeten relevant moeten zijn voor het doel waarvoor ze bedoeld zijn te
worden gebruikt, en voor zover nodig in relatie tot dat doel, juist, volledig en up-to-date.
Daartoe moeten kwaliteitsborgingprocessen ingericht worden (systematische checks met de
werkelijkheid, crosschecks met andere gegevens). Een voorbeeld hiervan is de landelijke
terugmeld voorziening (TMV).
Standaarden:
 Alle databases zijn ANSI SQL 2 compliant
 De standaard database voor de gemeente Sneek is Oracle (momenteel versie 10).
 Indien Oracle niet mogelijk is wordt voor SQL server gekozen.
3
Rechten Principe: De concepten authenticatie en autorisatie zijn een centrale service, wat zorg
draagt voor het beveiligen van de informatievoorziening.
Regels:
De meeste applicaties kennen een eigen authenticatiefunctie en autorisatiefunctie. Aan de
hand van een applicatie-eigen userdatabase of –directory, waarin usernamen, wachtwoorden
en profielen zijn opgeslagen, wordt toegang en bevoegdheden toegekend.
De authenticatie- en autorisatie functie is een oneigenlijke applicatiefunctie. Bij voorkeur vindt
authenticatie van gebruikers buiten de applicatie plaats aan de hand van gegevens in een
applicatie-onafhankelijke directory.
Standaardpakket Principe: Functionaliteiten en taken worden ondersteund door middel van
standaardpakketten wat bijdraagt aan een beter beheersbaarheid en ondersteuning van de
informatievoorziening.
Regels:
 De gemeente Sneek krijgt beschikking over alle bijbehorende systeem- en
gebruikersdocumentatie.
 Een standaardpakket kent meestal meer opties dan nodig zijn. Daarom moet bij de
implementatie van een standaardpakket van te voren een functioneel ontwerp gemaakt
worden waarin de afbakening van functionaliteiten beschreven staat.
 Alle standaardpakketten zijn open-ended, wat betekent dat ze in een groter informatiesysteem
(informatievoorziening) opgenomen kunnen worden).
Centralisatie principe: Door gebruik te maken van centrale generieke voorzieningen voor
informatiebeheer zorgen we voor uniformering, kostenbesparing en kwaliteit van informatie.
Regels:
 Dislocaties van de gemeente Sneek die niet via glasvezel zijn verbonden worden van
applicaties voorzien middels het concept service based computing (bijv. Citrix).
 Alle bedrijfskritische applicaties maken via het ESB gebruik van de centrale voorzieningen
(BAG, GBA, WOZ, DMS, BPM).
 Een Visie, doelstellingen, een Programma van Eisen, een procesbeschrijving, gevolgd door
een pakketselectie vormen de basis voor een constructie keuze.
4
1.3.1 De software omgeving
De applicatie zal binnen het bestaande applicatielandschap van de gemeente Sneek moeten
functioneren. Bovendien moet het gegevens “klaarzetten” voor externe partijen. Dit betekent dat er
een aantal relaties bestaan. Deze relaties staan hieronder benoemd samen met de regels voor de
bestaande ICT omgeving.
Relaties
o RO online (extern)
o Eigen viewer
o CAD-GIS
o Midoffice
o BPM
o DMS
o Testomgeving
Midoffice Principe:
Het concept midoffice zorgt voor het uitwisselen van informatie tussen front en backoffice, wat leidt tot
betere dienstverlening. Het orkestreert informatiestromen naar de juiste plek in de organisatie. Het
vormt de geautomatiseerde kern van de organisatie.
In het geval van de WRO betekent dat dus dat informatie tussen de applicatie en Viewer via het
midoffice moet verlopen op basis van services.
Regels:
 Het midoffice wordt het centrale punt voor de informatiehuishouding en is daarmee een
waardevol artefact binnen de organisatie.
 Het midoffice moet een oplossing zijn die in eigen beheer en leverancieronafhankelijke is.
 Voor het midoffice geldt dat het gevuld wordt met standaardproducten, waardoor aansluiting
met andere applicaties en organisatie vereenvoudigd wordt.
Standaarden:
 Het midoffice moet voldoen aan de standaard dikke midoffice zoals deze door het ICTU is
gedefinieerd.
 Het midoffice moet aansluiten op de standaard GFO zaken (ICTU).
Service Bus Principe:
Een ESB draagt zorg voor het uitwisselen van services tussen applicaties, wat leidt tot ontsluiting van
functionaliteiten binnen de organisatie. Deze functionaliteiten kunnen daar toegepast worden om de
één loket gedachte te realiseren.
Regels:
 In Sneek wordt met behulp van een servicebus de volgende functionaliteiten gerealiseerd.




Communicatie tussen diensten van de website en de verwerkende applicaties in de
backoffice
Communicatie tussen het KCC en applicaties in de backoffice
Het regelt in samenwerking met BPM (Opentext) de workflow voor de organisatie.
Synchronisatie tussen applicaties voor de informatiegebieden adressen, personen en
objecten
 Alle applicaties die aangemerkt zijn als basisregistratie of kernsysteem kennen een koppeling
met de enterprise service bus en wisselen via dit kanaal informatie uit.
 Een servicebus is platformonafhankelijk om optimale communicatie en aansluiting te
realiseren.
 De gemeentelijke servicebus sluit aan op de servicebus van de Rijksoverheid om zo landelijke
dekking te realiseren.
5
 De servicebus realiseert in ieder geval de functionaliteiten Orkestratie, history, accounting,
queing, loadbalancing, application and services monitoring, error handling, security, replicatie /
synchronisatie.
Standaarden:
De standaarden waarvan de servicebus gebruik dient te maken zijn:
 BPEL
 SOAP
 STUF2
 XML
 JBI
 WUS
 ebXML
Koppelvlak Principe: Koppelvlakken zijn componenten die data vertalen en transformeren en zorg
dragen voor een connectie tussen applicaties of services en een broker of servicebus.
Regels:
Voor de applicaties die zijn aangeduid als bedrijfskritische applicaties dient een koppelvlak te
komen.
Standaarden:
 Koppelvlakken voldoen aan de specificaties zoals deze in de NORA beschreven zijn.
 De overdracht tussen de koppelvlakken van applicaties dient te gebeuren volgens
gemeentelijke standaarden over de overdracht (StUFbg) en volgens open standaarden.
Koppelingen Beheersbaarheid Principe:
Als het aantal noodzakelijke koppelingen tussen applicaties groeit dan wordt het geheel
onbeheersbaar indien de koppelingen overwegend van het type point-to-point zijn. Als de koppelingen
adapters zijn die aan een centrale broker of enterprise service bus zitten, wordt het geheel vele malen
beheersbaarder.
Regels:
Waar mogelijk worden applicaties gekoppeld aan het centrale ESB. Point-to-point
verbindingen worden zoveel mogelijk uitgefaseerd.
Standaarden:
Koppelvlakken voldoen aan de specificaties zoals deze in de NORA beschreven zijn.
Data Distributie Principe:
Door alleen applicaties te kopen die toelaten via open data uitwisselingsformaten te communiceren,
wordt de organisatie onafhankelijker en weerbaarder tegen producenten van applicaties met
proprietary data uitwisselingsmogelijkheden. De informatievoorziening wordt in deze situatie ook te
weinig flexibel. Men is soms voor de eigen innovatie afhankelijk van de ontwikkelingsprogramma’s van
leveranciers. Dit is uitermate ongewenst.
Regels:
 Een applicatie dient minimaal via xml alle (relevante) informatie te kunnen ontsluiten voor
gebruik door andere applicaties.
 De gemeente Sneek is en blijft eigenaar van alle informatie opgeslagen in applicaties en mag
dit naar eigen gelieven gebruiken.
 Applicaties moeten ingericht kunnen worden volgens het procesmodel van de gemeente
Sneek, om data distributie te vereenvoudigen.
Standaarden:
Datadistributie dient te voldoen aan de standaard zoals deze door ICTU en EGEM
voorgeschreven zijn.
6
Berichten Principe: Componenten communiceren met elkaar met behulp van gestandaardiseerde
berichten in een generieke open infrastructuur die interoperabiliteit tussen domeinen garandeert
Regels:
Voor het uitwisselen van berichten wordt gebruik gemaakt van de door het Rijk
voorgeschreven standaard StUF2. StUF is de berichtenstandaard om in het gemeentelijke
veld systemen aan elkaar te koppelen. StUF voorkomt dat elke gemeente maatwerk moet
ontwikkelen voor koppelingen tussen systemen. Als gemeente kun je StUF gebruiken als
universele standaard voor gegevensuitwisseling, ongeacht de leverancier. De StUF-standaard
wordt toegepast binnen gemeenten, tussen gemeenten onderling, en tussen gemeenten en
externe partijen, zoals de landelijke basisregistraties, en andere partners, zoals de
Belastingdienst, Waterschappen en zorginstellingen.
Standaarden:
Voor het berichtenverkeer (messaging) wordt de standaard SOAP gebruikt
Service Principe: Een service is een set van statusloze en roaming applicatiefunctionaliteiten die
beschikbaar worden gesteld aan andere applicaties of gebruikers via een platformonafhankelijke
interface. Niet elke set van applicatiefunctionaliteiten is automatisch een service.
Regels:
 Een service is een duidelijk omschreven (geautomatiseerde en handmatige) functie die
relevant is voor bedrijfsprocessen, onafhankelijk van andere services kan worden gecreëerd
en los van andere services kan opereren, maar tevens zonder problemen kan samenwerken
met andere services en makkelijk te vinden is.
 Een service kan worden aangeroepen met een eenduidig voorgeschreven verzoek en levert
een eenduidig vastgelegd resultaat op.
 Generieke services gericht op het primaire proces: dit zijn services die door meer dan één
dienst gebruikt worden en bedoeld zijn om het primaire proces te ondersteunen, denk hierbij
aan services als incasso, registreren van objecten etc.
 Generieke services gericht op het ondersteunende proces: dit zijn services gericht op
ondersteunende processen als financiën, personeel en organisatie, distributie etc.
 Specifieke services: dit zijn services die gemaakt zijn voor één dienst
 Externe services: dit zijn services die ontwikkeld en beheerd worden door andere partijen.
Hierbij valt te denken aan DigiD, RDW kentekeninformatie, GBA-V, Digitaal Klant Dossier etc.
Workflow Principe: Het concept workflowmanagement is een centrale service, wat zorg draagt voor
het beheersen van processen.
Regels:
 Er is een centrale oplossing voor workflowmanagement namelijk BPM van Opentext,
andere applicaties kunnen daarmee samenwerken
 In de workflow applicatie is de gemeentelijke taak en functiescheiding in te regelen.
Standaarden:
 Voor het uitwisselen van human workflow berichten wordt gebruik gemaakt van de standaard
XPDL.
 Voor het uitwisselen van machine workflow berichten wordt gebruik gemaakt van de
standaard BPEL.
7
DMS principe: Het concept DMS is een centrale service, wat zorg draagt voor het beheersen van
documenten en documentstromen.
Regels:
 Er is een centrale oplossing voor document en record management namelijk NGD van
Opentext, andere applicaties kunnen daarmee samenwerken.
 Het DMS wordt van workflow voorzien middels het concept BPM
 Het DMS wordt ingericht volgens de processtappen zoals deze beschreven staan in het
informatiemodel. Op basis van deze stappen kan het DMS als een service aangeroepen
worden.
Standaarden:
 In het DMS wordt zaaksgewijs gewerkt volgens het GFO-Zaken.
 Bestanden worden opgeslagen in het formaat ODF.
Basisregistratie Principe: het concept basisregistraties maakt eenmalige opslag en meervoudig
gebruik mogelijk, wat leidt tot een betere beheersing en kwaliteit van informatie en informatiestromen.
Regels:
 Het aanwezig zijn van authentieke registratie dient te betekenen dat het voor de gebruiker van
de betreffende gegevens in principe niet langer noodzakelijk is zelf onderzoek te doen naar de
juistheid van dit gegeven (als er echter in het gebruik procedures zijn voor het bepalen van de
juistheid, dan hoeven die zeker niet zonder meer te vervallen). Het gegeven kan met andere
woorden voor de taakuitoefening van de gebruiker worden gehanteerd alsof deze gebruiker
het gegeven zelfstandig heeft verzameld.
 Aan gegevens in een authentieke registratie worden vanwege het overheidsbrede belang
hogere eisen gesteld, o.m. ten aanzien van de procedures voor signalering en correctie van
onjuiste gegevens (terugmeld plicht). Door het brede gebruik zullen meer signalen van
onjuistheden naar boven komen, waardoor een zelfreinigende werking ontstaat. Als afnemers
twijfelen aan de juistheid van de gegevens in de authentieke registratie dan hebben zij de
plicht dit te melden aan de houder. De houder heeft vervolgens ook de plicht de melding
serieus te onderzoeken en zo nodig correcties door te voeren. De basisregistraties dienen
aangesloten te worden op de TMV (Terug Meld Voorziening).
 De authentieke registratie wordt verplicht gebruikt door de hele overheid en de als authentiek
aangewezen gegevens kunnen in de werkprocessen zonder nader onderzoek gebruikt
worden. Het is niet toegestaan gegevens die reeds binnen een authentieke registratie
aanwezig zijn, opnieuw te verzamelen.
 Omdat bij introductie van een authentieke registratie de directe band tussen het verzamelen
van gegevens en het uitvoeren van een wettelijke taak vervalt, dient (over de grenzen van
verschillende organisaties en wetgeving heen) glashelder te zijn wat de inhoud van de
registratie is. Belangrijke aspecten zijn de definities van de gegevens in de authentieke
registratie en het domein (de objecten van registratie) waarover gegevens worden vastgelegd.
Deze gegevens dienen voor iedere authentieke registratie vastgelegd te zijn in een
gegevenswoordenboek.
 Er zal binnen het stelsel van authentieke registraties sprake zijn van openbare en gesloten
registraties, m.n. gezien de privacygevoeligheid van een groot aantal gegevens waarom het
gaat. Bij openbare authentieke registratie zal de nadruk met betrekking tot de toegankelijkheid
liggen op zaken als leveringsvoorwaarden terwijl bij gesloten authentieke registraties de
nadruk zal liggen op autorisatieprocedures. Indien een houder van een registratie
geautoriseerd wenst te worden voor het gebruik maken van gegevens die in een gesloten
authentieke registratie zijn opgenomen, vindt hierover expliciete besluitvorming plaats volgens
een geformaliseerde procedure. Autorisatieverzoeken worden getoetst aan de bij de inrichting
van de authentieke registratie geformuleerde randvoorwaarden ten aanzien van de mate
waarin de registratie openbaar is en de uitgangspunten aangaande de privacy.
 Omdat de eisen die worden gesteld aan een authentieke registratie in de loop van de tijd
veranderen, zal soms bijsturing van de inhoud, organisatie, bestuurlijke ophanging en/of
wetgeving van een authentieke registratie noodzakelijk zijn. De afnemers moeten hierop op
een niet vrijblijvende wijze invloed kunnen uitoefenen. Het niet-vrijblijvende karakter is met
8
name van belang omdat afnemers voor het uitvoeren van hun taak afhankelijk zijn van
gegevens uit een authentieke registratie.
Standaarden:
De basisregistraties voldoen in ieder geval aan de principes zoals deze geformuleerd zijn in
de handreikingen GBA en BAG van EGEM.
Basisregistratie Principe 2: een basisregistratie functioneert als bronbestand voor een specifieke set
van gegevens, welke beschikbaar worden gesteld middels services aan applicaties.
Regels:
Elke applicatie moet met de basisregistraties GBA, BAG en WOZ samenwerken en deze als
bron gebruiken.
Kernsysteem Principe: kernsystemen zijn thema gericht en voldoen aan eenmalige opslag,
meervoudig gebruik. Het toekennen van kernsystemen (naast basisregistraties) zorgt voor eenduidige
en eenmalige gegevensopslag voor ondersteuning van secundaire processen, wat leidt tot betere
interne dienstverlening.
Regels:
 Een kernsysteem heeft een open interface en kan middels XML informatie naar andere
applicaties ontsluiten.
 Een kernsysteem vervult maximaal 1 functie en ontsluit benodigde functionaliteiten via het
ESB naar de organisatie.
 Een kernsysteem dient als bronbestand voor een specifieke set gegevens en alle andere
applicaties maken daar gebruik van.
Standaarden:
De kernsystemen zijn:
Gegevenset
Personeelsgegevens
Financiële gegevens
Document gegevens
Proces gegevens
Zaak gegevens
Transactiegegevens
Vergunningen
Geografisch kernbestand
Applicatie (huidig)
PIMS (Centric)
Key2Financien (Centric)
DMS (Opentext)
BPM (Opentext)
Nader te bepalen (project midoffice)
Nader te bepalen (project midoffice)
Nader te bepalen (project omgevingsvergunning)
Nader te bepalen (project BAG, WKPB,
omgevingsvergunning)
Data Consistentie Principe: Door database consistentie middels standaarden zal de snelheid en
kwaliteit van de informatievoorziening, en met name die van primaire bedrijfsapplicaties fors omhoog
gaan en zullen de beheerinspanningen en kosten verlagen.
Regels:
Gegevens moeten relevant moeten zijn voor het doel waarvoor ze bedoeld zijn te
worden gebruikt, en voor zover nodig in relatie tot dat doel, juist, volledig en up-to-date.
Daartoe moeten kwaliteitsborgingprocessen ingericht worden (systematische checks met de
werkelijkheid, crosschecks met andere gegevens). Een voorbeeld hiervan is de landelijke
terugmeld voorziening (TMV).
Standaarden:
 Alle databases zijn ANSI SQL 2 compliant
 De standaard database voor de gemeente Sneek is Oracle (momenteel versie 10).
 Indien Oracle niet mogelijk is wordt voor SQL gekozen.
9
1.4 Gegevensuitwisseling
Standaarden: Vanuit functioneel oogpunt worden door de WRO de volgende standaarden
gehanteerd. Voor standaarden op het gebied van berichtenverkeer verwijzen wij naar de regels over
de Service Bus.





IMRO 2008
GML
XML
Open GIS
NEN bouw
Input:
 Analoge plannen
 CAD tekeningen
 GML bestanden + toelichting, voorschriften, bijlage etc.
Output:
 IMRO gecodeerde plannen
 Visualisaties van plannen
 CAD tekeningen met codering en IMRO codering
 IMRO gecodeerde GML plankaart
 Manifest bestanden
 Digitale plan bestanden voor RO online
 Plancontourenkaart
 Rapportage status digitale plannen
Beveiliging:
 PKI certificaat
Gegevens:
 Geometrische gegevens op basis van een digitale ondergrond (gesloten vlakken tekenen).
 Basisgegevens plan: plannaam, plannummer, plantype, locatiegebied
 Kenmerken en attributen: bestemmingen, aanduidingen, voorschriften
10