Programma IP&A Drechtsteden, Drechtsteden Technisch Architectuur (DTA)

Transcriptie

1 Programma IP&A Drechtsteden, Drechtsteden Technisch Architectuur (DTA) ICT Beleid Applicatie criteria Gestelde eisen aan applicaties (en software services) vanuit de Drechtstedelijke ICT infrastructuren (inclusief GRID) en Applicatie- en Technisch Beheer. Status Definitief Versie 1.1 Redactie DTA (Drechtsteden Technische Architectuur) Datum

2 Versiebeheer Versie Datum Wijzigingen Auteur Initiële versie. Ton Voogt Tweede conceptversie. John van Eck Wijzigingen reviewronde, Ton Voogt, Paul Zweers, Paul John van Eck Goes, Matthieu Wust en John van Eck verwerkt. 0.9 Oktober 2007 Versie t.a.v. MT-ICT Dordrecht (geen aanpassingen) John van Eck Versie aangepast aan Drechtsteden. John van Eck Definitieve versie Integratie directoryservice aangevuld met GRID John van Eck planning en afwijking Oracle standaard ter goedkeuring DTA Tekstuele wijzigingen hoofdstuk 1 en 2. John van Eck Hoofdstuk 2 PMO als besluitorgaan i.p.v. WAC (Besluit PMO ). Toevoegen tabel per eis hoofdstuk 3. Opmerkingen Mark Slooff t.a.v. Minimum Baseline Applicaties verwerkt in zoverre relevant voor dit document. Hoofdstukken 3 t/m 8 revisie op recente versies/techniek. Integratie van het officiële document en de uitgeklede versie t.a.v. aanschaftrajecten (dit laatste document is bij deze vervallen). Tevens paragrafen t.a.v. gebruik van het document toegevoerd. Criteria aangepast/toegevoegd. WINS niet toegestaan. Netwerk USB dongle wel toegestaan. Standaard pakket tenzij (bij 80% functionaliteit) toegevoegd. Nummering criteria toegevoegd Review op 1.09 van Paul Goes (DTA) verwerkt. Definitieve versie ter vrije verspreiding. John van Eck Goedkeuring Versie Datum Naam/Functie/Orgaan 0.9 oktober 2007 Drechtsteden Technische Architectuur (DTA) en MT-ICT Dordrecht PMO Programma IP&A Drechtsteden Formele distributie en distributie ter review Versie Datum Naam/Functie/Orgaan John van Eck (ter review) Ton Voogt, Paul Zweers en Matthieu Wüst (ter review) Paul Goes (ter review) Beheerders afd. ICT Dordrecht, Mark Voogd, Corné Dekker, afd. IPM Dordrecht (ter review) 0.9 oktober 2007 MT-ICT Dordrecht (ter review) PMO Programma IP&A Drechtsteden (ter vaststelling) DTA (ter review) ICT Beleid - Applicatie Criteria definitieve versie

3 Fred Hilvers (manager SCD/GI/ATB a.i), Math Verhoef (adjunct-manager SCD/GI/ATB), Sjoerd Bruinsma (manager SCD/AB2/IAB en SCD/AB2IVT), Math Muijres (progammamanager IP&A Drechtsteden), Ben Akkerboom (hoofd programmabureau IP&A Drechtsteden), Ferdi van Engelen (deelprogrammamanager A IP&A Drechtsteden), Rob Palant (projectleider IP&A instrumenteren A), Matt Janssens projectleider IP&A Migratie en uitrol Uniforme werkplek), Piet Brouwer (changemanager SCD/GI/ATB), medewerkers SCD/GI/ATB, SCD/AB2/IAB, SCD/AB2/IVT en relevante projectmedewerkers Uniforme werkplek (ter formele distributie) ICT Beleid - Applicatie Criteria definitieve versie

4 Inhoudsopgave INHOUDSOPGAVE INLEIDING AANLEIDING DOEL INDELING EISEN BRONNEN EIGENDOM OVERZICHT VEELGEBRUIKTE AFKORTINGEN PROCEDURES GEBRUIK VAN DE APPLICATIE CRITERIA BIJ AANSCHAFTRAJECTEN Toets op applicatiecriteria vóór aanschaf Aanschaf als onderdeel van aanbesteding GEBRUIK VAN DE AC BIJ IN-HOUSE APPLICATIEONTWIKKELING WIJZIGINGSPROCEDURE CERTIFICERINGPROCEDURE GEDOOGPROCEDURE ONVOORZIENE GEVALLEN EN BELANGENAFWEGING ORGANISATORISCHE CRITERIA APPLICATIEPORTFOLIO INDELING APPLICATIES FUNCTIONALITEIT IN-HOUSE APPLICATIEONTWIKKELING (ZELFBOUW) HOSTING VERVLECHTING KOPPELING MET EXTERNE SYSTEMEN LEVERANCIERSCONTINUÏTEIT EIGENAARSCHAP LICENTIES TECHNISCHE CRITERIA APPLICATIETYPES APPLICATIECONTINUÏTEIT VERSIENUMMERING TAALVERSIE AUTHENTICATIE EN AUTORISATIE Active Directory integratie Active Directory Application Partition Active Directory in Application Mode CONFIGURATIE CRITERIA DEVICE AFHANKELIJKHEDEN ENVIRONMENT VARIABELEN NETWERK ONTSLUITINGSCRITERIA WERKPLEK STARTMENU ONTSLUITING M.B.V. DNS WEB- EN APPLICATIESERVER CRITERIA WEBSERVERS WEBSERVER IN DE DMZ APPLICATIESERVERS DATABASE CRITERIA STANDAARDISATIE...18 ICT Beleid - Applicatie Criteria definitieve versie

5 7.2 DATABASETOEGANG EN RECHTEN FILE-BASED DATABASES DATABASECOMMUNICATIE ODBC (Open Database Connectivity) SQL DATABASEOBJECTEN ORACLE SQL SERVER MYSQL PLATFORM CRITERIA ALGEMEEN CRITERIA VOOR WEBAPPLICATIES (APPLICATIETYPE 1A) CRITERIA VOOR APPLICATIES DIE GEHOST WORDEN VIA SBC/SOFTGRID (APPLICATIETYPE 1B EN 2) CRITERIA VOOR APPLICATIES DIE GEHOST WORDEN VIA SOFTGRID/FATCLIENT (APPLICATIETYPE 3) CRITERIA VOOR SOFTGRID DEPLOYMENT CRITERIA VOOR CLUSTER APPLICATIES CRITERIA VOOR ACTIVEX COMPONENTEN INTEGRATIE CRITERIA (KOPPELINGEN) GEAUTOMATISEERDE KOPPELINGEN KOPPELINGEN MET STANDAARD KA TOEPASSINGEN INSTALLATIE CRITERIA INSTALLATIE PROCEDURE INSTALLATIE VOORWAARDEN ONTWIKKELCRITERIA ONTWIKKELPRINCIPES Ontwikkelomgevingen ONTWIKKELRICHTLIJNEN Ontwikkelstandaarden Bewezen technologie Hergebruik van componenten N-tier applicatiemodel Infrastructuuronafhankelijk Integratiemogelijkheden Ontwikkelmethodiek BEHEERCRITERIA BEHEERMODEL INFORMATIESYSTEMEN DRECHTSTEDEN DOCUMENTATIE TOEGANG TOT APPLICATIE DOOR LEVERANCIER OPMERKINGEN...18 BIJLAGE 1 INVULLIJST CRITERIA LEVERANCIER...18 BIJLAGE 2 INVULLIJST CRITERIA EIGENAAR...18 ICT Beleid - Applicatie Criteria definitieve versie

6 1 Inleiding 1.1 Aanleiding Binnen de Drechtsteden 1 dient er gekomen te worden tot één uniforme, gestandaardiseerde, centrale, beschikbare, flexibele, veilige en centrale ICT infrastructuur, die door de Serviceeenheid Applicatie- en Technisch Beheer (A&T Beheer) van het Servicecentrum Drechtsteden (SCD) eenduidig beheerd kan worden en waarover men in control is. Om hieraan gestalte te geven is door het programma IP&A Drechtsteden een Technisch Beleidsplan ICT (TBP) opgesteld. De directe aanleiding hiervoor is de noodzaak om de strategische ICT visie van de Drechtsteden zoals vastgelegd in het strategisch plan IP&A Drechtsteden, mede uit te werken naar een integrale strategie betreffende een nieuwe ICT infrastructuur op korte en middellange termijn. Het deelprogramma I van het IP&A programma Drechtsteden heeft als taak om via verschillende projecten deze nieuwe centrale ICT infrastructuur te realiseren. Deze nieuwe ICT infrastructuur heeft de naam Gemeenschappelijke Regionale ICT-infrastructuur Drechtsteden (GRID) gekregen. De noodzaak om een integrale strategie ook op het gebied van ICT infrastructuur te bepalen is de laatste jaren sterk toegenomen, dit gezien het grote aantal ontwikkelingen, zowel intern als extern, die zich in een steeds sneller tempo voordoen en die grote impact hebben op de ICT infrastructuur. Daarnaast worden de eisen (standaardisatie, verlaging kosten, hogere beschikbaarheid, beveiliging, enz.) die gesteld worden aan de ICT infrastructuur steeds hoger, mede op basis van nieuwe behoeften, zoals o.a. veilig thuis/telewerken en mobiel werken en flexwerk en desk-sharings concepten. Het TBP beschrijft de strategische richting, waarlangs de GRID infrastructuur van de Drechtsteden zich zal ontwikkelen. In het document Uitgangspunten regionale infrastructuur zijn de architectuurprincipes en de technologische hoofdkeuzes vastgelegd van de nieuwe GRID infrastructuur. Om de GRID infrastructuur gecontroleerd en conform heldere richtlijnen te implementeren, is het noodzakelijk op verschillende deelgebieden (technisch) beleid te ontwikkelen. Één van deze deelgebieden is de applicatieportfolio welke aan gebruikers aangeboden gaat worden. Binnen het SCD is het ter beschikking stellen van de applicaties aan de gebruikers centraal geregeld bij service-eenheid A&T Beheer. Duidelijk is dat er binnen de Drechtsteden heel veel verschillende applicaties in gebruik zijn. Binnen de verschillende applicaties wordt gewerkt met meerdere (verouderde) versies en sommige van deze applicaties leveren dezelfde functionaliteit. Bovendien is niet duidelijk aan welke criteria een applicatie moet voldoen voordat deze gecontroleerd en beheerd binnen de infrastructuur aangeboden kan worden. Een en ander is in strijd met de gehanteerde strategische visie op de GRID infrastructuur en de GRID architectuurprincipes en de door A&T Beheer gehanteerde uitgangspunten en randvoorwaarden van eenduidig beheer. Alleen een duidelijke set van criteria, waaraan applicaties moeten voldoen, stellen de Drechtsteden in staat controle te krijgen over het beheer van applicaties en de ICT infrastructuur en daarmee te voldoen aan de strategische visie op de GRID infrastructuur en de GRID architectuurprincipes te borgen. 1.2 Doel In dit document zijn de criteria gedefinieerd waaraan applicaties moeten voldoen om binnen de infrastructuur van de Drechtsteden toegelaten te worden. De criteria zijn afgeleid van de randvoorwaarden en uitgangspunten van het Strategisch Beleidsplan IP&A, het TBP en de GRID architectuurprincipes. Het TBP en de GRID architectuurprincipes zijn leidend in de 1 Waar Drechtsteden is geschreven dient gelezen te worden alle deelnemende organisaties binnen het Servicecentrum Drecthsteden (gemeenten Alblasserdam, Dordrecht, Hendrik-Ido-Ambacht, Papendrecht, Sliedrecht en Zwijndrecht, GR Drechtsteden en GR Regio Zuid-Holland Zuid). ICT Beleid - Applicatie Criteria definitieve versie

7 bepaling van de criteria. Daarnaast kunnen meer algemenere eisen t.a.v. applicaties opgenomen worden binnen dit document, denk aan ontwikkelstandaarden, gebruik van generieke functionaliteit, wijze van koppelen, voorgeschreven applicatiearchitecturen, ontwikkelen onder architectuur, enz. Het doel van dit document is een set van criteria te definiëren welke aan applicaties opgelegd worden. De criteria gelden voor de huidige applicaties én voor nieuwe applicaties en dienen om: de beheerinspanning op applicaties te optimaliseren; te garanderen dat applicaties correct functioneren; de beschikbaarheid van applicaties te garanderen; te garanderen dat applicaties geen gevaar opleveren voor de consistentie, continuïteit, performance en beveiliging van de infrastructuur van de Drechtsteden, inclusief andere applicaties; te garanderen dat applicaties op een eenduidige manier ontwikkeld en onderhouden kunnen worden. nieuwe behoeftes zoals o.a. veilig thuis- en mobiel werken en concepten als flexwerken en desk-sharing mogelijk te maken. Bovendien geeft dit document: Applicatieontwikkelaars, ontwikkelprojecten en afdelingen verantwoordelijk voor de inkoop van applicaties inzicht in de gehanteerde criteria; Een beschrijving van de procedures die gevolgd dienen te worden om een ingekocht of ontwikkeld product binnen de infrastructuur geaccepteerd te krijgen; Leveranciers inzicht in de eisen die gesteld zijn aan applicaties; Beheerders inzicht in de eisen die gesteld zijn aan de te beheren applicaties. 1.3 Indeling eisen De geformuleerde eisen ten aanzien van de applicaties zijn ingedeeld in drie niveaus, het principe is afgeleid van het MoSCoW principe, waarbij de W niet wordt meegenomen en de betekenis is, zoals hieronder weergegeven: Must Have () aan deze eis dient voldaan te worden (knock-out criteria); Should Have (SH) het voldoen aan deze eis is zeer gewenst, maar ze vormen geen knock criteria. In een applicatie selectietraject waarbij er meerdere aanbieders van de betreffende functionaliteit zijn kunnen deze eisen onderdeel zijn van het selectie wegingsproces; Could Have (CH) dit betreffen aanbevelingen. In een applicatie selectietraject waarbij er meerdere aanbieders van de betreffende functionaliteit zijn kunnen deze eisen onderdeel zijn van het selectie wegingsproces. 1.4 Bronnen De volgende bronnen zijn geraadpleegd bij de totstandkoming van dit document: Beleidsdocument Informatiebeveiliging, versie ; Baseline Informatiebeveiliging, versie ; Applicatieconsolidatie Mandaat, versie 0.3; Applicatieconsolidatie PID, versie 2.0; Technisch Beleidsplan ICT, versie 1.1, datum ; Checklist implementatie nieuwe bedrijfsapplicatie, versie 1.3, datum ; Protocol 1.0 werken onder architectuur, versie 1.0, datum ; Strategisch plan IP&A Drechtsteden conceptversie 2, datum ; Uitgangspunten Regionale Infrastructuur versie 1.0, datum ; NORA 2.0, ; GEMMA, conform samenhangnotitie juni ICT Beleid - Applicatie Criteria definitieve versie

8 1.5 Eigendom 2008 Drechtsteden. Geen enkel deel van dit document mag worden vermenigvuldigd in welke vorm of door welke middelen dan ook zonder schriftelijke toestemming van de Drechtsteden. Dit document is vertrouwelijk en mag alleen worden gebruikt voor de doeleinden waarvoor het is vrijgegeven. 1.6 Overzicht veelgebruikte afkortingen Afkorting SCD GI AB2 ATB A&T beheer IAB IVT GRID SBC TBP Verklaring Servicecentrum Drechtsteden Organisatiecluster Gebouw & Infrastructuur van het Servicecentrum Drechtsteden Oraganisatiecluster Advies & Beleid 2 van het Servicecentrum Drechtsteden Service-eenheid Applicatie- en Technisch Beheer van het Servicecentrum Drechtsteden Service-eenheid Applicatie- en Technisch Beheer van het Servicecentrum Drechtsteden Service-eenheid Informatiserings- en Automatiseringsbeleid van het Servicecentrum Drechtsteden Service-eenheid Implementatie- en Verandertrajecten van het Servicecentrum Drechtsteden Gemeenschappelijke Regionale ICT-infrastructuur Drechtsteden Server Based Computing Technisch Beleidsplan ICT ICT Beleid - Applicatie Criteria definitieve versie

9 2 Procedures 2.1 Gebruik van de Applicatie criteria bij aanschaftrajecten Toets op applicatiecriteria vóór aanschaf Uitdrukkelijk wordt gesteld dat het toetsen ( de technische architectuurtoets ) of een nieuwe applicatie voldoet aan de gestelde applicatiecriteria in dit document dient te gebeuren voordat een verplichting met de applicatieleverancier aangegaan wordt. Het niet voldoen aan alle Must Have () eisen leidt tot de status afgekeurd van de applicatie. Er kan niet tot aanschaf van de applicatie worden overgegaan. De technische architectuurtoets is onderdeel van de certificeringsprocedure (zie paragraaf 2.4) en wordt uitgevoerd door een architect Technische Architectuur (ICT-architect). De architectuurtoets gebeurd op basis van de volledig ingevulde invullijst criteria leverancier in bijlage 1 door de applicatieleverancier (inclusief de verdere door de applicatieleverancier ter beschikking gestelde documentatie, zie hiervoor paragraaf 12.2) en de volledige ingevulde invullijst criteria eigenaar in bijlage 2 door de toekomstige applicatie-eigenaar. De technische architectuurtoets is dus een papieren toets. Indien een applicatie de technische architectuurtoets met goed gevolg heeft doorlopen zal vervolgens gedurende het installatieproces van de applicatie de acceptatieomgeving gecontroleerd worden of de applicatie daadwerkelijk aan alle technische eisen () voldoet. Indien dit niet het geval is zal van de leverancier worden verlangd dat deze aanpassingen doorvoert zodat de applicaties alsnog aan alle eisen voldoet, aangezien hij via de invlullijst in bijlage 1 aangegeven heeft aan alle eisen te voldoen Aanschaf als onderdeel van aanbesteding Indien de aanschaf van een applicatie onderdeel uitmaakt van een aanbestedingsprocedure dienen de Applicatiecriteria op de volgende wijze in de offerteaanvraag van de aanbesteding meegenomen te worden: De gestelde eisen en wensen in dit document zijn onderdeel van het technisch programma van eisen. Dit document maakt onderdeel uit van de offerteaanvraag. Alle Must Have () eisen zijn zogenaamde minimum eisen. Het niet voldoen aan één van deze minimum eisen leidt tot uitsluiting van de aanbieder. Alle Should Have (SH) en Could Have (CH) eisen kunnen gescoord worden. Het technische programma van eisen dient dan ook binnen het criterium kwaliteit van de gunningscriteria meegewogen te worden. Aanbieders dienen de volledig ingevulde invullijst criteria leverancier zoals opgenomen in bijlage 1 in hun offerte mee te sturen. Eigenaar vult de invullijst criteria eigenaar in bijlage 2 volledig in. Toetsing op het voldoen aan de applicatiecriteria (architectuurtoets) gebeurd op basis van de beide volledige ingevulde invullijsten (leverancier en eigenaar) door de architect Technische Architectuur. 2.2 Gebruik van de AC bij in-house applicatieontwikkeling De Applicatie criteria gelden ook voor applicaties die door de Drechtsteden zelf ontwikkeld en gebouwd worden (onder verwijzing naar criteria GRID/AC/002 (standaard, tenzij) en hoofdstuk 11). In een vroegtijdig stadium van de start van het in-house applicatieontwikkelingtraject, o.a. bij de keuze van de tooling ter ondersteuning van de bouw en de keuze voor de applicatiearchitectuur dient rekening gehouden te worden met de beschreven criteria. Het is dus raadzaam om in een vroegstadium de applicatiearchitectuur te laten toetsen door de architect Technische Architectuur. ICT Beleid - Applicatie Criteria definitieve versie

10 2.3 Wijzigingsprocedure Een wijzigingsverzoek wordt officieel ingebracht bij de changemanager en doorloopt de wijzigingsprocedure. De changemanager maakt onderdeel uit van de service-eenheid Applicatie- en Technisch beheer van het SCD. De wijzigingsprocedure heeft tot doel, om noodzakelijke wijzigingen binnen de infrastructuur gecontroleerd uit te voeren, zodat verstoringen en afwijkingen van de infrastructuur als gevolg van de wijzigingen worden voorkomen. In deze procedure wordt een wijzigingsverzoek beoordeeld door verschillende afdelingen die elk de impact van de wijziging beoordelen in relatie tot hun specifieke aandachtsgebied. Het invoeren van een nieuwe applicatie (of software service) mag alleen na formele toestemming van het WAG 2 en indien de applicatie de status gecertificeerd heeft gekregen vanuit de certificeringsprocdure (zie paragraaf 2.4). 2.4 Certificeringprocedure De certificeringprocedure van de Drechtsteden heeft tot doel te controleren of applicaties en (software) services voldoen aan de applicatiecriteria welke opgesteld zijn door de Drechtsteden. De certificeringprocedure van de Drechtsteden is onderdeel van de hierboven genoemde wijzigingsprocedure voor de Drechtsteden. De changemanager ziet er op toe dat, voor nieuwe applicatie of wijzigingen in de applicatiearchitectuur van bestaande applicaties (impact op de applicatiecriteria), de certificeringsprocdure wordt doorlopen. De certificeringprocedure heeft tot doel om na te gaan of een applicatie of een software service gecertificeerd kan worden voor toelating op een Drechtstedelijke ICT infrastructuur. In de certificeringsprocedure wordt een applicatie of software service getoetst (technische architectuurtoets) aan de Applicatiecriteria. Deze architectuurtoets wordt uitgevoerd door de architect Technische Architectuur. Applicaties worden pas toegestaan binnen een ICT infrastructuur als zij conform deze procedure getest en geaccepteerd zijn op technisch correct functioneren binnen de infrastructuur (OTAP) en voldoen aan alle (Must Have) criteria en zover als mogelijk aan de SH (Should Have) criteria die genoemd zijn in dit document. In de certificeringprocedure wordt verder aandacht besteed aan de impact die de introductie van een nieuw product kan hebben op de operationele beschikbaarheid, de betrouwbaarheid en de performance van de infrastructuur en de benodigde beheerslast. Daarnaast wordt gecontroleerd of het product niet strijdig is met architectuurprincipes en werkplek- en infrastructuurconcepten van de Drechtsteden. De certificeringprocedure heeft formeel maar twee mogelijke uitkomsten: De applicatie wordt gecertificeerd. De applicatie kan zonder problemen binnen de ICT infrastructuur geïmplementeerd worden. De applicatie wordt afgekeurd. De applicatie wordt niet op de ICT infrastructuur geïmplementeerd. De afkeuring gaat gepaard met een lijst van de eisen uit dit document (uitdrukkelijk dient op de lijst de versie van het Applicatiecriteria document opgenomen te worden en het nummer van de eis conform dit document) waarop de applicatie is afgekeurd en bevat per eis, waar niet aan wordt voldaan, een toelichting waarom niet is voldaan. De applicatie wordt in overleg met de applicatie-eigenaar verbouwd of er vindt nieuwbouw plaats. 2 Wijzigings Advies Groep Drechtsteden ICT Beleid - Applicatie Criteria definitieve versie

11 2.5 Gedoogprocedure In uitzonderlijke gevallen kunnen applicaties, die door de certificeringsprocedure zijn afgekeurd en dus niet aan de criteria voldoen, alsnog in beheer worden genomen. Dit mag alleen na formele toestemming van het PMO 3. De applicatie-eigenaar dient ter behandeling in het PMO overleg een plan van aanpak in, dat voldoet aan de volgende eisen: Het plan van aanpak beschrijft hoe en wanneer de applicatie zal worden gemigreerd naar een gecertificeerde applicatie. De gedoogperiode kent dus een einddatum. N.B. een alternatief is de volledige afbouw van de applicatie. Voor deze sterfhuisconstructie dient ook een plan van aanpak ingediend te worden. Het plan van aanpak is goedgekeurd door de stuurgroep ICT van de organisatie (indien aanwezig). Het plan van aanpak geeft aan welk budget benodigd is voor de aanschaf van de vervangende applicatie en benodigde migratie en toont aan dat dit budget beschikbaar is. Tevens bevat dit plan van aanpak de meerkosten voor exploitatie van de gedoogapplicatie, ook hiervan dient aangetoond te worden dat het budget beschikbaar is. A&T Beheer zal namelijk eisen stellen om er voor te zorgen dat eventuele ongewenste impact op de reguliere ICT infrastructuur wordt voorkomen. De architecuur van de infrastructuuroplossing om de gedoogapplicatie te hosten dient dus in het plan van aanpak inzichtelijk te worden gemaakt, zowel qua techniek als financieel. Het plan van aanpak geeft aan op welke termijn de migratie is afgerond. Na deze deadline zal de gedoogde applicatie van de ICT infrastructuur verwijderd worden. De vervangende applicatie die in het plan van aanpak wordt beschreven dient voordat deze op de ICT infrastructuur wordt geplaatst ook het certificeringsproces te doorlopen. De changemanager van de service-eenheid Applicatie- en Technische beheer van het SCD is verantwoordelijk voor de controle of het plan van aanpak conform de planning wordt uitgevoerd en of men zich aan de opgestelde gedoogafspraken houdt. Wanneer het PMO het plan goedkeurt geeft zij daarbij een goedkeuring tot tijdelijk gedogen af en krijgt de uit te faseren applicatie officieel de status gedoogd. Het plan van aanpak dient daarna uitgevoerd te worden. Het PMO geeft bij elke goedkeuring tot gedogen aan wat de deadline van de gedoogperiode is; de gedoogperiode is dus altijd een tijdelijke. Verlenging van de gedoogperiode kan alleen door het PMO gegeven worden en kan alleen in uitzonderlijke situaties worden afgegeven. 2.6 Onvoorziene gevallen en belangenafweging Indien er sprake is van een aanvraag voor een applicatie waarvan redelijkerwijs gesteld kan worden dat het beleid, zoals vastgesteld in dit document, niet van toepassing kan zijn, dan wordt overleg gepleegd met de architect Technische Architectuur (ICT-architect). Deze beoordeelt of het ICT Beleid Applicatie Criteria onverkort geldig is of dat er inderdaad sprake is van een afwijkende situatie waarvoor een specifieke architectuur en beleidstoets noodzakelijk is. In dit laatste geval kan dit eventueel leiden tot aanvulling van het technische beleid en/of technische architectuur. Mocht niet tot overeenstemming gekomen worden tussen de aanvrager en de architect Technische Architectuur dan wordt de kwestie (met argumenten onderbouwd) voorgelegd aan het PMO. In gevallen dat een applicatie de status afgekeurd krijgt, maar de aanvrager vindt dat hij en/of zijn organisatieonderdeel daarmee ernstig in zijn/haar belang geschaad wordt, kan deze de kwestie voorleggen aan het PMO. Dit dient wel gepaard te gaan met een volledig uitgewerkte Business case (kosten/baten analyse), waarbij in overleg met SCD A&T beheer ook de exploitatielasten van beheer inzichtelijk zijn gemaakt. Deze business case dient gepaard te gaan met een advies van de stuurgroep ICT (indien aanwezig) van de betreffende organisatie. In alle overige niet voorziene gevallen beslist het PMO. 3 PMO staat voor Programmamanagers overleg van het programma IP&A Drechtsteden. Het PMO treedt op als Wijzigingsadviesraad (WAR) van de Drechtsteden (besloten in PMO overleg ), zolang dit orgaan nog niet is ingesteld, dan wel niet een evenwichtige vertegenwoordiging van alle belanghebbenden heeft. ICT Beleid - Applicatie Criteria definitieve versie

12 3 Organisatorische criteria 3.1 Applicatieportfolio Binnen de Drechtsteden is een applicatieportfolio aanwezig. Dit is een op functionaliteit gebaseerde lijst van applicaties die zijn gecertificeerd, conform de certificeringsprocedure door de Drechtsteden en dus worden ondersteund door Service-eenheid Applicatie- en technisch beheer van het SCD van de Drechtsteden. 3.2 Indeling Applicaties Binnen de Drechtsteden wordt voor de wijze van toepassing van applicaties de volgende indeling gehanteerd: - Standaardapplicaties, dit zijn de applicaties die door de Service-eenheid Applicatieen technisch beheer van het SCD standaard aan iedere gebruiker van de Drechtsteden worden aangeboden en generieke functionaliteit bieden. Eigenaar en licentiebeheerder van deze applicaties is het Servicecentrum Drechtsteden. De standaardapplicaties zijn opgenomen in de applicatieportfolio Drechtsteden. - Keuze applicaties, dit zijn applicaties die niet standaard aan iedere gebruiker worden aangeboden maar via de daarvoor vastgestelde aanvraagprocedure kunnen worden aangevraagd bij de Service-eenheid Applicatie- en technisch beheer van het SCD van de Drechtsteden. Eigenaar en licentiebeheerder van deze applicaties is het Servicecentrum Drechtsteden. De keuze applicaties zijn opgenomen in de applicatieportfolio Drechtsteden. - Bedrijfsapplicaties, dit zijn applicaties die ingezet worden ter ondersteuning van specifieke bedrijfsprocessen. Voor deze applicaties is in een organisatie een eigenaar benoemd, die tevens verantwoordelijk is voor het licentiebeheer. Tevens dient het functionele beheer in de organisatie belegd te zijn. De bedrijfsapplicaties zijn opgenomen in de applicatieportfolio Drechtsteden. - Beheerapplicaties, dit zijn applicaties die ingezet worden voor het technisch beheer, applicatiebeheer dan wel het functioneel beheer. Zover deze applicaties ingezet worden voor applicatiebeheer (indien belegd buiten SCD A&T beheer) en functioneel beheer zijn zij opgenomen in de applicatieportfolio Drechtsteden. T.a.v. eigenaarschap en licentiebeheer is bij inzet voor technisch beheer dan wel technisch applicatiebeheer, het model zoals gehanteerd bij de standaard- en keuzeapplicaties van toepassing. Indien beheerapplicaties alleen worden ingezet voor functioneel beheer dan wel functioneel applicatiebeheer geldt t.a.v. eigenaarschap en licentiebeheer het model van de bedrijfsapplicaties. 3.3 Functionaliteit Om binnen de ICT architectuur van de Drechtsteden te kunnen standaardiseren op bepaalde functionaliteit, krijgen gebruikers alleen die bepaalde functionaliteit die ten behoeve van de uitoefening van hun taak benodigd is. Deze functionaliteit wordt ingevuld door applicaties die opgenomen zijn in het applicatieportfolio. Als een bepaalde functionaliteit reeds wordt ingevuld door een bepaald product/applicatie, dan is het niet toegestaan alternatieve producten/applicaties voor deze functionaliteit in te voeren. 001 Indien de gewenste functionaliteit voor meer dan 80% ingevuld wordt door een applicatie uit het applicatieportfolio van de Drechtsteden dan is het niet toegestaan een nieuwe applicatie hiervoor aan te schaffen. ICT Beleid - Applicatie Criteria definitieve versie

13 3.4 In-house applicatieontwikkeling (zelfbouw) Het kopen van standaard software prevaleert boven in-house applicatieontwikkeling (zelfbouw), dus standaard tenzij. 002 Indien de benodigde functionaliteit voor 80% in standaard software voorhanden is, wordt standaard software aangeschaft en wordt dus niet zelf gebouwd Hosting Applicaties en gegevens, die eigendom zijn van de Drechtsteden, worden altijd binnen een ICT infrastructuur in beheer bij Service-eenheid Applicatie- en technisch beheer van het SCD van de Drechtsteden geplaatst, zodat de Drechtsteden te allen tijde in staat is deze gegevens te modificeren en te controleren zoals zij goed acht. In de praktijk betekent dit, dat alle systemen, waarop een applicatie of dienst voor de Drechtsteden wordt aangeboden, direct zonder een externe firewall te passeren, benaderbaar zijn door de Drechtsteden werkplekken. Alleen met goedkeuring van het PMO kan hiervan afgeweken worden. 003 Hosting van de applicatie vindt plaats op één van de ICT infrastructuren in beheer bij service-eenheid Applicatie- en Technisch beheer van het SCD. Alleen met goedkeuring van het PMO kan hiervan afgeweken worden. 3.6 Vervlechting 004 Het is dienstenleveranciers niet toegestaan applicaties of diensten op systemen van de Drechtsteden te plaatsen, die ook gebruikt worden voor het aanbieden van functionaliteit aan andere (niet- Drechtsteden) partijen. (Tenzij op uitdrukkelijk verzoek van de Drechtsteden en na een formele, geaccordeerde opdracht van A&T Beheer van het SCD (A&T Beheer kan accorderen weigeren)) 3.7 Koppeling met externe systemen Verschillende partners van de Drechtsteden (zoals het Waterschap, Belastingdienst, CWI e.a.) bieden applicaties en gegevens aan, die door de Drechtsteden gebruikt worden. Deze applicaties en gegevens zijn uiteraard geen eigendom van de Drechtsteden. De aanbiedende partner is te allen tijde verantwoordelijk voor de integriteit van de gegevens. Dit soort functionele koppelingen met partners mogen alleen onder strikte voorwaarden gerealiseerd worden. Deze voorwaarden staan vermeld in de aansluitvoorwaarden van de Drechtsteden en zijn met name bedoeld voor Business-to-Business koppelingen. 005 Koppelingen met externe systemen voldoen aan de aansluitvoorwaarden van DrechtNet. 3.8 Leverancierscontinuïteit Applicaties worden pas toegestaan binnen de infrastructuur van de Drechtsteden, als de continuïteit van de applicatieleverancier 5 voldoende gewaarborgd kan worden (applicatieleveranciers kunnen zowel intern als extern zijn). Aan de volgende voorwaarden dient daarom te worden voldaan: Er is vertrouwen in de applicatie en zijn leverancier; Er door de leverancier support geboden wordt op het herstel van problemen en fouten; 4 Beleidsregel nummer 21 van het beleidskader beleidsterrein I&A Handboek Kaderstelling d.d Beleidsgroep Kaderstelling. 5 In dit document wordt de term (applicatie)leverancier zowel gebruikt voor externe leveranciers als interne leveranciers (in-house ontwikkelde applicaties). ICT Beleid - Applicatie Criteria definitieve versie

14 Er door de leverancier het benodigde onderhoud en doorontwikkeling gewaarborgd wordt; Freeware 6 wordt niet toegestaan; Hobbyware wordt niet toegestaan; Voor bedrijfsapplicaties worden Escrow -overeenkomsten gesloten, waarin vastgelegd wordt hoe het eigendom van de sourcecode overgedragen wordt indien er geschillen zijn of de softwareleverancier niet langer naar behoren het juiste niveau van onderhoud kan garanderen Leverancierscontinuiteit dient gewaarborgd te zijn. Voor bedrijfsapplicaties dient een Escrow overeenkomst afgesloten te worden. SH 3.9 Eigenaarschap Een bedrijfsapplicatie heeft altijd een eigenaar (de persoon of afdeling op wiens initiatief de applicatie is aangeschaft c.q. gebouwd en budgetverantwoordelijk is voor de applicatie.) Voor de overige soorten applicaties fungeert Service-eenheid Applicatie- en technisch beheer van het SCD als eigenaar. 008 Er is een (toekomstige) eigenaar van de bedrijfsapplicatie vastgesteld Licenties De Drechtsteden dient te allen tijde te beschikken over voldoende licenties om alle gerechtigde gebruikers van een applicatie hiermee te kunnen laten werken. 009 Er zijn voldoende licenties aangekocht van de applicatie voor het gebruik van de applicatie. 6 Met de term freeware wordt geen open-source software bedoeld. ICT Beleid - Applicatie Criteria definitieve versie

15 4 Technische criteria 4.1 Applicatietypes Drechtsteden onderscheidt drie soorten applicatietypes: 1. Webbased/n-tier applicaties (webapplicaties) - applicatietype 1, dit zijn applicaties waarbij de userinterface gebaseerd is op een web browser en er d.m.v. scheiding van de technische tiers er minimaal drie tiers te onderscheiden zijn (client web/applicatieserver en databaseserver). Er wordt onderscheid gemaakt tussen webbased applicaties zonder te laden plugins in de browser (type 1a) en applicaties waarbij plugins geladen dienen te worden (type 1b). 2. Client-server applicaties - applicatietype 2, dit zijn applicaties met over het algemeen rijke user interfaces gebaseerd op een 2-tier architectuur (een client en een server (meestal de databaseserver)). 3. desktop applicaties - applicatietype 3, dit zijn applicaties die geschikt zijn om op één PC te draaien en gebruikmaken van een 1-tier architectuur Applicaties dienen primair ontwikkeld te worden conform het applicatietype 1 Applicaties die gebouwd zijn onder DOS zijn niet toegestaan. Windows applicaties dienen minimaal 32-bits applicaties te zijn. Het is niet toegestaan gebruik te maken van 16-bits Windows applicaties. Applicaties die gebruik maken van multimedia aspecten, zoals video en geluid, zijn niet toegestaan. SH SH Vanuit de ICT infrastructuur worden er eisen gesteld t.a.v. de drie applicatietype ten aanzien van de wijze van aanbieden Zowel ingekochte standaardapplicaties als (nieuw) ontwikkelde applicaties (in-house ontwikkeld dan wel aangekocht) dienen door de ICT infrastructuur conform één van onderstaande manier aangeboden te kunnen worden. Webbased/n-tier applicaties Deze applicaties dienen aangeboden te worden op basis van een webbrowser. Indien er sprake is van een niet-zuivere webbased applicatie (er dienen plugins geladen te worden in de browser) dan dient de webapplicatie aangeboden te worden zoals beschreven onder client-server applicaties. Client-server (2-tier) applicaties Server Based Computing (SBC) is voor de Drechtsteden een strategisch platform voor het aanbieden van applicaties. In het geval, dat applicaties niet op browser technologie gebaseerd zijn, moeten zij m.b.v. SBC gebaseerd op Citrix en via de streaming technologie van Microsoft Softgrid aangeboden kunnen worden. De client tier draait hierbij dus op de SBC omgeving. Desktop applicaties Deze applicaties dienen geschikt te zijn om via streaming technologie van Microsoft Softgrid op een fatclient aangeboden te kunnen worden. (Alleen) met goedkeuring van het PMO kan hiervan afgeweken worden. ICT Beleid - Applicatie Criteria definitieve versie

16 4.2 Applicatiecontinuïteit Applicaties dienen over een zekere mate van continuïteit te beschikken. Hiervoor gelden de volgende richtlijnen: Applicaties maken gebruik van bewezen technologie (zie ook ). Componenten van applicaties en infrastructuurcomponenten dienen gebaseerd te zijn op versies die in full support zijn en de periode van full support nog minimaal 1 jaar duurt. Componenten van applicaties die specifiek benoemd zijn in hoofdstuk 6 en 7 (webserver, applicatieserver en/of database) dienen gebaseerd te zijn op de versie(s) die bij Drechtsteden als standaard bepaald is (zijn). Zie hiervoor hoofdstuk 6 en 7. SH 4.3 Versienummering Alle applicaties beschikken over een unieke identificatie (versienummer). Het versienummer van een applicatie is altijd binnen de applicatie te achterhalen. Het versienummer is tijdens het gebruik zichtbaar in het scherm of is m.b.v. een subfunctie op te vragen. Het is mogelijk, met behulp van geautomatiseerde hulpmiddelen, het versienummer van iedere applicatie op te vragen zonder de applicatie daadwerkelijk te starten. Voor executables is het versienummer van de applicatie op te vragen via de attributen van de applicaties (de properties van de executable). 4.4 Taalversie 026 Applicaties worden altijd in de Nederlandse versie gebruikt. Als er van een benodigde applicatie geen Nederlandstalige versie beschikbaar is, wordt het gebruik van een Engelstalige versie toegestaan. Andere taalversies zijn niet toegestaan. 4.5 Authenticatie en autorisatie Let op: Active Directory intergratie is pas mogelijk na realisatie van de nieuwe GRID 7 infrastructuur. Indien de applicatie de mogelijkheid biedt tot AD integratie kan dit dus pas toegepast worden nadat de applicatie gemigreerd is naar de nieuwe GRID infrastructuur (2009/2010) Active Directory integratie Om SingleSignOn te bevorderen vindt authenticatie voor een applicatie plaats via een directory service. Indien authenticatie plaatsvindt op een directory service is dit bij voorkeur op ingerichte Microsoft Active Directory van de Drechtsteden. Bij gebruik van Active Directory voor het opslaan van configuratiegegevens mogen deze gegevens uitsluitend één van de volgende mogelijkheden toepassen: Configuratiegegevens worden in de Application Partition van de Active Directory geplaatst (zie 4.6.2) Configuratiegegevens worden in een Active Directory in Application Mode (AD/AM) geplaatst (zie 4.6.3) SH CH 7 Gemeenschappelijke Regionale Infrastructuur Drechsteden ICT Beleid - Applicatie Criteria definitieve versie

17 4.5.2 Active Directory Application Partition Bij het ontwerpen van een applicatie dient in de architectuur en het ontwerp rekening gehouden te worden met het feit, dat het niet toegestaan is wijzigingen in andere partities dan de Application Partition van de Active Directory door te voeren. Applicaties of services die toch wijzigingen in andere partities aanbrengen, mogen alleen geïmplementeerd worden na toestemming van Wijzigings Advies Commissie Als applicaties afhankelijk zijn van Active Directory objecten of attributen, moeten de afhankelijkheden duidelijk gedocumenteerd zijn. Als een applicatie wijzigingen aanbrengt in de Application Partition of de Configuration Partition van de Active Directory, moeten deze wijzigingen duidelijk gedocumenteerd zijn, inclusief de object class, reden van wijziging of toevoeging en waar de wijziging binnen de Partition zijn gelokaliseerd Active Directory in Application Mode 032 Voor het ontwikkelen van webapplicaties heeft het de absolute voorkeur om de Application Mode methode van Active Directory te gebruiken. Hiermee kan een scheiding worden aangebracht tussen applicatieauthenticatie (tegen de NOS AD (Network Operating System Active Directory) en applicatieconfiguratie. 4.6 Configuratie criteria Er zijn een aantal configuratie-eisen, die aan applicaties gesteld worden. Deze zijn hieronder opgesomd: CH Applicaties maken geen gebruik van vaste drive-mapping letters (zij mogen niet hard gecodeerd zijn in de applicatieprogrammatuur). Daar waar applicaties file services nodig hebben maken zij gebruik van UNC paden. Het gebruik van hard gecodeerde (UNC) paden is niet toegestaan Applicaties zijn niet afhankelijk van hard gecodeerde vaste IP adressen. Applicaties mogen geen wijzigingen doorvoeren in het operating systeem (zoals het vervangen van DLL s). Applicaties mogen geen wijzigingen doorvoeren in de beveiliging van het operating systeem (bijvoorbeeld rechten wijzigen op systeem directories). Applicaties mogen niet in systeem directories schrijven en het schrijven in programma directories moet tot een minimum beperkt blijven. Applicaties mogen geen user-escapes bevatten. Dit betekent, dat het niet mogelijk mag zijn vanuit de context van de applicatie een andere applicatie te starten of toegang te geven tot het besturingssysteem (bijvoorbeeld het starten van een command shell). De applicatiecomponenten (zover zij niet in de presentatielaag (client) worden gepositioneerd) van de applicatie dienen geautomatiseerd gestart en gestopt te kunnen worden. Het gebruik van wachtwoorden in plain text hierbij is niet toegestaan. ICT Beleid - Applicatie Criteria definitieve versie

18 4.7 Device afhankelijkheden Applicaties ondersteunen de standaard schermgrootte, kleuren en fonts van de Drechtsteden. Applicaties zijn te besturen, door uitsluitend gebruik te maken van het toetsenbord (dus zonder pointing device). Het is niet toegestaan applicaties te gebruiken, die afhankelijk zijn van machineafhankelijke configuratiemiddelen. Dit type middelen verstoren het werkplekonafhankelijke gedrag van een applicatie. Hiermee wordt o.a. bedoeld: een licentiekey in de registry; een dongle (werkplekafhankelijk, een netwerkdongle is wel toegestaan, indien deze gebaseerd is op USB technologie.); HOSTS en LOSTS files. Vanwege beperkingen op het gebruik is het niet toegestaan dat applicaties (buiten installatie om, conform installatievoorwaarden) gebruik maken van het gebruik van floppy, CD-ROM, DVD-ROM, enz. drives van een werkstation. SH 4.8 Environment variabelen Sommige (legacy-) applicaties en commandscripts maken gebruik van environmentvariabelen. Deze variabelen bevatten een aantal specifieke kenmerken voor de omgeving, waarbinnen de applicatie of script draait. 046 Binnen de infrastructuur mogen applicaties en scripts alleen gebruikmaken van de besturingssysteem systeemvariabelen en door de Drechtsteden gedefinieerde systeemvariabelen. Het is niet toegestaan zelf systeemvariabelen te definiëren. Voor het tijdelijk onthouden van gegevens is het aan scripts toegestaan gebruik te maken van environmentvariabelen. Deze environmentvariabelen zijn dan alleen geldig tijdens de looptijd van het script. 4.9 Netwerk Applicaties worden zodanig ingericht, dat gegeven het applicatietype, de belasting van het netwerk (zowel LAN als WAN) zo efficiënt mogelijk wordt ingericht (onnodige belasting wordt zoveel mogelijk voorkomen). Applicaties dienen gebaseerd te zijn op het TCP/IP protocol. Het gebruik van het Microsoft WINS protocol is niet toegestaan. Applicaties ondersteunen het gebruik van DNS namen. Applicaties moeten onafhankelijk van NetBIOS kunnen opereren. DNS en NetBIOS namen mogen niet hard gecodeerd zijn in de applicatie. Het is niet toegestaan om enige vorm van functionaliteit 8 dan wel hardware buiten de perimeter firewall te plaatsen, met uitzondering van toegestane client devices (laptops, PDA s, enz) en benodigde netwerkcomponenten om netwerkkoppelingen mogelijk te maken (o.a. met internet). Standaard FTP vanaf een client naar een server wordt niet toegestaan. 8 Uiteraard wordt hier niet gedoeld op ASP- dan wel SAAS oplossingen, deze worden aangeboden vanaf een ICT-infrastructuur in beheer van een externe partij ICT Beleid - Applicatie Criteria definitieve versie

19 Bij het ontwerp van de applicatie wordt in de architectuur rekening gehouden met de netwerkbelasting die de applicatie gaat genereren. Daar waar mogelijk wordt gebruik gemaakt van optimaliseringen in zowel ontwerp als in de technische uitwerking. ICT Beleid - Applicatie Criteria definitieve versie

20 5 Ontsluitingscriteria 5.1 Werkplek startmenu Alle applicaties dienen gestart te kunnen worden vanuit het werkplek startmenu. Webapplicaties worden indien aanwezig gestart vanuit een webportal. Bij het starten van een webapplicatie wordt de applicatie altijd in een nieuwe browsersessie gestart. Het starten van een applicatie mag een reeds gestarte applicatie niet beïnvloeden qua werking of afbreken. In het startmenu dienen alle snelkoppelingen naar applicaties te worden voorzien van een logische naam. 5.2 Ontsluiting m.b.v. DNS Applicaties die gestart worden op basis van een DNS naam, zijn altijd voorzien van een Fully Qualified Domain Name (FQDN). Alle applicaties die gestart worden m.b.v. een DNS naam, hebben een FQDN met domain naam <applicatienaam>.<domeinnaam>.nl, CH ICT Beleid - Applicatie Criteria definitieve versie