agendapunt 3.a.2 925039
Aan College van Dijkgraaf en Hoogheemraden DELFLANDSE ENTERPRISE ARCHITECTUUR Portefeuillehouder Datum Aard bespreking Bijlagen Zaaknummer
Haersma Buma, M.A.P. van 31 januari 2011 Opiniërend 2 21049
Gremia
Datum
Aard
PFO Hae
3-1-2011
B
Advies/ besluit Gewijzigd akkoord
D&H
31-1-2011
B
Gewijzigd akkoord
Parafering Geparafeerd door: Lourens, C.E. Geparafeerd door: Lourens, C.E. Hupkes, A.
Gevraagd besluit College van Dijkgraaf en Hoogheemraden 31-1-2011 1. kennis te nemen van de Delflandse Enterprise Architectuur versie 1.0 2. in te stemmen met het gebruik van de DEA 1.0 voor de inrichting van de informatievoorziening
Besluit College van Dijkgraaf en Hoogheemraden 31-1-2011 Titel van het voorstel wijzigen
Delflandse Enterprise Architectuur
1.
Probleemstelling - context
In februari 2010 heeft de VV het strategisch informatieplan vastgesteld met daarin een aantal ambitieuze doelstellingen voor de ontwikkelingen van de informatievoorziening. In dit plan werd architectuur genoemd als een kritische succesfactor voor het realiseren van de ambities, bijvoorbeeld op het gebied van elektronische dienstverlening en managementinformatie. Voorjaar 2010 is daarom gestart met een traject voor het opstellen van een eerste versie van een architectuur voor Delfland. Sterke groei van ICT toepassingen maar samenhang ontbreekt Door de toenemende mogelijkheden van informatie- en communicatietechnologie (ICT) zijn veel bedrijfsprocessen de afgelopen jaren steeds verder geautomatiseerd. Dit is klein begonnen met het automatiseren van (delen van) administratieve processen, maar is inmiddels volledig doorgedrongen tot alle aspecten van de ondersteunende en primaire processen. Zo worden bijvoorbeeld waterpeilgegevens realtime gemeten en op basis daarvan worden gemalen geautomatiseerd aangestuurd. En burgers kunnen hun klachten/bezwaren digitaal via internet indienen en de legger digitaal inzien op de website van Delfland. Dergelijke ICT-projecten zijn vaak ingevuld vanuit de behoefte van een individueel proces, zonder dat daarbij voldoende is gekeken naar de samenhang tussen de ICT oplossingen binnen Delfland als geheel (dit wordt ook wel „eilandautomatisering‟ genoemd). Als gevolg hiervan heeft Delfland nu een veelheid aan informatiesystemen, databases en andere gegevensverzamelingen, systeemkoppelingen en rapportages. Zo hebben we verschillende meetsystemen die allemaal op een net iets andere manier actuele informatie uit het veld verzamelen, verwerken en presenteren. Ook liggen bepaalde gegevens, zoals gegevens van burgers en bedrijven en personeelsgegevens, op meerdere plekken vast. Daarnaast worden ook door de maatschappij steeds hogere eisen gesteld aan de manier waarop binnen de overheid wordt samengewerkt, waardoor het steeds belangrijker wordt om ook over de organisatiegrenzen heen met elkaar samen te werken. Burgers en bedrijven willen hun gegevens eenmalig verstrekken en verwachten dat die vervolgens binnen de gehele overheid worden gebruikt (authentieke basisregistraties). En bij de omgevingsvergunning moeten gemeenten, waterschappen en provincies samenwerken bij het verstrekken van een vergunning. Deze ontwikkelingen hebben ook grote gevolgen voor de informatievoorziening en ICT bij Delfland. Architectuur zorgt voor structuur en samenhang Bovenstaande problematiek is niet uniek voor Delfland maar speelt in vrijwel alle organisaties. Binnen het ICT vakgebied is daarom het begrip „Architectuur‟ geïntroduceerd om deze problematiek aan te pakken. Een architectuur van een organisatie bestaat uit modellen van de huidige en de gewenste situatie, in combinatie met een set van afspraken hoe we van de huidige naar de gewenste situatie willen komen (de zogenaamde architectuurprincipes). Dit is vergelijkbaar met de rol van architectuur bij de verbouwing van een bestaand gebouw: er worden bouwtekeningen gemaakt van de bestaande en gewenste situatie en afspraken/randvoorwaarden voor de realisatie (bijv. veel glas, duurzame materialen etc).
Architectuur bij Delfland: hulpmiddel bij de verdere ontwikkeling van de ICT. Afgelopen zomer is binnen Delfland hard gewerkt aan het opstellen van een eerste versie van een Delflandse Enterprise Architectuur (DEA). Hierbij is in een aantal workshops input ingewonnen bij betrokkenen uit de hele organisatie en is uiteraard ook gebruik gemaakt van bestaande strategische documenten binnen Delfland (WBP, kadernota) en daarbuiten (bijv. de Nederlandse Overheid Referentie Architectuur). Het resultaat van dit proces is de bijgevoegde versie van de DEA 1.0 bestaande uit modellen en principes op verschillende lagen (zie ook onder 12. Toelichting). Met deze architectuur heeft Delfland een belangrijk hulpmiddel in handen om te toetsen of nieuwe initiatieven passen binnen de gewenste ontwikkelrichting. Ook kunnen met de architectuur gebieden worden geïdentificeerd waar bepaalde applicaties en/of functionaliteit geïntegreerd kunnen worden. De architectuur zal vooral worden gebruikt als uitgangspunt en kader door de adviseurs en beslissers op het I&A domein. Het effect hiervan raakt de gehele organisatie; zowel de primaire als de ondersteunende processen. Concernbrede samenhang en standaardisatie betekenen immers dat de organisatie binnen de kaders van de architectuur moet opereren en geen volledige vrijheid heeft bij de I&A keuzes die binnen de processen worden gemaakt. Het gebruik van DEA zal daarom een verplicht onderdeel worden van alle business cases op I&A gebied en vormt tevens het vertrekpunt voor de roadmap applicatiereductie. NB. De architectuur is dus voorwaarde voor concernsturing en standaardisatie van de informatievoorziening. Voor de duidelijkheid; de enterprise architectuur zelf lost de problemen niet op, maar biedt wel het benodigde inzicht in en kader voor de informatievoorziening om onderbouwde beslissingen te kunnen nemen.
2.
Beoogd effect
De beoogde effecten van het opstellen van een enterprise architectuur voor Delfland zijn te vinden in de volgende perspectieven; Architectuur draagt bij aan het realiseren van een goed ingerichte informatievoorziening, die is toegesneden op de bedrijfsprocessen, geen overbodige onderdelen bevat en die voldoende flexibel is om met veranderingen om te kunnen gaan. Architectuur draagt bij aan het aan het realiseren van de doelstellingen van het strategisch informatieplan zoals e-dienstverlening, externe integratie en managementinformatie. Architectuur maakt de samenhang tussen processen, gegevens en applicaties en de mogelijke overlap inzichtelijk en vormt daarmee het startpunt voor meer standaardisatie en het verminderen van het aantal applicaties. Architectuur draagt bij aan professionelere sturing op de informatievoorziening, zowel vanuit het concernperspectief als vanuit de individuele sectoren. Architectuur draagt dus bij aan bijvoorbeeld de volgende doelstellingen;
Bedrijfsgegevens worden slechts op één plek opgeslagen en beheerd; Standaardisatie en het verminderen van het aantal applicaties; Het uitwisselen van gegevens met andere overheden gebeurt eenvoudig en efficiënt (gemeenten, Rijkswaterstaat, etc.); Geïntegreerde managementinformatie1 is beschikbaar; Het optimaliseren van het gebruik van informatiesystemen binnen bedrijfsprocessen; Het flexibel kunnen inspelen op veranderende omstandigheden zoals nieuwe wetgeving.
1
Hiermee bedoelen we stuurinformatie die is samengesteld vanuit meerdere informatiesystemen en/of bedrijfsprocessen.
2
3.
Kernboodschap
Na vaststelling wordt de DEA gebruikt als kader voor de ontwikkeling van de informatievoorziening. Hiermee wordt een belangrijke stap gezet op het gebied van concernbrede sturing en planmatige inrichting van de informatievoorziening. Conclusies In het architectuurtraject hebben we de huidige situatie geanalyseerd en de gewenste toekomstige situatie besproken met diverse belanghebbenden. De conclusies zijn samen te vatten in een beweging die we met het architectuurtraject in gang willen zetten (zie afbeelding op de volgende pagina en verder onder 12. Toelichting). Van
Naar
1. Werken op papier
Digitaal werken
2. Dubbele gegevensopslag
Gegevens eenduidig enkelvoudig opslaan
3. Schaduwadministraties
Optimaal gebruik van applicaties
4. Losse rapportages
Geïntegreerde management informatie
5. Intern gericht
Koppeling met externe partijen
6. Probleempje-systeempje
Hergebruik van functionaliteiten
7. Eilandautomatisering
Standaardisatie en integratie
8. Gesloten standaarden en software
Open standaarden en software
9. Melden wijzigingen achteraf
Vooraf betrekken bij besluitvorming
Aanbevelingen Vanuit het architectuurtraject worden de volgende aanbevelingen gedaan voor het vervolgtraject (zie ook Hoofdstuk 12. Toelichting):
- Inbedden van de architectuur in de organisatie en de manier van werken; - Verder uitwerken van de Business architectuur; - Verder verdiepen en uitwerken van de informatie architectuur, voor geconstateerde knelpunten bij bepaalde applicaties en gegevens.
4.
Historie - eerdere besluitvorming Op 4 februari 2010 is het strategisch informatieplan vastgesteld door de VV. Op 19 maart 2010 heeft de stuurgroep I&A besloten tot het starten van een architectuurtraject, met als doel het opstellen van een eerste versie van een enterprise architectuur door Delfland. Het DMT heeft de DEA 1.0 op 27 oktober 2010 besproken en de directie heeft de DEA 1.0 op 2 november 2010 vastgesteld. De DEA 1.0 is op 8 november behandeld in het College van D&H en aangehouden met de volgende opmerkingen: “Het college neemt kennis van het voorstel. Het college is op dit moment niet in staat in te stemmen met de voorgestelde conclusies en de aanbevelingen over te nemen. De secretaris wordt verzocht op korte termijn te komen met de bestuurlijke beslispunten van aanbevelingen en conclusies en deze aan het college voor te leggen, plus een betere aansluiting van de beslispunten met achterliggende teksten.”
3
5.
Beleid
De architectuur vormt samen met het strategisch informatieplan het I&A beleid van Delfland. 6.
Financiën
Het vaststellen van de Delflandse Enterprise Architectuur heeft geen directe financiële consequenties. Op termijn draagt de architectuur bij aan kostenbeheersing op het I&A domein, omdat meer rendement wordt gehaald op het gebied van informatievoorziening en technische infrastructuur voor hetzelfde geld. 7.
Organisatorische en personele consequenties
Gezien de drukte rondom het implementatieplan kadernota is gekozen voor een aanpak waarbij het beslag op de capaciteit binnen Delfland minimaal was. De volgende mensen zijn betrokken bij de totstandkoming van de architectuur; Stuurgroep: stuurgroep I&A Projectgroep: vertegenwoordigers uit team IGIS en ICT-services, aangevuld met externe expertise Werkgroep I&A: brede vertegenwoordiging uit het I&A-domein van de organisatie, te weten; functioneel beheerders uit de sectoren, senior adviseurs IGIS, ICT-services, DIV, Concerncontrol, KAM Na vaststelling zal de architectuur worden gebruikt voor het vormgeven en beoordelen van initiatieven op het gebied van informatievoorziening. Daarmee heeft de architectuur dus consequenties voor heel Delfland, maar het zijn vooral de mensen in het I&A domein die ermee zullen gaan werken en de integraal managers zullen helpen bij het inrichten van de informatievoorziening voor hun processen binnen de kaders van de architectuur. 8.
OR/GO
n.v.t. 9.
Risico- en beheersmaatregelen
Commitment Architectuur is alleen effectief als het management en bestuur erachter staan en dit uitdragen. Om slagvaardig tot een (inhoudelijke) uitwerking te komen is gekozen voor een combinatie van de stuurgroep I&A en een werkgroep I&A. Door periodieke terugmelding van tussenresultaten naar het DMT, directie en het PFO van de dijkgraaf, zijn DMT en bestuur meegenomen in het traject van de totstandkoming van de architectuur. Ook na vaststelling blijft het essentieel dat de I&A adviseurs alle betrokkenen meenemen in het werken met de architectuur.
10.
Communicatie (in- en extern)
DMT en directie worden geïnformeerd via het DMT-overleg. Het bestuur wordt geïnformeerd via het PFO van de dijkgraaf. Na vaststelling zal de architectuur via intranet beschikbaar worden gesteld en via overleggen worden gecommuniceerd naar alle teamleiders en andere belanghebbenden. Voor het communiceren van de architectuur naar de organisatie – op een begrijpelijke en toepasbare manier – wordt met team Communicatie afgestemd. Extern is er ook interesse vanuit andere waterschappen en Het Waterschapshuis voor onze pragmatische aanpak van het architectuurtraject.
4
11.
Bevoegd orgaan
Ambtelijke vaststelling vindt plaats door de directie, na bespreking in het DMT. Bestuurlijke vaststelling vindt plaats in het College van D&H.
12.
Toelichting
Aanpak van het DEA 1.0 traject De Delflandse Enterprise Architectuur (DEA)2 bevat de volgende onderdelen:
-
modellen van de huidige situatie, waarin de structuur van en de samenhang binnen de huidige informatievoorziening inzichtelijk wordt gemaakt; modellen van de gewenste situatie, waarin de structuur van en de samenhang binnen de gewenste, toekomstige informatievoorziening wordt geschetst; ‘principes’ 3, die richting geven aan de ontwikkeling van de informatievoorziening, zodat naar de gewenste situatie kan worden toegewerkt (zie pagina 6 en 7 voor een overzicht van de in de DEA gedefinieerde principes op de verschillende niveaus).
De scope van de opdracht was om een eerste versie van de Delflandse Enterprise Architectuur op te leveren. Hierbij is het niet het streven om volledig te zijn of zaken in detail uit te werken, maar de elementen die worden opgenomen moeten wel correct zijn. In een vervolgtraject zullen onderdelen van de architectuur in meer detail worden uitgewerkt. Voor het ordenen van de diverse architectuurproducten wordt het raamwerk van de NORA (Nederlandse Overheids Referentie Architectuur) gebruikt, zoals in de afbeelding hieronder is weergegeven. Zie voor aanvullende informatie ook Bijlage 1 – Applicatie Inventarisatie.
DEA 1.0: Architectuur-principes en modellen Principes zijn in het document DEA 1.0 uitgewerkt in de vorm van strategische uitgangspunten, algemene principes, business principes en informatie principes. Bij alle principes wordt de rationale vastgelegd (waarom vinden we dit als Delfland belangrijk) en worden de consequenties uitgewerkt (wat betekent het als we dit principe consequent hanteren). Zie voor een globaal overzicht de tabel op de volgende pagina‟s.
2
Met het woord ‘enterprise’ wordt hier bedoeld dat de architectuur betrekking heeft op de informatievoorziening van de hele organisatie. 3 In de literatuur wordt ook wel over „architectuurprincipes’ of ‘ontwerpprincipes’ gesproken.
5
Strategische uitgangspunten Schoon water
Voldoende water
Stevige dijken
Gezuiverd afvalwater
Instrumentarium
Professionele organisatie, autoriteit op watergebied
Algemene principes Delfland is een uitvoeringsorganisatie met een wettelijke taak Effectgericht
Gebiedsgericht
Marktgericht
Operational Excellence
Standaardisatie
Flexibiliteit
Koppeling inhoud en geld
Samenwerking
Innovatief
Klantgericht
Transparantie
Duurzaamheid
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
Producten en diensten 1. BBP-structuur 2. Eenduidige producten en diensten 3. Digitale kanalen
Processen 1. 24x7 inrichting van primaire processen 2. Digitale processen 3. Klant heeft inzicht in status 4. WIA (Waterschaps Informatie Architectuur) processen als uitgangspunt 5. Procesbesturing met KPI‟s (Key Performance Indicators)
Informatie principes
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 van applicaties 10. Procesondersteuning door workflow 11. Software maakt gebruik van open standaarden 12. Afbakening functionaliteiten 13. Gebruik van mobiele apparaten 14. Rekening houden met software en gegevens bij aanschaf van hardware
Gegevens en berichten 1. Heldere verantwoordelijkhede n 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
Informatie-uitwisseling 1. Gegevensuitwisseling volgens open standaarden 2. Gegevensleveringsovereenkomsten 3. Automatische gegevensuitwisseling 4. Doelgericht gebruik services
6
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 (Main /Sub Equipment Rooms) 8. Green IT 9. Anytime, anywhere 10. Sector standaarden 11. Gestandaardiseerde infrastructuur 12. Single Sign On 13. Gescheiden omgevingen voor innovatie
Gegevensopslag 1. Scheiding rekenkracht en dataopslag 2. Eenmalig opslaan van gegevens
Beveiligingsen beheerprincipes
Beveiliging 1. Voldoen aan de Code voor Informatiebeveiliging
Beheer 1. Beheer volgens standaarden 2. Scheiding van testen productieomgevingen 3. Vastleggen eigenaar en organisatie van beheer 4. Pro-actief beheer 5. Dienstverlening conform SLA (Service Level Agreement) 6. Onderscheid testfasen 7. Voorrangsprotocol bij uitval van systemen
Netwerk 1. Eén gezamenlijk Netwerk voor Kantoorautomatisering en Technische Automatisering 2. Eén routeringsprotocol
N.B. Dit document bevat de principes, zoals die uit de gesprekken en de analyse van de strategische documenten naar voren zijn gekomen. In een volgende versie van de architectuur zullen deze principes verder worden uitgewerkt en aangevuld. Deze lijst is een momentopname van de zomer van 2010 en is dus geen statische lijst. Zo zijn er al ideeën geopperd over bijvoorbeeld zaakgericht werken en over de mate van samenwerking met de andere waterschappen op ICT-gebied. Als in strategische documenten heldere keuzes worden gemaakt worden deze als principe toegevoegd in een nieuwe versie van de DEA. In de DEA zijn de volgende modellen opgenomen:
-
Procesmodel; Objectenmodel (gegevens); Functionaliteitenmodel; Technisch model.
7
Op basis van deze basismodellen is bovendien een aantal gecombineerde modellen opgesteld, die de relaties tussen de verschillende aspecten weergeven:
- Processen – functionaliteiten; - Functionaliteiten – objecten. In Bijlage 1 – Applicatie Inventarisatie (apart document) zijn ook nog 2 modellen opgenomen waarin de geïnventariseerde applicaties afgebeeld zijn op het procesmodel en het objectenmodel. Conclusies architectuurtraject In het architectuurtraject hebben we de huidige situatie geanalyseerd en de gewenste toekomstige situatie besproken met diverse belanghebbenden. De conclusies zijn samen te vatten in een beweging die we met het architectuurtraject in gang willen zetten (zie volgende pagina). Van
Naar
1. Werken op papier
Digitaal werken
2. Dubbele gegevensopslag
Gegevens eenduidig enkelvoudig opslaan
3. Schaduwadministraties
Optimaal gebruik van applicaties
4. Losse rapportages
Geïntegreerde management informatie
5. Intern gericht
Koppeling met externe partijen
6. Probleempje-systeempje
Hergebruik van functionaliteiten
7. Eilandautomatisering
Standaardisatie en integratie
8. Gesloten standaarden en software
Open standaarden en software
9. Melden wijzigingen achteraf
Vooraf betrekken bij besluitvorming
1. Werken op papier Er gebeurt nog heel veel op papier, terwijl binnen de overheid wordt gestreefd naar zoveel mogelijk digitaal werken. Digitaal werken betekent onder meer dat processen worden ondersteund door workflow en de beschikking hebben over een toegankelijk en geordend digitaal archief. Een randvoorwaarde hierbij is dat medewerkers ook de beschikking hebben over digitale hulpmiddelen, bijvoorbeeld voor het beheren van het digitale archief en het ontsluiten van digitale (post)stukken. 2. Gegevens worden op meerdere plekken en niet eenduidig opgeslagen Op dit moment worden gegevens meestal opgeslagen bij de applicatie die ze gebruikt, waardoor er meerdere “gegevensbakjes” ontstaan met dezelfde typen gegevens. Gevolg hiervan is dat gegevens op meerdere plekken beheerd moeten worden waardoor verschillen ontstaan en dat het uitwisselen of combineren van deze gegevens wordt daardoor lastiger dan nodig is. Voorbeelden hiervan zijn meetgegevens, relatiegegevens, personeelsgegevens, geografische gegevens en ook de verschillende typen modellen. 3. Schaduwadministraties Omdat de gegevens in systemen niet altijd als betrouwbaar worden ervaren, zijn op diverse plekken in de organisatie schaduwadministraties ontstaan. Voorbeelden hiervan zijn eigen financiële Excel overzichten. Dit belemmert een goed en eenduidig beheer van deze gegevens en het kost de organisatie bovendien veel tijd om de juiste en actuele gegevens te vinden.
8
4. Geen geïntegreerde managementinformatie Sommige applicaties binnen Delfland hebben wel rapportagefunctionaliteit, maar dit is nog erg summier en beperkt. Het kost over het algemeen veel tijd om rapportages te maken en gegevens combineren is handwerk. Geïntegreerde managementinformatie uit meerdere bronnen ontbreekt nog. Qua vorm beperken rapportages zich op dit moment tot platte, cijfermatige overzichten. Er zijn geen management dashboards. 5. Weinig externe koppelingen De informatievoorziening van Delfland is nog steeds erg intern gericht. Nu de behoefte om te koppelen met externe partijen toeneemt, moet de informatievoorziening in staat zijn om informatie uit te wisselen op basis van (open) standaarden. Dit betekent ook dat er hogere eisen worden gesteld aan de kwaliteit van de gegevens. Ook is het belangrijk om de klanten een veel centralere positie te geven in de dienstverlening van Delfland en dus ook in de architectuur. De huidige processen en BBP-producten zijn nog veelal vanuit de waterschapstaak geformuleerd en minder vanuit de klant. Ook standaarden binnen de Waterschapswereld en standaarden binnen de Nederlandse overheid worden steeds belangrijker omdat Delfland steeds meer moet acteren als onderdeel van de elektronische overheid. Hiervoor is informatie-uitwisseling met andere overheden zoals gemeenten en met basisregistraties essentieel. 6. Overlap in applicaties Er is in de huidige situatie sprake van overlappende functionaliteit in applicaties. Dat komt doordat in het verleden vaak voor elk probleem een systeem werd gezocht dat alles kan oplossen (het “probleempje-systeempje” syndroom). Hierdoor werd niet gekeken of het mogelijk was om voor onderdelen van het probleem bestaande functionaliteit her te gebruiken. 7. Eenduidigheid in het systemenlandschap In navolging van het vorige punt zien we dat in sommige gevallen per gebied (of afdeling) is gekozen voor een bepaalde oplossing die afwijkt van de rest van Delfland. Deze oplossing is vaak vanuit de lokale blik bepaald, zonder daarbij rekening te houden met impliciete of expliciete standaarden binnen Delfland. Voorbeeld hiervan is de recentelijk geïnstalleerde Keller software voor droogtemetingen. 8. Open standaarden en software De Nederlandse overheid bevordert het gebruik van open standaarden en open source software. Het gebruik van open standaarden maakt het uitwisselen van gegevens tussen systemen en organisaties eenvoudiger („interoperabiliteit‟), omdat iedereen dezelfde “taal” spreekt. Een voorbeeld van een open standaard is het StUF-formaat, voor de uitwisseling van WOZ-gegevens met gemeenten. Het gebruik van open source software vermindert leveranciersafhankelijkheid en bevordert concurrentie op de softwaremarkt. Een voorbeeld van open source software is Open Office, als tegenhanger van Microsoft Office. Delfland zal zich steeds meer richten op de inzet van open standaarden en open source software. 9. Architectuur vooraf in het wijzigingsproces betrekken In de huidige situatie gebeurt het vaak dat eerst een nieuw pakket wordt aangeschaft en dan pas wordt bepaald of en hoe het past. Met de DEA hebben we een hulpmiddel in handen waarmee we vooraf al kaders en richtlijnen mee kunnen geven bij vernieuwing van hard- en software. Het is belangrijk dat dit procesmatig in de organisatie wordt geborgd. Pas dan hebben we echt profijt van de architectuur.
9
Hoe gaat architectuur bij deze beweging helpen? De architectuur draagt op de volgende manieren bij aan deze beweging:
Het bieden van handvatten voor strategische keuzes in de informatievoorziening, als verdiepingsslag van het strategisch informatieplan; Het bevorderen van het denken in functionaliteiten in plaats van ‘probleempje-systeempje’; De architectuur biedt concrete richtlijnen aan projecten (vertaling van bovengenoemde beweging); Het leveren van richtlijnen voor het centraal opslaan en beheren van gegevens, gekoppeld aan meervoudig gebruik. Vervolgtraject De Delflandse Enterprise Architectuur schetst een gewenste situatie voor de lange termijn. De volgende fase is om de architectuur stapsgewijs werkelijkheid te laten worden. In het vierde kwartaal van 2010 is gestart met het opstellen van een „roadmap‟ voor een eerste opschoning van het applicatielandschap. Hiermee wordt een start gemaakt met de invulling van centrale regie op informatievoorziening zoals is beschreven in het strategisch informatieplan 20102015. In de loop 2011 zal hieraan verder invulling worden gegeven. Aanbevelingen architectuurtraject
1. Inbedden van de architectuur in de organisatie en de manier van werken Opnemen van architectuur in projectmatig werken (Project Start Architectuur). Een architectuurtoets uitvoeren, ook bij ‘kleine’ wijzigingen. Bijhouden van afwijkingen op de architectuur en periodiek herzien. Opleiden van integraal managers op het gebied van informatiemanagement en architectuur. Opleiden van strategisch adviseurs, senior adviseurs en functioneel beheerders op het gebied van architectuur. 2. Verder uitwerken van de Business architectuur Architectuur breder inzetten dan alleen I&A: ook business architecten aanwijzen en de business architectuur verder verdiepen. De architectuur uitwerken voor de ondersteunende bedrijfsprocessen. 3. Verder verdiepen en uitwerken van de informatie architectuur, voor geconstateerde knelpunten bij bepaalde applicaties en gegevens Keuzes maken voor strategische applicaties. Definiëren van begrippen/objecten in samenwerking met materiedeskundigen. Verder analyseren van de volgende applicatieclusters: o Applicaties die meetgegevens vastleggen (meetsystemen); o applicaties binnen de ondersteunende processen (losse applicaties vs. ERP); o Applicaties waarin alleen referentiedata vastligt (zijn deze ook in de vorm van onlinewebservices of in de ‘cloud’ beschikbaar?); o Applicaties die workflow-functionaliteit bevatten (wellicht introduceren van een generieke applicatie voor workflow); o Applicaties die modellen genereren of bewerken, inclusief de toepassing van de modellen binnen Delfland (hier zijn raakvlakken met de visie op het Geïntegreerd BOS en het onderzoeksproject 3Di). Verder analyseren van de volgende gegevensclusters (inclusief taxonomie): o Relatiegegevens; o Meetgegevens. Verder uitwerken van de centrale positie van klanten in de dienstverlening van Delfland: o Opstellen producten- en dienstencatalogus; o Producten en diensten vertalen naar onderliggende informatieproducten. 10
