Delflandse Enterprise Architectuur. Versie 1.0

Delflandse Enterprise Architectuur Versie 1.0

Opstellers:

Status: Datum: Kopie:

Steven Ham Aster Hupkes Jan Middelburg Marlies van Steenbergen (Sogeti) Renzo Wouters (Sogeti) Concept 3 september 2010

Delflandse Enterprise Architectuur versie 1.0

Managementsamenvatting In het strategisch informatieplan 2010 – 2015 is architectuur gepositioneerd als één van de fundamenten van het „informatiehuis‟ van Delfland. De Delflandse Enterprise Architectuur (DEA) heeft als doel om te komen tot een efficiënte, effectieve en toekomstvaste informatievoorziening. De DEA beschrijft met behulp van principes en modellen waar de informatievoorziening aan moet voldoen en wat de belangrijkste onderdelen van de informatievoorziening zijn. Door deze zaken op een samenhangende en gestructureerde wijze vast te leggen, wordt het makkelijker voor besluitvormers om de juiste keuzes in de informatievoorziening te maken binnen programma‟s en projecten. De DEA bestaat uit principes en modellen. De modellen, die zowel de huidige („IST‟) als de gewenste situatie („SOLL‟) weergeven, dragen bij aan het verkrijgen van inzicht. De principes, die aangeven welke eisen Delfland aan de informatievoorziening stelt, dragen bij aan het sturen. Dit is weergegeven in onderstaande figuur.

IST

principes

SOLL

De DEA bevat de volgende modellen. - Procesmodel; - Objectenmodel; - Functionaliteitenmodel; - Technisch model. Op basis van deze basismodellen is bovendien een aantal gecombineerde modellen opgesteld, die de relaties tussen de verschillende modellen weergeven. - Logisch informatiesystemenmodel - Processen - functionaliteiten - Functionaliteiten - objecten Binnen de DEA zijn principes op 6 niveaus geordend: - Strategische uitgangspunten; - Algemene principes; - Business principes; - Informatie principes; - Technische principes; - Beveiligings- en beheerprincipes. Met de eerste versie van de DEA zijn de kaders neergelegd waar de toekomstige informatievoorziening aan dient te voldoen. Daarmee is echter nog niet automatisch geborgd dat Delfland de architectuur inzet bij veranderingstrajecten, om te zorgen dat de gekozen oplossingen voldoen aan deze kaders. Het proces dat hiervoor moet worden ingericht noemen we ‘Werken onder architectuur’. Bij het werken onder architectuur is het van belang dat wijzigingen binnen de informatievoorziening altijd worden getoetst aan de architectuur. Dit wordt bereikt door het procesmatig inbedden van de architectuurtoets bij wijzigingen in de informatievoorziening. Het proces werken onder architectuur is in dit document slechts globaal beschreven; dit dient in de praktijk nog verder uitgewerkt en aangevuld te worden.

Datum: 3 september 2010

pagina 2 van 42


Inhoud Managementsamenvatting

2

1.

Inleiding

4

1.1 1.2

Aanpak architectuurtraject Opbouw van dit document

5 5

2.

Delflandse Enterprise Architectuur

6

2.1 2.2 2.3 2.4 2.5

Inleiding Architectuurverankering Architectuurprincipes Architectuurmodellen Gelaagde architectuur

6 7 9 10 11

3.

Uitgangspunten voor de architectuur

12

4.

Business architectuur

14

4.1 Business Principes 4.2 Business Modellen 4.2.1 Procesmodel

14 15 15

5.

17

Informatie architectuur

5.1 Informatie Principes 5.2 Informatie Modellen 5.2.1 Objectenmodel 5.2.2 Functionaliteitenmodel

17 18 18 22

6.

26

Technische architectuur

6.1 Technische Principes 6.2 Technische Modellen 6.2.1 4-lagenmodel 6.2.2 Netwerkmodel

26 27 27 30

7.

Beveiliging en beheer

31

8.

Gecombineerde modellen

31

8.1 8.2 8.3

Processen – functionaliteiten Functionaliteiten – objecten Logisch informatiesystemenmodel

31 33 35

9.

Gebruik van de architectuur

40

9.1 9.2 9.3

Werken (z)onder architectuur Project Start Architectuur Architectuur als stuurinstrument

40 41 42


pagina 3 van 42


1. Inleiding In het strategisch informatieplan 2010 – 2015 is architectuur gepositioneerd als één van de fundamenten van het „informatiehuis‟ van Delfland.

Figuur 1 – Het 'informatiehuis' van Delfland Delfland heeft behoefte om meer structuur en samenhang te realiseren in de informatievoorziening. In het verleden is vaak voor elk probleem een eigenstandige oplossing geïmplementeerd, met als resultaat een enorme wildgroei in applicaties met soms (deels) overlappende functionaliteit en gegevens die op meerdere plekken worden bijgehouden. De hoeveelheid gegevens binnen Delfland groeit exponentieel, terwijl het in sommige situaties lastig blijkt te zijn om de juiste informatie boven tafel te krijgen. Hierdoor is het noodzakelijk om de informatievoorziening beter te structureren, zowel qua opslag als qua transport (of uitwisseling). Architectuur is een belangrijk hulpmiddel voor Delfland om enerzijds meer structuur en samenhang binnen en anderzijds een beter inzicht in de informatievoorziening te realiseren. Architectuur beschrijft op globaal niveau de structuur van de verschillende componenten van de informatievoorziening (processen, gegevens, applicaties, informatiefuncties) en beschrijft daarnaast de samenhang daartussen. Hierdoor wordt het makkelijker om de impact van wijzigingen op de informatievoorziening snel en goed te kunnen bepalen. Dit document beschrijft de eerste versie van de Delflandse Enterprise Architectuur (DEA), die in de zomermaanden van 2010 tot stand is gekomen. Deze eerste versie zal in de komende periode verder aangevuld en uitgediept worden. Het belangrijkste aspect blijft echter het daadwerkelijk gebruik maken van de architectuur. Hiervoor wordt in dit document ook de eerste aanzet gegeven (zie hoofdstuk 9).


pagina 4 van 42


1.1

Aanpak architectuurtraject

Het opstellen van deze eerste versie van de DEA is uitgevoerd door het projectteam architectuur in de periode mei tot en met augustus 2010. Uitgangspunten voor de gekozen aanpak zijn dat er snel een eerste resultaat kan worden opgeleverd, terwijl het beslag op de capaciteit in de organisatie minimaal is. De aanpak op hoofdlijnen was als volgt: o 3 workshops met de stuurgroep I&A; o Voorbereiding van de workshops met de werkgroep I&A; o Het tussenresultaat is afgestemd met de portefeuillehouder en gepresenteerd in het DMT. De stuurgroep I&A bestaat uit de (plv.) secretaris-directeur en 3 DMT-leden. De werkgroep I&A bestaat uit een brede vertegenwoordiging uit het I&A-domein: senior I-adviseurs, functioneel (applicatie) beheerders, concerncontrol, KAM, DIV en ICTservices.

1.2

Opbouw van dit document

Allereerst wordt in Hoofdstuk 2 een toelichting gegeven op de Delflandse Enterprise Architectuur. Hoofdstuk 3 beschrijft de Strategische uitgangspunten en de Algemene principes. In Hoofdstuk 4 wordt de Business architectuur behandeld, met de bijbehorende principes en het processenmodel. Hoofdstuk 5 beschrijft de Informatie Architectuur en hoofdstuk 6 de technische architectuur. Hoofdstuk 7 bevat principes op het gebied van beveiliging en beheer. In hoofdstuk 8 zijn de gecombineerde modellen opgenomen. In hoofdstuk 9 ten slotte, worden handvatten geboden voor het toepassen van de architectuur en de inrichting van het proces „Werken onder architectuur‟.


pagina 5 van 42


2. Delflandse Enterprise Architectuur 2.1

Inleiding

De Delflandse Enterprise Architectuur (DEA) heeft als doel om te komen tot een efficiënte, effectieve en toekomstvaste informatievoorziening. De DEA beschrijft met behulp van principes en modellen waar de informatievoorziening aan moet voldoen en wat de belangrijkste onderdelen van de informatievoorziening zijn. Door deze zaken op een samenhangende en gestructureerde wijze vast te leggen, wordt het makkelijker voor besluitvormers om de juiste keuzes in de informatievoorziening te maken binnen programma‟s en projecten. De DEA geeft ook handreikingen om knelpunten in de huidige informatievoorziening aan te pakken door overzicht en samenhang te creëren. Voorbeelden van dergelijke knelpunten zijn het veelvuldig gebruik van papier en spreadsheets, het bijhouden van schaduwadministraties en het “probleempje-systeempje” syndroom (voor elk probleem een nieuw systeem). Hierdoor is vaak grote inspanning vereist om correcte en geïntegreerde informatie uit de systemen te verkrijgen. Ook maakt dit het soms lastig om processen op elkaar af te stemmen en is het niet altijd gemakkelijk om in te spelen op veranderende omstandigheden. Een van de zaken waar de DEA bij helpt is het realiseren van meer standaardisatie en het signaleren van ongewenste redundantie in applicaties en gegevensopslag. Dit maakt het mogelijk de kwaliteit en uitwisseling van gegevens te verbeteren en borgen en een mogelijke vermindering van het aantal applicaties te realiseren. Architectuur is een stuurinstrument om te borgen dat de inrichting van de informatievoorziening optimaal wordt en blijft voor het realiseren van de organisatiedoelen. Binnen Delfland hanteren we de volgende definitie van architectuur: “Architectuur is een consistent geheel van modellen en principes dat richting geeft aan de ontwikkeling van de organisatie, processen, informatievoorziening en technische infrastructuur” (bron: DYA). In deze eerste versie van de DEA ligt daarbij de nadruk op de informatievoorziening en technische infrastructuur. Zoals aangegeven bestaat de DEA uit principes en modellen. De modellen, die zowel de huidige („IST‟) als de gewenste situatie („SOLL‟) weergeven, dragen bij aan het verkrijgen van inzicht. De principes, die aangeven welke eisen Delfland aan de informatievoorziening stelt, dragen bij aan het sturen. Dit is weergegeven in Figuur 2.

IST

principes

SOLL

Figuur 2 – DEA is een combinatie van modellen en principes Het totaal aan principes geeft weer welke eisen Delfland stelt aan haar informatievoorziening. De modellen laten vanuit verschillende gezichtspunten zien hoe verschillende onderdelen van Delfland met elkaar samenhangen. Principes en modellen zijn complementair aan elkaar: het toepassen van de principes leidt tot modellen en, andersom, modellen zijn gebaseerd op bepaalde principes.


pagina 6 van 42


2.2

Architectuurverankering

Aangezien Delfland niet in isolatie opereert, is de DEA ook niet in isolatie opgesteld, maar verankerd in reeds bestaande architecturen. De Nederlandse Overheids Referentie Architectuur (NORA) is de algemene referentie architectuur voor de gehele overheid, maar staat daarbij een verdieping toe per domein. Gemeentes, provincies en ook waterschappen 1 ontwikkelen eigen referentie architecturen binnen de kaders van de NORA. De samenhang tussen de verschillende architecturen staat in de figuur hieronder weergegeven. INTERNATIONALE STANDAARDEN EUROPEAN INTEROPERABILITY FRAMEWORK NEDERLANDSE OVERHEID REFERENTIE ARCHITECTUUR DOMEIN REFERENTIE ARCHITECTUUR (Gemeenten, Provincies, Waterschappen etc.)

BEDRIJFSREFERENTIE ARCHITECTUUR (Delfland)

PROJECT ARCHITECTUUR

Figuur 3 – Samenhang tussen architecturen Voor de ordening van de verschillende onderdelen van de architectuur maken we binnen Delfland gebruik van het architectuurraamwerk uit de NORA, dat is weergegeven in Figuur 4.

Figuur 4 – Het aangevulde NORA raamwerk 1

De referentie architectuur voor de waterschappen wordt de WILMA (Waterschaps Informatie en Logische Model Architectuur) genoemd en is momenteel in ontwikkeling. De verwachting is dat de WILMA in 2011 beschikbaar komt.


pagina 7 van 42


De hoofdindeling in het NORA raamwerk is business architectuur, informatie architectuur en technische architectuur (de drie rijen in het raamwerk). De business architectuur bevat principes en modellen op het gebied van organisatie, diensten & producten en processen. De informatie architectuur bevat principes en modellen op het gebied van applicaties, gegevens en informatie-uitwisseling. De technische architectuur bevat principes en modellen op het gebied van technische componenten, gegevensopslag en netwerk. In de DEA hanteren we deze zelfde indeling. Om echter principes en modellen op het gebied van business, informatie en techniek op te stellen, zijn er wel strategische kaders nodig. Deze strategische kaders – afkomstig uit het Waterbeheerplan en de Kadernota 2011 – vormen de uitgangspunten op basis waarvan keuzes gemaakt worden in de architectuur. Om een expliciete koppeling te kunnen leggen tussen de strategische kaders en de keuzes en principes voor de architectuur, is een vertaling gemaakt in de vorm van Strategische uitgangspunten en Algemene principes (zie Figuur 4): o Strategische uitgangspunten zijn vooral extern gericht: wat Delfland wil bereiken en welk beeld naar buiten wordt gegeven; o Algemene principes zijn meer intern gericht: de organisatie die Delfland wil zijn om de strategische uitgangspunten te bereiken. Voor het definiëren van de principes en modellen die het raamwerk invullen, is zoveel mogelijk gebruik gemaakt van bestaand materiaal. Geput is uit: - Waterbeheerplan 2010 – 2015; - Kadernota 2011; - Strategisch Informatieplan 2010 – 2015; - Nederlandse Overheids Referentie Architectuur (NORA); - Waterschaps Informatie Architectuur (WIA); - Gezamenlijke Visie op ICT van Het Waterschapshuis; - Uitwisselingsmodel AQUO van de IDsW.


pagina 8 van 42


2.3

Architectuurprincipes

De principes van de DEA zijn opgebouwd volgens een vast stramien: Naam Korte weergave van het principe, Bijvoorbeeld „Geen redundante functionaliteit‟. Statement Het daadwerkelijke principe. Het statement heeft de vorm van een voorschrift en is zo verwoord dat het toetsbaar is. Bijvoorbeeld „Delfland zorgt ervoor dat benodigde functionaliteit slechts door één informatiesysteem wordt ondersteund‟. Rationale De motivatie voor het principe: waarom is dit principe van belang voor Delfland. Bijvoorbeeld „Door functionaliteit maar in één informatiesysteem te realiseren, zijn minder informatiesystemen nodig wat kosten kan besparen en zijn aanpassingen makkelijker door te voeren‟. Consequenties De gevolgen van het hanteren van het principe: wat moet Delfland doen om dit principe te realiseren. Bijvoorbeeld „Delfland gebruikt maar één Document Management Systeem, bij standaardpakketten wordt expliciet vastgesteld welke functionaliteit van het pakket binnen Delfland gebruikt wordt en welke niet en functionaliteiten worden zo ontworpen dat ze in meerdere processen gebruikt kunnen worden‟. Eigenaar De senior manager die belanghebbende is bij het naleven van het principe. De eigenaar is degene die zich hard maakt voor het principe en degene naar wie geëscaleerd wordt bij overtreding van het principe. Verwijzing Een verwijzing naar andere principes waar dit principe een relatie mee heeft. In dit document zijn in de hoofdstukken 4, 5, 6 en 7 voor de leesbaarheid alleen naam en statement opgenomen. De volledige tekst van de principes is opgenomen in het referentiedocument „Architectuurprincipes‟. Zoals aangegeven zijn de principes onderverdeeld in businessprincipes, informatieprincipes en technische principes. Daarnaast zijn er principes op het gebied van beveiliging en beheer. Al deze principes zijn een afgeleide van de strategische uitgangspunten en algemene principes. Daarnaast hebben de principes ook onderling relaties: de technische principes maken de informatieprincipes mogelijk en de informatieprincipes ondersteunen de businessprincipes. Dit is weergegeven in Figuur 5.

Strategische uitgangspunten

Algemene principes

Beheer- en beveiligingsprincipes

Business principes

Informatie principes

Technische principes

Afgeleide principes

Figuur 5 – Samenhang tussen de verschillende typen principes


pagina 9 van 42


2.4

Architectuurmodellen

De DEA bevat de volgende modellen. - Procesmodel Een weergave van de hoofdprocessen die door Delfland worden uitgevoerd. Het procesmodel is belangrijk voor de informatievoorziening, omdat de processen bepalen wat de informatiebehoefte van Delfland is. In die zin vormt het procesmodel de kapstok voor alle overige modellen. - Objectenmodel Een weergave van de zaken (objecten) waarover Delfland gegevens vastlegt om haar taken te kunnen vervullen. Gegevens over objecten worden vastgelegd en gebruikt in processen. Daarbij is het belangrijk te beseffen dat gegevens regelmatig ook door andere processen worden gebruikt. Dat betekent dat gegevens op een „open‟ wijze moeten worden vastgelegd. - Functionaliteitenmodel Een weergave van de functionaliteiten die door de informatievoorziening ondersteund (kunnen) worden. Een functionaliteit is een afgebakende en zelfstandig uit te voeren activiteit. Een functionaliteit kan binnen verschillende processen gebruikt worden, bijvoorbeeld het plannen van werkzaamheden. Over het algemeen bewerkt een functionaliteit bepaalde gegevens. - Technisch model Een weergave van de onderlinge samenhang tussen de verschillende technische componenten waarop de informatiesystemen draaien. Het procesmodel, objectenmodel en functionaliteitenmodel geven weer welke kernprocessen, objecten en functionaliteiten van belang zijn voor Delfland om haar opgaven te realiseren. In die zin vormen deze modellen een tijdloos kader. De wijze waarop processen worden uitgevoerd, gegevens worden vastgelegd en functionaliteiten worden ondersteund met applicaties ontwikkelt zich continu. Deze ontwikkeling kan worden weergegeven door de actuele of gewenste invulling af te beelden op de kernmodellen. In de bijlage „Applicatie inventarisatie‟ is dit gedaan door de huidige applicaties af te beelden op de drie modellen. Dit geeft de huidige situatie van het applicatielandschap van Delfland weer. Op een vergelijkbare manier kan de gewenste situatie verbeeld worden, eventueel via een aantal tussenfasen. Op basis van deze modellen is bovendien een aantal gecombineerde modellen opgesteld, die de relaties tussen de verschillende modellen weergeven. - Logisch informatiesystemenmodel Een weergave van hoe in de toekomst informatiesystemen gezamenlijk de informatievoorziening van Delfland kunnen invullen. Informatiesystemen zijn een combinatie van gerealiseerde functionaliteiten en beheerde gegevens. De afbakening van informatiesystemen in het logisch informatiesystemenmodel is gebaseerd op de informatieprincipes. Het geeft een „ideale‟ informatievoorziening weer. - Processen - functionaliteiten Een afbeelding van de functionaliteiten op de processen. Het model geeft weer welke processen gebruik maken van welke functionaliteiten. - Functionaliteiten - objecten Een afbeelding van de objecten op de functionaliteiten. Dit model geeft weer welke functionaliteit welke objecten beheert. Dat betekent dat alleen via die functionaliteit de (initiële) vastlegging gebeurt van het object. Deze gecombineerde modellen verschaffen extra inzicht, door relaties tussen de modellen zichtbaar te maken. Zo geeft het afbeelden van de objecten op de functionaliteiten aan in welke functionaliteiten welke gegevens ontstaan. Het afbeelden van de functionaliteiten op de processen geeft aan welke functionaliteiten door meerdere processen gebruikt worden (generieke functionaliteiten) en welke specifiek zijn voor een proces (specifieke functionaliteiten). Dit leidt tot keuzes met betrekking tot generieke Delflandbrede applicaties versus specifieke applicaties voor één proces.


pagina 10 van 42


2.5

Gelaagde architectuur

Figuur 6 – Drie-lagen architectuur In bovenstaande figuur is in één overzicht het globale resultaat van het architectuurtraject weergegeven. Belangrijk in dit overzicht is de opdeling in drie lagen: processen, functionaliteit en gegevens. Delfland bereikt haar resultaten door het uitvoeren van bedrijfsprocessen. Binnen die bedrijfsprocessen worden gegevens geregistreerd, aangepast en verwerkt die nodig zijn voor het bereiken van het resultaat. Zo wordt binnen het proces „Vergunningverlening‟ een vergunning geregistreerd. Om die gegevens te kunnen verwerken is (geautomatiseerde) functionaliteit nodig. De functionaliteit ondersteunt geautomatiseerd het bedrijfsproces door verwerking van de in het bedrijfsproces benodigde gegevens. De lagen zijn duidelijk van elkaar gescheiden. Dat levert een aantal voordelen op. Het zorgt ten eerste voor meer flexibiliteit in en toekomstvastheid van de informatievoorziening binnen Delfland. Door op deze manier te kijken naar de informatievoorziening wordt voorkomen dat elke verandering in een bedrijfsproces leidt tot een nieuw informatiesysteem met bijbehorende vastlegging van gegevens. Daarmee wordt het syndroom van het “probleempje – systeempje” voorkomen en wordt hergebruik van functionaliteit en gegevens beter mogelijk. Een tweede voordeel is de betere betrouwbaarheid van de gegevens. De gegevenslaag laat zien welke gegevensobjecten belangrijk zijn voor de bedrijfsvoering van Delfland. Deze gegevensobjecten worden gezien als unieke bron van informatie, de „waarheid‟. Dat betekent dat een gegeven slechts door één functionaliteit wordt vastgelegd en dat meerdere functionaliteiten en processen dit gegeven kunnen gebruiken (eenmalige opslag, meervoudig gebruik). Hiermee wordt dubbele vastlegging van dezelfde soort gegevens voorkomen, is gebruik van eenmaal vastgelegde gegevens betrouwbaarder en is rapportage en sturing op meerderde manieren (bijvoorbeeld proces- en programmasturing) mogelijk.


pagina 11 van 42


3. Uitgangspunten voor de architectuur In het vorige hoofdstuk zijn principes gedefinieerd als uitspraken die richting geven aan de gewenste inrichting van de informatievoorziening. Deze principes komen uiteraard niet uit de lucht vallen, maar zijn gerelateerd aan de strategie en de doelstellingen van Delfland. In dit hoofdstuk staan de strategische uitgangspunten en de algemene principes weergegeven, die richting geven aan de overige architectuurprincipes. De strategische uitgangspunten en algemene principes zijn vooral afgeleid van het Waterbeheerplan 2010-2015 en de Kadernota 2011.

Figuur 7 – Het aangevulde NORA raamwerk In het document “Architectuurprincipes” zijn de onderstaande principes verder uitgewerkt, inclusief de rationale en de consequenties. Principe Statement Strategische uitgangspunten 1. Schoon water 2. Voldoende water

3. Stevige dijken 4. Gezuiverd afvalwater 5. Instrumentarium 6. Professionele organisatie, autoriteit op watergebied


Delfland is verantwoordelijk voor schoon en gezond water in zijn kanalen, sloten daar waar dit bijdraagt aan de leefbaarheid van het gebied. Delfland zorgt dat het watersysteem en het beheer en onderhoud op orde zijn zodat het beheergebied beter bestand is tegen extreem natte en extreem droge situaties en Delfland het reguliere beheer en onderhoud efficiënt kan uitvoeren. Delfland draagt zorg voor stevige dijken om zijn beheersgebied te beschermen tegen overstromingen. Delfland draagt zorg voor het zuiveren van afvalwater, in overeenstemming met de Europese normen. Delfland zet haar instrumenten optimaal in om te zorgen dat de kerntaken zo efficiënt en effectief mogelijk kunnen worden uitgevoerd. Delfland heeft het imago van een modern en vooruitstrevend waterschap en wordt gezien als autoriteit op het gebied van water.

pagina 12 van 42


Principe Algemene principes

Statement

1. Uitvoeringsorganisatie met een wettelijke taak

Delfland is een uitvoeringsorganisatie met een wettelijke taak op het gebied van waterbeheer. Deze wettelijke taak is primair richtinggevend voor alle activiteiten. Delfland stemt te nemen maatregelen af op het vereiste effect. Delfland pakt beleid en uitvoering integraal aan, door per gebied alle aspecten mee te nemen. Delfland gedraagt zich in haar zakelijke contacten en samenwerkingsrelaties als een marktpartij. Delfland voert haar processen op een efficiënte manier uit, tegen zo laag mogelijke maatschappelijke kosten. Delfland maakt gebruik van standaarden en generieke voorzieningen. Delfland is voorbereid op het tijdig kunnen inspelen op veranderende omstandigheden. Delfland streeft ernaar de verantwoordelijkheid voor de inhoud en voor het geld te beleggen bij één verantwoordelijke eigenaar. Delfland zoekt actief de samenwerking, zowel intern als extern, om zijn opgave te realiseren. Delfland is een innovatief waterschap, mits dat bijdraagt aan de eigen opgave. Delfland gaat mee met de binnen de e-overheid en NORA geformuleerde wijze van het omgaan met klanten. Delfland is in de uitoefening van haar opgaven transparant naar klanten, (keten)partners, bestuurders en medewerkers. Delfland voert zijn taken op een maatschappelijk verantwoorde wijze uit en levert zo een bijdrage aan een duurzame, leefbare en veilige maatschappij.

2. Effectgericht 3. Gebiedsgericht 4. Marktgericht 5. Operational Excellence 6. Standaardisatie 7. Flexibiliteit 8. Koppeling inhoud en geld 9. Samenwerking 10. Innovatief 11. Klantgericht 12. Transparantie 13. Duurzaamheid


pagina 13 van 42


4. Business architectuur De business architectuur richt zich op de organisatie van Delfland, met de producten en diensten die worden geleverd en de processen waarmee deze producten en diensten worden voortgebracht2.

Figuur 8 – Positionering Business Architectuur

4.1

Business Principes

De business principes zijn onderverdeeld in organisatie, diensten & producten en processen. Principe Statement Business Principes - Organisatie 1. Vraaggestuurde organisatie 2. Bestuur bepaalt 3. Organisatiesturing langs 2 assen; via de lijn en via programma‟s 4. Programmamanagement 5. Integraal management 6. Prestatiemanagement 7. Externe verantwoording 8. Samenwerkingsverbanden met externe partijen

Delfland is een vraaggestuurde organisatie die met beide benen in de samenleving staat. Bij Delfland is het bestuur de partij die beslist, vaststelt en stuurt. Delfland hanteert meerdere invalshoeken van organisatiesturing binnen haar besturingsmodel; zowel via de lijn als via programma‟s. Delfland gebruikt programmamanagement om te sturen op de realisatie van de doelen in het WBP. Delfland gebruikt integraal management om te sturen op de interne organisatie. Delfland gebruikt prestatiemanagement om alle collectieve initiatieven en activiteiten te richten op de succesvolle realisatie van organisatiedoelen én individuele doelen. Delfland legt externe verantwoording af over de taakuitvoering aan de stakeholders Delfland kiest voor het aangaan van samenwerkingsverbanden met externe partijen, als dit voldoende voordelen oplevert.

2

In dit document wordt de productenstructuur BBP niet beschreven. Zie hiervoor de documentatie van de Unie van Waterschappen.


pagina 14 van 42


Business Principes – Diensten en Producten 1. BBP structuur 2. Eenduidige producten en diensten 3. Digitale kanalen

Delfland gebruikt voor rapportage en benchmarking de BBP structuur. Delfland streeft bij de inrichting van producten en diensten naar eenduidigheid en standaardisatie. Delfland levert haar producten en diensten bij voorkeur via digitale kanalen.

Business Principes –Processen 1. 24x7 uitvoering van primaire processen 2. Digitale processen 3. Klant heeft inzicht in status 4. WIA processen als uitgangspunt 5. Procesbesturing met KPI‟s

4.2

Delfland richt de processen voor het uitvoeren van haar kerntaken zodanig in dat deze waar nodig volcontinu uitgevoerd kunnen worden. Delfland zorgt ervoor dat processen, inclusief de door de klant geïnitieerde processen, zoveel mogelijk digitaal plaatsvinden. Delfland geeft haar klanten volledig inzicht in de status van het proces en de gegevens die over hen zijn geregistreerd. Delfland gaat bij de procesinrichting uit van de WIA hoofdprocessen. Bij het ontwerp van processen worden KPI‟s gedefinieerd ten behoeve van de procesbesturing.

Business Modellen

De business architectuur bevat één model: het procesmodel. 4.2.1 Procesmodel Het procesmodel geeft de hoofdprocessen weer die door Delfland worden uitgevoerd. Het procesmodel is belangrijk voor de informatievoorziening, omdat de processen bepalen wat de informatiebehoefte van Delfland is. In die zin vormt het procesmodel de kapstok voor alle overige modellen. Het procesmodel is integraal overgenomen van de projectgroep Hoofdprocessen/AO.


pagina 15 van 42


Besturende processen Besturing Opstellen en actualiseren strategie en organisatiebeleid

Beleid vertalen in maatregelen, activiteiten en middeleninzet

‘Intern’ beheersen (control)

Relatiebeheer Opbouwen en onderhouden externe relaties

Opstellen jaarlijkse plannen t.a.v. prestaties en resultaten

Innovatie Verkennen ontwikkelingen en kansen

Afhandelen van meldingen en klachten

Uitvoeren verkennend onderzoek

Verantwoorden

Primaire processen Regelgeving Opstellen en beheren legger

Opstellen en actualiseren verordeningen

Planvorming

Opstellen en actualiseren beleidsregels

Opstellen en actualiseren themagerichte plannen

Opstellen en actualiseren gebiedsgerichte plannen

Beïnvloeden, toetsen en anticiperen op plannen van derden

Opstellen en actualiseren calamiteitenplannen

Opstellen en actualiseren waterakkoorden

Opleiden en oefenen

(Water)gebiedsbeheer Bestrijden calamiteit

Waterkeringenbeheer Aanleggen, verwerven, nieuwbouwen

Plannen en ontwerpen

Onderhouden

Beheren

Aanleggen, verwerven, nieuwbouwen


Onderhouden

Beheren

Afvalwaterzuivering Aanleggen, verwerven, nieuwbouwen


Beheren

Onderhouden

Vergunningverlening Houden vooroverleg

Toetsen aanvraag

Opstellen ontwerpvergunning

Opleggen aanslagen

Verwerken bezwaren en beroepen

Ontvangen en verwerken bedenkingen

Calamiteitenbeheersing

Watersysteembeheer

Handhaving Verlenen vergunning

Plannen uitvoeren toezicht

Ontvangen en verwerken van meldingen WVO

Repressieve handhaving

Belastingheffing en invordering Actualiseren basisgegevens

Verwerken verzoeken

Invorderen

Ondersteunende processen Communicatie

Financiën

Juridische zaken

Technologie

Personeel

Informatie

Huisvesting

Organisatie

Figuur 9 – Procesmodel


pagina 16 van 42


5. Informatie architectuur

Figuur 10 – Positionering Informatie Architectuur

5.1

Informatie Principes

De informatie principes zijn onderverdeeld in medewerkers & applicaties, berichten & gegevens en informatie-uitwisseling. Principe Statement Informatie Principes – Medewerkers en applicaties 1. Geen redundante functionaliteit 2. Beschikbaarheid informatiesystemen 3. Open source 4. Hergebruik voor kopen

5. standaardpakketten voor ondersteunende processen 6. Software ondersteuning gegarandeerd 7. Presentatie via webtechnologie 8. Applicaties passen binnen Delfland standaarden 9. Eigenaarschap applicaties 10. Procesondersteuning door workflow 11. Software maakt gebruik van open standaarden 12. Afbakening functionaliteiten 13. Gebruik van mobiele apparaten 14. Proeftuin voor innovatie 15. Software en gegevens bij aanschaf van “water” hardware


Delfland zorgt ervoor dat benodigde functionaliteit slechts door één informatiesysteem wordt ondersteund. Delfland stemt de ondersteuning en beschikbaarheid van informatiesystemen af op de behoefte van de bedrijfsprocessen. Bij gelijke geschiktheid heeft open source de voorkeur. Bij vernieuwing van de informatievoorziening vindt realisatie van functionaliteiten plaats in de volgorde: 1. Hergebruik van binnen Delfland reeds bestaande voorzieningen; 2. Kopen van standaardvoorzieningen. Voor de ondersteunende processen worden standaardpakketten gebruikt. Delfland gebruikt alleen bewezen software waarvan de ondersteuning is gegarandeerd. Presentatie van gegevens naar extern gebeurt via Webtechnologie. Nieuwe applicaties moeten passen binnen de geldende standaarden van Delfland. Elke applicatie heeft een eigenaar in de business. Delfland gebruikt workflow voor ondersteuning van de bedrijfsprocessen. Nieuw aan te schaffen software voldoet aan open standaarden. Applicaties zijn zoveel mogelijk opgebouwd uit zelfstandig uitvoerbare stukken afgebakende functionaliteit. Bij aanschaf van nieuwe toepassingen wordt, waar zinvol, rekening gehouden met eventueel gebruik in het veld op mobiele apparaten. Innovatieve ontwikkelingen vinden plaats in een proeftuin gescheiden van de productieomgeving. Bij de aanschaf van nieuwe “water” hardware, zoals meetapparatuur en overige instrumenten, dient expliciet bepaald te worden of de bijbehorende software en gegevensopslag past binnen de architectuur.

pagina 17 van 42


Informatie Principes – Berichten en gegevens 1. Heldere verantwoordelijkheden gegevensbeheer 2. Eenduidige definities 3. Integrale gegevensbehoefte vastgelegd 4. Gegevens afgestemd op behoefte processen 5. Gegevenskwaliteit afgestemd op behoefte processen 6. Eenmalige opslag, meervoudig gebruik 7. Metagegevens 8. Gegevens bruikbaar voor meerdere invalshoeken 9. Vertrouwelijkheid

Voor alle gegevensclusters van Delfland worden de drie rollen van gegevenseigenaar, gegevensbeheerder en functioneel applicatiebeheerder expliciet belegd bij verschillende personen. Voor alle gegevens bestaat een eenduidige definitie waarover overeenstemming is tussen de verschillende gebruikers in de organisatie. Er is voor alle kerngegevens en voor gegevens uit de authentieke basisregistraties altijd een actueel, integraal en gedetailleerd beeld van de wensen en eisen die alle verschillende gebruikers van dit type gegevens hebben. Delfland onderhoudt alleen die gegevens waarvan de toegevoegde waarde binnen één of meerdere bedrijfsprocessen kan worden aangetoond. De kwaliteit van de gegevens (actualiteit, volledigheid, nauwkeurigheid, uniformiteit) is zodanig geborgd dat dit voorziet in de integrale behoefte van de bedrijfsprocessen. Gegevens worden eenmalig opgeslagen en beheerd bij de bron en kunnen meervoudig worden gebruikt. De gegevens zijn voorzien van metagegevens ten behoeve van beheer en de ontsluiting van informatie. De gegevens zijn op zodanige manier vastgelegd dat ze vanuit meerdere invalshoeken te benaderen zijn. Delfland garandeert dat informatie alleen toegankelijk is voor bevoegde personen en alleen wordt gebruikt voor het doel waarvoor zij is verzameld.

Informatie Principes – Informatie-uitwisseling 1. Gegevensuitwisseling volgens open standaarden 2. Gegevensleveringsovereenkomsten 3. Automatische gegevensuitwisseling 4. Doelgericht gebruik services

5.2

Gegevens worden volgens landelijke, en bij voorkeur open, standaarden opgeslagen om uitwisseling van gegevens mogelijk te maken. Voor elk geval van gegevensuitwisseling, intern en extern, wordt een gegevensleveringsovereenkomst opgesteld tussen leverancier en afnemer met afspraken over kwaliteit, betekenis, frequentie en vorm van levering. Uitwisseling van kerngegevens gebeurt geautomatiseerd. Informatie-uitwisseling gebeurt door middel van services bij uitwisseling met externe partijen en bij meervoudige afname binnen de organisatie.

Informatie Modellen

De informatie architectuur bevat twee modellen: het objectenmodel en het functionaliteitenmodel. 5.2.1 Objectenmodel Het objectenmodel geeft de zaken (objecten) weer waarover Delfland gegevens vastlegt ten einde haar taken te kunnen vervullen. Gegevens over objecten worden vastgelegd en gebruikt in processen. Daarbij is het belangrijk te beseffen dat gegevens regelmatig worden gebruikt door andere processen dan waarin ze worden vastgelegd. Dat betekent dat gegevens op een „open‟ wijze moeten worden vastgelegd. Een object is iets in de werkelijkheid (abstract of fysiek) dat voor Delfland belangrijk is om gegevens over vast te leggen. Het objectenmodel laat deze objecten in relatie tot elkaar zien. Ieder hoofdobject is verdeeld in verschillende subobjecten. Het model is van belang om twee redenen: 1. Het levert een eenduidige indeling van begrippen en hun definities. 2. Het biedt een overzicht van alle objecten die nodig (en voldoende) zijn om het primaire proces van Delfland uit te kunnen voeren. Het model kan vervolgens gebruikt worden om te toetsen of 1. Een beoogde verandering (bijvoorbeeld het introduceren van een nieuwe applicaties) past binnen de gehanteerde begripsindeling en -definitie; 2. Een beoogde verandering niet leidt tot dubbel vastlegging van hetzelfde (sub)object; 3. Consolidatie van applicaties die hetzelfde object vastleggen en beheren mogelijk is (bijvoorbeeld twee verschillende applicaties die meetgegevens vastleggen).


pagina 18 van 42


Relatie Regel Keur Beleidsregel

Beheeractie Besluit

Project

Werkorder

Verordening Legger

Standaard

Beheerobject

Hand havings maatregel

Vergunning

Plan Kabel / leiding Grondwater

Plan van derden

Staat

Vaarweg

Vernieuwing

Geografie

Tactisch plan

Ontwerp

Strategisch plan

Water huishouding

Kunstwerk

Operationeel plan Vastgoed element

Waterkering Riolering

Meting

Afwijking

Inspectie

Toetsing

Calamiteit

Meetwaarde

Klacht

Incident

Regelgever

Leverancier Klant

Partner

Figuur 11 – Objectenmodel


pagina 19 van 42


Toelichting op het objectenmodel Centraal in het model staat het object Beheerobject. Het Beheerobject is daarmee ook het centrale, belangrijkste object binnen de primaire taak van Delfland; het object waaromheen alle processen en informatievoorziening zijn georganiseerd. Een Beheerobject is een abstract of fysiek fenomeen in de werkelijkheid dat van belang is voor de uitoefening van de taken van Delfland. Denk daarbij aan een waterkering, een vaarweg of een gemaal. Van elk Beheerobject ligt het ontwerp, de staat en de geografie vast. Om de taken van Delfland uit te kunnen voeren zijn objecten nodig die direct zijn gerelateerd aan het Beheerobject. Een Plan beschrijft een voorstel voor verandering die (mogelijk) invloed heeft op de Beheerobjecten. Een Regel legt normen op aan het ontwerp en het gebruik (door een Relatie) van Beheerobjecten. Een Meting wordt uitgevoerd om te kunnen bepalen of een Beheerobject (of een geheel aan Beheerobjecten) zich in de juiste staat bevindt (conform een Regel). Een Afwijking is een constatering dat een Beheerobject afwijkt van de gewenste staat (verkregen uit een Meting of gemeld door een Relatie). Een Beheeractie moet ervoor zorgen dat een Beheerobject weer in de juiste staat wordt gebracht (na een geconstateerde Afwijking of conform een Regel). In onderstaande tabel wordt elk hoofdobject en de bijbehorende subobjecten voorzien van een definitie3. BEHEEROBJECT Definitie Subobjecten

Attributen

Relaties

3

Een BEHEEROBJECT is een abstract, kunstmatig of natuurlijk fenomeen, dat van belang is voor de uitoefening van de taken van een waterschap. KUNSTWERK Een kunstmatig tot stand gekomen werk dat van belang is binnen de waterhuishouding. WATERHUISHOUDING <definitie volgt> KABEL/LEIDING <definitie volgt> GRONDWATER <definitie volgt> VAARWEG <definitie volgt> WATERKERING Een BEHEEROBJECT dat water tegenhoudt. RIOLERING <definitie volgt> VASTGOED ELEMENT <definitie volgt> ONTWERP Een beschrijving van de (toekomstige) werkelijkheid van een BEHEEROBJECT. STAAT De actuele toestand van een BEHEEROBJECT. GEOGRAFIE De locatie van een BEHEEROBJECT op het aardoppervlak. METING Een METING meet de actuele staat van een BEHEEROBJECT. REGEL Een REGEL geeft de kaders aan voor vernieuwing, gebruik door een RELATIE, beheer en onderhoud van een BEHEEROBJECT. BEHEERACTIE Een BEHEERACTIE is AFWIJKING Een AFWIJKING is een constatering dat een BEHEEROBJECT mogelijk niet functioneert zoals deze geacht wordt te functioneren. PLAN Een PLAN bevat het voornemen veranderingen aan te brengen in een BEHEEROBJECT (of aan het geheel van BEHEEROBJECTen).

Een aantal definities zal op een later tijdstip nog moeten worden toegevoegd.


pagina 20 van 42


REGEL Definitie

Subobjecten

Een REGEL is een voorschrift dat geldt voor vernieuwing, gebruik, onderhoud en beheer van een BEHEEROBJECT, van toepassing voor (RELATIEs van) het WATERSCHAP. BELEIDSREGEL <definitie volgt> BESLUIT Vastgesteld plan (bron: van Dale) STANDAARD Vaststaand, erkend voorbeeld of model (bron: van Dale), dat geldt als norm of richtlijn. VERORDENING Door het bestuur van het WATERSCHAP uitgevaardigde bindende regeling. (bron: van Dale) KEUR Een verordening met regels die het WATERSCHAP hanteert bij de bescherming van waterkeringen, watergangen en bijbehorende kunstwerken. (bron: Wikipedia) LEGGER Document of dossier waarin de belangrijkste kenmerken van alle waterlopen, kunstwerken ed en de keurbegrenzingen van een bepaald waterschapsgebied staan. VERGUNNING Een officiële (noodzakelijke) toestemming van het WATERSCHAP om een bepaalde in principe verboden activiteit uit te voeren op een BEHEEROBJECT.

BEHEERACTIE Definitie Subobjecten

PROJECT

WERKORDER HANDHAVINGS MAATREGEL

Een tijdelijke organisatie bedoeld voor het invoeren van een grote verandering aan een (geheel van) BEHEEROBJECT(en). Een reguliere actie voor het doorvoeren van een verandering een BEHEEROBJECT. Een corrigerende maatregel genomen door een WATERSCHAP na constatering van een overtreding van een RELATIE van een bepaalde REGEL.

AFWIJKING Definitie

Een AFWIJKING is een kennisgeving van een gebeurtenis, geconstateerde waarneming of een geconstateerd feit met betrekking tot een aangelegenheid die verband houdt met de taken van het WATERSCHAP. (bron: Aquo-lex), verkregen van een RELATIE of door een METING.

Subobjecten

CALAMITEIT KLACHT INCIDENT

Een constatering van een ramp binnen het WATERSCHAP. Een kennisgeving van een ontevredenheid over het WATERSCHAP door een RELATIE. Een constatering van een afwijking van de normale operatie van een BEHEEROBJECT.

METING Definitie Subobjecten

Een METING is een kwantitatieve toestand van een BEHEEROBJECT. INSPECTIE Controle op het naleven van of voldoen aan de REGELs in het gebruik en beheer van een BEHEEROBJECT. TOETSING <definitie volgt> MEETWAARDE Automatisch verkregen METING.

PLAN Definitie Subobjecten

Een PLAN is een voornemen van een WATERSCHAP of RELATIE dat invloed heeft op de taken van het WATERSCHAP. VERNIEUWING <definitie volgt> STRATEGISCH PLAN <definitie volgt> TACTISCH PLAN <definitie volgt> OPERATIONEEL PLAN <definitie volgt> PLAN VAN DERDEN <definitie volgt>


pagina 21 van 42


RELATIE Definitie Subobjecten

Een zakelijke betrekking van het WATERSCHAP met een persoon of organisatie buiten het WATERSCHAP. REGELGEVER Diegene die regelgevingen, van belang voor het waterschap opstelt. KLANT Afnemer van een dienst van het waterschap. PARTNER Een persoon of bedrijf dat in samenwerking met het waterschap diensten levert aan een KLANT. LEVERANCIER Een persoon of bedrijf dat diensten levert aan het waterschap.

5.2.2 Functionaliteitenmodel Het functionaliteitenmodel geeft de functionaliteiten weer die door de informatievoorziening ondersteund (kunnen) worden. Een functionaliteit is een afgebakende en zelfstandig uit te voeren activiteit. Een functionaliteit kan doorgaans binnen verschillende processen gebruikt worden, bijvoorbeeld het plannen van werkzaamheden. Over het algemeen bewerkt een functionaliteit bepaalde gegevens. Een functionaliteit wordt geleverd door één of meerdere informatiesystemen. In het functionaliteitenmodel zijn deze functionaliteiten gegroepeerd tot clusters van logisch bij elkaar horende functionaliteiten. Het model geeft een totaaloverzicht van alle functionaliteiten die nodig zijn om de primaire taken van Delfland uit te kunnen voeren. Het model is van belang omdat daarmee een scheiding wordt aangebracht tussen de bedrijfsprocessen en informatiesystemen. Een informatiesysteem is een combinatie van door het informatiesysteem geleverde functionaliteiten en door het informatiesysteem beheerde objecten. In de praktijk komt het vaak voor dat een proces direct verbonden is met een bepaald informatiesysteem (bijvoorbeeld een applicatie voor vergunningverlening en handhaving, waarin functionaliteiten voor het beheren van relaties, voor documenten en werkorders is geïntegreerd). Het nadeel daarvan is dat daardoor dezelfde functionaliteit in verschillende informatiesystemen voorkomt (omdat dezelfde functionaliteit in verschillende processen nodig is). Door nu de functionaliteiten (en objecten) onafhankelijk van de informatiesystemen te visualiseren, wordt het gemakkelijker om functionaliteiten te benoemen die voor hergebruik in aanmerking komen.


pagina 22 van 42


Rapporteren en analyseren

Ontvangen meldingen

Integreren, aggregeren en rapporteren

Planning werkzaamheden Planning werkzaam heden

Workflow Management Beoordelings proces

Besluit vormings proces

Bewaken status uitvoering (incl. derden)

Beheren werkvoorraad

Verzamelen / registreren meetgegevens

Valideren meetgegevens

Ontsluiten meetgegevens

Signaleren afwijking (alarmering)

Modelleren dynamische systemen

Modelleren statische systemen

Aannemen melding

In behandeling nemen melding

Content management

Document Management

Geografische Onder Informatie houden en verwerking beheren

Meten

Modelleren

Relatie beheer Opbouwen en ontsluiten dynamische geografie

Algemene communicatie

Ontwerpen Ontwerpen beheerobject

Communicatie individuele meldingen

Beheren relatie gegevens

Creëren document

Opbouwen en ontsluiten statische geografie

Bewaken staat beheerobject

Ontvangen informatie van externe relaties

Vastleggen contact met relaties

Beheren digitaal archief

Combineren model met geografische data

Asset management

Beheren vergunningen

Bedienen Aansturen beheerobject

Ondersteunende functionaliteit Middelen beheer

Personeels management

Project management

Verwerken en betalen factuur

Planning en control

Figuur 12 – Functionaliteitenmodel


(complex) analyseren

Vergunningverlening en handhaving

Communiceren en presenteren

Programma management

pagina 23 van 42

Invorderen

Ondersteuning handhaving

Contract- en service management


Toelichting op het functionaliteitenmodel Ontvangen meldingen4 Aannemen melding

Het registreren en zo nodig compleet maken van een melding, gedaan door een relatie

In behandeling nemen melding

Het toekennen van de melding aan de juiste behandelaar

Workflow Management Het besturen/bewaken van het proces van het ambtelijk goedkeuren van een voorgenomen actie Het besturen/bewaken van het proces van het bestuurlijk goedkeuren van een voorgenomen actie Het bewaken van de voortgang van de uitvoering van (reguliere) werkzaamheden Het toewijzen van werkzaamheden aan medewerkers en het beheren van de individuele werkvoorraad

Beoordelingsproces Besluitvormingsproces Bewaken status uitvoering (incl. derden) Beheren werkvoorraad Planning werkzaamheden Planning werkzaamheden

Het inplannen van een goedgekeurde (reguliere) actie

Relatiebeheer Het vastleggen en onderhouden van gegevens over relaties (burgers, bedrijven en ketenpartners) van Delfland Het vastleggen van een contactmoment met een bepaalde relatie van Delfland

Beheren relatiegegevens Vastleggen contact met relaties Communiceren en presenteren

Het communiceren van een boodschap aan een breed publiek (zowel intern als extern) Het communiceren van een boodschap aan een (groep van) individu(en)

Algemene communicatie Communicatie individuele meldingen Ontvangen informatie van externe relaties

Het ontvangen van (digitale) informatie van externe relaties

Content Management

Het beheren van de inhoud van de website en intranet van Delfland

Geografische informatieverwerking Opbouwen en ontsluiten van dynamische geografie Opbouwen en ontsluiten van statische geografie Combineren model met geografische data

Het samenstellen en beschikbaar stellen van geografische, realtime veranderende informatie Het samenstellen en beschikbaar stellen van geografische, statische, informatie Het koppelen van geografische informatie aan beheerobjecten ten behoeve van modellering

Meten Verzamelen / registreren meetgegevens Valideren meetgegevens Ontsluiten meetgegevens Signaleren afwijking (alarmering)

Het verzamelen en registreren van meetgegevens over de staat van een beheerobject Het valideren van de correctheid en betrouwbaarheid van meetgegevens Het beschikbaarstellen van geregistreerde en gevalideerde meetgegevens Het afgeven van een signaal dat uit de geregistreerde en gevalideerde meetgegevens blijkt dat een bepaalde norm wordt overschreven

Modelleren Modelleren dynamische systemen Modelleren statische systemen

Het vervaardigen van modellen van dynamische systemen, zoals het watersysteem van Delfland Het vervaardigen van modellen van statische systemen, zoals een model voor de sterkteberekening van een waterkering

4

Ontvangen meldingen is feitelijk een combinatie van Relatiebeheer en Workflowmanagement, maar wordt hier apart genoemd om te benadrukken dat dit een generieke functionaliteit is.


pagina 24 van 42


Onderhouden en beheren Bewaken staat beheerobject Assetmanagement

Het continu bijhouden van de toestand waarin een bepaald beheerobject zich bevindt Het tijdens de totale levenscyclus van een beheerobject zorgen dat het beheerobject zich in de juiste toestand bevindt

Documentmanagement Creëren document Beheren digitaal archief

Het initieel aanmaken van een document, met bijbehorende metagegevens Het beheren van de levenscycli van alle documenten binnen het digitale archief

Rapporteren en analyseren5 Programmamanagement6 Integreren, aggregeren en rapporteren (Complex) analyseren

Het beheersen van een samenhangend geheel aan veranderingen, die gericht zijn op het bereiken van een specifiek doel Het integreren en aggregeren van informatie vanuit verschillende bronnen en van verschillende aard en daarover rapporteren Het analyseren van informatie vanuit verschillende bronnen en van verschillende aard (voor het ontdekken van trends, afwijkingen, e.d.)

Ontwerpen Ontwerpen beheerobject

Het maken van een ontwerp van een nieuw te realiseren beheerobject

Bedienen Aansturen beheerobject

Het – op afstand – in de juiste toestand brengen van een beheerobject

PIOFAH Middelenbeheer Personeelsmanagement

Het beheren van de ondersteunende middelen voor de uitoefening van de taak van Delfland Het verwerken van informatie over het in- en externe personeel van Delfland

Projectmanagement

Het beheersen van een (eenmalige) verandering

Verwerken en betalen factuur

Het verwerken en betalen van een factuur

Planning en control

De voorbereiding van financieel-economisch beleid en de controle op de uitvoering ervan

Invorderen

Het vorderen van een uitstaande schuld van een relatie van Delfland

Contract- en servicemanagement

Het opstellen en beheren van contracten en serviceafspraken met leveranciers en partners

Vergunningverlening & Handhaving Beheren vergunningen Ondersteuning handhaving

Het vastleggen, beheren, analyseren en rapporteren ten behoeve van het vergunningenproces Het analyseren en rapporteren ten behoeve van het handhavingsproces

5

Dit betreft managementinformatie. Operationeel rapporteren is niet als aparte functionaliteit opgenomen, omdat ieder informatiesysteem een dergelijke functionaliteit standaard levert. 6 Programmamanagement betreft het rapporteren en analyseren op programmaniveau. Hieronder valt niet het Projectmanagement.


pagina 25 van 42


6. Technische architectuur

Figuur 13 – Positionering Technische Architectuur

6.1

Technische Principes

De technische principes zijn onderverdeeld in technische componenten, gegevensopslag en netwerk. Principe Statement Technische Principes – Technische componenten 1. “proven” en supported software 2. 7*24 beschikbaarheid door redundantie 3. Werkplek is roaming 4. Centraal beheerbare oplossingen 5. Portfolio op basis van “need to have” 6. Alleen toegang “trusted” devices 7. N+1 redundantie MER en SERs 8. Green IT 9. Anytime, anywhere 10. Sector standaarden 11. Gestandaardiseerde infrastructuur 12. Single Sign On 13. Gescheiden omgevingen voor innovatie


Delfland gebruikt bewezen („proven‟) technologie, waarvoor support is gegarandeerd. Delfland voert alle bedrijfskritische technische componenten dubbel uit om 7*24 beschikbaarheid te kunnen garanderen. Werkplekken bij Delfland zijn zodanig ingericht dat elke medewerker van Delfland deze kan gebruiken. Delfland realiseert alleen oplossingen die vanuit één punt beheerd kunnen worden. Het IT portfolio van Delfland is gericht op het kunnen uitvoeren van de kerntaak van Delfland. Delfland onderscheid verschillende toegangsniveaus voor verschillende doelgroepen en devices. Delfland richt serverruimtes bedrijfszeker in doordat uitval van essentiële componenten kan worden opgevangen. Delfland streeft naar een duurzamen inrichting van de ICT omgeving. Het is mogelijk om de eindgebruikersfunctionaliteit van systemen tijden plaatsonafhankelijk beschikbaar te stellen, met zo min mogelijk specifieke eisen aan de werkplek van de gebruiker. Delfland conformeert zich aan standaarden binnen de sector waterschappen (o.m. via Het Waterschapshuis). Delfland streeft naar een geüniformeerde en gestandaardiseerde technische infrastructuur. Een medewerker hoeft zich slechts eenmaal aan te melden op het netwerk om toegang te verkrijgen tot al zijn applicaties. Innovatieve ontwikkelingen worden ondersteund vanuit een aparte technische omgeving, los van productie.

pagina 26 van 42


Principe Statement Technische Principes – Gegevensopslag 1. Scheiding rekenkracht en dataopslag 2. Eenmalig opslaan van gegevens

Delfland realiseert dataopslag en rekenkracht nooit op dezelfde hardware. Delfland streeft ernaar om (ongestructureerde) gegevens eenmalig te bewaren.

Technische Principes – Netwerk 1. Eén gezamenlijk Netwerk voor KA en TA 2. Eén routeringsprotocol

6.2

Het netwerk van Delfland (LAN en WAN) ondersteunt Kantoorautomatisering (KA), Technische automatisering (TA), koppelingen daartussen en koppelingen met andere netwerken. Het netwerk van Delfland (LAN en WAN) maakt gebruikt van één marktstandaard voor de routering van het netwerkverkeer.

Technische Modellen

De technische architectuur bevat twee modellen: het 4-lagenmodel en het netwerkmodel. 6.2.1 4-lagenmodel Delfland hanteert een 4-lagenmodel voor de ICT infrastructuur. In de volgende figuur is dit weergegeven. Het model is gebaseerd op de visie van een dubbelvoudig (redundant) rekencentrum. Dit houdt in dat de storage, server infrastructuur gebalanceerd is verdeeld over twee rekencentrumlocaties. Hiermee is invulling gegeven aan het begrip “Uitwijk”. De aparte component uitwijk komt hiermee te vervallen. Uitbreidingen op en wijzigingen in de infrastructuur worden volgens het 4-lagenmodel doorgevoerd.


pagina 27 van 42


Figuur 14 – Het 4-lagen model


pagina 28 van 42


Het 4-lagen model onderscheidt de volgende lagen. Laag 1: Storage Alle apparatuur en programmatuur voor de opslag, back-up en restore van alle data, evenals van testen uitwijkvoorzieningen voor de opslag. Hieronder valt het Storage Area Netwerk (SAN) en het back-up SAN, de Virtual Tape Library (VTL) voor de backup van de opgeslagen gegevens en de tape-library voor de back-up op tape. Laag 2: Back-end In de Back-end laag van het 4-Lagen Model worden met name de kritische netwerk servers opgenomen. Hieronder vallen onder andere: Alle (virtuele) servers voor databases, mail en agenda; (virtuele) Servers ten behoeve van testen uitwijkvoorzieningen; (virtuele) Servers ten behoeve van het beheer van deze laag; Alle (virtuele) domainservers; Alle (virtuele) servers voor de active directorie. Laag 3: Front-end Dit betreft: Alle (virtuele) servers voor webapplicaties, het kennisnet; (virtuele) Servers voor server based computing (Citrix); Servers met zgn. virtuele omgevingen (VMWare) voor applicaties; (virtuele) Servers voor virus bescherming; (virtuele) Servers voor de testen uitwijk testvoorzieningen; (virtuele) Servers voor het beheer van deze laag. Laag 4: Access

Toegang tot de ICT-infrastructuur van Delfland zowel van intern Delfland als van buiten Delfland. Dit betreft: Alle (virtuele) servers voor authenticatie en autorisatie (Netilla); Alle (virtuele) servers voor firewalls; Alle (virtuele) servers voor intrusiondetection; Alle (virtuele) servers in het DMZ. Het LAN en het WAN maken ook onderdeel uit van de accesslaag. De LAN en WAN laag richt zich met haar oplossingen op de beveiliging van de ICT-infrastructuur, haar gebruikers en de beveiligde toegang tot applicaties en netwerken. LAN :Het Local Area Network, de passieve en actieve netwerkcomponenten binnen de verschillende gebouwen van Delfland. WAN: Het Wide Area Network, de netwerkcomponenten ten behoeve van de communicatie tussen de verschillende gebouwen van Delfland en ten behoeve van de communicatie met apparatuur in het veld. Voor de Automatiseringstrategie en het Meerjaren Automatiseringplan wordt binnen Delfland de volgende – op het lagenmodel gebaseerde – rubricering gebruikt. Storage Servers, onderverdeeld in o Back-end o Front-end Access Clients Alle apparatuur die in de PDC wordt aangeboden (desktops, laptops, PDA‟s, etc.) en waarmee medewerkers de applicaties die zij nodig hebben voor het uitvoeren van hun werk kunnen benaderen en evt. bedienen. Telefonie Alle apparatuur die in de PDC wordt aangeboden (Smartphones, GSM‟s, telefoons etc.) en waarmee medewerkers de applicaties die zij nodig hebben voor het uitvoeren van hun werk kunnen benaderen en evt. bedienen. Beheer Managen en monitoren van alle lagen. Staat dwars op alle onderstaande lagen. Testvoorzieningen Serverruimtes


pagina 29 van 42


6.2.2 Netwerkmodel Het netwerkmodel geeft op hoog niveau inzicht in de opbouw van de Netwerkinfrastructuur van Delfland. Het geeft inzicht in: De wijze waarop de hoofdlocaties van Delfland zijn ontsloten; De wijze waarop de koppeling met het Hoogheemraadschap van Schieland en de Krimpenerwaard is gerealiseerd; De wijze waarop kleine locaties, thuisplekken en mobiele werkplekken op het netwerk van Delfland zijn aangesloten; De wijze waarop internettoegang is gerealiseerd; Waar en hoe – ringnetwerk of dubbele aansluiting – redundantie is gerealiseerd; Capaciteit van de verbinding tussen de locaties. Het netwerkmodel voor de technische infrastructuur is gebaseerd op de visie van een dubbelvoudig (redundant) rekencentrum. Dit rekencentrum is geprojecteerd op de locaties Delft (Delftechpark) en Vlaardingen.

Figuur 15 – Netwerkmodel


pagina 30 van 42


7. Beveiliging en beheer Beveiliging en beheer zijn architectuurdimensies die als het ware dwars staan op de dimensies business, informatie en techniek. Beveiliging en beheer hebben namelijk op alle drie typen architectuur betrekking. Onderstaande tabel geeft de architectuurprincipes weer die gedefinieerd zijn voor beveiliging en beheer. Principe Beveiligingsprincipes

Statement

1. Voldoen aan de Code voor Informatiebeveiliging

Delfland voldoet aan de door de overheid gestelde standaarden voor informatiebeveiliging (NEN 27002).

Principe Beheerprincipes

Statement

1. Beheer volgens standaarden 2. Scheiding van testen productieomgevingen

Beheeractiviteiten worden ingericht volgens standaard beheermethoden. Voor elke applicatie is er minimaal een test-/acceptatie- en een productieomgeving beschikbaar. In voorkomende gevallen worden er aparte testen acceptatieomgevingen beschikbaar gesteld. Delfland legt van alle elementen uit het raamwerk (“9-vlakjes”) vast wie eigenaar van het element is en op welke wijze dit wordt beheerd. Delfland monitort de ICT dienstverlening en reageert pro-actief op verstoringen. Beheeractiviteiten worden geleverd op basis van vooraf afgesproken Service Level Agreements (SLA). Bij het testen wordt onderscheid gemaakt in verschillende testfasen met elk hun eigen doelen en testers. Indien er sprake is van een situatie waarbij de beschikbaarheid van systemen geheel of grotendeels wegvalt, is er een vaste volgorde waarin de systemen weer worden hersteld. De volgorde van het herstel van de systemen is als volgt; Tijdens een calamiteit 1. Tijdens een calamiteit hebben alle informatiesystemen die nodig zijn voor het oplossen van die calamiteit voorrang. Dit omvat zowel systemen voor de bediening van de infrastructuur als ondersteunende systemen zoals MS Office. Buiten een calamiteit 2. Alle systemen voor de bediening van de infrastructuur. Dit omvat zowel de Technische automatisering als onderliggende infrastructuur zoals het netwerk. 3. Alle systemen die nodig zijn tijdens een calamiteit. Dit omvat zowel informatiesystemen van de primaire processen als kantoorapplicaties zoals Office en Communicatiehulpmiddelen. 4. Overige bedrijfskritische informatiesystemen, zoals GIDS. 5. Alle overige systemen.

3. Vastleggen eigenaar en organisatie van beheer 4. Pro-actief beheer 5. Dienstverlening conform SLA 6. Onderscheid testfasen 7. Voorrangsprotocol bij uitval van systemen

8. Gecombineerde modellen 8.1

Processen – functionaliteiten

In Figuur 16 worden de functionaliteiten afgebeeld op de processen. Het model toont in welke processen welke functionaliteiten worden gebruikt. Functionaliteiten die aan de rand (rechts onder) van de blokken „besturende processen‟ en „primaire processen‟ zijn geplaatst, zijn generieke functionaliteiten en worden door alle in dat blok genoemde processen gebruikt.


pagina 31 van 42


Met behulp van het model kan het volgende duidelijk worden gemaakt: 1. Welke processen welke functionaliteit gebruiken (zodat bijvoorbeeld duidelijk is welke processen geraakt worden als een informatiesysteem die die functionaliteit levert, een verandering ondergaat). 2. Of een beoogde verandering in ondersteuning van de bedrijfsprocessen ingevuld kan worden met reeds bestaande functionaliteit; 3. Waar in het bestaande informatiesysteemlandschap overlap bestaat in functionaliteit of waar juist „witte vlekken‟ te onderkennen zijn.

Besturende processen Besturing Opstellen en actualiseren strategie en organisatiebeleid

Beleid vertalen in maatregelen, activiteiten en middeleninzet

Opstellen jaarlijkse plannen t.a.v. prestaties en resultaten

‘Intern’ beheersen (control)

Relatiebeheer Opbouwen en onderhouden externe relaties

Innovatie Verkennen ontwikkelingen en kansen

Afhandelen van meldingen en klachten


Verantwoorden

Uitvoeren verkennend onderzoek


Relatiebeheer

Workflow management

Planning werkzaamheden


Documentmanagement

Primaire processen Regelgeving Opstellen en beheren legger

Opstellen en actualiseren verordeningen

Planvorming

Opstellen en actualiseren beleidsregels

Opstellen en actualiseren themagerichte plannen

Opstellen en actualiseren gebiedsgerichte plannen

Beïnvloeden, toetsen en anticiperen op plannen van derden

Opstellen en actualiseren waterakkoorden

Opstellen en actualiseren calamiteitenplannen

Opleiden en oefenen

(Water)gebiedsbeheer Ontwerpen

Modelleren

Onderhouden en beheren

Modelleren

Onderhouden en beheren

Meten Bestrijden calamiteit

Waterkeringenbeheer Aanleggen, verwerven, nieuwbouwen





Onderhouden

Beheren

Watersysteembeheer

Bedienen

Onderhouden

Beheren

Afvalwaterzuivering

Bedienen

Beheren

Onderhouden

Vergunningverlening Houden vooroverleg

Toetsen aanvraag

Ontvangen meldingen

Handhaving

Ontvangen en verwerken bedenkingen

Opstellen ontwerpvergunning

Relatiebeheer

Ontvangen meldingen

Calamiteitenbeheersing


Verlenen vergunning

Plannen uitvoeren toezicht

Repressieve handhaving

Ontvangen en verwerken van meldingen WVO



Relatiebeheer

Belastingheffing en invordering Actualiseren basisgegevens

Opleggen aanslagen

Verwerken bezwaren en beroepen

Verwerken verzoeken

Invorderen

Geografische informatieverwerking

Workflow management

Planning werkzaamheden


Documentmanagement

Figuur 16 – Combinatiemodel processen en functionaliteiten


pagina 32 van 42


8.2

Functionaliteiten – objecten

In Figuur 17 zijn de objecten afgebeeld op de functionaliteiten. De figuur geeft weer welke functionaliteit welke objecten beheerd. Dat betekent dat alleen via die functionaliteit de (initiële) vastlegging gebeurt van het object. Een object kan slechts door één functionaliteit worden beheerd. In een aantal gevallen wordt eenzelfde object echter in meerdere functionaliteiten beheerd, bijvoorbeeld Beheerobject. Daarvoor geldt dat een deel van de gegevens van het object door de ene functionaliteit wordt beheerd en een andere deel door een andere functionaliteit. Bijvoorbeeld het beheer van geografische gegevens van een Beheerobject vindt plaats binnen de functionaliteit Geografische Informatieverwerking en het beheer van het ontwerp van het Beheerobject binnen de functonaliteit Ontwerpen.


pagina 33 van 42


Figuur 17 – Combinatiemodel functionaliteiten en objecten


pagina 34 van 42


8.3

Logisch informatiesystemenmodel

Het logisch informatiesystemenmodel geeft aan hoe in de toekomst informatiesystemen gezamenlijk de informatievoorziening van Delfland kunnen invullen. Informatiesystemen zijn een combinatie van gerealiseerde functionaliteiten en beheerde gegevens. De afbakening van informatiesystemen in het logisch informatiesystemenmodel is gebaseerd op de informatieprincipes. De in het model genoemde informatiesystemen zijn logische informatiesystemen in de zin dat ze een „ideale‟ ordening van functionaliteiten en gegevens weergeven. Ideaal betekent hier dat functionaliteiten die dicht bij elkaar liggen qua inhoud en verantwoordelijkheid bij elkaar gegroepeerd zijn. Het logisch informatiesystemenmodel is een eerste stap naar een concreet toekomstig applicatiemodel. Met behulp van het model kan het volgende duidelijk worden gemaakt. 1. Hoe de informatievoorziening van Delfland op effectieve en efficiënte wijze opgedeeld kan worden in een samenhangend geheel van informatiesystemen. Het model geeft de meest gewenste afbakening van informatiesystemen. 2. Voor welke functionaliteit in de toekomst generieke informatiesystemen ingezet kunnen worden. Met generieke informatiesystemen wordt hiermee gedoeld op functionaliteit die veelvuldig voorkomt binnen elk organisatietype, die zonder al te veel maatwerk in de markt te verkrijgen is (uiteraard is de inrichting en de invulling wel Delfland-specifiek). Deze informatiesystemen worden over het algemeen Delflandbreed gebruikt. 3. Voor welke functionaliteit waterschapsspecifieke informatiesystemen nodig zijn. Dit zijn informatiesystemen die mogelijk via Het Waterschapshuis voor alle waterschappen ontwikkeld en beheerd kunnen worden. Dit betreft systemen die over het algemeen niet Delflandbreed gebruikt worden, maar een processpecifieke toepassing kennen. 4. Waar het beheer van gegevens belegd moet worden om eenmalige opslag, meervoudig gebruik te kunnen realiseren. Dit laatste is aangegeven in de tabel op pagina 37 en 38. In Figuur 18 is de informatievoorziening van Delfland geplaatst in de context van relevante informatievoorziening van andere overheidsorganisaties (de context van de NORA). Dit laat zien dat Delfland niet geïsoleerd opereert.


pagina 35 van 42

Delflandse Enterprise Architectuur versie 1.0 Hoogheemraadschap van Delfland frontoffice

generieke informatiesystemen

specifieke informatiesystemen

Portaal (intern)

Meetsysteem Meetsysteem Meetsysteem

Document Management Systeem (DMS)

Asset management / Onderhouds Management Systeem

Geografisch Informatie Systeem (GIS)

Relatiebeheer systeem

Modelleersysteem Modelleersysteem Modelleersysteem

Management Informatie Systeem

Meldingen Systeem

Regel

Beheer actie

Plan

Workflow Management (WFM)

Portaal (extern)

Delflandse gegevens

Modelleersysteem Modelleersysteem Ontwerpsysteem

Beheerobject

Afwijking

Relatie Meting

Modelleersysteem Modelleersysteem Bedieningssysteem

PIOFAH Vergunningverlening & Handhaving

Ondersteunende processen (PIOFAH) Informatie-uitwisseling

Informatie-uitwisseling op sectoraal en landelijk niveau Digikoppeling Landelijke voorzieningen

frontoffice Landelijke portalen Omgevings loket online (OLO)

Sectorale voorzieningen Toekomstige voorzieningen

Digimelding

gegevens binnen de overheid sectorale basisregistraties

ODB

Digilevering

WION Toekomstige voorzieningen Toekomstige portalen

landelijke basisregistraties

GBA

NHR

BAG

BGT

BRK

...

Sectorale organisaties (andere waterschappen) en andere organisaties binnen de overheid (ketenpartners, aanbieders sectorale en landelijke voorzieningen)

Figuur 18 – Logisch informatiesystemenmodel


pagina 36 van 42


Nadere toelichting op het logisch informatiesystemenmodel Figuur 18 kan van boven naar beneden en van links naar rechts gelezen worden. De bovenste helft van de figuur geeft de informatiehuishouding van Delfland weer. De onderste helft geeft de voor Delfland relevante externe overheidsomgeving in de vorm van de informatievoorzieningen van overheidsorganisaties die relevant zijn voor Delfland (landelijke en sectorale voorzieningen), doordat Delfland er gebruik van maakt of er een koppeling mee heeft. Van links naar rechts is een onderscheid gemaakt tussen de informatievoorziening die het onderhouden van contacten met relaties ondersteunt (front office), de informatievoorziening die de interne processen ondersteunt (informatiesystemen) en de voor de informatievoorziening relevante gegevens (gegevens). Als we de informatiehuishouding van Delfland nader bekijken (de bovenste helft van de figuur), dan zien we dat er een aantal informatiesystemen onderscheiden wordt. Een informatiesysteem is een combinatie van bepaalde functionaliteiten die het systeem biedt en bepaalde gegevens die het systeem beheert. In de figuur zijn die gegevens helemaal rechts apart weergegeven. Dit is gedaan om te benadrukken dat, hoewel deze gegevens in een bepaald informatiesysteem beheerd worden, dat wel zo moet gebeuren dat ze toegankelijk en bruikbaar zijn voor andere informatiesystemen (à la het drielagenmodel zoals beschreven in hoofdstuk 2). Het kan voorkomen dat de gegevens over bepaalde objecten, bijvoorbeeld over beheerobjecten of metingen, verdeeld zijn over verschillende informatiesystemen. In dat geval is het echter essentieel dat er: - nauwkeurig wordt afgebakend welk deel van de gegevens in welk informatiesysteem beheerd wordt; - onderlinge afspraken gemaakt worden over de wijze waarop de gegevens worden vastgelegd, zodat ze waar wenselijk aan elkaar gerelateerd kunnen worden. Dat betekent onder andere dat verschillende gegevens over hetzelfde beheerobject die in twee verschillende systemen worden beheerd, eenzelfde identificatie krijgen, zodat duidelijk is dat het over hetzelfde beheerobject gaat. Ook kan het voorkomen dat dezelfde functionaliteit in meerdere informatiesystemen voorkomt. Dit is het geval als de betreffende functionaliteit zo nauw verweven is met andere functionaliteiten in het systeem dat het vanuit praktisch oogpunt niet zinvol is om het los te koppelen. In de informatiesystemen is een onderscheid gemaakt tussen generieke informatiesystemen, die Delfland-breed ingezet kunnen worden, in meerdere processen, en specifieke informatiesystemen die qua inzet doorgaans beperkt zijn tot één proces. Voor de generieke systemen geldt bovendien dat deze gangbare functionaliteit bevat die op de markt goed verkrijgbaar is. Van een aantal specifieke informatiesystemen bestaan in de praktijk meerdere varianten (aangegeven met een aantal rechthoeken achter elkaar). Zo worden meerdere meetsystemen ingezet, afhankelijk van het soort metingen dat uitgevoerd wordt. Wel is het zo dat er onderling afspraken gemaakt dienen te worden over de wijze waarop de meetgegevens worden vastgelegd, zodat deze waar wenselijk gecombineerd kunnen worden ten behoeve van bijvoorbeeld analyses en rapportages. De hiernavolgende tabel geeft globaal de inhoud van de genoemde informatiesystemen weer in de vorm van de functionaliteiten die het bevat en de gegevens die ermee worden beheerd.


pagina 37 van 42


Informatiesysteem

Omschrijving

Meetsysteem

Het verzamelen, valideren en ontsluiten van meetgegevens aan beheerobjecten. Afhankelijk van het soort metingen dat uitgevoerd wordt, kunnen er verschillende meetsystemen gebruikt worden. Wel worden er afspraken gemaakt over de wijze waarop metingen worden vastgelegd. Het opstellen en doorrekenen van modellen. Voor verschillende soorten modellen kunnen verschillende specifiek toegesneden modelleersystemen nodig zijn. Het maken van een ontwerp van een nieuw beheerobject. Voor verschillende soorten beheerobjecten kunnen verschillende specifiek toegesneden ontwerpsystemen nodig zijn. Het automatisch aansturen van beheerobjecten (procesautomatisering). Dit soort systemen ligt zeer dicht aan tegen het object dat aangestuurd wordt en kan daarom per type object verschillen.

Modelleersysteem

Ontwerpsysteem

Bedieningssysteem

Vergunningverlening & Handhaving Portal (intern)

Het ondersteunen van het vergunningsverlenings- en handhavingsproces. Het „toegangsportaal‟ voor de medewerkers van Delfland naar diverse vormen van informatie (Intranet).

Portal (extern)

Workflowmanagement

Het aansturen en bewaken van processen.

Relatiebeheersysteem

Het beheren van de gegevens over relaties van Delfland.

Meldingensysteem

Het beheren (vastleggen en bewaken) van door relaties gedane meldingen. Dit systeem kan wellicht op termijn opgaan in het relatiebeheersysteem in combinatie met workflow. Het beheren (vastleggen en ontsluiten) van het digitale archief van Delfland.

Document Management Systeem


Functionaliteiten

Gegevens

Verzamelen/registreren meetgegevens Valideren meetgegevens Ontsluiten meetgegevens Signaleren afwijking (alarmering

Meting

Modelleren dynamische systemen Modelleren statische systemen

Beheerobject (model)

Ontwerpen beheerobject

Beheerobject (ontwerp)

Aansturen beheerobject Verzamelen/registreren meetgegevens Valideren meetgegevens Ontsluiten meetgegevens Signaleren afwijking (alarmering) Bewaken staat beheerobject Beheren vergunningen Ondersteuning handhaving Planning werkzaamheden Content management Algemene communicatie

Meting Beheerobject

Content management Algemene communicatie Communicatie individuele meldingen Ontvangen informatie van externe partijen Beoordelingsproces Besluitvormingsproces Bewaken status uitvoering (incl. derden) Beheren werkvoorraad Beheren relatiegegevens Vastleggen contact met relaties Aannemen melding In behandeling nemen melding

Creëren document Beheren digitaal archief

Regel (vergunning) Beheeractie

(PIOFAH)

Relatie Afwijking

(PIOFAH) Regel Plan

pagina 38 van 42


Geografisch Informatie Systeem

Het beheren en ontsluiten van geografische informatie.

Asset Management Systeem

Het actief beheren van de assets van Delfland.

Management Informatie Systeem

Het verzamelen, aggregeren, analyseren en rapporteren van gegevens uit verschillende bronnen ten behoeve van strategisch en tactische management. Het ondersteunen van de ondersteunende processen. Nog bekeken moet worden of het verstandig is om de genoemde functionaliteiten inderdaad in één (ERP) systeem op te nemen of om te kiezen voor verschillende systemen.

Ondersteunende systemen


Opbouwen en ontsluiten dynamische geografie Opbouwen en ontsluiten statische geografie Combineren model met geografische data Bewaken staat beheerobject Assetmanagement Planning werkzaamheden Programmamanagement Integreren, aggregeren en rapporteren (complex) analyseren

Beheerobject (geografie)

Middelenbeheer Personeelsmanagement Projectmanagement Verwerken en betalen factuur Planning en control Invorderen Contract- en servicemanagement

(PIOFAH)

Beheerobject Beheeractie (geaggregeerd)

pagina 39 van 42


9. Gebruik van de architectuur Met de eerste versie van de DEA zijn de kaders neergelegd waar de toekomstige informatievoorziening aan dient te voldoen. Daarmee is echter nog niet automatisch geborgd dat Delfland de architectuur inzet bij veranderingstrajecten, om te zorgen dat de gekozen oplossingen voldoen aan deze kaders. Het proces dat hiervoor moet worden ingericht noemen we ‘Werken onder architectuur’, waarbij ook de mogelijkheid moet bestaan om – tijdelijk – te werken zonder architectuur.

9.1

Werken (z)onder architectuur

In onderstaande afbeelding is het architectuurproces werken (z)onder architectuur afgebeeld, volgens de architectuurmethodiek DYA van Sogeti. Dit model laat de keuze zien tussen werken onder architectuur en werken zonder architectuur7.

Figuur 19 – Het architectuurproces volgens DYA

Werken onder architectuur Bij het werken onder architectuur is het van belang dat wijzigingen binnen de informatievoorziening altijd worden getoetst aan de architectuur. Dit wordt bereikt door het procesmatig inbedden van de architectuurtoets bij wijzigingen in de informatievoorziening.

7

Dit model wordt verder bij Defland niet toegepast.


pagina 40 van 42


Voor het meegeven van kaders bij veranderingen dient een onderscheid gemaakt te worden tussen aanvragen, wijzigingen en projecten (doorgaans complexere wijzigingen): - Aanvragen. Dit betreft het leveren van reeds vastgestelde producten en diensten, hiervoor is reeds een architectuurtoets uitgevoerd. - Wijzigingen. Wijzigingen in de informatievoorziening worden getoetst door de AWI (Adviesgroep Wijzigingen Informatievoorziening) waarna besluitvorming plaatsvindt in de Stuurgroep I&A. Het voorstel is de architectuurtoets parallel aan de AWI intake (business case) uit te voeren op basis van een architectuur checklist. De AWI kan vaststellen voor welke wijzigingen de architectuurtoets uitgevoerd dient te worden. - Projecten. Projecten bij Delfland worden uitgevoerd volgens de methodiek “ProjectMatig Werken”. Het ligt voor de hand om het werken onder architectuur te borgen in de methodiek “ProjectMatig Werken”. Dit wordt bereikt door: Het aspect architectuur toe te voegen aan de startnotitie; De deliverable “Project Start Architectuur” (PSA) toe te voegen, op te leveren gelijktijdig met het PID (Project Initiatie Document). De PSA beschrijft de architectuurkaders voor de projectrealisatie en helpen de projectmanager bij het maken van de juiste keuzes. Toevoegen van architectuur toetsmomenten tijdens de ontwerpen realisatiefase, hiermee wordt geborgd dat de afgesproken architectuurkaders juist worden geïmplementeerd. De rol van de Stuurgroep I&A en de AWI hierbij zal nader moeten worden uitgewerkt. Werken zonder architectuur Het werken onder architectuur kan in bepaalde situaties belemmerend zijn bij het onder tijdsdruk doorvoeren van noodzakelijke aanpassingen in de informatievoorziening. In dergelijke situaties is het – na een besluit van de stuurgroep I&A – toegestaan om oplossingen te implementeren buiten de architectuurkaders. Dit is echter altijd onder de voorwaarde dat de oplossing in een later staduim weer onder architectuur wordt gebracht. Het proces werken (z)onder architectuur is in dit document slechts globaal beschreven; dit dient in de praktijk nog verder uitgewerkt en aangevuld te worden.

9.2

Project Start Architectuur

Projecten worden begeleid bij het werken onder architectuur door middel van een Project Start Architectuur (PSA). De PSA is de vertaling van de algemene architectuurprincipes en modellen zoals beschreven in dit document naar projectspecifieke richtlijnen. De enterprise architectuur wordt als het ware toegesneden op het specifieke probleemgebied, zodat de PSA een concreet en doelgericht kader aangeeft waarbinnen het project moet worden uitgevoerd. De PSA wordt aan het begin van het project opgesteld, in samenwerking tussen de architecten en het projectteam. Aanpak voor het opstellen van een PSA Bij het opstellen van een PSA worden de volgende activiteiten uitgevoerd: Bepalen van het probleemgebied en de voorgenomen verandering; Bepalen van geldende architectuurkaders voor het probleemgebied; o Principes (business, informatie en techniek); o Modellen (afbakening probleemgebied); o Bepalen welke objecten, processen en functionaliteiten worden geraakt; o Bepalen of er generieke voorzieningen zijn waarop moet worden aangesloten; Opnemen van de kaders in de PSA en de consequenties delen met het projectteam.


pagina 41 van 42


9.3

Architectuur als stuurinstrument

Architectuur is geen doel op zich, maar dient als stuurinstrument om te komen tot een efficiënte en effectieve informatievoorziening. Om dit daadwerkelijk te kunnen realiseren is het belangrijk om de volgende spelregels te hanteren. Architectuur is een continu proces De architectuur is nooit „af‟. Voortschrijdend inzicht en nieuwe ontwikkelingen kunnen herziening van de keuzen die in de architectuur gemaakt zijn nodig maken. Het is daarom belangrijk actief beheer van de architectuur in te richten. Anders verliest de architectuur op den duur haar waarde. „Just enough, just in time‟-architectuur Er zijn altijd wel aanvullingen op en uitwerkingen van de architectuur te bedenken. Dit kan gemakkelijk leiden tot het maar blijven schaven aan de architectuur in plaats van de architectuur te gaan gebruiken. De voorliggende versie van de DEA bevat al veel mogelijkheden om op te sturen. In het gebruik moet blijken waar nog behoefte is aan verdere uitwerking. Uitbreiding van de architectuur gebeurt dan behoeftegestuurd, waarmee de doelgerichtheid van de architectuur gewaarborgd blijft. „Comply or explain‟ De architectuur is richtinggevend. Dat betekent dat veranderingen moeten plaatsvinden vanuit de architectuurprincipes en modellen. De praktijk is echter weerbarstig en zonder meer voldoen aan de architectuur zal niet altijd gemakkelijk zijn of zelfs onmogelijk blijken. Belangrijk is dat in die gevallen de discussie wordt gevoerd en een weloverwogen afweging wordt gemaakt met betrekking tot eventuele afwijkingen.


pagina 42 van 42

Delflandse Enterprise Architectuur. Versie 1.0

Recommend Documents