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

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 Versie Redactie Datum

Definitief 1.1 DTA (Drechtsteden Technische Architectuur) 24-10-2008

Versie 0.1 0.2 0.3

Datum 10-7-2006 02-01-2007 19-01-2007

0.9 1.0

Oktober 2007 22-01-2008

1.01

21-05-2008

1.09

5-10-2008

1.1

24-10-2008

Versie 0.9 1.0

Datum oktober 2007 12-03-2008

Versie 0.1 0.2 0.3

Datum 13-7-2006 02-01-2007 08-01-2007 19-01-2007

0.9 1.0 1.09

oktober 2007 11-03-2008 05-10-2008

Versiebeheer Wijzigingen Initiële versie. Tweede conceptversie. Wijzigingen reviewronde, Ton Voogt, Paul Zweers, Paul Goes, Matthieu Wust en John van Eck verwerkt. Versie t.a.v. MT-ICT Dordrecht (geen aanpassingen) Versie aangepast aan Drechtsteden. Definitieve versie. Integratie directoryservice aangevuld met GRID planning en afwijking Oracle standaard ter goedkeuring DTA. • •

Tekstuele wijzigingen hoofdstuk 1 en 2. Hoofdstuk 2 PMO als besluitorgaan i.p.v. WAC (Besluit PMO 17-09-2008). • 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.

Auteur Ton Voogt John van Eck John van Eck John van Eck John van Eck John van Eck

John van Eck

John van Eck

Goedkeuring Naam/Functie/Orgaan Drechtsteden Technische Architectuur (DTA) en MT-ICT Dordrecht PMO Programma IP&A Drechtsteden Formele distributie en distributie ter review 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) MT-ICT Dordrecht (ter review) PMO Programma IP&A Drechtsteden (ter vaststelling) DTA (ter review)

ICT Beleid - Applicatie Criteria – definitieve versie 1.1 – 24-10-2008

2

1.1

24-10-2008

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)


3

Inhoudsopgave INHOUDSOPGAVE ..................................................................................................................................4 1

INLEIDING ........................................................................................................................................6 1.1 1.2 1.3 1.4 1.5 1.6

2

AANLEIDING..................................................................................................................................6 DOEL .............................................................................................................................................6 INDELING EISEN .............................................................................................................................7 BRONNEN ......................................................................................................................................7 EIGENDOM ....................................................................................................................................8 OVERZICHT VEELGEBRUIKTE AFKORTINGEN .................................................................................8

PROCEDURES ..................................................................................................................................9 2.1 GEBRUIK VAN DE APPLICATIE CRITERIA BIJ AANSCHAFTRAJECTEN...............................................9 2.1.1 Toets op applicatiecriteria vóór aanschaf ............................................................................9 2.1.2 Aanschaf als onderdeel van aanbesteding............................................................................9 2.2 GEBRUIK VAN DE AC BIJ IN-HOUSE APPLICATIEONTWIKKELING ...................................................9 2.3 WIJZIGINGSPROCEDURE ..............................................................................................................10 2.4 CERTIFICERINGPROCEDURE .........................................................................................................10 2.5 GEDOOGPROCEDURE ...................................................................................................................11 2.6 ONVOORZIENE GEVALLEN EN BELANGENAFWEGING ...................................................................11

3

ORGANISATORISCHE CRITERIA.............................................................................................12 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10

4

APPLICATIEPORTFOLIO ................................................................................................................12 INDELING APPLICATIES ...............................................................................................................12 FUNCTIONALITEIT .......................................................................................................................12 IN-HOUSE APPLICATIEONTWIKKELING (ZELFBOUW) ....................................................................13 HOSTING .....................................................................................................................................13 VERVLECHTING ...........................................................................................................................13 KOPPELING MET EXTERNE SYSTEMEN .........................................................................................13 LEVERANCIERSCONTINUÏTEIT .....................................................................................................13 EIGENAARSCHAP .........................................................................................................................14 LICENTIES ...................................................................................................................................14

TECHNISCHE CRITERIA.............................................................................................................15 4.1 APPLICATIETYPES .......................................................................................................................15 4.2 APPLICATIECONTINUÏTEIT ...........................................................................................................16 4.3 VERSIENUMMERING ....................................................................................................................16 4.4 TAALVERSIE ................................................................................................................................16 4.5 AUTHENTICATIE EN AUTORISATIE ...............................................................................................16 4.5.1 Active Directory integratie .................................................................................................16 4.5.2 Active Directory Application Partition...............................................................................17 4.5.3 Active Directory in Application Mode ................................................................................17 4.6 CONFIGURATIE CRITERIA ............................................................................................................17 4.7 DEVICE AFHANKELIJKHEDEN ......................................................................................................18 4.8 ENVIRONMENT VARIABELEN .......................................................................................................18 4.9 NETWERK ....................................................................................................................................18

5

ONTSLUITINGSCRITERIA..........................................................................................................18 5.1 5.2

6

WEB- EN APPLICATIESERVER CRITERIA ............................................................................18 6.1 6.2 6.3

7

WERKPLEK STARTMENU ..............................................................................................................18 ONTSLUITING M.B.V. DNS ..........................................................................................................18 WEBSERVERS ..............................................................................................................................18 WEBSERVER IN DE DMZ .............................................................................................................18 APPLICATIESERVERS ...................................................................................................................18

DATABASE CRITERIA .................................................................................................................18 7.1

STANDAARDISATIE ......................................................................................................................18


4

7.2 DATABASETOEGANG EN RECHTEN...............................................................................................18 7.3 FILE-BASED DATABASES..............................................................................................................18 7.4 DATABASECOMMUNICATIE .........................................................................................................18 7.4.1 ODBC (Open Database Connectivity)................................................................................18 7.4.2 SQL.....................................................................................................................................18 7.5 DATABASEOBJECTEN...................................................................................................................18 7.6 ORACLE .......................................................................................................................................18 7.7 SQL SERVER ...............................................................................................................................18 7.8 MYSQL.......................................................................................................................................18 8

PLATFORM CRITERIA ................................................................................................................18 8.1 8.2 8.3 2) 8.4 3) 8.5 8.6 8.7

9

ALGEMEEN ..................................................................................................................................18 CRITERIA VOOR WEBAPPLICATIES (APPLICATIETYPE 1A).............................................................18 CRITERIA VOOR APPLICATIES DIE GEHOST WORDEN VIA SBC/SOFTGRID (APPLICATIETYPE 1B EN 18 CRITERIA VOOR APPLICATIES DIE GEHOST WORDEN VIA SOFTGRID/FATCLIENT (APPLICATIETYPE 18 CRITERIA VOOR SOFTGRID DEPLOYMENT ...................................................................................18 CRITERIA VOOR CLUSTER APPLICATIES .......................................................................................18 CRITERIA VOOR ACTIVEX COMPONENTEN ..................................................................................18

INTEGRATIE CRITERIA (KOPPELINGEN).............................................................................18 9.1 9.2

10 10.1 10.2 11

GEAUTOMATISEERDE KOPPELINGEN............................................................................................18 KOPPELINGEN MET STANDAARD KA TOEPASSINGEN ...................................................................18 INSTALLATIE CRITERIA ........................................................................................................18 INSTALLATIE PROCEDURE............................................................................................................18 INSTALLATIE VOORWAARDEN .....................................................................................................18 ONTWIKKELCRITERIA ..........................................................................................................18

11.1 ONTWIKKELPRINCIPES ................................................................................................................18 11.1.1 Ontwikkelomgevingen.........................................................................................................18 11.2 ONTWIKKELRICHTLIJNEN ............................................................................................................18 11.2.1 Ontwikkelstandaarden ........................................................................................................18 11.2.2 Bewezen technologie...........................................................................................................18 11.2.3 Hergebruik van componenten.............................................................................................18 11.2.4 N-tier applicatiemodel........................................................................................................18 11.2.5 Infrastructuuronafhankelijk................................................................................................18 11.2.6 Integratiemogelijkheden .....................................................................................................18 11.2.7 Ontwikkelmethodiek............................................................................................................18 12 12.1 12.2 12.3 13

BEHEERCRITERIA ...................................................................................................................18 BEHEERMODEL INFORMATIESYSTEMEN DRECHTSTEDEN ............................................................18 DOCUMENTATIE ..........................................................................................................................18 TOEGANG TOT APPLICATIE DOOR LEVERANCIER..........................................................................18 OPMERKINGEN .........................................................................................................................18

BIJLAGE 1 INVULLIJST CRITERIA LEVERANCIER ...................................................................18 BIJLAGE 2 INVULLIJST CRITERIA EIGENAAR ...........................................................................18


5

1

Inleiding

1.1

Aanleiding 1

Binnen de Drechtsteden 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).


6

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 (MH)– 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 16-11-2005; Baseline Informatiebeveiliging, versie 16-11-2005; Applicatieconsolidatie Mandaat, versie 0.3; Applicatieconsolidatie PID, versie 2.0; Technisch Beleidsplan ICT, versie 1.1, datum 06-04-2006; Checklist implementatie nieuwe bedrijfsapplicatie, versie 1.3, datum 02-03-2006; Protocol 1.0 ‘werken onder architectuur, versie 1.0, datum 23-05-2006; Strategisch plan IP&A Drechtsteden conceptversie 2, datum 13-12-2007; Uitgangspunten Regionale Infrastructuur versie 1.0, datum 31-08-2007; NORA 2.0, 25-04-2007; GEMMA, conform samenhangnotitie juni 2008.


7

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


8

2

Procedures

2.1

Gebruik van de Applicatie criteria bij aanschaftrajecten

2.1.1 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’ (MH) 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 (MH) 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.

2.1.2 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 (MH) 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.


9

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 2 formele toestemming van het WAG 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 MH (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: • •

2

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.

Wijzigings Advies Groep Drechtsteden


10

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 3 formele toestemming van het PMO . 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 17-09-2008), zolang dit orgaan nog niet is ingesteld, dan wel niet een evenwichtige vertegenwoordiging van alle belanghebbenden heeft.


11

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 standaarden 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. GRID/AC001

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.


MH

12

3.4

In-house applicatieontwikkeling (zelfbouw)

Het kopen van standaard software prevaleert boven in-house applicatieontwikkeling (zelfbouw), dus ‘standaard tenzij’. GRID/AC002

3.5

Indien de benodigde functionaliteit voor 80% in standaard software voorhanden is, wordt standaard software aangeschaft en wordt dus niet 4 zelf gebouwd.

MH

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. GRID/AC003

3.6

MH

Vervlechting

GRID/AC004

3.7

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.

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))

MH

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. GRID/AC005

3.8

Koppelingen met externe systemen voldoen aan de aansluitvoorwaarden van DrechtNet.

MH

Leverancierscontinuïteit

Applicaties worden pas toegestaan binnen de infrastructuur van de Drechtsteden, als de 5 continuïteit van de applicatieleverancier 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. 12-082008 Beleidsgroep Kaderstelling. 5 In dit document wordt de term (applicatie)leverancier zowel gebruikt voor externe leveranciers als interne leveranciers (in-house ontwikkelde applicaties).


13

• • • •

Er door de leverancier het benodigde onderhoud en doorontwikkeling gewaarborgd wordt; 6 Freeware 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.

GRID/AC006 GRID/AC007

3.9

Leverancierscontinuiteit dient gewaarborgd te zijn.

MH

Voor bedrijfsapplicaties dient een Escrow overeenkomst afgesloten te worden.

SH

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. GRID/AC008

Er is een (toekomstige) eigenaar van de bedrijfsapplicatie vastgesteld.

MH

3.10 Licenties De Drechtsteden dient te allen tijde te beschikken over voldoende licenties om alle gerechtigde gebruikers van een applicatie hiermee te kunnen laten werken. GRID/AC009

6

Er zijn voldoende licenties aangekocht van de applicatie voor het gebruik van de applicatie.

MH

Met de term ‘freeware’ wordt geen open-source software bedoeld.


14

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. GRID/AC010 GRID/AC011 GRID/AC012 GRID/AC013

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 MH MH SH

Vanuit de ICT infrastructuur worden er eisen gesteld t.a.v. de drie applicatietype ten aanzien van de wijze van aanbieden. GRID/AC014 GRID/AC015

GRID/AC016

GRID/AC017

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.


MH

MH

MH

MH

15

4.2

Applicatiecontinuïteit

Applicaties dienen over een zekere mate van continuïteit te beschikken. Hiervoor gelden de volgende richtlijnen: GRID/AC018 GRID/AC019 GRID/AC020

4.3

GRID/AC025

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.

MH MH

Alle applicaties beschikken over een unieke identificatie (versienummer).

MH

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).

MH MH MH MH

Taalversie

GRID/AC026

4.5

SH

Versienummering

GRID/AC021 GRID/AC022 GRID/AC023 GRID/AC024

4.4

Applicaties maken gebruik van bewezen technologie (zie ook 11.2.2).

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.

MH

Authenticatie en autorisatie 7

Let op: Active Directory intergratie is pas mogelijk na realisatie van de nieuwe GRID 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).

4.5.1 Active Directory integratie GRID/AC027 GRID/AC028 GRID/AC029

7

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 MH

Gemeenschappelijke Regionale Infrastructuur Drechsteden


16

4.5.2 Active Directory Application Partition GRID/AC030

GRID/AC031

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

MH

MH

4.5.3 Active Directory in Application Mode GRID/AC032

4.6

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.

CH

Configuratie criteria

Er zijn een aantal configuratie-eisen, die aan applicaties gesteld worden. Deze zijn hieronder opgesomd: GRID/AC033 GRID/AC034 GRID/AC035 GRID/AC036 GRID/AC037 GRID/AC038 GRID/AC039 GRID/AC040 GRID/AC041

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

MH

Applicaties zijn niet afhankelijk van hard gecodeerde vaste IP adressen.

MH

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.

MH


MH

MH

MH MH MH

MH

17

4.7

Device afhankelijkheden

GRID/AC042 GRID/AC043 GRID/AC044

GRID/AC045

4.8

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 LMHOSTS 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.

MH SH MH

MH

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. GRID/AC046

4.9

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.

MH

Netwerk

GRID/AC047 GRID/AC048 GRID/AC049 GRID/AC050 GRID/AC051 GRID/AC052 GRID/AC053 GRID/AC054

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.

MH

Het gebruik van het Microsoft WINS protocol is niet toegestaan.

MH

Applicaties ondersteunen het gebruik van DNS namen.

MH

Applicaties moeten onafhankelijk van NetBIOS kunnen opereren.

MH

DNS en NetBIOS namen mogen niet hard gecodeerd zijn in de applicatie.

MH

8

Het is niet toegestaan om enige vorm van functionaliteit 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.

MH

MH

MH

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


18

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.


19

5

Ontsluitingscriteria

5.1

Werkplek startmenu

GRID/AC055 GRID/AC056 GRID/AC057 GRID/AC058 GRID/AC059

5.2

Alle applicaties dienen gestart te kunnen worden vanuit het werkplek startmenu. Webapplicaties worden indien aanwezig gestart vanuit een webportal.

MH

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.

MH

CH

MH MH

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 .<domeinnaam>.nl,


MH MH

20

6

Web- en applicatieserver criteria

Voor applicaties van type 1 gelden de eisen t.a.v. de web- en/of applicatieserver zoals in dit hoofdstuk vermeld.

6.1

Webservers


6.2

Voor applicaties die vanaf het LAN benaderd worden dient de webserver gebaseerd te zijn op Apache (minimaal versie 1.3 of minimaal versie 2.0) of Windows IIS (gebaseerd op Windows server 2003 R2). De webserverinrichting t.b.v. de applicatie dient conform de Apache dan wel de Microsoft Server 2003 R2 Windows IIS standaardinrichting van de Drechtsteden plaats te vinden. Indien Windows IIS als webserver wordt gebruikt, dan dient als operating system Windows server 2003 R2 als platform gebruikt te worden. Indien Apache als webserver wordt gebruikt, dan dient als OS platform Red Hat Enterprise Linux (RHEL), minimaal in versie 5, gebruikt te worden.

MH MH MH MH

Webserver in de DMZ

Voor applicaties die aan externen (dus buiten het DrechtNet (LAN/MAN) en andere personen dan interne medewerkers) aangeboden worden en geen gebruik maken van het aanbieden via 9 het hosting principe van SBC (zie paragraaf 8.3) gelden een aantal extra eisen: GRID/AC066 GRID/AC067 GRID/AC068 GRID/AC069 GRID/AC070 GRID/AC071

Er dient gebruikt gemaakt te worden van een DMZ constructie, waarbij gebruikt wordt gemaakt van sessie ontkoppeling. De webserver dient gebaseerd te zijn op Apache (minimaal versie 1.3 of minimaal versie 2.0). Als OS platform dient Red Hat Enterprise Linux (RHEL) versie 5, gebruikt te worden. Zowel de webserver als het hardware OS dient specifiek gehardend te worden. In de DMZ (web) mag geen sprake zijn van opslag van gegevens.

MH

De applicatieleverancier dient bereid te zijn om medewerking te verlenen aan een onderzoek door een derde partij naar het beveiligingsmodel van de applicatie indien de Drechtsteden dit noodzakelijk acht.

MH

MH MH MH MH

9

SBC staat voor Server Based Computing, dit is een hosting principe waarbij alle applicaties op de werkplek van de eindgebruiker aangeboden worden via een centraal serverpark en dus niet op de werkplek (client) zelf worden geïnstalleerd. SBC maakt het ook mogelijk om ook voor applicaties met een client-server architectuur, dan wel webapplicaties waarvoor zogenaamde ‘plug-ins’ op de client geïnstalleerd moeten worden, concepten als flexwerken, desksharen en veilig thuis- dan wel mobiel werken mogelijk te maken.


21

6.3

Applicatieservers


Applicatieservers dienen gebaseerd te zijn op het J2EE platform of het Microsoft .Net platform. Indien een J2EE applicatieserver gebruikt wordt, dan dient als OS platform Red Hat Enterprise Linux (RHEL) versie 5, gebruikt te worden. Indien een Microsoft .Net applicatieserver gebruikt wordt, dan dient als operating system Windows server 2003 R2 als platform gebruikt te worden. Indien de applicatieserver gebaseerd is op de Oracle applicatieserver (Oracle containers for Java (OC4J)) dan dient de applicatieserverinrichting t.b.v. de applicatie conform de Oracle J2EE applicatieserver standaardinrichting te kunnen plaatsvinden. Indien de applicatieserver gebaseerd is op het Microsoft .NET platform dan dient de applicatieserverinrichting t.b.v. de applicatie conform de Microsoft .NET applicatieserver standaardinrichting te kunnen plaatsvinden.


MH MH MH MH

MH

22

7

Database criteria

7.1

Standaardisatie

In het kader van standaardisatie gaat de voorkeur uit naar zo min mogelijk verschillende databases. Binnen de Drechtsteden is voor Oracle gekozen als standaard Relational Database Management Systeem (RDBMS). Voor de ontwikkeling van nieuwe applicaties gaat de voorkeur uit naar databases op basis van Oracle. Als Oracle, voor de keuze van de database, geen optie is, wordt Microsoft SQL-server of MySQL als open source alternatief toegestaan. GRID/AC077

7.2

MH

Databasetoegang en rechten



7.3

De database van applicaties dient gebaseerd te zijn op Oracle. Indien de gewenste functionaliteit in de markt niet beschikbaar is onder Oracle, dan wel de uit een selectietraject gekozen leverancier geen Oracle als database kan aanbieden, dan kan MS SQL Server of MySQL als alternatief worden ingezet.

Toegang tot een database is voor een eindgebruiker alleen mogelijk via logische toegang door middel van een applicatie. De logische toegang van een applicatie op de database mag niet plaatsvinden d.m.v. een database user, welke ook objecteigenaar (schema-eigenaar) is. De logische toegang dient plaats te vinden via een daarvoor aangemaakte applicatie database-user met een rol waaraan beperkte rechten zijn toegekend, dan wel via een aparte database user per eindgebruiker met een rol waaraan beperkte rechten zijn toegekend. Indien een database user wachtwoord in een bestand opgeslagen dient te zijn t.b.v. het aanloggen op de database dan dient dit wachtwoord te alle tijde encrypted te worden opgeslagen. (Directe) toegang tot de database is voorbehouden aan geautoriseerde beheerders. Applicaties hebben geen toegang tot database users of rollen die bedoeld zijn voor database administrators (bijvoorbeeld de DBA rol van Oracle). Database user t.b.v. de applicatie krijgen hun rechten via een applicatiespecifieke rol, het is niet toegestaan om van voorgedefineerde rollen in de database gebruik te maken.

MH MH

MH MH MH MH

File-based databases

Het gebruik van multi-user file-based databaseapplicaties, die beschikbaar worden gesteld via een fileshare, kan potentieel een groot gevaar opleveren voor de belasting van het netwerk. (Onder multi-user wordt een applicatie verstaan waarbij meerdere medewerkers gelijktijdig gebruik kunnen maken van dezelfde database). Voorbeelden hiervan zijn applicaties op basis van de MS-Access en FoxPro databases. Deze applicaties worden in het geval van multi-user gebruik binnen de infrastructuur niet toegestaan. Het gebruik van multi-user file-based databaseapplicaties, die beschikbaar worden gesteld via een fileshare, worden dus alleen toegestaan als het single-user applicaties betreft. De applicatie wordt dan beschouwd als zijnde data. De gebruiker kan dan ook geen rechten ontlenen aan technisch of functioneel beheer. Alleen als er gegronde reden bestaat zal deze situatie worden toegestaan.


23

Het gebruik van een multi-user MS-Access applicatie, waarbij MS-Access gebruikt wordt als front-end van een RDBMS is echter wel toegestaan. Er wordt dan immers gebruik gemaakt van een ‘volwassen’ database voor dataopslag, zoals: • Oracle • MS-SQL • MySQL Zie hiervoor paragraaf 7.6 t./m 7.8. De versie van Microsoft Office waar de Drechtsteden op standaardiseert, is Microsoft Office 2003. Daar waar MS-Access dus is toegestaan, kunnen alleen applicaties geaccepteerd worden, die geschreven zijn in (of geconverteerd zijn naar) MS-Access 2003.

7.4

Databasecommunicatie

7.4.1 ODBC (Open Database Connectivity) De bovenstaande bezwaren tegen MS-Access richten zich vooral tegen het gebruik van de database en niet tegen het gebruik van het MS-Access user-interface. Voor alternatieven moet dus vooral gekeken worden naar een vervanging van de database. Het is dus toegestaan MSAccess te gebruiken als de applicatie via een ODBC-koppeling (Open Database Connectivity) gebruik maakt van een volwassen database (RDBMS) zoals aangegeven bij 8.1. MS-Access wordt dan puur gebruikt als ontwikkeltool voor de presentatielaag. ODBC is een interface laag, die het applicaties mogelijk maakt transparant met databases te communiceren. Applicaties kunnen zo ontwikkeld worden, zonder te weten tegen welke database gesproken wordt. Applicaties die gebruik maken van ODBC, mogen, vanwege compatibiliteit, stabiliteit en performance redenen, alleen gebruik maken van ODBC versie 4.00 of hoger. GRID/AC084

Applicaties die gebruik maken van ODBC mogen alleen gebruik maken van ODBC versie 4.00 of hoger.

MH

Specifiek m.b.t. ODBC zijn er een aantal onhebbelijkheden: • ODBC is niet standaard voor ieder serverplatform. • Om gebruik te kunnen maken van ODBC, is er een lokale installatie en configuratie van drivers noodzakelijk, hetgeen werkplek onafhankelijkheid en beheer moeilijk maakt. • Het configureren van een ODBC driver is veel te complex om aan standaard gebruikers over te laten. • ODBC levert problemen op het gebied van user security en data integriteit. Als de beveiliging binnen een applicatie geregeld wordt en niet op de data, is ODBC een potentieel beveiligingslek. De bovenstaande eigenschappen leggen de volgende criteria aan ODBC op: GRID/AC085 GRID/AC086 GRID/AC087 GRID/AC088

Het gebruik van ODBC op werkplekken voor applicaties van type 1 en 2 (web- en client-server applicaties) is niet toegestaan (ODBC koppelingen vanaf de SBC omgeving naar de database backend zijn wel toegestaan, maar worden afgeraden). Het gebruik van ODBC op werkplekken voor applicaties van type 3 (desktopapplicaties) is niet toegestaan. 10 Het gebruik van ODBC over het WAN is niet toegestaan.

MH

Web- applicatieservers mogen wel m.b.v. ODBC communiceren met databaseservers maar niet over het WAN.

MH

SH MH

10

WAN wordt in dit document gebruikt als term voor een vaste verbinding van een Drechtsteden locatie met het Rekencentrum Drechtsteden niet zijnde een vaste verbinding via de glasvezelinfrastructuur van DrechtNet.


24

7.4.2 SQL GRID/AC- SQL is de standaard database query-taal. MH 089 Vanwege performance redenen is het niet verstandig om communicatie via SQL over WAN toe te staan. Dit legt de volgende criteria aan het gebruik van SQL op: GRID/AC090 GRID/AC091

7.5

MH

Web/Applicatieservers mogen wel m.b.v. SQL communiceren met databaseservers maar niet over het WAN.

MH

Databaseobjecten


7.6

Het gebruik van SQL over het WAN is niet toegestaan.

Objecten die in de database t.b.v. de applicatie aangemaakt worden dienen te allen tijde aangemaakt te worden onder een owner (account) welke specifiek voor de betreffende applicatie is aangemaakt. Voor applicaties die gebruik maken van één of een beperkt aantal databaseschema’s is het gebruik van PUBLIC SYNONYMS niet toegestaan.

MH SH

Oracle

Binnen de Drechtsteden wordt gestandaardiseerd op één versie van Oracle, namelijk versie 9i, release 2, versie 9.2.0.7. Eind 2008/2009 wordt de overstap gemaakt naar Oracle10g als standaard database versie. GRID/AC094 GRID/AC095 GRID/AC096 GRID/AC097 GRID/AC098 GRID/AC099 GRID/AC100

7.7

De door de applicatie ondersteunde databaseversies dienen Oracle9i versie 9.2.0.7 en Oracle10g te zijn. Oracle11g wordt niet ondersteund door SCD A&T Beheer. De applicatieleverancier dient aan te geven welke Edition van Oracle nodig is en tevens specifiek aan te geven waarom eventueel goedkopere Editions in combinatie met de applicatie niet te gebruiken zijn. De applicatieleverancier dient aan te geven welke Oracle Database Options benodigd zijn. Als databaseserver voor Oracle dient Linux (Red Hat Enterprise Linux versie 5) en Unix (HP-UX 11.11) gebruikt te worden. De databaseinrichting t.b.v. de applicatie dient conform de Oracle database standaardinrichting van de Drechtsteden plaats te vinden. Zie hiervoor het document ‘Oracle_standaard_tbv_leveranciers.doc’. De database character set, de national character set en de optimizer mode t.b.v. de Oracle database-inrichting dienen bekend te zijn. Indien voor de applicatie een Oracle client nodig is dient de applicatie compatibel te zijn met de Oracle Client versie Oracle9i release 2.

MH MH MH MH MH MH MH

SQL Server

Binnen de Drechtsteden wordt gestandaardiseerd op één versie van SQL server, namelijk SQL Server 2005. GRID/AC- De door de applicatie ondersteunde databaseversie dient SQL server 2005 MH 101 te zijn. GRID/AC- De applicatieleverancier dient aan te geven welke versie (edition) van SQL MH 102 Server nodig is en tevens specifiek aan te geven waarom eventueel goedkopere versies in combinatie met de applicatie niet te gebruiken zijn. GRID/AC- Als databaseserver voor SQL server dient Windows Server 2003 R2 MH 103 gebruikt te kunnen worden. GRID/AC- De databaseinrichting t.b.v. de applicatie dient conform de SQL Server MH 104 database standaardinrichting van de Drechtsteden plaats te vinden.


25

7.8

MySQL

Binnen de Drechtsteden wordt gestandaardiseerd op één versie van MySQL, namelijk MySQL versie 5.0. GRID/AC105 GRID/AC106 GRID/AC107 GRID/AC108

De door de applicatie ondersteunde databaseversie dient MySQL versie 5.0 te zijn. De applicatieleverancier dient aan te geven welke versie van MySQL er nodig is en tevens specifiek aan te geven waarom eventueel goedkopere versies in combinatie met de applicatie niet te gebruiken zijn. Als databaseserver voor MySQL dient Linux (Red Hat Enterprise Linux) versie 5 gebruikt te worden. De database-inrichting t.b.v. de applicatie dient conform de MySQL database standaardinrichting van de Drechtsteden plaats te vinden.


MH MH MH MH

26

8

Platform criteria

8.1

Algemeen

GRID/AC109

GRID/AC110 GRID/AC111 GRID/AC112 GRID/AC113 GRID/AC114 GRID/AC115

8.2

Alle software die door derden wordt geleverd moet bij voorkeur gecertificeerd zijn (in het bezit zijn van een keurmerk) voor het platform (Microsoft, Linux, Citrix), waarop de applicatietiers komen te draaien. Dit betekent dat de installatie, de-installatie, het functioneren en andere aspecten voldoen aan de eisen van het platform. Het cliëntgedeelte van applicaties van applicatietypes 1b, 2 en 3 dient Windows XP Professional (SP2 en SP3) en Windows Vista compatibel te zijn. Voor het operating system van servers (webapplicatie en databaseservers) geldt dat deze ingericht dient te kunnen worden conform de daarvoor geldende standaardinrichting van de Drechtsteden. Het is niet toegestaan dat applicatieprogrammatuur bestanden/files naar systeemdirectories (inclusief de standaard tijdelijke (temp/tmp directories) van database-, web- en/of applicatieservers schrijft. Bij gebruik van de applicatie is het niet toegestaan dat er root/administrator rechten op een server nodig is. Alle hardware wordt door Service-eenheid Applicatie- en Technisch beheer van het SCD aangeschaft, tenzij Service-eenheid Applicatie- en Technisch beheer van het SCD anders overeenkomt met een applicatieleverancier. Alle hardware is in beheer bij SCD A&T Beheer, tenzij SCD A&T Beheer met de eigenaar van de applicatie hierover afwijkende afspraken maakt..

CH

MH MH MH MH MH MH

Criteria voor webapplicaties (applicatietype 1a)


Webapplicaties dienen geschikt te zijn voor Microsoft Internet Explorer versie 7.0. Webapplicaties dienen te voldoen aan de voorwaarden t.a.v. Active X componenten, zie paragraaf 8.7.

MH MH

8.3 Criteria voor applicaties die gehost worden via SBC/SoftGrid (applicatietype 1b en 2) Server Based Computing (Citrix) in combinatie met applicatievirtualisatie via Microsoft SoftGrid wordt binnen de Drechtsteden grootschalig als standaard ingezet. De hieronder genoemde criteria voor SBC zijn dus van het grootste belang voor het consistent houden van de ICT infrastructuur. GRID/AC118


Applicaties moeten voldoen aan het beveiligingsmodel van de interne Windows (XP, Vista, Windows 2003 server) architectuur. In dit model is een strikte scheiding gelegd tussen de systeemspecifieke en de gebruikersspecifieke taken die binnen het besturingsysteem draaien. Directe toegang tot hardwarematige resources, zoals harddisk, netwerkkaart, seriële en parallelle poorten, is in dit model niet meer mogelijk. Gebruik van deze resources kan alleen plaatsvinden via Windows systeemdrivers. Applicaties die de hardware rechtstreeks aanspreken worden niet toegestaan. Applicaties, welke onder SBC gebruikmaken van multimedia aspecten, zoals video en geluid, worden niet toegestaan. Indien applicaties dienen gebruik maken van APIs in het Windows Operating System dan dient gebruikt gemaakt te worden van de standaard door Microsoft meegeleverde Windows APIs. Binnen een SBC-omgeving is dit nog veel belangrijker dan binnen een standaard omgeving dat een applicatie gebruikmaakt van de standaard Windows API’s. Met behulp van dit principe is het mogelijk om zoveel


MH

MH SH

27



mogelijk gebruik te maken van de voordelen van een SBC omgeving, zoals het gebruik van ‘common resources’ (shared memory), waardoor verschillende delen van applicaties maar eenmalig in het geheugen geladen hoeven te worden en gelijktijdig door verschillende sessies gebruikt kunnen worden. Als applicaties de namen van files aan gebruikers tonen of gebruikers in staat stellen filenamen in te voeren, moet de applicatie in staat zijn om te gaan met alle toegestane Win32 filenamen, inclusief Long File Names en Universal Naming Convention (UNC) paden. Het is applicaties niet toegestaan gebruik te maken van de onderstaande, verouderde configuratie files, aangezien deze niet meer gebruikt worden door Windows XP / Windows Vista / Windows 2003 R2: • Win.ini • System.ini • Autoexec.bat • Config.sys Applicaties, die gebruikmaken van ‘polling’ van invoerapparatuur, zijn niet toegestaan. ‘Polling’ van invoerapparatuur veroorzaakt overdadig processorgebruik en veroorzaakt dus een verhoogde belasting van het netwerkverkeer binnen de SBC omgeving. Tevens gelden de specifieke criteria voor Softgrid deployment criteria, zie paragraaf 8.5.

MH

MH

MH

MH

8.4 Criteria voor applicaties die gehost worden via SoftGrid/Fatclient (applicatietype 3) GRID/AC125

GRID/AC126 GRID/AC127 GRID/AC128

GRID/AC129

8.5

Applicaties moeten voldoen aan het beveiligingsmodel van de interne Windows (XP, Vista, Windows 2003 server) architectuur. In dit model is een strikte scheiding gelegd tussen de systeemspecifieke en de gebruikersspecifieke taken die binnen het besturingsysteem draaien. Directe toegang tot hardwarematige resources, zoals harddisk, netwerkkaart, seriële en parallelle poorten, is in dit model niet meer mogelijk. Gebruik van deze resources kan alleen plaatsvinden via Windows systeemdrivers. Applicaties die de hardware rechtstreeks aanspreken worden niet toegestaan. Indien applicaties gebruik dienen te maken van APIs in het Windows Operating System dan dient gebruikt gemaakt te worden van de standaard door Microsoft meegeleverde Windows APIs. Als applicaties de namen van files aan gebruikers tonen of gebruikers in staat stellen filenamen in te voeren, moet de applicatie in staat zijn om te gaan met alle toegestane Win32 filenamen, inclusief Long File Names en Universal Naming Convention (UNC) paden. Het is applicaties niet toegestaan gebruik te maken van de onderstaande, verouderde configuratie files, aangezien deze niet meer gebruikt worden door Windows XP / Windows Vista /Windows 2003 R2: • Win.ini • System.ini • Autoexec.bat • Config.sys Tevens gelden de specifieke criteria voor Softgrid deployment, zie paragraaf 8.5.

MH

SH MH

MH

MH

Criteria voor SoftGrid deployment


Het gebruik van specifiek voor de applicatie geïnstalleerde drivers op de client of SBC omgeving is niet toegestaan. Applicaties waarbij door de gebruiker product activatie nodig is zijn niet toegestaan.


MH MH

28


8.6

MH SH

Criteria voor Cluster applicaties

GRID/AC134

8.7

Applicaties die gebruik maken van specifieke hardware kenmerken (karakteristieken) zijn niet toegestaan. Het gebruik van geavanceerde functionaliteit zoals COM, DCOM en DDE is niet toegestaan.

Cluster applicaties dienen gecertificeerd te zijn voor het clusterplatform

MH

Criteria voor ActiveX componenten

ActiveX componenten zijn applets, kleine programma’s die een bepaalde (deel)functionaliteit verzorgen. ActiveX componenten worden bijvoorbeeld gebruikt in webapplicaties. Deze componenten hebben de eigenschap, dat zij zichzelf op de werkplek kunnen installeren en configureren. Om volledige functionaliteit te kunnen bieden voor webbased applicaties zijn deze ActiveX componenten noodzakelijk binnen onze infrastructuur. Daar ActiveX componenten echter gebruikt kunnen worden voor het distribueren van virussen of code met kwade bedoelingen, zijn deze componenten een security risico. Het gebruik van ActiveX componenten wordt daarom niet toegestaan, als deze componenten benaderd worden op omgevingen buiten het netwerk van de Drechtsteden (bijvoorbeeld op het Internet). Het gebruik van ActiveX componenten is wel toegestaan, als aan de volgende eisen is voldaan: GRID/AC135 GRID/AC136 GRID/AC137 GRID/AC138

Er wordt door de applicatieleverancier gegarandeerd, dat de ActiveX componenten veilig zijn. De te gebruiken ActiveX componenten zijn gecertificeerd voor gebruik binnen de Drechtsteden. (Certificeren houdt in: “controleren of aan alle eisen die in dit document staan is voldaan”.) ActiveX componenten zijn alleen in een gebruikersomgeving te gebruiken via een webportal van de Drechtsteden (bijvoorbeeld het Intranet). Via security policies wordt de gebruikers dan toegestaan om ActiveX componenten te installeren vanaf deze specifieke webportal (trusted site). Installatie van ActiveX componenten op de fysieke werkplek (thin- en fatclient) vanaf Internet is niet toegestaan.


MH MH MH

MH

29

9

Integratie criteria (koppelingen)

9.1

Geautomatiseerde koppelingen.


9.2

Koppelingen dienen op het logische niveau (services, interfaces) gebouwd te worden Koppelingen dienen gebaseerd te zijn op open standaarden (zoals bijvoorbeeld SOAP/XML en EbXML). Het bestandsformaat van de berichten die over de geautomatiseerde koppelingen worden uitgewisseld dient gebaseerd te zijn op XML Uit te wisselen berichten dienen gebaseerd te zijn op een XML schema of DTD. Voor SOAP/XML uitwisseling geldt dat er een WDSL beschrijving aanwezig dient te zijn.

SH SH SH SH MH

Koppelingen met standaard KA toepassingen


Bij het ontwerp van software dient rekening gehouden te worden met de mogelijkheden van integratie met standaard KA toepassingen (Microsoft Office 2003). Bij integratie met standaard KA toepassingen (denk o.a. tekstverwerker en mail) dient gebruik te worden gemaakt van de standaard aanwezige programmeerinterfaces (APIs).


SH SH

30

10

Installatie criteria

10.1 Installatie procedure GRID/AC146

Applicaties zijn altijd voorzien van een duidelijke en gedocumenteerde installatie procedure.

MH

10.2 Installatie voorwaarden GRID/AC147

Voordat installatie plaatsvindt op de ICT infrastructuur van de Drechtsteden dient voldaan te zijn aan alle voorwaarden zoals gesteld in de document ‘Installatievoorwaarden van de Drechtsteden’.


MH

31

11

Ontwikkelcriteria

11.1 Ontwikkelprincipes 11.1.1 Ontwikkelomgevingen GRID/AC148 GRID/AC149 GRID/AC150 GRID/AC151

Het onderhoud op applicaties binnen de ICT-infrastructuur mag nooit plaatsvinden in de productieomgeving. De Test-, Ontwikkel- en Acceptatie- omgevingen moeten dus volledig logisch en fysiek gescheiden zijn van de productieomgeving. Voor bedrijfsapplicaties geldt dat het minimale aantal omgevingen altijd bestaat uit een acceptatie- en een productieomgeving. Ontwikkelaars zijn niet gerechtigd om binnen de test-, acceptatie- en productieomgeving ontwikkelwerkzaamheden uit te voeren.

MH MH MH MH

11.2 Ontwikkelrichtlijnen In deze paragraaf worden een aantal algemene ontwikkelrichtlijnen meegeven voor de ontwikkeling van applicaties. Deze hebben de status van aanbeveling (CH). Ze gelden voor zowel in-house bouw als bouw die uitbesteedt wordt aan externe leverancier.

11.2.1 Ontwikkelstandaarden Bij het ontwikkelen van software wordt gebruik gemaakt van (open) standaarden. Hiermee wordt gewaarborgd dat: • de integratie van applicaties, applicatiecomponenten en infrastructuur eenvoudiger gerealiseerd kan worden en dat de onderlinge uitwisselbaarheid vergroot wordt; • de afhankelijkheid van bepaalde producten en leveranciers kleiner wordt; • de programma’s flexibeler en opener worden; • de continuïteit op de langere termijn verzekerd is; • veranderingen in de software beter worden begroot en efficiënter kunnen worden doorgevoerd. Functionele softwarecomponenten worden zodanig ontworpen dat ze via gedefinieerde services (interfaces) met elkaar kunnen communiceren en een samenhangend geheel vormen (service oriented architecture). De componenten en hun services worden gestandaardiseerd. Door de standaardisatie van componenten en services, alsmede het gebruik van een standaard ontwikkelmethodiek en het gebruik van generieke functionaliteit, wordt gewaarborgd dat de complexiteit van de software laag blijft. Ontwikkelaars kunnen zich toeleggen op een gedefinieerde functionele component en kunnen daardoor een beter overzicht houden op het op te leveren deel. Wijzigingen zullen doorgaans ook slechts een beperkt aantal componenten beslaan en daardoor eenvoudiger door te voeren en te testen zijn.

11.2.2 Bewezen technologie Bij het ontwikkelen van software wordt gebruik gemaakt van in de markt bewezen en algemeen geaccepteerde methodologie en technologie. Door gebruik te maken van bewezen technologie wordt gewaarborgd dat de continuïteit op de langere termijn verzekerd is en dat desinvesteringen in de softwareontwikkeling voorkomen worden. Door gebruik te maken van bewezen methodologie is de afhankelijkheid voor het onderhoud beperkter.

11.2.3 Hergebruik van componenten Er wordt naar gestreefd om zoveel mogelijk algemene functionaliteit onder te brengen in gestandaardiseerde componenten. Deze componenten worden geschikt gemaakt voor hergebruik. Dit heeft het voordeel dat niet steeds opnieuw het wiel uitgevonden hoeft te worden. Het ontwikkelproces kan hiermee versneld worden en de kosten vallen lager uit. Het ontwikkelproces zal enerzijds generieke componenten moeten opleveren en anderzijds zal het


32

de reeds gerealiseerde (en gepubliceerde) componenten moeten gebruiken. Dit vanuit het oogpunt van kwaliteit, financiën en doorlooptijd. Als een bepaalde functionaliteit reeds wordt ingevuld door een bepaalde component, dan is het niet toegestaan alternatieve componenten voor deze functionaliteit te ontwikkelen.

11.2.4 N-tier applicatiemodel Bij de ontwikkeling van nieuwe applicaties wordt bij voorkeur uitgegaan van een n-tier applicatiemodel. In dit model worden in ieder geval drie logische lagen onderscheiden: de presentatielaag (zorgt voor de afhandeling van de presentatie van de applicatie naar de gebruiker), de verwerkingslaag (hierin is de bedrijfslogica verwerkt) en de gegevenslaag (zorgt voor de gegevensopslag).

11.2.5 Infrastructuuronafhankelijk De ontwikkelingen binnen de Drechtsteden, zorgen de komende jaren voor een continue verandering op infrastructureel gebied. Bij de ontwikkeling van software moet hierop ingespeeld worden, zodat de software zo veel mogelijk onafhankelijk is van de onderliggende infrastructuur. Software moet eenvoudig geschikt gemaakt kunnen worden voor verschillende typen media. Men mag er niet vanuit gaan, dat software alleen op desktops of laptops moet kunnen functioneren. Ook nieuwere typen werkplekken, zoals handhelds (PDA’s), tablet PC’s en smartphones moeten ondersteund kunnen worden.

11.2.6 Integratiemogelijkheden Integratie van verschillende applicaties kan op verschillende niveaus plaatsvinden: op de datalaag, logicalaag en op de presentatielaag. Bij integratie op de datalaag wordt op laag niveau data tussen applicaties uitgewisseld, meestal op databaseniveau, deze vorm van koppelen wordt ten zeerste afgeraden, vanwege de grote beheerinspanning, gevaren voor dataintegriteit en beperkte mogelijkheden tot hergebruik. Bij integratie op logicaniveau wordt het mogelijk om bepaalde functionaliteit gemeenschappelijk te gebruiken (zie hiervoor de integratiecriteria in hoofdstuk 9). Bij integratie op presentatieniveau wordt het mogelijk om van het ene programma naar het andere programma te schakelen. Bij het ontwerpen van software wordt rekening gehouden met de integratie van standaard toepassingen. Denk hierbij aan tekstverwerking, presentatietools, e-mailclient, etc. Er mag uitsluitend geïntegreerd worden met deze standaard toepassingen door gebruik te maken van gestandaardiseerde programmeer interfaces.

11.2.7 Ontwikkelmethodiek Bij het ontwikkelen van applicaties wordt bij voorkeur gebruikt gemaakt van onderstaande best practices: • Gebruik van een ontwikkel methodiek, zoals Rational Unified Process (RUP) of Dynamic Systems Development Method (DSDM); • Projectbeheersing (bijvoorbeeld Prince2); • Softwarekwaliteitscriteria conform Quint/ISO; • Gebruik van patterns; • Gebruik van een standaard ontwikkelframework; • Gebruik van conventies (naamgeving, code, enz.);


33

12

Beheercriteria

12.1 Beheermodel Informatiesystemen Drechtsteden GRID/AC152

De taken, verantwoordelijkheden en bevoegdheden t.a.v. het beheer dienen te zijn georganiseerd conform het document ‘Beheermodel Informatiesystemen Drechtsteden’. Dit houdt o.a. in dat : • Iedere applicatie een functionele beheerder heeft, die verantwoordelijk is voor de functionaliteit van de applicatie; • Iedere applicatie heeft een technische beheerder heeft, die verantwoordelijk is voor het technisch functioneren van de applicatie; • Iedere applicatie heeft een applicatie beheerder heeft, die verantwoordelijk is voor het onderhoud van de applicatie; • Voor iedere applicatie een eigenaar aangewezen is;

MH

12.2 Documentatie GRID/AC153

Alle applicaties beschikken over alle noodzakelijke documentatie, waaronder in ieder geval de volgende handleidingen conform onderstaande tabel ‘Documentatie’.

Tabel ‘Documentatie’ Documentatie Installatie handleiding Configuratie handleiding Beheer handleiding Gebruikers handleiding

Taal Nederlands Nederlands Nederlands of Engels Nederlands

Beschrijving applicatie architectuur

Nederlands of Engels

Technische beschrijving services/interfaces

Nederlands of Engels

MH

Opmerkingen

Dit kan ook een helpfile zijn, die vanuit de applicatie opgeroepen kan worden. Beschrijving van de applicatie in zijn technische hoofdcomponenten (tiers en interfaces). Documentatie van de specificatie van de service/interface, gebruikte protocollen en relevante objecten.

12.3 Toegang tot applicatie door leverancier GRID/AC154

Soms is het voor het onderhouden van een applicatie of dienst noodzakelijk, dat de leverancier van de applicatie toegang krijgt tot een systeem van de Drechtsteden. In dat geval wordt de (fysieke) toegang tot het systeem verstrekt door de Service-eenheid Applicatie- en technisch beheer van het SCD. Het is niet toegestaan de applicatieleverancier toegang tot een systeem te verlenen via het Internet of een modemkoppeling.


MH

34

13

Opmerkingen

Het is mogelijk om in aanschaftrajecten naast de functionele eisen nog additionele criteria op te stellen voor aan te kopen software, zoals bepaalde certificering van leveranciers, het hanteren van een bepaalde ontwikkel- projectmethodiek door leverancier, bewezen ervaring met bepaalde platforms & producten, enz. Het opstellen van dit soort criteria gebeurd normaal gesproken in overleg met het aankopende organisatieonderdeel, Service-eenheden IAB en IVT en Service-eenheid Inkoop & Aanbesteding van het Servicecentrum Drechtsteden. Eventueel kunnen andere organisatieonderdelen betrokken zijn.


35

Bijlage 1 Invullijst criteria leverancier Bijlage 1 is bedoeld voor de leverancier om aan te geven of aan een eis of wens uit dit document wordt voldaan en tevens om een korte toelichting te geven (dit betreft alleen de eisen en wensen die relevant zijn voor de leverancier, er zijn namelijk ook een aantal eisen en wensen die specifiek bedoeld zijn voor de toekomstige applicatie-eigenaar). In de toelichting bij de eis of wens dient bij ‘Ja’ aannemelijk gemaakt te worden waarom voldaan wordt aan de eis of wens. Er mag verwezen worden naar documentatie die met de ‘invullijst criteria leverancier’ aangeleverd zal worden (graag hoofdstuk of paragraaf aangeven waarnaar verwezen wordt). Bij een ‘nee’ op Must Have eisen dient aangegeven te worden waarom niet aan de eis wordt voldaan. Onderstaand wordt alleen het template van de invullijst getoond. De in te vullen lijst is opgenomen in een apart Word document met de bestandsnaam ‘Bijlage 1 invullijst leverancier Applicatiecriteria.doc’. Dit om het invullen te vergemakkelijken. Nummer GRID/AC-000

Eis / Wens MH

Voldaan

Toelichting

Ja / Nee


36

Bijlage 2 Invullijst criteria eigenaar Bijlage 2 is bedoeld voor de toekomstige eigenaar van de applicatie om aan te geven of aan een eis of wens uit dit document wordt voldaan en tevens om een korte toelichting te geven (dit betreft alleen de eisen en wensen die specifiek bedoeld zijn voor de toekomstige eigenaar van de applicatie, de overige eisen en wensen zijn bedoeld voor de leverancier van de applicatie). In de toelichting bij de eis of wens dient bij ‘Ja’ aannemelijk gemaakt te worden waarom voldaan wordt aan de eis of wens. Er mag verwezen worden naar documentatie die met de ‘invullijst criteria eigenaar’ aangeleverd zal worden (graag hoofdstuk of paragraaf aangeven waarnaar verwezen wordt). Bij een ‘nee’ op Must Have eisen dient aangegeven te worden waarom niet aan de eis wordt voldaan. Onderstaand wordt alleen het template van de invullijst getoond. De in te vullen lijst is opgenomen in een apart Word document met de bestandsnaam ‘Bijlage 2 invullijst eigenaar Applicatiecriteria.doc’. Dit om het invullen te vergemakkelijken. Nummer GRID/AC-000

Eis / Wens MH

Voldaan

Toelichting

Ja / Nee


37

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

Recommend Documents