ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

Transcriptie

1 Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum :

2 Versiebeheer Versie Datum Status Door Opmerkingen Definitief John van Eck Vastgestelde versie MT-ICT Dordrecht Definitief John van Eck Versie PMO programma IP & A Drechtsteden Distributie Versie Datum Naam Functie Bedrijf Programmamanagers en architecten programma IP&A Drechtsteden Goedkeuring Versie Datum Naam Functie Status PMO programma IP&A vastgesteld Drechtsteden 2

3 Inhoudsopgave 1 Inleiding Doelstelling van dit document Uitgangspunten Vormen van beheer Belegging van de drie vormen van beheer bij de Drechtsteden Functioneel beheer Technisch beheer Applicatiebeheer Fysieke toegang tot apparatuur, programmatuur en gegevens in relatie tot de drie vormen van beheer Fysieke toegang tot apparatuur en programmatuur van informatiesystemen in relatie tot de drie vormen van beheer Fysieke toegang tot gegevens die opgeslagen zijn binnen gegevensbanken (databases) van informatiesystemen in relatie tot de drie vormen van beheer Batchverwerkingen Ontwikkelafspraken Project Start Architectuur (PSA) Opleverprocedure

4 1 Inleiding Binnen de organisaties die deelnemen aan het Servicecentrum Drechtsteden draait een groot aantal informatiesystemen welke ondersteuning bieden aan de bedrijfsprocessen van deze organisaties zowel als de bedrijfsprocessen van het Servicecentrum Drechtsteden zelf. De levenscyclus van een informatiesysteem loopt vanaf het moment dat vanuit het informatiebeleid besloten wordt tot ontwikkeling van een informatiesysteem tot het moment dat het informatiesysteem wordt uitgefaseerd. Binnen deze levenscyclus zijn verschillende toestanden (zie bijlage 1) van het informatiesysteem te onderkennen, waarbinnen verschillende beheertaken dienen te worden uitgevoerd. Bij de organisaties die deelnemen aan het Servicectrum Drechtsteden zijn verschillende organisatieonderdelen en externe partijen betrokken bij de uitvoering van dit beheer. Binnen de Drechtsteden was (tot dit document) er ten aanzien van het beheer informatiesystemen echter geen eenduidig beheermodel vastgelegd, waarin het beheer rondom informatiesystemen beschreven staat en waaraan de taken, verantwoordelijkheden en bevoegdheden (TVBs) van de verschillende organisatieonderdelen, externe partijen en personen gerelateerd kunnen worden. In de beheerpraktijk leverde dit veel onduidelijkheden en discussies op over wie wat mag t.a.v. informatiesystemen, vooral over rechten binnen, toegang tot informatiesystemen en eigen ontwikkeling van informatiesystemen. Daarnaast zijn er nog een aantal ontwikkelingen op basis waarvan het noodzakelijk is geworden om goede afspraken te maken en duidelijkheid te creëren omtrent de TVBs van het beheer van informatiesystemen. Dit zijn o.a.: - Toenemende integratie van informatiesystemen binnen de Drechtsteden en met informatiesystemen van externe partijen. - Ontwikkelingen t.a.v. informatiearchitectuur van de Drechtsteden, zoals o.a. het principe van eenmalige registratie, meervoudig gebruik van gegevens, rol Frontoffice en MidOffice t.o.v. de backoffice, ontwikkeling Mozaiek, enz. - Toenemende focus op Informatiebeveiliging en rechtmatigheid (o.a. invoering changemanagement, OTAP, functiescheiding, enz.). - Toegenomen ontwikkeling van informatiesystemen in eigen beheer van de Drechtsteden (o.a. in het kader van E-government en Sociale Dienst). - Professionalisering ICT - Overheveling van beheertaken van de organisaties naar het Servicecentrum Drechtsteden. 2 Doelstelling van dit document Het doel van dit document is om het beheermodel op hoofdlijnen voor het beheer van informatiesystemen bij de Drechtsteden vast te leggen. In eerste instantie wordt niet gestreefd naar beschrijving van een volledig beheermodel, maar wordt een aanpak gehanteerd waarbij steeds de op dat moment relevante onderwerpen worden toegevoegd aan het document. Op deze manier zal dit document op termijn uitgroeien tot een volledig beheermodel Informatiesystemen Drechtsteden. Verder wordt gestreefd naar een zo n praktisch mogelijke beschrijving van de relevante onderwerpen. 3 Uitgangspunten De baseline Informatiebeveiliging geldt als uitgangspunt. Als referentiemodel bij het opstellen van dit document is gebruik gemaakt van het boek beheer informatiesystemen van Prof. dr. ir. M. Looijen. 4 Vormen van beheer Looijen onderscheidt drie vormen van beheer binnen het beheer van informatiesystemen, dit zijn functioneel beheer, applicatiebeheer en technisch beheer. Waarbij de volgende globale omschrijving van de verantwoordelijkheid van deze drie vormen van beheer door Looijen wordt gegeven: - Functioneel beheer is verantwoordelijk voor de instandhouding van de functionaliteit van het informatiesysteem. 4

5 - Applicatie beheer is verantwoordelijk voor de instandhouding van de applicatieprogrammatuur 1 en de gegevensbanken. - Technisch beheer is verantwoordelijk voor de instandhouding van de operationalisering van het informatiesysteem, bestaande uit apparatuur, programmatuur en gegevensverzamelingen die vanuit het gebruik continu beschikbaar moeten zijn. 5 Belegging van de drie vormen van beheer in de Drechtsteden 5.1 Functioneel beheer De eigenaar van het informatiesysteem is binnen de Drechtsteden verantwoordelijk voor het beleggen van het functioneel beheer van het informatiesysteem. Normaal gesproken zal dit een persoon of personen zijn die werkzaam zijn bij het (de) organisatieonderde(e)l(en) waarvoor het informatiesysteem bedrijfsprocessen ondersteunt. Dit ligt in de lijn met de huidige praktijk. 5.2 Technisch beheer Het technisch beheer van informatiesystemen wordt exclusief belegd bij de serviceeenheid Netwerken computerbeheer van het Servicecentrum Drechtsteden of een externe partij (hier gelden aparte beleidsregels voor). Momenteel geldt voor alle organisatieonderdelen van de Drechtsteden gedwongen winkelnering ten aanzien van de afname van de diensten van Technisch beheer van de serviceeenheid Netwerk- en computerbeheer van het Servicecentrum Drechtsteden. Geen enkel ander organisatieonderdeel van de Drechtsteden is bevoegd om taken die tot het technisch beheer behoren, te verrichten. 5.3 Applicatiebeheer Binnen applicatiebeheer wordt door de Drechtsteden onderscheid gemaakt tussen applicatieonderhoud 2 en technisch applicatiebeheer. Het applicatieonderhoud richt zich op het onderhoud 3 van applicatieprogrammatuur en gegevensbanken. Het technisch applicatiebeheer richt zich op de daadwerkelijke implementatie van de nieuwe of gewijzigde applicatieprogrammatuur en gegevensbanken. Applicatieonderhoud vindt binnen het OTAP-model plaats in de ontwikkel- en testomgeving. Voor deze laatste omgeving geldt dat deze dan specifiek ter ondersteuning van het applicatieonderhoud ingericht dient te zijn (o.a. testen opleverscripts, testen programmatuur, enz.), zie ook bijlage 2. Het applicatieonderhoud is normaal gesproken belegd bij een externe partij, de applicatieleverancier. In geval van applicatieonderhoud, in eigen beheer, van de Drechtsteden kan het applicatieonderhoud belegd zijn bij een organisatieonderdeel of binnen een projectorganisatie van de Drechtsteden. Functioneel beheer en Technisch beheer stellen eisen en randvoorwaarden t.a.v. het applicatieonderhoud en de oplevering van nieuwe of gewijzigde applicatieprogrammatuur en/of gegevensbanken. Aan de eisen en randvoorwaarden van technisch beheer zal voldaan moeten worden om tot in productiename van de wijziging of nieuwe functionaliteit over te gaan. Technisch applicatiebeheer is belegd bij de afdeling Informatisering/ICT. Over de invulling van applicatiebeheer zijn momenteel de meeste onduidelijkheden in de organisatie. Dit beheermodel heeft dan ook als belangrijk doel om ten aanzien van de TVBs van het applicatiebeheer duidelijkheid te scheppen. 1 Onder applicatieprogrammatuur wordt verstaan alle programmatuur anders dan basisprogrammatuur (o.a. besturingssystemen), databasemanagementprogrammatuur, web- en applicatieserverprogrammatuur en programmatuurmiddelen. 2 Onder applicatieonderhoud valt zowel nieuwe ontwikkeling van applicatieprogrammatuur en gegevensbanken als aanpassing van bestaande applicatieprogrammatuur en gegevensbanken (wijzigingen). 3 Onder onderhoud vallen zowel wijzigingen als nieuwe ontwikkelingen. 5

6 6 Fysieke toegang tot apparatuur, programmatuur en gegevens in relatie tot de drie vormen van beheer 6.1 Fysieke toegang tot apparatuur en programmatuur van informatiesystemen in relatie tot de drie vormen van beheer Voor het beschrijven van toegangsrechten dient onderscheid gemaakt te worden in toegang tot apparatuur en programmatuur aan de ene kant en gegevens aan de andere kant. Deze paragraaf beschrijft de toegang tot apparatuur en programmatuur en de volgende paragraaf beschrijft de toegang tot de gegevens. Voor toegang t.b.v. het beheer van informatiesystemen tot apparatuur, programmatuur en gegevens van informatiesystemen (en ICT infrastructuur) wordt het principe gehanteerd van alleen toegang indien nodig vanuit de uit te voeren beheertaak. Hieruit volgt dat voor functioneel beheer er geen fysieke toegang is tot de apparatuur of programmatuur van informatiesystemen in geen van de OTAP omgevingen. Functioneel beheerders maken alleen via de functionaliteit van het informatiesysteem gebruik van dat informatiesysteem, met uitzondering van de toegang tot gegevens (zie volgende paragraaf). Applicatiebeheer in de vorm van applicatieonderhoud heeft alleen fysieke toegang tot de applicatieprogrammatuur in een ontwikkelomgeving (en eventueel een testomgeving, zie onder de vorm beheer applicatiebeheer), over de precies benodigde rechten op de ontwikkelomgeving voor applicatieonderhoud worden afspraken gemaakt met technisch beheer. Applicatiebeheer in de vorm van technisch applicatiebeheer heeft alleen fysieke toegang tot die componenten van het specifieke informatiesysteem waarop wijzigingen dan wel nieuwe programmatuur of een gegevensbank geïmplementeerd dienen te worden. Technisch beheer heeft fysieke toegang tot de apparatuur en programmatuur van informatiesystemen in zoverre dit vanuit de beheertaken van technisch beheer noodzakelijk is. 6.2 Fysieke toegang tot gegevens die opgeslagen zijn binnen gegevensbanken (databases) van informatiesystemen in relatie tot de drie vormen van beheer Gegevens die opgeslagen zijn in informatiesystemen zijn eigendom van de eigenaar van het informatiesysteem. Dat betekent dat de eigenaar ook verantwoordelijk is voor deze gegevens. Dat heeft tot gevolg dat een functioneel beheerder buiten de functionele toegang tot deze gegevens de rechten op een gegevensbank heeft om gegevens te kunnen raadplegen, invoeren, wijzigen en verwijderen (gegevensbeheer). Indien de eigenaar op basis van functiescheiding, rechtmatigheid, enz. vindt dat dit niet gewenst is, worden er nadere afspraken gemaakt. Technisch beheer stelt randvoorwaarden ten aanzien van de hulpmiddelen die bij het gegevensbeheer gebruikt worden en de wijze waarop deze hulpmiddelen worden gebruikt. Applicatiebeheer in de vorm van applicatieonderhoud heeft alleen toegang tot gegevens die zijn opgeslagen in de ontwikkelomgeving en mogelijk testomgeving (zie onder vorm van beheer applicatiebeheer). Applicatiebeheer in de vorm van technisch applicatiebeheer heeft alleen toegang tot gegevens in de OTAP-omgevingen in zoverre dit nodig is voor de implementatie van nieuwe of gewijzigde applicatieprogrammatuur en gegevensbanken. Technisch beheer heeft alleen toegang tot gegevens in zoverre dit vanuit de beheertaken van technisch beheer noodzakelijk is. 7 Batchverwerkingen In veel informatiesystemen wordt gebruik gemaakt van geautomatiseerde bulk -verwerking van gegevens, ook wel batchverwerking genoemd. Functioneel beheer is verantwoordelijk om te bepalen wanneer en in welke frequentie deze batchverwerkingen gedraaid worden. Het daadwerkelijk draaien van de batchverwerking is de verantwoordelijkheid van technisch beheer. Tussen functioneel beheer en technisch beheer worden afspraken gemaakt over het proces van batchverwerking. 6

7 8 Ontwikkelafspraken Indien er sprake is van ontwikkeling van informatiesystemen (enige vorm van functionaliteit) in eigen beheer van de Drechtsteden, dan worden er ten aanzien van de te ontwikkelen functionaliteit tussen de opdrachtgever en technisch beheer (serviceeenheid Netwerk- en computerbeheer van het Servicecentrum Drechtsteden) in overleg afspraken gemaakt die vastgelegd worden in de volgende twee documenten: 1. Project Start Architectuur (PSA) 2. Opleverprocedure In een Project Start Architectuur wordt na overleg een concreet en doelgericht kader neergelegd waarbinnen het project moet worden uitgevoerd. Het kader wordt gevoed door algemeen gehanteerde principes, beleidslijnen en modellen van/door programma IP & A Drechtsteden. De opleverprocedure is bedoeld om vast te leggen hoe het proces van oplevering van nieuwe dan wel gewijzigde functionaliteit verloopt. 8.1 Project Start Architectuur (PSA) Een Project Start Architectuur dient in ieder geval te bestaan uit de volgende onderwerpen: Omgevingsmodel van de functionaliteit (bedrijfscontext en bedrijfsprocessen). Afbakening ICT oplossing (contextdiagram tot omgeving (applicaties en gebruikers), inhoud van de ICT oplossingen (te onderscheiden functionaliteiten, interfacing, technische architectuur). Project overschrijdende ontwerpkeuzes. Standaarden en richtlijnen (ontwerp- en ontwikkelstandaarden (conventies), sjablonen en richtlijnen). 8.2 Opleverprocedure De opleverprocedure bevat minimaal afspraken omtrent de volgende onderwerpen (met inachtneming van hetgeen in dit beheermodel is beschreven): aanmelding van oplevering (change) wijze van opleveren (scripts) op te leveren documentatie (datamodel, installatiehandleiding, overzicht wat gewijzigd is, enz.) frequentie en omvang van opleveren (patches, releases) planning termijnen versiebeheer aantal betrokken omgevingen uit te voeren tests op te stellen testplannen procedure in geval acceptatietesten niet positief zijn (back-out) procedure bij urgentie Taken, verantwoordelijkheden en bevoegdheden in het opleverproces 7

8 Bijlage 1 Toestanden model levenscyclus Informatiesysteem volgens Looijen IBP: InformatieBeleid- en Planning O: Ontwikkeling AI: Acceptatie en Invoering G: Gebruik W: Wijziging E: Exploitatie 8

9 Bijlage 2 OTAP, staat voor de verschillende omgevingen die bij de ontwikkeling en wijziging van informatiesystemen gehanteerd worden. O staat voor de ontwikkelomgeving, hierin worden nieuwe functionaliteit of wijzingen in ontwikkeld. Toestand O. T staat voor testomgeving, hierin worden de nieuw ontwikkelde programmatuur door de ontwikkelaars getest en tevens de opleverscripts getest door de ontwikkelaars. Zie ook opmerking bij acceptatieomgeving. Toestand O. A staat voor accpetatieomgeving, hierin wordt door functioneel beheer en technisch beheer getest of de nieuwe of gewijzigde programmatuur aan de gestelde eisen voldoet. (Binnen de Drechtsteden wordt het begrip testomgeving over het algemeen gebruikt om de acceptatieomgeving aan te geven). Toestand AI. P staat voor productieomgeving, de live omgeving waar de eindgebruikers van het informatiesysteem gebruik van maken. Toestand G en E. Afhankelijk van de omvang van het ontwikkelingstraject van een informatiesysteem en het belang van het informatiesysteem kunnen er meer of minder omgevingen toegepast worden. 9