Standaardpakketten en architectuur

Standaardpakketten en architectuur Checklist voor pakketselectie Publicatie van de CIO Interest Group Architectuur CIO Platform Nederland, juni 2012 www.cio-platform.nl/publicaties CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012

Van de opstellers Architecten wordt vaak gevraagd te participeren in pakketselectietrajecten. Onderdeel van dergelijke selectietrajecten is het toetsen van het pakket (of de pakketten) aan de bestaande architectuur, (de baseline architecture in TOGAF). Om deze toetsing te ondersteunen heeft de CIO Interest Group (CIG) Architectuur van het CIO Platform Nederland een checklist opgesteld. Hiermee kan op een objectieve manier worden getoetst in hoeverre pakketten kunnen worden ingepast in de bestaande architectuur. De uitkomsten van deze toetsing kunnen vervolgens gebruikt worden om richting de stakeholder(s) de impact van de selectie te specificeren. De checklist kan ook worden verstrekt aan de leveranciers zodat zij hem zelf kunnen invullen waarna de architect de antwoorden kan verifiëren. Met de collectieve kracht en kennis van onze CIG zijn wij van mening dat we met deze checklist een waardevolle publicatie hebben voor de CIO. Naast bruikbaarheid voor de CIO zijn veel van de publicaties van het platform een belangrijke informatiebron voor het procurement traject. Andere CIGs hebben ook diverse publicaties opgeleverd. Allemaal onstaan uit de ambitie van het CIO Platform om onze kennis gemeenschappelijk te maken en elkaars ervaring te delen. De bijeenkomsten van de CIGs zijn altijd inspirerend en leerzaam en deze publicatie is het resultaat van een aantal bijeenkomsten. Naast het resultaat in de vorm van deze publicatie heeft het proces er naar toe velen van ons als professional verrijkt. Dank aan onze organisaties om ons op deze manier te mogen ontwikkelen in onze professionaliteit! De opstellers (zie pagina 18). CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 3 van 19

Inhoudsopgave 1! Aanleiding en vraag... 5! 2! Leeswijzer... 6! 3! Applicatieprincipes... 7! 3.1! Geen functionele redundantie... 7! 3.2! Ieder pakket heeft een functionele eigenaar... 7! 3.3! Architectuurovereenstemming... 7! 4! Pakket Toetsingscriteria... 8! 4.1! Intregratie... 8! 4.2! Lokalisatie... 9! 4.3! User Interface... 10! 4.4! Security... 11! 4.5! Service levels... 13! 4.6! Leverancier... 14! 4.7! Technologie... 15! 4.8! Aanpasbaarheid... 17! 5! Deelnemers CIG Architectuur... 18! CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 4 van 19

1 Aanleiding en vraag De CIG Architectuur is een actieve CIG binnen het CIO Platform met gemiddeld drie bijeenkomsten per jaar en altijd een hoge opkomst. De bijeenkomsten zijn altijd op een locatie van een van de leden. Binnen deze CIG worden concrete cases van de gastheer of gastvrouw besproken en vaak worden daarnaast vraagstukken van de leden behandeld en waar mogelijk verwerkt in publicaties. In een van de bijeenkomsten kwam de vraag hoe omgegaan wordt met het mappen van standaardpakketten op de vigerende architectuur van de organisatie. Dit bleek bij veel leden te spelen en daarom is in september 2011 een uitvraag gedaan onder de CIO s van het platform. Hoe ga je om met de implementatie van standaardpakketten binnen de architectuur van je organisatie? Er kwamen veel reacties en we zijn als CIG aan de slag gegaan om te komen tot een lijst met toetsingscriteria voor pakketselectietrajecten. Belangrijke constatering uit dit onderzoek is dat deze criteria voor heel veel leden dezelfde blijken te zijn. We willen onze leden een behapbare set met handvatten geven om ze te helpen bij dit soort, vaak complexe, trajecten. Een subgroep vanuit de CIG Architectuur is vervolgens aan de slag gegaan met een verbijzondering op de principes op basis van de reacties. Deze zijn daarna geaggregeerd tot een bruikbare checklist die in deze publicatie is opgenomen. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 5 van 19

2 Leeswijzer Ervaring heeft geleerd dat het verstandig is om (vooraf) een ranking model op te stellen zodat resultaten zeker als meerdere pakketten worden getoetst zo objectief mogelijk kunnen worden vergeleken en beoordeeld. Een optie is bijvoorbeeld om elk antwoord te scoren (1 5) gebaseerd op compliancy voor de desbetreffende vraag. In hoofdstuk 3 is een drietal principes gedefinieerd dat gehanteerd kan (zou moeten ) worden bij de initiële selectie van de applicatie. Deze principes hebben te maken met functionaliteit en governance. Het zijn dus geen technische criteria. In hoofdstuk 4 worden (technische) architectuurtoetsingscriteria benoemd. Ten behoeve van de overzichtelijkheid zijn deze gebundeld in de volgende hoofdgroepen: Integratie Lokalisatie User interface Security Service levels Leverancier Technologie Aanpasbaarheid De in dit document genoemde toetsingscriteria zijn vooral gebaseerd op ervaringen van (de organisaties van) de opstellers van dit document. Uiteraard zijn niet altijd alle toetsingscriteria overal van toepassing. Dit is afhankelijk van de applicaties die getoetst moeten worden en/of de organisatie waarin de architect werkzaam is. Ook is de lijst niet uitputtend: het is aan de architect om dit te beoordelen en de lijst aan te passen / uit te breiden waar gewenst en nodig. Benoemen van specifieke pakketten of technologieën is in dit document zo veel mogelijk vermeden. Verwezen wordt dan naar pakket x <van organisatie> of technologie x <van organisatie>. Je dient hier (indien van toepassing) dan het door jouw organisatie gebruikte pakket of de gebruikte technologie te vermelden. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 6 van 19

3 Applicatieprincipes Hoewel dit document zich richt op de toetsing van de applicatie op nonfunctionele criteria, zijn er drie principes die gebruikt kunnen worden in de functionele toetsing van een applicatie. 3.1 Geen functionele redundantie De inzet van een pakket mag niet leiden tot ongewenste functionele redundantie in het applicatielandschap. Het pakket wordt ingezet voor nieuwe functies of ter vervanging van bestaande functies. 3.2 Ieder pakket heeft een functionele eigenaar Er moet in de business één persoon of orgaan zijn waaraan de ICT afdeling rapporteert over het pakket. Dit is over het algemeen ook de persoon die het budget voor het pakket fourneert. Een pakket zonder functionele eigenaar in de business zal onvermijdelijk leiden tot problemen in de bedrijfsvoering rondom dit pakket. 3.3 Architectuurovereenstemming De applicatie moet passen binnen de algemene architectuur die het bedrijf nastreeft. Denk hierbij aan architectuuruitgangspunten als SaaS unless, Service Oriented Architecture et cetera. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 7 van 19

4 Pakket Toetsingscriteria De volgende toetsingscriteria kunnen worden gehanteerd bij het classificeren van een pakket voor de inpassing in de bestaande architectuur. Als een pakket NIET aan één of meer van deze toetsingscriteria voldoet betekent dit niet dat het pakket niet voldoet, maar dat inpassing in de bestaande architectuur tot meer inspanning en daarmee gerelateerde kosten zal leiden. 4.1 Intregratie Omdat vrijwel ieder pakket moet integreren met bestaande applicaties is het integratievermogen van het pakket een belangrijk toetsingscriterium. 4.1.1 Aanbieden van services Het pakket is in staat om gegevens en algoritmen, beheerd binnen het pakket, te ontsluiten via standaard web services. Deze web services voldoen aan alle geldende SOA standaarden. 4.1.2 Aanroepen van services Het pakket is in staat om gegevens en algoritmen, niet beheerd binnen het pakket, te gebruiken via de aanroep van web services. 4.1.3 Office suites Het pakket biedt integratie met de Office suite <van organisatie>, email, kalender en contact oplossingen die in gebruik zijn binnen <de organisatie>. Denk hierbij ook aan plug-ins die integratie vanuit de Office suite <van organisatie> naar het pakket faciliteren. 4.1.4 Import faciliteiten Het pakket biedt voorzieningen om bulk-invoer te faciliteren via importfaciliteiten. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 8 van 19

4.1.5 Exportfaciliteiten Het pakket biedt de mogelijkheid om alle informatie, beheerd binnen het pakket, te exporteren naar een vooraf gedefinieerd standaard formaat. 4.1.6 Applicaties worden geïntegreerd door middel van een integration broker. Alle gegevensuitwisseling van en naar centrale informatiesystemen geschiedt via een integration broker. De applicaties worden, indien nodig, real-time gekoppeld. Hierbij bepaalt het proces de benodigde snelheid. Business logica ten behoeve van de gegevensuitwisseling wordt in de integration broker geïmplementeerd en niet in de applicaties. Voor de integratie wordt gebruik gemaakt van internationaal geaccepteerde industrie standaarden. 4.2 Lokalisatie Als het gebruik van pakketten de landsgrenzen overschrijdt, dient het pakket hierop getoetst te worden. 4.2.1 Talen Het pakket wordt aangeboden in de talen die voor het bedrijf relevant zijn en de gebruikers kunnen daaruit hun eigen taal kiezen. 4.2.2 Lokalisaties Bij de implementatie van het pakket kunnen die lokalisaties (currency sign, decimal separator, date notation, etc.) gekozen worden die voor <de organisatie> relevant zijn. 4.2.3 Multi-byte Het pakket ondersteunt multi-byte karakter sets zodat ook opslag en weergave van talen als Chinees, Thais etc. mogelijk is. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 9 van 19

4.2.4 Tijdzones Het pakket is volledig voorbereid op het gebruik in meerdere tijdzones. Tijden worden opgeslagen in UTC (Universal Time Coordinated) en alleen bij weergave of invoer worden lokale tijden gebruikt. Business rules (b.v. einde transactie ligt ná begin transactie) zijn gebaseerd op UTC, zodat einde zomertijd niet tot problemen leidt. 4.3 User Interface Om te zorgen dat de implementatie van het pakket zo soepel mogelijk verloopt is de user interface van cruciaal belang. 4.3.1 Zelf verklarend Het pakket is zodanig opgezet dat met minimale training de gebruiker in staat is om het pakket correct te bedienen. 4.3.2 Help functies Het pakket biedt naast een standaard helpfunctie met zoekmogelijkheid ook context sensitive help functies, balloon-tips met hover -functie aan. 4.3.3 Help functies voor beheerders. Naast eindgebruikers helpfuncties biedt het pakket een uitgebreide helpfunctie voor de beheerders. 4.3.4 Technische documentatie Technische documentatie dient beschikbaar, compleet en van voldoende kwaliteit te zijn om technisch beheer door <de organisatie> mogelijk te maken. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 10 van 19

4.3.5 Functionele documentatie Functionele documentatie dient beschikbaar, compleet en van voldoende kwaliteit te zijn om functioneel beheer door <de organisatie> mogelijk te maken. 4.3.6 (Muis) navigatie Het aantal schermen/muiskliks dat nodig is om door het systeem te navigeren dan wel transacties in te voeren biedt een optimale balans tussen flexibiliteit en complexiteit van het systeem. 4.3.7 User interface De user interface van de applicatie is in lijn met de user interface van de overige applicaties binnen de organisatie. De user interface is aanpasbaar aan de huisstijl van <de organisatie>. Een gebruiker hoeft niet te schakelen tussen meerdere user interfaces voor uitvoering van een werkproces. 4.3.8 Portal technologie De applicatie is goed te integreren in de portaltechnologie die in de organisatie wordt gebruikt voor ontsluiting van informatie. 4.4 Security Applicaties dienen te voldoen aan het informatiebeveiligingsbeleid van <de organisatie>. 4.4.1 Checklist informatiebeveiliging CIO Platform De applicatie is getoetst aan de checklist Informatiebeveiliging van het CIO Platform Nederland. Te downloaden vanaf de website www.cio-platform.nl. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 11 van 19

4.4.2 Integriteit De integriteit van gegevens dient gewaarborgd te worden. Zowel door strenge toegangscontroles (zie volgende paragraaf), door controle- en auditmechanismen en eventueel met behulp van technische voorzieningen. Maatregelen ten behoeve van deze integriteitswaarborgen dienen in lijn te zijn met het desbetreffende beleid van <de organisatie>. 4.4.3 Invoercontrole Het pakket biedt invoercontroles die voorkomen dat niet-integere informatie in het systeem wordt ingevoerd. Dit dient ook te voorkomen dat ongewenste duplicaten in het systeem ontstaan. Dit geldt zowel voor online als batchinvoer. 4.4.4 Auditing Alle transacties die in het systeem ingevoerd worden zijn te herleiden naar specifiek tijdstip van transactie en de persoon die de transactie heeft uitgevoerd. 4.4.5 Vertrouwelijkheid Gegevens zijn beschermd tegen ongeautoriseerde toegang en gebruik. Dit vraagt dat het pakket garandeert dat toegang tot het pakket alleen is voorbehouden aan de daartoe geautoriseerde gebruikers. Hierbij dient de toegang afgestemd te kunnen worden op het benodigde en gewenste gebruik van het pakket. 4.4.6 Directory integratie De pakketoplossing kan geïntegreerd worden met de standaardoplossingen voor identity- en accessmanagement van <de organisatie>. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 12 van 19

4.4.7 Strong authenticatie Bij SaaS-oplossingen moet het moet mogelijk zijn om strong (two-factor) authenticatie in te richten, gebaseerd op de door de organisatie ingerichte infrastructuur. Dit om te voorkomen dat alleen het achterhalen van een wachtwoord voldoende is voor toegang tot het pakket. 4.4.8 Wet- en regelgeving Het pakket moet op beveiligingsgebied (met name privacy) voldoen aan de weten regelgeving van toepassing voor <de organisatie>. 4.5 Service levels 4.5.1 Beschikbaarheid De beschikbaarheid van het pakket moet in lijn gebracht kunnen worden met de business requirements m.b.t. beschikbaarheid. Indien nodig, moet het pakket 24x7 beschikbaar ingericht kunnen worden (in- of exclusief onderhoudsvensters). 4.5.2 Support De leverancier biedt een support aan gedurende de tijden die noodzakelijk zijn voor de ondersteuning van het pakket. Voor globale organisaties zal dit vaak neerkomen op 24x365 support voor alle supportvragen (om te voorkomen dat men in andere delen van de wereld overdag geen functionele vragen kan stellen). De support dient, desgewenst, ook beschikbaar te zijn in verschillende talen. 4.5.3 Clustering, fail-over, disaster recovery Het pakket biedt heldere mogelijkheden om de beschikbaarheid van het pakket op het gewenste niveau te brengen. Dit betekent dat het pakket op een geclusterde omgeving moet kunnen draaien en dat de leverancier duidelijke instructies heeft hoe een fail-over en/of disaster recovery voorziening ingericht dient te worden. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 13 van 19

4.5.4 Archivering en opschoning Het pakket dient voorzieningen te bieden om historische data uit het systeem te archiveren en te verwijderen uit het online transactiesysteem. Retention policies moeten leidend zijn voor het (evt. via automatische scheduling) uitvoeren van archiverings- en opschoningsacties. Bij uitfaseren van de applicatie moet het mogelijk zijn de data in leesbare vorm te behouden. 4.5.5 User provisioning Het pakket moet mogelijkheden bieden voor externe user provisioning om te voorkomen dat <de organisatie> iedere gebruiker in alle pakketten separaat moet opvoeren. Dit moet de Identity- en Access Management oplossingen en processen van <de organisatie> optimaal ondersteunen. 4.5.6 Performance en schaalbaarheid Het pakket moet zodanig schaalbaar zijn dat de performance van de applicatie volledig in lijn is met de performance eisen die <de organisatie> aan de applicatie stelt. 4.6 Leverancier Naast het pakket zelf, dient de leverancier op een aantal elementen getoetst te worden. Dit betreft enerzijds standaard leverancierschecks door de afdeling inkoop, die voor iedere leverancier gelden (stabiliteit, concernstructuur, omvang, locatie, gebruikte taal, etc.). Daarnaast is er voor pakketleveranciers een aantal aanvullende toetsingscriteria van toepassing: 4.6.1 Implementatie support De leverancier biedt uitgebreide implementatieondersteuning via eigen serviceafdeling of via een partnernetwerk. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 14 van 19

4.6.2 Release planning De leverancier heeft een duidelijke releaseplanning. Ook de impact van upgrades naar nieuwe releases wordt duidelijk beschreven. Onderscheid dient gemaakt te worden in het proces van het aanbrengen van fixes, minor en major releases. 4.6.3 Certificeringen en audits Voor SaaS pakketten is het essentieel dat de leverancier aantoont dat de processen en techniek voor het aanbieden van de dienst ISO-27001 gecertificeerd zijn en dat SAS Type II audit reports beschikbaar zijn. 4.6.4 Exit strategie De SaaS provider heeft een duidelijk beschreven exitstrategie, die bij voorkeur kostenloos en eenvoudig te realiseren is. Klanten zouden zonder moeilijke omwegen naar een andere provider moeten kunnen overstappen en eenvoudig aan hun data moeten kunnen komen. 4.6.5 Lokatie van de opgeslagen data Het moet ten allen tijde duidelijk zijn waar de data van de klant wordt opgeslagen. Dit om specifieke regelgeving omtrent de data locaties te kunnen toetsen. 4.7 Technologie Om vast te kunnen stellen in welke mate het pakket past binnen de huidige technologie architectuur, dient het pakket getoetst te worden op een aantal aspecten. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 15 van 19

4.7.1 Hosting Het pakket is te implementeren met gebruikmaking van de huidige technologie bouwstenen gebruikt in de hosting omgeving van de organisatie. Denk hierbij aan: Server hardware Server operating systeem Virtualisatieplatform Database management systeem Integratie suite (Tibco, Webmethods, etc.) 4.7.2 Netwerk De bandbreedte en latency requirements en beperkingen van het pakket zijn vooraf bekend en passen binnen de beschikbare bandbreedte en latency situatie van <de organisatie>. 4.7.3 Client access Het pakket draait op de client werkstations die door de organisatie ondersteund worden of in de toekomst ondersteund gaan worden. Denk hierbij ook aan mobility platformen als ios, Android, Windows Mobile, Symbian. 4.7.4 Web-based Voor web-based applicaties: het pakket is te gebruiken met alle geaccepteerde webbrowsers en hun meest courante versies (2012: Internet Explorer, Chrome, Firefox, Safari). 4.7.5 Ontwikkelomgeving Het uitgangspunt is dat de functionaliteit van de applicatie zodanig past bij <de organisatie> dat geen maatwerk benodigd is. Bij maatwerk moet kenbaar worden gemaakt welke ontwikkelomgeving is gebruikt bij de realisatie van de applicatie en dient in lijn te zijn met reeds beschikbare ontwikkelomgevingen in <de organisatie>. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 16 van 19

4.8 Aanpasbaarheid Voor veel pakketten is het noodzakelijk om ze zodanig aan te kunnen passen dat ze beter aansluiten bij de processen van <de organisatie>. Voor een aantal pakketten zal dit niet relevant zijn. 4.8.1 Customizations Het pakket is aan te passen naar de specifieke bedrijfsvoering van <de organisatie>, als de standaard functionaliteit niet voldoet en de aanpassing noodzakelijk is. 4.8.2 Upgrades Bij upgrades moeten aangebrachte customizations automatisch meegenomen worden naar de nieuwe versie. 4.8.3 DTAP strategie Het pakket moet duidelijke richtlijnen bieden voor het opzetten van Development, Test, Acceptatie en Productie (DTAP) omgevingen. Ook dient helder te zijn hoe customizations de diverse stappen in het ontwikkelproces doorlopen. CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 17 van 19

5 Deelnemers CIG Architectuur Organisatie Voornaam Achternaam Océ Louis Anderson Ministerie van Infrastructuur en Milieu Robert Bennis SHV Michel Boudewijns Royal Vopak Lambert Caljouw LUMC Rob Cornelisse Belastingdienst Martijn de Bruijne APG Hans de Weme Koninklijke Boskalis Westminster N.V. Alexander den Hartog UMC Utrecht Marco Deterink Athlon Car Lease Nederland Robert Diependaal Enexis B.V. Louis Dietvorst Rabobank Nederland Rob Douwes Essent IT B.V. Maurice Herben Delta N.V. Paul Hoekman Randstad Holding Hans Hoogerhuis ABN AMRO Bank Henk Houtzager De Nederlandsche Bank Henrik Jacobsson LUMC Martin Kalshoven LUMC Ursula Letschert PGGM Richard Lugtigheid Ministerie LNV Karin Middeljans AkzoNobel N.V. Dolf Moonen UMC Utrecht Klaas Nieuwhof Transavia.com Hans Pasker Nederlandse Spoorwegen Pascal Reijnders UWV Mario Seekles NXP Semiconductors Netherlands B.V. Theo Smit Gemeente Haarlemmermeer Jan ten Kate UWV Peter Valkenburg CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 18 van 19

(vervolg deelnemers CIG Architectuur) Organisatie Voornaam Achternaam UMC Utrecht Leon van der Zande ANWB Walter van Duyneveldt Heineken International Henri van Lambalgen ECT Jan van Ommeren Heijmans Nederland B.V. Wim van Son LUMC Gieneke van Veenen Nederlandse Gasunie N.V. Bernd Veenstra Nutreco Guido Verdijck Kluwer Kees-Jan Voogd PostNL Peter Vos Koninklijke BAM Groep N.V. Minto Witteveen Ymere Walter Wittkamp Stork Peter Zaat CIO Platform Rik van Embden CIO Platform Ronald Verbeek CIO Platform Foppe Vogd CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012 - pagina 19 van 19

De vereniging van ICT eindverantwoordelijken in grote organisaties van de vraagzijde www.cio-platform.nl CIG Architectuur - Standaardpakketten en architectuur - CIO Platform Nederland - juni 2012