Standaardpakketten en architectuur

CIG 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

CIG Architectuur

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

CIG Architectuur

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

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

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 of technologie x . Je dient hier (indien van toepassing) dan het door jouw organisatie gebruikte pakket of de gebruikte technologie te vermelden.


CIG Architectuur

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

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 , email, kalender en contact oplossingen die in gebruik zijn binnen <de organisatie>. Denk hierbij ook aan plug-ins die integratie vanuit de Office suite naar het pakket faciliteren.

4.1.4 Import faciliteiten Het pakket biedt voorzieningen om bulk-invoer te faciliteren via importfaciliteiten.


CIG Architectuur

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

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

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

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

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

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

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

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

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

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

(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


“

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

Standaardpakketten en architectuur

Recommend Documents