Doorbelasting Rijksapplicatiestore

Doorbelasting Rijksapplicatiestore

Applicatie distributie en verrekening binnen de gesloten Rijkscloud December 2012 12.I000253 B05.F

Inhoudsopgave

De contactpersonen van

Pagina

KPMG met betrekking tot dit rapport zijn: ir. J.A.M. Donkers RE KPMG Advisory N.V.

Managementsamenvatting

2

1. Introductie

3

2. Context

6

Partner Tel:

+ 31 (0)30 658 2155

[email protected]

mr. drs. S.R. Wallagh MBA

3. Rijksapplicatiestore

11

4. Bekostiging van IT in het Rijk en in de Cloud

18

5. Bekostiging van de Rijkscloud-applicatiestore

23

6. Aanbevelingen en toekomstvisie

33

Bijlagen

38

KPMG Advisory N.V. Senior Manager Tel:

+31 (0)30 658 2475

[email protected]

© 2012 KPMG Advisory N.V., registered with the trade register in the Netherlands under number 33263682, is a subsidiary of KPMG Europe LLP and a member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (‘KPMG International’), a Swiss entity. All rights reserved. Printed in the Netherlands. The KPMG name, logo and ‘cutting through complexity’ are registered trademarks of KPMG International.

1 12.I000253 B05F

Managementsamenvatting

Uw vraag In navolging van uw verzoek en onze offerte (onze referentie 12.I000253. B05 F) hebben wij een onderzoek uitgevoerd naar de kostendrivers en doorbelastingsmethoden binnen een Rijkscontext van een applicatiestore. Daarbij hebben wij een aantal scenario’s voor doorbelasting van de Rijksapplicatiestore in kaart gebracht, waarbij door ons specifiek aandacht is besteed aan mogelijke risico’s en de inpasbaarheid binnen overheidsbudgetteringsmethoden. Onze aanpak In dit document hebben wij uw vraagstelling allereerst in een breder kader gezet. Wij beschrijven de lopende opdrachten, beleidskaders en internationale ontwikkelingen inzake cloud & applicatiestores. Vervolgens noemen wij relevante kostendrivers van applicaties en de store. De ontwikkelde scenario's moeten aansluiten bij de bekostiging van IT zoals dat binnen het Rijk gebruikelijk is. Deze bekostigingen schetsen wij dus eerst, om vervolgens de aansluiting met een applicatiestore te benoemen. Dit resulteert in vier scenario’s met bekostigingswijzen van de Rijksapplicatiestore. De scenario’s worden vervolgens vergeleken met de uitgangspunten voor bekostiging. Van hieruit brengen wij dan de inpasbaarheid van de scenario's in kaart. Tot slot geven wij ook nog een korte toekomstvisie over hoe de Appstore zich kan gaan ontwikkelen. Centraal in de beantwoording van de vraag staan vier scenario's: 1. Scenario 1: “De aanbieder betaalt” In dit scenario draagt de applicatie-aanbieder alle kosten. Eigenaren financieren zelf de ontwikkeling, acceptatie en exploitatie van de applicatie. De beheerkosten van de Rijksapplicatiestore worden op basis van lumpsum verdeeld over alle applicatie-eigenaren die applicaties aanbieden via de Rijksapplicatiestore.

2. Scenario 2: “Gebruikersregistratie” In dit scenario draagt de aanbieder (van de applicatie) aanvankelijk alle kosten, echter, de mogelijkheid bestaat om tevens de afnemer mee te laten betalen aan de exploitatiekosten. De Rijksapplicatiestore registreert nauwkeurig de afname van applicaties zodat de aanbieder in gesprek kan gaan met de afnemer. Vervolgens kunnen afspraken over de bekostiging gemaakt worden, al dan niet op basis van vooraf bekend gemaakte kosten. 3. Scenario 3: Commerciële Appstore Dit scenario zoals de Apple Appstore en Google Play’s Android store. Hier betalen afnemers voor gebruik en hiermee worden de aanbieders gecompenseerd. De afnemer bepaalt wanneer hij een applicatie of dienst wil aanschaffen. De prijs is bij aanschaf bekend en er vindt geen nacalculatie plaats. 4. Scenario 4:”Gematigde markt” is een mengvorm tussen de commerciële appstores en vormen van registratie. Door betalingen enerzijds niet te koppelen aan personen, maar aan groepen, en anderzijds de betalingen periodiek te laten plaatsvinden, worden een aantal van de administratieve bezwaren van een commerciële applicatiestore ondervangen. Afhankelijk van de invulling van de kassafunctie wordt innovatie en hergebruik sterk of minder sterk gestimuleerd en kunnen de budgetrisico’s worden ingeperkt. Aanbeveling De intrinsieke voor- en nadelen van de verschillende scenario’s zijn vergeleken op basis van bekostigingsuitgangspunten van de overheid, algemene ITbeleidsuitgangspunten en meer algemene applicatiestore-gerelateerde kenmerken. Op basis daarvan komen wij tot de conclusie dat op basis van de gestelde uitgangspunten scenario 2 “Gebruikersregistratie” het hoogst scorende compromis vormt tussen wenselijkheid, haalbaarheid, innovatie en efficiency. Als er echter meer belang wordt gehecht aan innovatie en hergebruik, kan ook het gematigde Marktmodel aantrekkelijk worden. Deze scoort op die punten hoger.


2 12.I000253 B05F

1. Introductie

1.1 Vraagstelling onderzoek

Dit onderzoek gaat in op de kostendrivers van de Rijksapplicatiestore en passende bekostiging Introductie

Binnen de reikwijdte

De Rijkscloud is volop in ontwikkeling, op applicatieniveau binnen de cloud kan hergebruik gestimuleerd worden door middel van een Rijksapplicatiestore. Voorafgaand aan de ontwikkeling van de Rijksapplicatiestore is er behoefte aan houvast inzake kostendrivers en bekostiging van de applicaties en Rijksapplicatiestore. Dit onderzoek gaat hierop in.

Bij de beantwoording van uw vraag ligt, zoals besproken, het zwaartepunt van de vraagstelling voor KPMG rondom de financiële aspecten van de Rijksapplicatiestore. Het resultaat van de opdracht is dit adviesrapport waarin de volgende onderzoeksvragen zijn uitgewerkt:

Uw vraag In uw opdrachtverlening d.d. 15 oktober 2012 zijn wij overeengekomen dat wij uiterlijk 17 december 2012 een rapport opleveren met daarin: 1. Kostendrivers binnen een Rijkscontext van een applicatiestore. 2. Een aantal scenario’s voor doorbelasting van de Rijksapplicatiestore. Daarbij zal specifiek aandacht zijn voor de budgettaire (planning) consequenties, mogelijke risico’s en inpasbaarheid binnen overheidsbudgetteringsmethoden. Om aansluiting bij de Rijksoverheid te bewaken worden huidige, succesvolle doorbelastingsmethoden binnen de Rijksoverheid meegenomen in het onderzoek. 3. Voorbeelden van dergelijke stores.

■ Welke bekostigingsmethoden voor IT-diensten worden gebruikt binnen de Rijksoverheid en welke methoden zijn gangbaar bij cloud-diensten? ■ Welke bekostigingsmethoden zijn geschikt voor de Rijksapplicatiestore? ■ Wat zijn de kostendrivers van een applicatie en de Rijksapplicatiestore? ■ Op basis van de inventarisatie worden vier scenario’s geschetst voor bekostiging van de doorbelasting van een Rijksapplicatiestore binnen de overheidsbekostigingsmethodieken. Belangrijkste benefits ■

Helder inzicht in kostendrivers ondersteunt het proces van beelden planvorming van de Rijksapplicatiestore.

■

Vroegtijdige aandacht voor bekostiging helpt bij de interne positionering en verwachtingen van de Rijksapplicatiestore.

4. Identificatie van potentiële dilemma’s/aandachtsgebieden. 5. Aanbevelingen.

■ Inzicht kan als input dienen voor businesscases rondom de Rijkscloud en de De vraagstelling van het onderzoek is meer toegespitst op doorbelasting van de Rijksapplicatiestore. Rijksapplicatiestore naar aanleiding van het startgesprek d.d. 25 oktober 2012 met de opdrachtgever.

Conform de opdrachtverlening hebben wij op 3 december een concept rapport opgeleverd ter bespreking en afstemming. Op basis daarvan is dit definitieve rapport opgesteld.


4 12.I000253 B05F

1.2 Onderzoeksopzet en leeswijzer

Onderzoeksopzet en leeswijzer

Onderzoeksopzet

Structuur rapport

Voor de opzet van het onderzoek is gebruik gemaakt van de volgende structuur.

Dit eindrapport volgt de structuur van de onderzoeksopzet. Hoofdstuk ‘Context onderzoek’ beschrijft de lopende opdrachten, beleidskaders en internationale ontwikkelingen inzake cloud en applicatiestores.

2.Context Onderzoek

3.Rijksapplicatiestore 1.Hoe kan bekostiging van de applicatiestore georganiseerd worden binnen het Rijk? 4.Bekostiging van IT in het Rijk en Cloud

• Lopende opdrachten • Beleidskaders • Internationale ontwikkelingen overheid • Internationale voorbeelden applicatiestore’s • Def initie applicatiestore • Scope applicatiestore • Applicatiestore in relatie tot gesloten Rijkscloud • Structuur Rijkscloud • Kostendrivers • Type applicaties

• Algemene uitgangspunten bekostiging • Bekostiging binnen het Rijk • Bekostiging in de cloud

5.Bekostiging de Rijksapplicatiestore

• Introductie scenario’s • Scenario’s (1 t/m 4) • Risico in de Pay-per-Use keten

6.Conclusies, aanbevelingen en toekomstvisie

• Conclusies • Aanbevelingen •Toekomstvisie

Vervolgens wordt in hoofdstuk “Rijksapplicatiestore” ingegaan op de Rijksapplicatiestore. Na de definitie wordt de scope vastgesteld en de relatie met de gesloten Rijkscloud beschreven. Aan het einde van het hoofdstuk staan de kostendrivers van applicaties en de store. In hoofdstuk “Bekostiging van IT in het Rijk en in de Cloud” wordt ingegaan op bekostiging van IT zoals gebruikelijk is binnen het Rijk. Daarnaast worden er bekostigingsmethodieken uit de cloud gepresenteerd. In hoofdstuk ‘Bekostiging van de Rijksapplicatiestore’ wordt de Rijksapplicatiestore gematcht met bekostigingswijzen in vier scenario’s. De scenario’s worden vervolgens vergeleken met de uitgangspunten voor bekostiging. Het laatste hoofdstuk gaat in op de conclusies omtrent de scenario's, aanbevelingen en de toekomstvisie.


5 12.I000253 B05F

2. Context

2.1 Lopende opdrachten

Geen overlap met de onderzoeken doelarchitectuur, scope Rijksapplicatiestore en BYOD Opdrachtomschrijving lopende onderzoeken

De opdracht richting KPMG is onderdeel van een bredere opdrachtverlening omtrent de Rijkscloud. Aan diverse partijen is gevraagd deelaspecten te bekijken. In onderstaande figuur staan de diverse opdrachten op hoofdlijnen ten opzichte van elkaar weergegeven zoals die door KPMG worden begrepen en aan de orde geweest zijn in het afstemmingsgesprek d.d. 13november 2012 met onderstaande partijen.

 Onderzoek Doelarchitectuur Rijkscloud & applicatiestore (Logica): een expertadvies over de (concept) doelarchitectuur voor de gesloten Rijkscloud en de Rijksapplicatiestore als onderdeel van de cloudstrategie met daarin aandachtspunten en aanbevelingen om te komen tot een definitieve doelarchitectuur.

LOGICA

Cloud Visie & Beleid

Overige clouddiensten

Rijksapplicatiestore

Informatiemanagement

BYOD Beleid en governance

Samenhang met de omliggende opdrachten inzake de Rijkscloud

Architectuur

Gartner

Management Centrum

KPMG

Buiten scope

 Onderzoek naar de scope van de Rijksapplicatiestore en de applicatiestore in relatie tot cloud, rekencentra, BYOD en beveiliging (Gartner): dit onderzoek gaat in op voorbeelden van andere overheden, de markt en grote (federatieve) entiteiten. Gartner beschrijft trends, hypes en mogelijke scenario’s voor de Rijksapplicatiestore. Gartner heeft telefonisch aangegeven dat de financiële aspecten van de Rijksapplicatiestore niet in scope zijn.  Onderzoek naar de bestuurlijke vragen ten aanzien van de inpassing van BYOD in het ICT-beheer van de Rijksoverheid (Management Centrum): dit onderzoek gaat in op besturingsvarianten (governance, aanbiederschap & organisatie), de samenstelling van een besturings- en expertgroep, een visie op mobiel hergebruik van data in relatie tot een enterprise content managementsysteem en toekomstscenario’s. Raakvlakken Onderdeel van de opdrachtverlening was dat KPMG en de andere mantelpartijen in afstemming met elkaar er zorg voor zullen dragen dat de opdracht van de partij niet overlapt met de andere opdrachten die in het kader van deze IASA-special worden verstrekt. Na het bestuderen van de opdrachtomschrijvingen, telefonisch contact met de partijen en de afstemmingsbijeenkomst (d.d.13 november 2012) bleek tijdens de meeting dat er geen overlap is met de lopende onderzoeken. Uiteraard zijn er wel raakvlakken: de Rijksapplicatiestore zal fungeren in een cloud omgeving met een specifieke architectuur (Logica). De algemene visie, toekomsten beleidskeuzes zullen door Gartner worden onderzocht. De doelgroep (lees: device keuzes) van de cloud zullen door Het Managementcentrum in beeld worden gebracht.


7 12.I000253 B05F

2.2 Beleidskaders

Ontwikkelingen en beleidskaders van invloed op de Rijksapplicatiestore

Beleidscontext van de opdracht De Rijksapplicatiestore vormt beleidsmatig een onderdeel van het Rijkscloud-beleid. En die vormt weer een onderdeel van het algemene Rijks ICT-beleid. Deze beleidsmatige hiërarchie biedt een aantal kaders en ontwikkelingen die de randvoorwaarden en (een deel van de) toetsingscriteria geven aan de KPMG-opdracht, die wij binnen onze opdracht gehanteerd hebben. Uitgangspunten Rijks ICT:  Voor software en hardware is hergebruik de norm. Alvorens software te ontwikkelen, wordt eerst op Rijksniveau vastgesteld of er geen bestaande applicatie gebruikt wordt die in de behoefte voorziet.1  Gebruik maken van een beperkt aantal datacenters om efficiëntie te verhogen (Project 4 Compacte Rijksdienst).1  Harmonisatie en standaardisatie in plaats van versnippering en maatwerk, o.a. door Rijksbreed gebruik van het Shared Service Center ICT (Project 7 Compacte Rijksdienst).1

Uitgangspunten Rijkscloud:  Gemeenschappelijk applicatiegebruik onder de noemer van ‘overheids cloudcomputing’ maakt het mogelijk om redundante aankoop van software te voorkomen.1  Inrichting Rijkscloud in eigen beheer als voorziening die generieke diensten levert binnen de Rijksdienst.3  De Rijkscloud maakt gebruik van moderne technologie en stelt de Nederlandse overheid in staat aan te sluiten bij de heersende internationale ontwikkelingen.3  De Rijkscloud wordt ingericht binnen een eigen beveiligd netwerk.3  Gebruikers kunnen ‘on demand’-diensten kiezen uit het GRC dienstenaanbod.4

 De Rijksdienst beschikt over een platform dat tijds-, plaatsen apparaatonafhankelijk werken, alsmede interdepartementale samenwerking, op een veilige en vertrouwde manier mogelijk maakt. 2  Grote en risicovolle ICT-projecten zijn op orde, o.a. door het ingevoerde CIO-stelsel.2  Indien mogelijk worden interne ICT-dienstverleners en vergelijkbare processen gebundeld.2

Bronnen: 1) Compacte Rijksdienst uitvoeringsprogramma 2) Informatiseringstrategie Rijk (I-Strategie Rijk) 3) Cloud Strategie Rijk: Kamerbrief over Cloud Computing. 2011 4) Doelarchitectuur Gesloten Rijkscloud (concept, versie 0.5)

Uitgangspunten Rijksapplicatiestore  Aangeboden diensten voor de rijksambtenaar kunnen op afroep geleverd worden via de store.4  De store krijgt een kassafunctie, door functionaliteit te ‘kopen’ wordt het verrekenmechanisme in gang gezet.4


8 12.I000253 B05F

2.3 Internationale ontwikkelingen

De publieke sector investeert meer in cloud, Nederland hoort bij de koplopers

KPMG-cloudonderzoek

KPMG heeft in 2011 een grote internationale studie naar de ontwikkeling van cloud binnen overheidsinstanties uitgevoerd. Onder respondenten bevonden zich 429 overheidsmanagers uit 10 landen. De belangrijkste bevindingen zijn: ■ De ontwikkelingen van cloud binnen de internationale Rijksoverheid gaan snel. Er wordt meer en meer IT-budget aan cloud besteed en de verwachtingen zijn dat cloud-toepassingen kostenvoordelen met zich meebrengen en het toekomstige businessmodel en de interactie met de burger sterk zullen veranderen.  De ontwikkeling en implementatie van cloud-initiatieven kennen verschillende stadia in de verschillende landen. Nederland staat op de vierde plek als het gaat om volledig geïmplementeerde cloud-projecten.

De impact van Cloud

 De investeringen in cloud bij de publieke sector versnellen. Ongeveer 12 procent van de respondenten geeft aan dat meer dan 10 procent van het ITbudget wordt toegewezen aan cloud-projecten. Dit percentage zal naar verwachting eind 2012 verdubbeld zijn naar 28 procent. Benodigde kostenbesparingen

11% 39% 29%

50%

21%

28% 27%

Cloud leidt tot kostenreductie Fundementele verandering van businessmodel Verandering in interactie met burgers / klanten

> 25%

11-25%

1-10%

Onbekend

 Van de ondervraagden denkt 50 procent dat er kostenvoordelen met cloud te behalen zijn, 28 procent denkt dat het fundamentele veranderingen in het businessmodel tot stand brengt en 39 procent verwacht dat de introductie van Cloud invloed heeft op de interactie met de burgers.  Een positieve businesscase wordt door 73 procent van de respondenten als noodzakelijk beschouwd om over te gaan op een cloud-omgeving. Ongeveer een tiende van de respondenten denkt dat een kostenbesparing van meer dan 25 procent noodzakelijk is om geld vrij te maken voor cloudinitiatieven, 21 procent verwacht dat een kostenreductie tussen 11 en 25 procent voldoende is en ongeveer een kwart denkt dat er al bij een kostenreductie tussen de 1 en 10 procent reden is om te investeren in cloudinitiatieven.  Beveiliging baart bij de respondenten de meeste zorgen bij een overstap op een cloud-omgeving, al biedt certificering hierin een oplossing.


9 12.I000253 B05F

2.4 Internationale voorbeelden applicatiestores

Casestudy: Google Play’s Android Market, G-Cloud & US Army Application Marketplace Andere applicatiestores Ter beeldvorming en vergelijking hebben wij een drietal grote applicatiestores bekeken: - Een grote commerciële applicatiestore (Google Play) - Twee grote overheidsstores (ieder met een andere insteek) Vergelijking applicatiestores

Omschrijving

Doel

Bekostiging

Google Play’s Android Market

G-Cloud Cloudstore

US Army Application Marketplace

Google Play voorziet in een online store van muziek, films, boeken en Android-applicaties. Binnen de Android Market worden honderdduizenden applicaties aangeboden voor tablets en de mobiele telefoon. Bijzonder is dat ontwikkelaars zelf applicaties kunnen publiceren, er vindt slechts een beperkte review plaats door Google.

Begin 2012 heeft de Britse overheid de G-Cloud Cloudstore gelanceerd. Met behulp van de Cloudstore kunnen (regionale) overheidsafdelingen eenvoudig IT-producten/ -diensten afnemen. De cloudstore is een database met meer dan 1.700 diensten verdeeld over vier gebieden: IaaS, PaaS, SaaS en overige services. Het portaal voorziet in het aankoopproces.

De US Army Application Marketplace brengt ontwikkelaars en eindgebruikers bij elkaar om te werken aan innovatieve oplossingen voor het Amerikaanse leger.

 Inkomsten genereren met de verkoop van applicaties en reclame-inkomsten;  Versterken positie Android door aanbieden van populaire applicaties;  Innovatie onder ontwikkelaars stimuleren.

 Efficiëntie bevorderen in het inkoopproces van (locale) overheden;  Kleine en middelgrote IT-leveranciers de kans bieden om aan de overheid te leveren;  Brede keuze bieden voor afnemers.

 Ontwikkeling van innovatieve applicaties voor het Amerikaanse leger;  Stimuleren van innovatie door samenwerking soldaten en ontwikkelaars.

 Google Play rekent $ 25 voor het aanbieden van een applicatie ter review;  Google houdt 30% in op alle inkomsten van de applicatie (aankoop, in-app purchases & reclame inkomsten).

 (Lokale) overheden dragen zelf de budgetverantwoordelijkheid en gaan via het G-Cloud-portaal een directe relatie aan met de IT-aanbieder.  De Cloudstore faciliteert enkel het selectieen aanschafproces.

 Externe applicatieontwikkelaars of leveranciers kunnen hun app betaald aanbieden;  Door middel van aan app-competitie volgen inzendingen van apps die vervolgens op het platform gedistribueerd worden.

De marketplace is een portaal voor het ontdekken, publiceren, raten en bespreken van applicaties. De sociale media-functies stimuleren interactie tussen de ontwikkelaar en eindgebruiker.

Zie voor gedetailleerde informatie de bijlage © 2012 KPMG Advisory N.V., registered with the trade register in the Netherlands under number 33263682, is a subsidiary of KPMG Europe LLP and a member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (‘KPMG International’), a Swiss entity. All rights reserved. Printed in the Netherlands. The KPMG name, logo and ‘cutting through complexity’ are registered trademarks of KPMG International.

10 12.I000253 B05F

3. Rijksapplicatiestore

3.1 Definitie Rijksapplicatiestore

Definitie Rijksapplicatiestore en uitgangspunten

Definitie Rijksapplicatiestore

Uitgangspunten Rijksapplicatiestore

Het denken over de Rijksapplicatiestore is binnen de overheid nog in ontwikkeling. Wij zijn uitgegaan van de beelden zoals die in de huidige documenten geschetst worden. De Rijksapplicatiestore is een centraal portaal met een overzicht van beschikbare applicaties voor de rijksambtenaar. De rijksambtenaar kan hier de beschrijving van de applicatie bekijken en de applicatie downloaden voor gebruik.

 Aangeboden diensten voor de rijksambtenaar kunnen op afroep geleverd

Eigenschappen van de Rijksapplicatiestore:

 De applicatiestore bevordert hergebruik en leidt tot efficiënt gebruik van

 de Rijksapplicatiestore is eenvoudig toegankelijk via de pc, laptop, tablet en

smartphone;  is in staat applicaties geschikt voor de pc, laptop, tablet en smartphone van

de rijksambtenaar aan te bieden (ervan uitgaande dat het apparaat van de ambtenaar voldoet aan de veiligheidscriteria). Alle applicaties zijn hier in scope, ook client-server applicaties (web-based, html5);  de Rijksapplicatiestore is een distributiekanaal. Het functioneel en technisch

worden via de store (Doelarchitectuur Applicatiestore);  De store krijgt een kassafunctie, door functionaliteit te ‘kopen’ wordt het

verrekenmechanisme in gang gezet (Doelarchitectuur Applicatiestore). Echter, dit is sterk afhankelijk van welke bekostigingsmethodiek gehanteerd wordt; applicaties;  Gemeenschappelijk applicatiegebruik onder de noemer van ‘overheids

cloudcomputing’ maakt het mogelijk om redundante aankoop van software te voorkomen. De Rijksapplicatiestore draagt hieraan bij;  De applicatiestore maakt gebruik van moderne technologie en stelt de

Nederlandse overheid in staat aan te sluiten bij de heersende internationale ontwikkelingen.

beheer van de applicaties liggen bij de aanbieder van de applicatie;  de Rijksapplicatiestore host enkel front-end applicaties. De applicaties halen

dynamische data op uit back-office systemen van de ontwikkelaar/aanbieder;  De applicaties slaan zelf geen vertrouwelijke gegevens op, tenzij beleid dit

(encrypted) toestaat.

Bron:

Rijksoverheid: Compacte Rijksdienst Uitvoeringsprogramma; Rijks Cloud Strategie; Interview P. van der Weyden; Doelarchitectuur Gesloten Rijkscloud Concept Versie 0.5


12 12.I000253 B05F

3.2 Scope Rijksapplicatiestore

Dit onderzoek is gericht op model 1: Rijksapplicatiestore voor en door de rijksambtenaar

Groeimodel Rijksapplicatiestore

Scope Rijksapplicatiestore

1

De definitie van de Rijksapplicatiestore is nog in ontwikkeling en daarmee ook de reikwijdte. In het figuur links worden drie varianten gepresenteerd. “Departementen” staan voor de aangesloten departementen op de Rijksapplicatiestore. Op termijn kunnen dit ook andere Rijksdiensten zijn.

3 Departementen

1: Rijksapplicatiestore voor en door (een deel van de) Rijksambtenaren

Rijksapplicatiestore

Externe applicatieontwikkelaars /leveranciers

In dit model worden applicaties ontwikkeld in opdracht van departementen en vervolgens geplaatst in de Rijksapplicatiestore. De Rijksapplicatiestore is centraal beschikbaar en te benaderen voor ambtenaren van de aangesloten departementen. Deze rijksambtenaren kunnen (mits geautoriseerd) de applicaties downloaden en gebruiken. 1 +2: Rijksapplicatiestore voor en door alle ambtenaren

2 ZBO’s, provincies, gemeenten, waterschappen

In dit model krijgen ook ambtenaren werkzaam bij ZBO’s, provincies, gemeenten en waterschappen toegang tot de Rijksapplicatiestore. Zij kunnen zowel applicaties aanbieden als afnemen. Het voordeel is dat hergebruik en efficiëntie nog verder benut kunnen worden. 1 + 2 + 3: toevoeging externe applicatieontwikkelaars/leveranciers In dit model kunnen externe applicatieontwikkelaars/leveranciers applicaties aanbieden aan de Rijksapplicatiestore en daarmee aan de (rijks)ambtenaar. Ontwikkelaars kunnen bijvoorbeeld apps gebaseerd op open data aanbieden. Dit model stimuleert innovatie door marktpartijen en de ontwikkeling van bestof-breed applicaties. In dit model is een zorgvuldige accreditatie/goedkeuring van de applicaties onontbeerlijk. Daarnaast zal er een verdienmodel voor de externe ontwikkelaars geïntroduceerd moeten worden.


13 12.I000253 B05F

3.4 Structuur Rijksapplicatiestore

De Rijksapplicatiestore kent vier mogelijke verrekeningsmomenten, beleidsafstemming is noodzakelijk Verrekeningsmomenten De Rijksapplicatiestore kent vier mogelijke verrekeningsmomenten (of er daadwerkelijk verrekening plaats vindt, is afhankelijk van de gekozen wijze van bekostiging):

Individuele gebruiker(s)

1 accordering Budgethouders gebruik van Applicatiestore

1. De eerste is niet een echt verrekeningsmoment. In veel situaties zullen niet individuen de financiële verplichtingen aangaan, maar budgethouders. Dat kunnen afdelingen zijn, proceseigenaren, of gehele departementen. Deze budgethouders kunnen zelfstandig financiële verplichtingen aangaan (bv. een applicatie aankopen voor de gehele afdeling), of op verzoek van een individu (bv. een special bestellen). In dat geval zal er eerst een stap zijn, waarbij er accordering door de budgethouder plaatsvindt van het verzoek van een individu. NB Bij een “echte”pay-as-you-go, zoals in commerciële appstores, zijn de individuele gebruikers en de budgethouders dezelfde personen.

3

2

Applicatiestore Product/diensten portefeuille

Applicatie-aanbieder

Strategisch en Tactisch ICT beleid

4 Verrekeningsmodel Applicatie-aanbieder <-> Applicatiestore

Operationeel ICTbeleid

Applicatiestore IT Architectuur Applicatiestore Infrastructuur

2. Verrekening tussen de budgethouder en de applicatie-aanbieder. Dit kan direct (pay-per-use) of indirect (via budgettering etc). 3. Verrekening tussen de budgethouder en de Rijksapplicatiestore zelf. Dit kan onderdeel zijn van een totaalbedrag (bij pay-per-use) of in een andere vorm. Dit kunnen zowel individuele gebruikers zijn als departementen. 4. Verrekening van kosten en opbrengsten tussen de Rijksapplicatiestore en de applicatie-eigenaren. Dit kan op stukbasis zijn per applicatie, of met algemene afspraken, of met een combinatie. 5. Een verrekening tussen de fysieke store provider (IT) en de store zelf. Hierbij gaat het om zaken als hostingkosten, datakosten en technisch beheer.

5

Beleidsafstemming Dit vergt afstemming van Rijkscloud beleid tussen het strategisch/tactisch niveau enerzijds, dat met name toeziet op de gebruikers en de applicaties en het operationeel beleid dat met name ziet op de technische componenten en infrastructuur. Het Rijkscloud-beleid op alle niveaus zal afgestemd moeten worden om te komen tot een geïntegreerde verrekeningsaanpak.


14 12.I000253 B05F

3.3 Rijksapplicatiestore in relatie tot gesloten Rijkscloud

De Rijksapplicatiestore is onderdeel van Generieke IaaS/PaaS laag in de Algemene Gesloten Rijkscloud (GRC) Scope binnen de GRC-infrastructuur

Rijksapplicatiestore in relatie tot GRC-omgeving

De GRC kent een aantal onderverdelingen: 1. Delen die specifiek voor één departement worden ingericht. Dit zijn dedicated stukken van de GRC (paars in figuur). Onderdeel hiervan kán zijn een dedicated Rijksapplicatiestore voor één departement. Deze valt buiten scope van dit onderzoek.

Rijksbreed GRC-beleid

Dedicated IaaS/ PaaS

Dedicated SaaS

- Dedicated Hosting

- Specifieke - Dedicated development applicaties omgeving

TBGI GRC-beleid

Generieke IaaS/PaaS

Generieke SaaS

-Rijksapplicatiestore - Generieke Hosting - Generieke development Omgeving

- Algemene applicaties

- etc.

Dedicated GRC infrastructuur

IT provider 1

Generieke GRC Infrastructuur

IT provider 2

…

IT provider X

Generiek Functioneel & Technisch Beheer

Specifiek Functioneel & Technisch Beheer

Departementaal GRC-beleid

2. Algemene delen van de GRC. Dit betreft zowel gemeenschappelijk cloud-beleid, en functionaliteit. Hierbinnen valt de Rjjksapplicatiestore (groen in figuur). 3. Onderliggend aan zowel de dedicated GRC als de algemene Rijkscloud ligt een gedeelde, gemeenschappelijke infrastructuur. Deze kan geleverd worden door diverse IT-providers. Onderdeel van de algemene infrastructuur kan ook een specifiek dedicated stuk infrastructuur zijn, die alleen door één departement wordt gebruikt. 4. Overkoepelend over en onderliggend aan de gehele Rijkscloud liggen een rijksbreed GRC beleid, IT- , beveiligings- en privacybeleid, die van toepassing zijn op zowel de dedicated als algemene Rijkscloudelementen. 5. In dit document zijn wij uitgegaan van één Rijksapplicatiestore. De scenario's die wij uitwerken zijn ook van toepassing indien er meerdere stores zouden komen.

Rijksbreed IT-, Beveiligings- en Privacybeleid © 2012 KPMG Advisory N.V., registered with the trade register in the Netherlands under number 33263682, is a subsidiary of KPMG Europe LLP and a member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (‘KPMG International’), a Swiss entity. All rights reserved. Printed in the Netherlands. The KPMG name, logo and ‘cutting through complexity’ are registered trademarks of KPMG International.

15 12.I000253 B05F

3.5 Kostendrivers

Kostendrivers van applicaties en de Rijksapplicatiestore

Kostendriversapplicatie

Detail: Kostendrivers Rijksapplicatiestore

De initiële kosten van een applicatie liggen bij de ontwikkeling van de applicatie. Vervolgens wordt de applicatie ter goedkeuring aangeboden aan de Rijksapplicatiestore. De platformaanbieder voert een accreditatie uit zodat er controle is over de applicaties in de Rijksapplicatiestore. Na acceptatie wordt de (front-end) applicatie gedistribueerd door de Rijksapplicatiestore. Functioneel beheer en doorontwikkeling blijven de verantwoordelijkheid van de ontwikkelaar, evenals de kosten die gemaakt worden met en bij de back-end systemen (specifiek bij client-server/HTML-applicaties).

Om applicaties op geschiktheid te beoordelen zal een accreditatieproces ingericht moeten worden, dit om de kwaliteit en veiligheid van de applicaties te garanderen. Per applicatie zullen kosten worden gemaakt voor de beoordeling. Vervolgens wordt de applicatie gepubliceerd in de Rijksapplicatiestore, vanaf dit moment resulteert dit in kosten voor hosting. Indirecte kosten van de store bestaan uit het functioneel –en technisch beheer en. de administratie & doorbelasting van de kosten

Kostendrivers applicatie

Applicatie Ontwikkel kosten

Kostendrivers Rijksapplicatiestore Ontwikkelkosten (incl. test) Back-end aanpassingen

App Store Acceptatiekosten

Doorontwikkeling applicatie

Variabele kosten (per applicatie)

Kosten voor publicatie van de applicatie

Acceptatie kosten Rijksapplicatiestore Exploitatie kosten Applicatie Exploitatie kosten

Rijksapplicatiestore acceptatiekosten

Hosting

Kosten Rijksapplicatiestore

Netwerkinfrastructuur

(Semi-) vaste kosten (per store)

Functioneel beheerstore

Technisch en Functioneel beheer applicatie Gebruikersondersteuning

Technisch beheerstore

Back-end systeem kosten Netwerkverkeer (met name bij HTML toepassingen)

Administratie & doorbelasting


16 12.I000253 B05F

3.6 Type applicaties

Verschillende typen applicatiegebruik binnen de overheid vragen verschillende aanpakken Type Applicatiegebruik

Typering applicatiegebruik en de impact op de Rijksapplicatiestore

Het totale applicatielandschap binnen de overheid kan onderverdeeld worden aan de hand van het type van gebruik (algemeen of specifiek) en verplichte of vrije keuze applicaties. Het betreft hier een functioneel onderscheid, niet een technisch onderscheid. De distributie van al deze type applicaties is potentieel binnen scope van de Rijksapplicatiestore.

Aangezien de Rijksapplicatiestore primair voorziet in de distributie van applicaties, is het type applicatie, gezien vanuit de Rijksapplicatiestore, niet primair relevant. Er is geen fundamenteel verschil tussen het opslaan en distribueren van verplichte applicaties versus een vrij keuze-applicatie. Toch is het onderscheid relevant om een tweetal redenen: eisen en doorbelasting:

Onderverdeling van gebruik van applicaties

Algemene applicaties

Verplichte applicaties

Vrij keuze applicaties

Bv.:

Bv.:

- Kantoorautomatisering

-Kantoorautomatisering + (Visio etc.)

- Security & Identy management -“Gaarkeuken”-apps (*)

-Social Media tools -Algemene (commerciële) apps

Bv:

Bv:

 Doorbelasting: bij de keuze van het type doorbelasting, kan de applicatieaanbieder laten meewegen of een applicatie verplicht is of niet. Een Pay-peruse scenario ligt bij vrij keuze-applicaties meer voor de hand, dan bij verplichte applicaties. Bij die groep ligt een jaarlijkse omslag van de kosten wellicht meer voor de hand.

-Primaire business applicaties

-Functiegerichte tooling

Licentiekosten en applicaties

-Vrijwillige departementale apps

 Sommige applicaties dragen directe (externe) licentiekosten (zoals bv. MS Office, Visio etc.). Deze kosten worden momenteel doorbelast op gebruikersbasis. In de nieuwe verrekening zal dit ook zo moeten blijven om de kosten inzichtelijk en beheersbaar te houden.

-“Cafetaria/Fastfood”-apps (*) Specifieke (departementale/ functiegerichte) applicaties

 Eisen: de eisen die gesteld worden aan verplichte applicaties kunnen verschillen van vrij keuze applicaties. Dit is zijdelings van belang voor de Rijksapplicatiestore. Een inspectie-applicatie voor een inspecteur vraagt een ander beschikbaarheids- en veiligheidsniveau dan een verjaardagsplanningstool. Deze eisen worden gedefinieerd door de applicatie-aanbieder. Maar ook de store zal zelf een minimum eisenpakket moeten definiëren waaraan applicaties dienen te voldoen (bv. qua security en applicatie-aanbiederschap). De store zal dus moeten verifiëren of alle applicaties voldoen aan een minimum eisenset. Wellicht wordt ervoor gekozen om afhankelijk van het type applicatie een andere minimum eisenset te definiëren.

-“Gaarkeuken”-apps(*)

-“Cafetaria/Fastfood”-apps (*)

(*) Conceptterminologie gebruikt door GDI ter classificering van type applicaties Gaarkeuken apps: zijn applicaties die verplicht uitgerold worden Cafetaria/fast food-applicaties zijn optioneel af te nemen, met verschillende niveaus van ondersteuning


17 12.I000253 B05F

4. Bekostiging van IT in het Rijk en in de Cloud

4.1 Algemene uitgangspunten bekostiging

Algemene uitgangspunten bekostiging

Stuurmogelijkheden en kostengedrag bepalen type financiering

Uitgangspunten goed opgezette bekostiging

Vanuit managementbesturing bezien spelen qua gepaste financieringswijze enerzijds de stuurmogelijkheden door de aanbieder op de producten en hun kosten een belangrijke rol en anderzijds het gedrag van de kosten (vast vs. variabel):

De hiernaast genoemde overwegingen leiden tot een aantal uitgangspunten voor een goed opgezette bekostiging (inzicht, risico en uitvoer). Daarnaast zijn er uitgangspunten specifiek voor de Rijksapplicatiestore (effect) toegevoegd. De bekostigingsscenario's worden getoetst aan de hand van deze uitgangspunten:

■ Financiering op basis van prijs maal hoeveelheid (p*q) is van toepassing indien de producten repetitief tot stand komen bij een relatief hoog volume met een min of meer standaard set aan genormeerde activiteiten. De klant kan de afnamehoeveelheid beïnvloeden en de kosten kennen een variabel karakter waarbij meer gebruik leidt tot hogere kosten. ■ Financiering op basis van lumpsum/abonnementsmodel is van toepassing waar het hoofdzakelijk vaste kosten betreft waarbij een verdeelsleutel moeilijk te vinden is dan wel weinig toegevoegde efficiencyprikkels geeft. ■ Financiering op basis van projectbekostiging is van toepassing indien de opdracht van de opdrachtgever tijdelijk van aard is en een incidenteel karakter kent. Deze activiteiten zullen projectmatig moeten worden aangestuurd en bekostigd op basis van een plan van aanpak met budget en resultaten op basis van de benodigde capaciteit, doorlooptijd en kosten. Bij elk type financiering horen andere afspraken rondom afgrenzing en definities, bouwstenen van de bekostiging, begroting, verantwoording, afrekening en onderhoud. Op de volgende pagina worden deze nader toegelicht. In dit hoofdstuk confronteren wij een tweetal invalshoeken met elkaar: bekostiging van IT binnen de overheid en bekostigingsmodellen van applicatiestores zoals die buiten de overheid gangbaar zijn. Vervolgens kijken wij naar de kostendrivers van de toekomstige Rijksapplicatiestore en het gedrag van de kosten en bijbehorende stuurmogelijkheden en risico’s. Dit leidt tot een viertal scenario’s voor bekostiging voor de toekomstige Rijksapplicatiestore die in het volgende hoofdstuk zullen worden uitgewerkt. Bron:

 Effect:  Stimuleert innovatie  Stimuleert hergebruik van applicaties  Stimuleert ontwikkeling rijksbrede applicaties  Inzicht:  Transparant  Compleet & systematisch  Ondersteuning bij besluitvorming  Oorzaak – gevolg kosten inzichtelijk  Controleerbaar (Audit)  Toepasbaar van applicaties met licentiekosten  Risico  Geen budgetrisico bij store provider  Geen budgetrisico bij applicatie-aanbieder  Geen budgetrisico bij gebruiker/departement  Uitvoer  Eenvoudig uit te voeren  Terugverdienmogelijkheid  Schaalbaarheid  Lage administratieve lasten  Inpasbaar overheidsbudgetproces

Kosten en baten van shared service centra: ‘De baten als ballast’ (KING)


19 12.I000253 B05F

4.2 Bekostiging IT binnen het Rijk

Drie typen bekostiging die veel gebruikt worden voor IT-diensten binnen het Rijk

Drie typen bekostiging van IT binnen de overheid Prijs * hoeveelheid (p*q)

Lumpsum bekostiging

Projectbekostiging

Omschrijving

Financiering op basis van prijs maal hoeveelheid en kwaliteit (p*q) is met name van toepassing indien de producten repetitief tot stand komen bij een relatief hoog volume met een min of meer standaardset aan genormeerde activiteiten. De klant kan de afnamehoeveelheid beïnvloeden. Dit is het zogenaamde beïnvloedbare budget

Financiering op basis van bekostiging is van toepassing waar het hoofdzakelijk vaste kosten betreft waarbij een verdeelsleutel moeilijk te vinden is dan wel weinig toegevoegde efficiencyprikkels geeft. Dit is het zogenaamde niet-beïnvloedbare budget, waarmee de dienstverlening tussen secundaire afdelingen en primaire afdelingen vormgegeven kan worden. Een veel toegepaste vorm is het solidariteitsprincipe, waarbij de hoogte van de lumpsum bepaald wordt op basis van een overeengekomen rekeneenheid (bv. FTE), maar losstaat van daadwerkelijk gebruik

Financiering op basis van projectbekostiging is van toepassing indien de opdracht van de opdrachtgever tijdelijk van aard is en een incidenteel karakter kent. Deze activiteiten zullen projectmatig moeten worden aangestuurd en bekostigd op basis van een plan van aanpak met budget en resultaten op basis van de benodigde capaciteit, doorlooptijd en kosten

Kostengedrag

Kosten zijn (relatief) variabel

Kosten zijn (relatief) vast

Kosten zijn variabel en specifiek voor de eenmalige activiteit.

Afgrenzing en definities

Productdefinities en –criteria (inclusief kwaliteit)

Vastgestelde set aan activiteiten

Projectdefinitie

Bouwstenen bekostiging

Volumebesluiten maal voorcalculatorisch integraal tarief per product

Vast budget behorende bij de vastgestelde set aan activiteiten

Uren maal voor-calculatorische uurtarieven en out-of-pocketkosten

Begroting

Productieverwachting

Plan met activiteiten en/of producten

Projectplan met milestones en resultaten

Verantwoording

Productierealisatie aantal besluiten

Gerealiseerde activiteiten- en productenoverzicht

Projectrealisatie

Afrekening

Over- en onderproductie besluiten (bandbreedtes) tegen voorcalculatorische integrale tarieven

Vast budget behorende bij de vastgestelde set aan activiteiten. Er kan nacalculatie plaatsvinden, bv. om budgetten aan te passen

Projectbudget of lagere realisatie. Bij hogere realisatie kan aanvullend budget worden ingediend

Onderhoud

Jaarlijks update tarieven op basis van nacalculatie en indexeringen

Jaarlijks update vast budget op basis van nacalculatie en indexeringen

Jaarlijks update uurtarieven op basis van nacalculatie en indexeringen


20 12.I000253 B05F

4.2 Bekostiging IT binnen het Rijk

Inventarisatie huidige bekostiging IT-diensten binnen de Rijksoverheid

Inventarisatie huidige verrekening

Totstandkoming integrale kostprijs SSC 3

De algemene modellen zoals hiervoor geschetst, worden in de praktijk ook zodanig, soms met kleine varianten, toegepast. Hieronder een overzicht hoe de bestaande shared service centra (SSC) hun kosten doorberekenen

In het kostprijsmodel van SSC worden personeelskosten, bedrijfsvoeringskosten, afschrijvingen, rente en overige materiële kosten onderscheiden. In het kostprijsmodel worden een aantal stappen gezet om tot de integrale kostprijs te komen1: 1. Producten zijn opgebouwd uit bouwstenen; 2. Kosten van het personeel worden doorberekend op basis van het Hafir-tarief, rekening houdend met meerkosten, toegewezen aan bouwstenen of aangemerkt als indirect; 3. Indirecte kosten en bedrijfsvoeringskosten worden aan de bouwstenen toegewezen in dezelfde verhouding als de directe personeelskosten; 4. Afschrijvingskosten worden m.b.v. CMDB (historische prijs, afschrijvingstermijn en aantal) toegewezen aan de bouwstenen; 5. In de financiële administratie worden de overige materiële kosten direct geboekt op het per bouwsteen aangemaakte artikel; 6. Opstelling van alle toegewezen kosten geeft de totale kosten per bouwsteen weer; 7. Door per product de betreffende (procentuele delen van de) bouwstenen te tellen, worden de totale kosten per product verkregen; 8. De totale kosten per product zijn vervolgens te delen door het aantal bij onze afnemers in productie zijnde accounts, pc’s, applicaties etc. Op deze manier wordt de kostprijs per eenheid product verkregen.

Kostenpost

Uitvoerder

Methodiek 2

DWR Client/Werkplek

SSC ICT

P*Q

Rijksportaal/Infra

SSC ICT

Solidariteitsprincipe op basis van IAR2

Regiekosten TBGI

TBGI


Migratie- en implementatiekosten van Rijksbrede voorzieningen

Departementen

Projectbekostiging voor (eigen) rekening departementen3

Instandhouding & doorontwikkeling

SSC ICT

10% van de exploitatiebegroting3

Rijksbrede voorzieningen (VPN’s Haagse Ring)

Logius

Op basis van daadwerkelijke kosten2

Activiteiten van Logius m.b.t. Rijksbrede voorzieningen

Logius


Rijkspas

Logius

Solidariteitsprincipe op basis van FTE3, voor doorontwikkeling wordt 10% gereserveerd

Kantoorautomatisering

DICTU

P*Q

Infrastructuur

DICTU

P*Q

Er zijn drie toewijzingsmomenten opgenomen:  Toewijzing bouwstenen aan producten;  Toewijzing personeel aan bouwstenen;  Toewijzing materiële kosten aan bouwstenen. Bronnen: 1) Beschrijving van het kostprijsmodel op hoofdlijnen, door Ger van Vlisteren (SSC) 2) Verdeelsleutel Generieke ICT-voorzieningen, door Jan Willem Brock (TBGI) 3) Uitgangspunten doorberekening generieke ICT (2013) door Jan Ploeg 4) Interview Bart Seesing


21 12.I000253 B05F

4.3 Bekostiging in de cloud

Bekostigingsmodellen van applicatiestores buiten de overheid

Bekostigingsmodellen van algemene applicatiestores Bekostigingsmodel

Omschrijving

Toepassing

Voorbeeld van model buiten de IT

Abonnementsmodel

De eenvoudige variant waar de afnemer betaalt op periodieke basis om gebruik te maken van een product of service. De rekening voor de afnemer is periodiek gelijk zonder dat daadwerkelijk gebruik belast wordt

Deze methode is erg populair bij Softwareas-a-Service-toepassingen zoals bijvoorbeeld Sales Force

Abonnement op krant

Betalen voor gebruik gedurende zelfgekozen tijdslot

De afnemer betaalt voor de periode waarin gebruik gemaakt is van het product/ de dienst. Vergelijkbaar met een hotelreservering

Bijvoorbeeld bij gebruik van een server in de cloud (zoals Amazon Web Services) waarbij de gebruiker per uur wordt gefactureerd

Huur van gereedschap

Betalen voor consumptie: eenmalige aanschaf

De afnemer schaft eenmaal het product aan en kan hier vervolgens onbeperkt gebruik van maken

Dit is het meest voorkomende model in de commerciële appstores (Google Play Android Market, Apple’s Appstore, Amazon Appstore)

Aankoop van een consumptiegoed

Betalen voor consumptie: pay-per-use

De afnemer betaalt puur voor gebruik op Dit model wordt veel toegepast binnen basis van een verdeelsleutel. Gebruik is hier IaaS-diensten voor infrastructuur waar de direct aan consumptie gerelateerd meeteenheid bijvoorbeeld geheugen, CPUcycles, schijfruimte of netwerkverkeer is

Een tolweg waar je als automobilist betaalt voor de afgelegde afstand

Hybride modellen

In de hybridevorm worden twee of meerdere Veel gebruikt voor software waar men naast modellen gecombineerd een eenmalig aanschafbedrag of periodieke onderhoudskosten moet betalen

Het meest voorkomende is voor vaste telefonie waar een deel van de rekening bestaat uit abonnementskosten en een deel uit gebruikskosten (pay-per-use).

Bron:

Cisco (2010) Managing the Real Cost of On-Demand Enterprise Cloud Services with Chargeback Models


22 12.I000253 B05F

5. Bekostiging van de Rijkscloud applicatiestore

5.1 Introductie

Introductie scenario’s ter bekostiging Rijksapplicatiestore

Introductie

Kostencategorieën en type financiering

De initiële inrichtingkosten van de applicatiestore worden door het SSC ICT als relatief laag ingeschat (50-150.000 euro). Gezien de lage kosten en het stimuleren van Rijksbreed gebruik is projectmatige bekostiging van de initiële kosten door BZK het meest voor de hand liggend. In de volgende scenario’s worden deze kosten buiten scope gelaten. In dit hoofdstuk worden vier scenario’s voor bekostiging van applicaties en de exploitatie van de Rijksapplicatiestore gepresenteerd. De eerste twee scenario’s zijn gebaseerd op bekostigingsmethoden die gangbaar zijn binnen de Rijksoverheid. Scenario drie is gebaseerd op bekostiging zoals gangbaar binnen commerciële applicatiestores. Scenario vier is een compromis tussen bestaande verrekeningsmodellen, lage administratieve lasten en een pay-pser-use concept.



Ontwikkelkosten: de ontwikkelkosten van een applicatie verschillen per applicatie en zijn eenmalig. Bij deze kostenstructuur past projectfinanciering het beste. Deze kosten worden dus niet gemaakt door de applicatiestore en worden direct gedragen door de aanbieder. Samenwerking tussen opdrachtgevers inzake ontwikkeling is uiteraard een optie. Scenario 1 en 2 hanteren projectfinanciering als bekostigingsmethodiek voor ontwikkelkosten. Voor scenario 3 en 4 geldt dat de initiële financiering via projectfinanciering verloopt, maar dat de verkoop van de applicatie zorgt voor inkomsten waarmee ontwikkelkosten (deels) terugverdiend kunnen worden.



Rijksapplicatiestore acceptatiekosten: deze categorie omvat Rijksapplicatiestoreacceptatiekosten (voor het goedkeuren van de applicatie zodat deze voldoet aan de requirements van de store). De Rijksapplicatiestore-acceptatiekosten komen repetitief tot stand per aangeboden applicatie met een standaard set aan activiteiten (en dus kosten). Ze zijn variabel met het volume aan aangeboden applicaties, derhalve is bekostiging op basis van p*q gepast.



Exploitatiekosten store: wanneer het aantal applicaties in de store toeneemt, groeien de exploitatiekosten marginaal. Het betreffen voornamelijk vaste kosten waarbij een verdeelsleutel moeilijk te vinden is. In dat geval past een lumpsum bekostiging. In scenario 1 en 2 worden de exploitatiekosten verdeeld over de aanbieders van applicaties: als men potentieel applicaties wil (gaan) aanbieden, betaalt men een deel van de exploitatielasten. Scenario 3 en 4 rekenen een percentage van de verkoopprijs van de applicatie als exploitatiekosten, zoals gebruikelijk bij commerciële applicatiestores.



Exploitatiekosten-applicatie: de aanbieder van een applicatie draagt zelf zorg voor de exploitatie en resulterende kosten. Deze kosten worden dus niet gemaakt door de Rijksapplicatiestore en worden direct gedragen door de aanbieder. In scenario 2 kunnen departementen op basis van gebruiksstatistieken afspraken maken voor toekomstige bekostiging van de applicatiekosten. In scenario 3 en 4 worden de exploitatiekosten (deels) terugverdiend door middel van verkoop van de applicatie.

Vier scenario’s 1) De aanbieder betaalt-scenario: de applicatie-aanbieder draagt alle kosten. 2) Gebruiksregistratie-scenario: initieel draagt de aanbieder alle kosten, echter op basis van afnamestatistieken kan de aanbieder in gesprek gaan met afnemers voor co-financiering van de kosten. 3) Commerciële Appstore-scenario: initieel draagt de aanbieder alle kosten, echter door middel van verkoop van de applicatie kan de aanbieder de kosten (deels) terugverdienen. 4) Gematigde Markt-scenario: initieel draagt de aanbieder alle kosten, echter door middel van verkoop van de applicatie kan de aanbieder de kosten (deels) terugverdienen. Verrekening vind plaats op groepenniveau en periodiek. Alle vier de scenario’s hanteren in ieder geval voor een deel van de kosten de p*qbekostiging. Voor scenario 2, 3 en 4 geldt dat er mogelijkheden zijn voor het terugverdienen van de kosten door de bredere distributie en/of verkoop van de applicatie. Voor elke investeringsbeslissing (het wel of niet maken van een applicatie) is de business case nog steeds het geijkte middel. Echter de terugverdien capaciteit van de applicatie door bredere verspreiding kan de uitkomst van deze business case positief beïnvloeden . Dit is natuurlijk afhankelijk van het gekozen scenario.


24 12.I000253 B05F

5.2 Scenario’s

Scenario 1. De aanbieder betaalt

De aanbieder betaalt In dit scenario draagt de applicatie-aanbieder alle kosten. Aanbieders van applicaties financieren zelf de ontwikkeling, acceptatie en exploitatie van de applicatie. De beheerkosten van de Rijksapplicatiestore worden op basis van lumpsum verdeeld over alle applicatie-eigenaren die applicaties aanbieden via de Rijksapplicatiestore. Zoals eerder beschreven zijn de kosten van de store nauwelijks afhankelijk van het aantal aangeboden applicaties, dus is een volumeafhankelijke bekostiging niet voor de hand liggend. Afnemers worden in dit scenario niet doorbelast, ze kunnen onbeperkt applicaties downloaden en gebruiken. Op deze manier wordt hergebruik bevorderd. Dit scenario is niet geschikt voor applicaties die per stuk additionele licentiekosten met zich meebrengen. Daarvoor is accordering en registratie van gebruik noodzakelijk. Kostencategorie

Ontwikkelkosten

Bron kosten Bekostiging

Aanbieder

Projectbekostiging

Wie betaalt

Store

P*Q

Aanbieder

Exploitatiekosten Rijksapplicatie store

Store

Lumpsum

Aanbieder

Aanbieder

Regulier budget

Voordelen ■ Eenvoudig bekostigingsmodel. Kosten zijn direct applicatiegebonden en ten laste van de aanbieder. Jaarlijkse afstemming omtrent lumpsumbedragen ■ Goed controleerbaar door auditdienst ■ Stimuleert gebruik van applicaties binnen eigen organisatie. Hergebruik van applicaties buiten de organisatie is in principe gratis voor de afnemer, maar aangezien de aanbieder hier slechts een gering financieel belang bij heeft, zal dit veelal niet actief gestimuleerd of ondersteund worden.

Aanbieder

Acceptatiekosten

Exploitatiekosten applicatie

Onderbouwing De aanname die ten grondslag ligt aan dit scenario is dat applicaties met name op departementaal niveau ontwikkeld en gebruikt zullen worden. Indien een applicatie gewenst is waar meerdere departementen baat bij hebben dan kunnen de departementen samen de ontwikkelkosten dragen, hoewel uit de interviews gebleken is dat dit feitelijk nog weinig gebeurt. Interdepartementaal kunnen vervolgens afspraken worden gemaakt over de doorbelasting van deze kosten. De doorbelasting kan geschieden volgens methoden die gangbaar zijn binnen de Rijksoverheid (P*Q met een nacalculatie, lumpsum).

Nadelen ■ Aanbieders dragen alle kosten, ook als de applicatie voornamelijk door andere departementen gebruikt wordt ■ Geen incentive voor gebruikers om applicaties minder intensief te gebruiken ■ Geen kostensturing ■ Niet toepasbaar voor applicaties met licentiekosten ■ Geen stimulans voor de ontwikkeling van applicaties die Rijksbreed inzetbaar zijn Budgetrisico ■ Geen budgetrisico bij aanbieders en afnemers. Kosten staan vast

Aanbieder


25 12.I000253 B05F

5.2 Scenario’s

Scenario 2. Gebruiksregistratie

Gebruiksregistratie

Onderbouwing

Aanvankelijk draagt de aanbieder van de applicatie alle kosten, echter in dit scenario is er de mogelijkheid om tevens de afnemer mee te laten betalen aan de exploitatiekosten. De Rijksapplicatiestore registreert nauwkeurig de afname van applicaties. Deze managementinformatie dient als instrument voor de aanbieder om in gesprek te gaan met de afnemer. Vervolgens kunnen afspraken door de aanbiedende partij met de afnemende partijen gemaakt worden over de bekostiging. Als de bekostiging hoger is dan de feitelijke exploitatielasten, kan de aanbieder van de applicatie daarmee ook (deels) de initiële investering terugverdienen, dan wel een “potje” opbouwen voor verdere doorontwikkeling. De aanbieder kan eventueel in de Rijksapplicatiestore vermelden dat afnemers vanaf een bepaalde periode gevraagd worden om mee te financieren. Voor licentiekostendragende applicaties kan hier een accorderingsproces aan gekoppeld worden. De exploitatiekosten van de Rijksapplicatiestore worden bekostigd door de applicatie-aanbieders. Bron kosten Bekostiging Wie betaalt Kostencategorie

In dit scenario kan de aanbieder van de applicatie in gesprek gaan met (zware) afnemers om budgetafspraken te maken. De statistieken van het gebruik dienen als input voor deze budgettaire discussie. Bij het aanbieden van de applicatie kan ook al reeds vermeld worden wat de kosten zullen worden, zodat afnemers een afgewogen besluit kunnen nemen. Afnemers zijn hierbij de betreffende (Rijks)overheidsorganisaties. Voordelen ■ Eenvoudig bekostigingsmodel. Kosten zijn direct applicatiegebonden en aanvankelijk ten laste van de aanbieder. Jaarlijkse afstemming omtrent geregistreerd gebruik en de lumpsumbedragen ■ Eerlijk: zware afnemers worden gevraagd (dan wel verplicht) mee te betalen ■ Introduceert pay-per-use-elementen zonder noodzaak voor directe verrekeningsmethodiek ■ Stimuleert hergebruik van applicaties, maar ook bewustzijn bij de afnemer

Ontwikkelkosten

Aanbieder

Projectbekostiging

Aanbieder

■ Opbouw van financiële reserve (“potje”) voor doorontwikkeling mogelijk ■ Inzetbaar voor applicaties met licentiekosten Nadelen

Acceptatiekosten

Store

P*Q

Aanbieder

■ Onderhandelingen kosten tijd en geld ■ Resulteert in interdepartementale geldstromen

Exploitatiekosten Rijksapplicatiestore


Budgetrisico Store

Aanbieder

Lumpsum

Regulier budget/ verrekening met afnemer

Aanbieder

■ Beperkt budget risico: vaste kosten. Co-financieringsafspraken gelden voor toekomstige kosten, niet voor reeds gemaakte kosten

Aanbieder mogelijk samen met afnemers


26 12.I000253 B05F

5.2 Scenario’s

Scenario 3. Commerciële Appstore

Commerciële Appstore

Onderbouwing

Dit scenario is gebaseerd op het businessmodel van commerciële stores zoals de Apple Appstore en Google Play’s Android store. Hier betalen afnemers voor gebruik en hiermee worden de aanbieders gecompenseerd. De afnemer bepaalt wanneer hij een applicatie of dienst wil aanschaffen. Applicaties worden gratis aangeboden, zijn eenmalig aan te schaffen of worden betaald via een abonnementsmodel. De prijs is bij aanschaf bekend en er vindt geen nacalculatie plaats.

De initiële kosten zijn voor rekening van de aanbieder, echter door middel van doorbelasting op basis van afname/gebruik kunnen deze kosten (deels) terugverdiend worden. Dit model introduceert bekostiging naar gebruik, maar is niet zonder risico. Afnemers zijn hierbij de betreffende (Rijks)overheidsorganisaties. De aanbieder kan zelf bepalen of ontwikkelkosten meegenomen worden in de prijsstelling. Als de aanbieder ontwikkelkosten meeneemt, heeft dit budgettaire consequenties. Binnen een baten– en lastendienst worden investeringen jaarlijks opgenomen als kosten. In dit model zou de aanbieder dus in de jaren van exploitatie inkomsten krijgen terwijl de kosten hiervoor al boekhoudkundig verwerkt zijn. Dit zal boekhoudkundig gefaciliteerd moeten worden.

De commerciële stores maken gebruik van directe facturatie, echter een overheidsvariant kan zijn om periodiek te factureren vanaf de aanbieder aan de afnemer op basis van statistieken uit de Rijksapplicatiestore. Een vast percentage van de verkoopprijs van de applicatie wordt gereserveerd door de Rijksapplicatiestore, ter compensatie voor de exploitatie van de store. Wie betaalt Wie betaalt Bron kosten Bekostiging Kostencategorie (initieel) (bij verkoop) Ontwikkelkosten

Aanbieder

Projectbekostiging

Aanbieder

Voordelen ■ Eigenaren zijn in staat om ontwikkelkosten en exploitatiekosten neer te leggen bij de afnemer, terugverdien mogelijkheid ■ Eerlijke verdeling van de lasten ■ Stimuleert innovatie van applicaties die Rijksbreed inzetbaar zijn

Acceptatiekosten

Exploitatiekosten Rijksapplicatiestore

Store

Store

P*Q

% van verkoopprijs applicatie

Nadelen

Aanbieder Gebruiker (prijs per applicatie) Store

■ Departementen zijn niet ingesteld op onbekende extra inkomsten of tekorten ■ Resulteert in interdepartementale geldstromen, verzwaring administratieve lasten Budgetrisico

Exploitatiekostenapplicatie

Aanbieder

Regulier budget

Aanbieder

■ Budgetrisico is sterk aanwezig op meerdere plaatsen in de keten


27 12.I000253 B05F

5.2 Scenario’s

Scenario 4. Een gematigde markt

Gematigde markt

Onderbouwing

Dit scenario is gebaseerd op het business model van commerciële stores zoals de Apple Appstore en Google Play’s Android store, maar richt zich qua betaling niet op het individu, maar op groepen. Betaling vindt dan niet plaats tussen een individu en de aanbieder van een applicatie, maar tussen een groep afnemers en de aanbieder. Groepen aanbieders kunnen zijn: departementen, onderdelen van departementen (afdelingen), proceseigenaren, etc. Belangrijk daarbij is dat de gebruikersgroep een gemeenschappelijke budgetverantwoordelijke heeft: het is die budgetverantwoordelijke die bepaalt of de gebruikers de applicaties mogen gebruiken, de kosten in overweging nemende.

De initiële kosten zijn voor rekening van de aanbieder, echter door middel van doorbelasting op basis van afname/gebruik kunnen deze kosten (deels) terugverdiend worden. Dit model introduceert bekostiging naar gebruik. De aanbieder kan zelf bepalen of ontwikkelkosten meegenomen worden in de prijsstelling. Als de aanbieder ontwikkelkosten meeneemt, heeft dit budgettaire consequenties. Binnen een baten– en lastendienst worden investeringen jaarlijks opgenomen als kosten. In dit model zou de aanbieder dus in de jaren van exploitatie inkomsten krijgen terwijl de kosten hiervoor al boekhoudkundig verwerkt zijn. Dit zal boekhoudkundig gefaciliteerd moeten worden.

Daarbij kan de betaling om de administratieve lasten te beperken ook periodiek plaatsvinden (jaarlijks, halfjaarlijks) in plaats van onmiddellijk bij afname. Kostencategorie Ontwikkelkosten

Acceptatiekosten

Exploitatiekosten Rijksapplicatie store

Bron kosten Bekostiging Aanbieder

Store

Projectbekostiging

P*Q

Store

% van verkoopprijs applicatie

Aanbieder

Regulier budget

Wie betaalt (initieel)

Wie betaalt (bij verkoop)

Voordelen ■ Eigenaren zijn in staat om ontwikkelkosten en exploitatiekosten neer te leggen bij de afnemer, terugverdienmogelijkheid ■ Eerlijke verdeling van de lasten

Aanbieder

■ Stimuleert innovatie van applicaties die Rijksbreed inzetbaar zijn ■ Door gematigde werking (geen individuele verrekeningen, en het verrekenen in periodieken i.p.v. direct) lage administratieve lasten

Aanbieder

Store

Gebruikers groepen (prijs per applicatie) Periodiek.

Nadelen ■ Departementen zijn niet ingesteld op onbekende extra inkomsten of tekorten ■ Resulteert in interdepartementale geldstromen, verzwaring administratieve lasten Budgetrisico


Aanbieder

■ Budgetrisico is sterk aanwezig op meerdere plaatsen in de keten


28 12.I000253 B05F

5.3 Risico’s binnen de scenario’s

De verschillende scenario’s brengen verschillende risico’s met zich mee

Opbrengstenrisico’s  Geen opbrengstenrisico: vaste opbrengsten per ontwikkelde applicatie

 S1: Geen opbrengsten  S2,3,4: OPBRENGSTENRISICO: Onbekend wat opbrengsten zullen worden

Kostenrisico’s

Developer

 Geen kostenrisico (geen kosten) Salaris/ vergoeding

 Geen kostenrisico: vaste kosten per applicatie/infra

Applicatie-aanbieder

Vergoeding per download

 S1,2: geen opbrengsten  S3,4: OPBRENGSTENRISICO: Onbekend wat opbrengsten zullen worden

• Plaatsingskosten • Vaste applicatiestore kosten  Geen kostenrisico: vaste kosten per applicatie/infra

Rijksapplicatiestore Kosten per applicatie

 Geen opbrengstenrisico (geen opbrengsten)

Gebruiker/departement Kosten voor applicatiestore infra

 Geen opbrengstenrisico (vaste inkomsten)

 S1,2: kosten van te voren bekend  S3,4:KOSTENRISICO: Onbekend wat kosten voor applicaties gaan worden: afhankelijk van noodzaak, wens en gebruik  Geen kostenrisico (vaste kosten)

IT-provider Nb: s1-s4= scenario 1-4 © 2012 KPMG Advisory N.V., registered with the trade register in the Netherlands under number 33263682, is a subsidiary of KPMG Europe LLP and a member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (‘KPMG International’), a Swiss entity. All rights reserved. Printed in the Netherlands. The KPMG name, logo and ‘cutting through complexity’ are registered trademarks of KPMG International.

Nb: s1-s4= scenario 1-4 29 12.I000253 B05F

5.4 Vergelijking scenario’s

Verschillen tussen de scenario’s

Verschillen op hoofdlijnen hoog

De verschillende scenario’s hebben elk hun eigen voor- en nadelen. In een volgend hoofdstuk schetsen wij een aanpak om de scenario’s te ranken op basis van een 17-tal kenmerken, onderverdeeld in vier categorieën (Effect, Inzicht, Risico en Uitvoer). Als wij naar twee specifieke elementen kijken (uitvoerbaarheid versus effect), kunnen wij ook al een onderverdeling maken: een scenario dat óf te laag scoort in uitvoerbaarheid óf te laag scoort in effect, ligt niet voor de hand om te implementeren. Daarom in iets meer detail de resterende scenario's 2 en 4.

laag

Onvoldoende uitvoerbaar

Uitvoerbaarheid

Scenario

1 Scenario

2 Scenario

4

Het verschil tussen scenario 2 en 4

Scenario

3 Niet effectief genoeg laag

Effect

Scenario 1= “De aanbieder betaalt” Scenario 2= “Gebruikersregistratie” Scenario 3= “Commerciële appstore” Scenario 4 = “Gematigde markt”

Scenario 2 “Gebruikersregistratie” en scenario 4 “Een gematigde markt” hebben een aantal overeenkomsten:  Beiden gaan uit van periodieke verrekening (jaarlijks bij scenario 2);  Bieden richten zich niet op individuen qua verrekening, maar op groepen;  Beiden stimuleren hergebruik.

hoog Er zijn ook verschillen:  Scenario 2 gaat impliciet uit van een budget, waarbij door extra gebruik er inkomsten kunnen komen. Scenario 4 gaat uit van een payper-use model om de kosten te verrekenen;  De inkomstenrisico’s zijn bij scenario 2 lager (budget vooraf) dan bij scenario 4 (pay-per-use).


30 12.I000253 B05F

5.4 Vergelijking scenario’s

De gebruiksregistratie biedt de meeste voordelen, het commerciële applicatiestoremodel past niet Scenario afweging Schaal:

Scenarios

++ = zeer goed, + = goed, +/- = gemiddeld, - =matig, -- =slecht

Gewicht

Eigenaar betaalt Gebruiks registratie

Commerciële appstore

Gematigde Markt

Effect Stimuleert innovatie

2

Stimuleert hergebruik van applicaties

2

Stimulert ontwikkeling rijksbrede applicaties

2

Transparant

2

Compleet & systematisch

1

Ondersteuning bij besluitvorming

1

Oorzaak - gevolg kosten inzichtelijk

2

+/--

+/+/+/-

++ ++ ++

+ + +

+/+ + ++ --

+/+ ++ + ++ ++

+ + + ++ -++

+ + + + + ++

++ ++ ++

++ + -

----

----

++ -++ ++ ++

+ +/+ ++ ++

-++ + ---

+/++ + +/+/-

6,3

7,2

5,0

5,7

Inzicht

Controleerbaarheid (audit)

1

Toepasbaar bij applicaties met licentiekosten

2

Geen budget risico bij appstore provider

2

Geen budget risico bij applicatie eigenaar

2

Geeen budgetrisico bij gebruiks (-organisatie)

2

Eenvoudig in te voeren

2

Terugverdien mogelijkheid

1

Risico

Uitvoer

Schaalbaarheid

0,5

Lage administratieve lasten

2

Inpasbaar in overheidsbudget proces

2

Gewogen Eindcijfer

Indicatieve invulling aan de hand van KPMG interne expertmeningen. Definitieve invulling en waardering zullen door een workshop moeten worden gevalideerd. © 2012 KPMG Advisory N.V., registered with the trade register in the Netherlands under number 33263682, is a subsidiary of KPMG Europe LLP and a member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (‘KPMG International’), a Swiss entity. All rights reserved. Printed in the Netherlands. The KPMG name, logo and ‘cutting through complexity’ are registered trademarks of KPMG International.

31 12.I000253 B05F

5.5 De Kassafunctie

De Rijksapplicatiestore kassafunctie: balans tussen lusten en lasten De kassafunctie binnen de Rijksapplicatiestore Een belangrijke organisatorische implementatievraag is hoe de kassafunctie wordt ingericht. Het betreft hierbij de functionele kant: hoe worden de betalingen onderling verrekend? Zoals eerder beschreven, verdient het aanbeveling de verrekeningen periodiek plaats te laten vinden, om de administratieve lasten te beperken. Voor de kassafunctie zijn een aantal modellen denkbaar: voor het gemak wordt hier over departementen gesproken, dit kunnen ook andere organisatorische eenheden zijn, mits ze een eigen budgetverantwoordelijkheid hebben. 1. Verrekening-variant. Ieder departement heeft één of meerdere speciale virtuele “courant rekeningen”. Hierop wordt virtueel geld gestort door departementen die applicaties “kopen” van het betreffende departement, en vanuit deze rekening worden applicaties bij andere departementen aangekocht. Periodiek worden de courant rekeningen van de departementen onderling verrekend met daadwerkelijke budgetten (geld). 2. Credits-variant. Ieder departement heeft, net als in het vorige model, een virtuele “courant rekening” waarop credits binnenkomen voor verkochte applicaties, en waaruit applicaties aangekocht worden. Variatie met het vorige model is dat er nu jaarlijks geen onderlinge verrekening plaatsvindt, maar dat er centraal (nieuwe) ontwikkelingsbudgetten worden vastgesteld, te verdelen naar gelang de hoogte van de credit op de courant rekening (dus meer verkopen levert meer nieuw ontwikkelingsbudget op). Voordeel hiervan is dat niet alle departementen onderling hoeven te verrekenen, maar dat dit centraal gebeurt. 3. Departementaal prepaid-model. In dit model krijgt ieder departement jaarlijks een budget via een soort prepaid card. Voor elke gekochte applicatie wordt een aantal credits van de prepaid card afgehaald, voor elk verkochte applicatie wordt een aantal credits bijgeboekt. Zodra de credits op zijn, moet een departement deze bijkopen. Dit betekent concreet het storten van een reëel budget in een centraal ontwikkelingspotje.

Aan het eind van het jaar wordt het centrale ontwikkelingspotje verdeeld aan de hand van de resterende credits.Overgebleven credits vervallen. Hiermee wordt gestimuleerd dat men applicaties deelt (krijgt men credits voor). Maar er vindt minimale verrekening plaats (lage administratieve lasten). 4.

Stimuleringsmodel. In deze toevoeging op de andere modellen (met het eerste model lijkt het niet te combineren) worden de credits bij verkoop van een applicatie verdubbeld (zonder dat de koper dit dubbele bedrag hoeft te betalen). Hiermee wordt gestimuleerd dat men applicaties zo breed mogelijk verkoopt.

Welke kassa is het beste? Een kassa binnen de Rijksapplicatiestore heeft een speciale rol. De kassa moet de overall doelstellingen van de Rijkscloud (-applicatiestore) stimuleren en ondersteunen. Belangrijke uitgangspunten daarbij zijn effectiviteit (o.a. stimuleren innovatie, hergebruik van applicaties en ontwikkelen rijksbrede applicaties), inzicht bieden en risico’s reduceren. Dit is eenvoudig uitvoerbaar. Daarbij lijkt de verrekeningsvariant het dichtst aan te sluiten bij een echte commerciële appstore (met de inherente drivers voor innovatie en hergebruik), maar zorgt wel voor diverse verrekeningen tussen departementen. De creditsvariant heeft minder administratieve kosten, maar vergt het instellen van een centraal budget en stimuleert maar tot beperkte hoogte hergebruik. Het departementale prepaid-model heeft de minste administratieve lasten, maar ondersteunt ook de beleidsdoelstellingen het minst direct. Met het stimuleringsmodel kan men de effectiviteit van het credit model en het prepaid-model wel nog vergroten. Welk kassamodel het beste de beleidsdoelstellingen ondersteunt, zal in nader onderzoek moeten worden vastgesteld.


32 12.I000253 B05F

6. Toekomstvisie & Aanbevelingen

Blik op de toekomst

Hoe kan de applicatiestore zich verder ontwikkelen?

Pleio, Plein Overheid als toekomstmodel

Vijf succesfactoren voor een goede applicatiestore

Pleio is een platform voor de overheid: om samen te werken en om voorzieningen op in te richten. Het is gebaseerd op Open Source (Elgg). Diensten die Pleio bijvoorbeeld aanbiedt: werkomgevingen voor ambtenaren die intra-organisaties aan een project werken, hosting van data-opslagruimte (werken in de cloud) en hosting van intranetten. Pleio moet worden gezien als een bottum-up gestuurde organisatie die ambieert om de gebruikers te geven wat ze van de huidige ICTorganisaties binnen de Rijksoverheid niet krijgen. Ander belangrijk uitgangspunt is dat iedereen die bijdraagt, een aandeel heeft in het geheel. Elke op Pleio aangesloten dienst wordt automatisch ter beschikking gesteld aan de gehele Rijksoverheid/alle gebruikers van Pleio. Uitgangspunt van de financiering van Pleio is dat centraal de basisvoorziening wordt geregeld en decentraal de specifieke diensten. Kosten voor de ontwikkeling van de dienstverlening en het aansluiten (interfaces) zijn voor rekening en risico van de opdrachtgever.

Volgens het magazine CIO.Com moeten enterprise appstores aan een vijftal zaken voldoen om succesvol te zijn. De Rijks Appstore zal dus ook hieraan moeten voldoen, wil ze zich groots kunnen ontwikkelen.

De Rijksapplicatiestore, nu en in de toekomst Pleio probeert een soort ecosysteem in te richten voor de overheidsprofessional, die zijn gewenste functionaliteiten kan op- of uitschakelen. Een Rijksapplicatiestore zou ook op deze manier moeten werken. De Rijksapplicatiestore kan als toegevoegde waarde hebben dat men snel goede initiatieven kan delen en dat het een vindplaats van functionaliteit wordt. Van simpele store naar een echt marktplein. Vraag is wel of het concept van een applicatiestore een toekomstvaste oplossing. Met een applicatie moet voor elke device een specifieke app gemaakt worden. Gaan we niet toe naar een model met bijvoorbeeld alleen links naar websites waar dezelfde functionaliteit wordt aangeboden?

1. Applicaties zijn makkelijk te vinden Organisaties moeten ervoor zorgen dat er een gemakkelijke search en discoveryfunctie voor toepassingen in een onderneming app store bestaat. Zeker als de store groeit, wordt dit een urgent probleem 2. Goede feedback of beoordelingen Beoordelingen en feedback zijn essentiële onderdelen van de onderneming applicatiestore. Als de Appstore niet over deze functie beschikt, dan is het moeilijk om de tevredenheid van gebruikers van de app te volgen binnen de organisatie. 3. Social Media integratie Veel organisaties maken gebruik van sociale media voor interne communicatie, maar verbinden deze niet met de enterprise app stores. De enterprise app store moet naadloos integreren met sociale media om de informatie, ontdekking, aanbevelingen, voorkeuren en opmerkingen over de apps te vergemakkelijken. 4. Goed beveiligings- en privacybeleid Als een app wordt ingediend voor publicatie in de app store, moet de applicatie worden gecheckt qua beveiliging. 5. Afdwingen User Interface en Visual Design Best Practices Alle enterprise apps moeten voldoen aan gepubliceerde richtlijnen met betrekking tot user experience (UX), visuele ontwerpen, kleur- en navigatieplannen en andere UI- (user interface) en UX-richtlijnen.

Bron: Cio.com © 2012 KPMG Advisory N.V., registered with the trade register in the Netherlands under number 33263682, is a subsidiary of KPMG Europe LLP and a member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative (‘KPMG International’), a Swiss entity. All rights reserved. Printed in the Netherlands. The KPMG name, logo and ‘cutting through complexity’ are registered trademarks of KPMG International.

34 12.I000253 B05F

Blik op de toekomst

Persoonlijke bekostiging met behulp van een prepaid budgetcard

De prepaid budgetcard De conclusie tot nu toe over de verschillende scenario's was dat een persoonlijk budget (zoals in scenario 3 geschetst) organisatorisch niet realistisch lijkt. Een mogelijke vorm om toch tot een persoonlijke financiering van de Rijksapplicatiestore op basis van pay-per-use te komen, is in de vorm van een prepaid budgetcard (een soort interne iTunes Card)., als aanvulling op scenario 4 (Gematigde Markt). Hiermee wordt binnen de Belastingdienst reeds geëxperimenteerd. Werking van prepaid budget:  Een medewerker van het Rijk krijgt een prepaid card. Op deze kaart staan de

credits die zijn budgethouder heeft betaald aan de Rijksapplicatiestore.  Het aantal credits dat de budgethouder heeft betaald, is het budget aan

applicaties voor dat jaar. De eindgebruiker is in dit model ook echt de eindgebruiker en niet de budgethouder.  Per download van een applicatie uit de Rijksapplicatiestore wordt bij de gebruiker een aantal credits in rekening gebracht. Voordelen en nadelen van de prepaid budgetcard

 De prepaid budgetcard is een eenvoudige manier om gebruik te

administreren en kan een opstap vormen naar scenario 3, waar bijvoorbeeld ontwikkelkosten kunnen worden terugverdiend op basis van gebruik Met een prepaid budgetcard is het mogelijk een pay-for-use financiering van de Rijksapplicatiestore vorm te geven, waar op basis van gebruik door de eindgebruiker wordt betaald. Dit met een relatief simpel budgetteringssysteem dat ministeries in hun begrotingen niet confronteert met onvoorziende uitgaven. Dit maakt een prepaid budgetcard als een mogelijke pay-per-usebekostigingssystematiek die tussen scenario 1 en scenario 2 in zit. Ook in dit model moet de keuze worden gemaakt bij de prijsstelling van de applicaties of hier alleen de exploitatiekosten van de Rijksapplicatiestore uit worden gedekt of ook de ontwikkelkosten met dito opbrengsten voor de opdrachtgever die de applicaties ontwikkeld heeft. In lijn van eerdere discussies gaan wij er hier vanuit dat alleen de exploitatiekosten van de applicaties gedekt worden, maar de keuze voor de applicatie prepaid budgetcard maakt wel dat er eenvoudig doorgestapt kan worden naar een volledige toepassing van scenario 3.

 Voordelen:  Legt de kosten waar deze gemaakt worden en stimuleert het

kostenbewustzijn. Al zijn de meerkosten bij meer gebruik van de Rijksapplicatiestore relatief  De prepaid budgetcard is in te passen in de budgetteringsystematiek van de overheid. Ook kleinere overheidsorganisaties kunnen op deze manier gemakkelijk en transparant betalen op basis van gebruik

Vast jaarbudget

 Nadelen:  Er wordt een nieuw systeem geïntroduceerd, de prepaid card  Incentives voor het ‘opmaken ‘ van het budget

Budget gebonden


Pay-per-Use Prepaid Prepaid cards Prepaid cards Prepaid cards cards

Rijkscloud Appstore

35 12.I000253 B05F

Blik op de toekomst

CBP: Gebruik BSN voor Rijkspas is in strijd met de wet. Maar wat dan wel?

Het probleem: wie is de ambtenaar Door een recente uitspraak van het CBP is het gebruik van het BSN-nummer voor de Rijkspas niet toegestaan: “uitgifte van de Rijkspas aan de rijksambtenaren niet is aan te merken als het uitvoeren van een publiekrechtelijke taak […] de noodzaak van de verwerking van het BSN bij de uitgifte van de Rijkspas aan rijksambtenaren door eiser niet is aangetoond (bron: LJN: BR7092, Rechtbank 'sGravenhage , AWB 11/2937) . Deze problematiek valt buiten scope van dit rapport. Echter, een goede en eenduidige identiteitscontrole is voor de Rijksapplicatiestore wel essentieel en randvoorwaardelijk voor de dienstverlening. Daarom zullen wij hier kort een drietal oplossingsrichtingen schetsen die op korte termijn identity management mogelijk maken, hangende verdere besluitvorming binnen de overheid en (her)inrichting van een definitieve Rijkspas-oplossing.

2. De iDeal manier: een federatief IAM-netwerk tussen de verschillende ministeries en hun ZBO’s en agentschappen Een federatief IAM-systeem ontstaat door “los-vaste”-koppelingen te maken tussen de verschillende IAM-registraties die al bestaan. Dit houdt in dat bij het inloggen op een aangesloten systeem, de verschillende IAM-registraties worden bevraagd en er namens de originele registratie een uitspraak wordt gedaan over de authenticatie en autorisatie van een ambtenaar. Dit systeem lijkt bijvoorbeeld op iDeal voor betalingen, of de manier waarop Google haar verschillende diensten met één authenticatie ontsluit. Omdat de verschillende registraties van verschillende kwaliteiten zijn, zou het kunnen dat sommige departementen (ZBO’s/agentschappen) niet kunnen deelnemen zonder hun eigen administratie up-to-spec te brengen. NB eHerkenning is een specifieke invulling van de iDeal-methode.

1. Gebruik eHerkenning, niveau 1 De eHerkenning is het aangewezen authenticatie- en autorisatiemiddel voor alle B2G-contacten (business to government). Steeds meer overheden sluiten op eHerkenning aan en eHerkenning is door de EC benoemd tot voorbeeld voor de EU. Door de infrastructuur van eHerkenning te gebruiken, kan een kant-en-klare oplossing, werkend met gebruikelijke standaarden en een goed normenkader snel gedeployed worden (veiliger krijg je het niet). Dit lijkt bijvoorbeeld ook op DigiD (alleen in een ander domein). Omdat eHerkenning een publiek private samenwerking is, betekent dit dat: - de ambtenaren in een registratie van een marktpartij worden opgenomen

3. Gebruik Google OpenID, facebook OpenID e.d. Er zijn “open” oplossingen in de markt die op een betrouwbare en goede architectuur gestoeld zijn. Deze IAM-oplossingen gaan niet uit van vaste identiteiten, maar van eigen identiteiten. Dit betekent dat men zelf een identiteit aanmaakt en die laat koppelen aan de te gebruiken dienst. Voor de applicatiestore moet hiervoor wel een vorm van autorisatie geregeld worden. Dat wil zeggen dat een leidinggevende op een gegeven moment de koppeling van de identiteit moet goedkeuren en daar een autorisatie aan moet toekennen (wat mag die identiteit doen op het systeem). Bij gebruik van publieke IAM-systemen speelt hier wel een groot privacydilemma.

- of dat de overheid een eigen registratie koppelt aan de eHerkenninginfrastructuur


36 12.I000253 B05F

Conclusie en aanbeveling

Een Gebruikersregistratiemodel stimuleert hergebruik binnen bestaande context Afwegingen per scenario

Conclusie

Op basis van o.a. de vraagstelling, algemene uitgangspunten, rijksspecifieke uitgangspunten (met name budgettaire processen), toekomstverwachtingen, kosten, gemat van implementatie en exploitatie etc., zijn er een viertal scenario’s ontwikkeld. Deze zijn vervolgens aan die uitgangpunten getoetst. Er is geen scenario dat op alle onderdelen het hoogst scoort.

De intrinsieke voor- en nadelen van de verschillende scenario’s zijn dus gelegd naast de bekostigingsuitgangspunten van de overheid, algemene ITbeleidsuitgangspunten en meer algemene applicatiestore gerelateerde kenmerken. Op basis daarvan komen wij tot de conclusie dat op basis van de gestelde uitgangspunten scenario 2 “Gebruikersregistratie” het hoogst scorende compromis vormt tussen wenselijkheid, haalbaarheid, innovatie en efficiency.

Scenario 1 “De aanbieder betaalt” scoort hoog op budgettaire risicobeheersing en op gemak van uitvoer. Maar daar tegenover staat dat het geheel geen inzicht geeft in daadwerkelijk gebruik, het slechts beperkt tot kostenbewustheid en rijksbreed hergebruik van applicaties leidt. Scenario 2: “Gebruikersregistratie” scoort hoog op inzicht in daadwerkelijk gebruik en sturing daarop. Ook de uitvoerbaarheid ligt hoog. Maar het introduceert wel een (beperkt) budgetrisico en stimuleert maar beperkt Rijksbreed hergebruik van applicaties. Scenario 3: “Commerciële applicatiestore” is een echt publiek internetmodel. De gebruiker betaalt alleen voor wat hij of zij nodig heeft. Maximale kostenbewustheid/inzicht bij de gebruiker dus. Daarnaast stimuleert dit model sterk innovatie: het loont om applicaties te ontwikkelen en aan te bieden, zeker als men de vraag naar de applicatie kan stimuleren. Dit scenario scoort echter slecht op inpasbaarheid binnen de overheidsbudgettering. Het introduceert budgetrisico's en allerlei (nieuwe) geldstromen. Daarmee is dit scenario potentieel ook kostbaar door de administratieve lasten. In de vorm van prepaid budgetkaarten is een deel van deze nadelen te ondervangen. Scenario 4: ”Gematigde markt” is een mengvorm tussen de commerciële appstores en vormen van registratie. Door betalingen enerzijds niet te koppelen aan personen, maar aan groepen, en anderzijds de betalingen periodiek te laten plaatsvinden, worden een aantal van de administratieve bezwaren van een commerciële applicatiestore ondervangen. Dit scenario deelt wel de budgetrisico’s met het commerciële applicatiestorescenario. Afhankelijk van de invulling van de kassafunctie wordt innovatie en hergebruik sterk of minder sterk gestimuleerd en kunnen de budgetrisico’s worden ingeperkt.

Als er echter meer belang wordt gehecht aan innovatie en hergebruik, kan ook het gematigde Marktmodel aantrekkelijk worden. Deze scoort op die punten hoger. De door de overheid geformuleerde doelstelling: “De store krijgt een kassafunctie, door functionaliteit te ‘kopen’ wordt het verrekenmechanisme in gang gezet” moet daarmee in eerste fase dus ruimer worden opgevat dan een echte, op geld gebaseerde, kassa. In dit rapport zijn een aantal mogelijke invullingen geschetst. Deze zullen nog verder uitgewerkt moeten worden in nader onderzoek. Ook scenario1 “De aanbieder betaalt” kent in een Rijkscloud-omgeving nog zijn toepassing. Voor applicaties waarvan vereist wordt dat eenieder (binnen een departement) deze gebruikt, is een registratie of pay-per-use mechanisme weinig zinvol. Een budgettaire verrekening op basis van solidariteit (of een andere lumpsummethode) ligt dan meer voor de hand. Scenario 3 “Commerciële applicatiestore”, zeker in de vorm van echte geldelijke verrekeningen, lijkt ons binnen de overheidsomgeving niet eenvoudig toepasbaar, met name door de administratieve lasten die het oplevert en de budgettaire risico’s. Door de introductie van een prepaid budgetcard kunnen de nadelen van scenario 3 deels worden ondervangen, zodat dit scenario alsnog toepasbaar wordt binnen een Rijksomgeving. Dit zal nader onderzocht moeten worden.


37 12.I000253 B05F

Bijlagen

Bijlage: Context

Met het programma Compacte Rijksdienst organiseert de overheid haar bedrijfsvoering en uitvoeringstaken doelmatiger Uitvoeringsprogramma Compacte Rijksdienst Het programma Compacte Rijksdienst is kaderstellend bij het opstellen van de departementale plannen van aanpak voor de invulling van de taakstelling. De met dit programma gerealiseerde netto en besparingen komen volledig ten goede aan de departementen die immers op hun begroting gekort zijn.

Effecten Compacte Rijksdienst

Eenheid

Doelmatigheid

COMPACTE RIJKSDIENST

Harmonisatie standaardisatie

Kostenbesparing

Het totale besparingspotentieel van het programma bedraagt circa EUR 700 tot EUR 800 miljoen. De bandbreedte van de besparingen is afhankelijk van nog te maken beleidsmatige keuzes (bijvoorbeeld bij project 12) of vereist aanscherping (bijvoorbeeld projecten 4 en 13). Het daadwerkelijk realiseren van de besparingen is een gezamenlijke verantwoordelijkheid van de departementen. Gemeenschappelijk applicatiegebruik onder de noemer van ‘overheids cloudcomputing’ maakt het mogelijk om redundante aankoop van software te voorkomen. Uitgangspunt hierbij is dat gemeenschappelijk software- en hardwaregebruik de norm is.

Projecten Compacte Rijksdienst met raakvlakken Rijksapplicatiestore:  Project 4 ICT-infrastructuur: doel is het reduceren van het aantal Rijksdienstdatacenters van 64 naar 4 à 5.  Project 7 realiseert één ICT dienstverlener voor de beleidskern en nauw verbonden uitvoeringsorganisaties. Het Shared Service Center ICT (SSC ICT) levert werkplekdiensten aan de beleidskernen en de nauw verbonden uitvoerende (kleinere) onderdelen. Uit het interview met de directeur SSC ICT, Perry van de Weyden, is naar voren gekomen dat SSC ICT momenteel bezig is met een Proofof-Concept van de Rijksapplicatiestore (interview d.d. 1 november 2012).

Bron:

Rijksoverheid: Compacte Rijksdienst Uitvoeringsprogramma; Jaarrapportage Bedrijfsvoering Rijk 2011; Jan Flippo (2011) De Compacte Rijksdienst Veranderingen in het IT-landschap; wat betekent dat voor de markt?


39 12.I000253 B05F

Bijlage: Context

Met de I-strategie wordt beoogd een rijksbrede Informatie-infrastructuur te ontwikkelen De Informatie-infrastructuur (I-infrastructuur) omvat de ICT-infrastructuur, de informatiehuishouding en de besturing daarvan. Het gaat daarbij om generieke kaders, diensten en producten die, in het kader van standaardisatie en hergebruik, beschikbaar worden gesteld aan alle organisaties binnen de Rijksdienst. De herinrichting van de I-infrastructuur zal in eerste instantie zijn gericht op de beleidskernen en de bijbehorende baten-lastendiensten. Het kabinet heeft er voor gekozen om, op basis van een positieve businesscase, ook de eigen uitvoeringsorganisaties te laten aansluiten op de rijksbrede bedrijfsvoeringsinfrastructuur en onderzoekt, mede op verzoek van de Tweede Kamer, de mogelijkheid om zelfstandige bestuursorganen (ZBO’s) eveneens te laten deelnemen. Het kabinet wil de mogelijkheden van cloud computing, in nauwe samenwerking met de markt maar in eigen beheer, benutten binnen de nodige randvoorwaarden op het gebied van informatiebeveiliging en aanbiederschap van gegevens. Zodoende kan de rijksambtenaar beschikken over een digitale werkomgeving die het mogelijk maakt altijd en overal bij de informatie te kunnen waarvoor hij of zij geautoriseerd is. Het gaat dan om zaken als netwerktoegang, generieke en specifieke applicaties, samenwerkfunctionaliteit (zoals social media) en keuzevrijheid in de te gebruiken apparatuur. Doorontwikkeling van de relatie en de samenwerking met het toeleverend bedrijfsleven is essentieel om geslaagde ICT-projecten te realiseren en om besparingsdoelen te halen. Voor nieuwe uitgaven zal in beginsel de ruimte moeten worden gevonden binnen de beschikbare kaders. De besluitvorming hierover wordt gebaseerd op business cases, die onderbouwen wat het concrete besparingspotentieel is en welke kosten noodzakelijk zijn om deze te realiseren.

Bron:

I-Strategie Rijk


40 12.I000253 B05F

Bijlage: Internationale voorbeelden applicatiestores

Case Study G-Cloud Cloudstore

G-Cloud Cloudstore Omschrijving

Begin 2012 heeft de Britse overheid de G-Cloud Cloudstore gelanceerd. Met behulp van de cloudstore kunnen (regionale) overheidsafdelingen eenvoudig IT-diensten afnemen. De cloudstore is een database met meer dan 1.700 diensten verdeeld over vier gebieden: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) en overige Services. G-Cloud toont alle benodigde informatie over de aanbieders en hun diensten. Het portaal voorziet in het aankoopproces tot aan de laatste stap: de finale selectie en aanschaf.

Doelstellingen ■ Het vergroten van de effectiviteit en efficiëntie van IT van de publieke sector;

Leveranciersaccreditatieproces Scoping template (Draft)

Scoping template Q&A

Added to pool awaiting submission

Scoping template approved

Assurance gained & evidence

Evidence set

PGA Scope Assessment

PGA asses accreditation recommendation

PGA: Pan Government Accreditation PSAB: Public Sector Accreditation Board

■ Verhogen flexibiliteit van het inkoopproces om snel te kunnen reageren op veranderende behoeftes; ■ Platform bieden voor midden– en kleinbedrijf om clouddiensten aan te bieden aan de overheid. Resultaten

■ De verwachte besparing van het G-Cloud & Cloudstore initiatief bedraagt £180 miljoen in de periode 2012-2015; ■ 74% van de leveranciers behoren tot het midden– en kleinbedrijf.

Risico’s

■ Het veranderen van de cultuur van maatwerk naar gestandaardiseerde diensten en producten is lastig;

Kritische prestatie indicatoren G-Cloud Programma ■ Kosten per FTE per cloud-product; ■ Het percentage van IT-aanschafkosten binnen de publieke sector gespendeerd in de Cloud-store; ■ Het aantal geaccrediteerde producten in de Cloudstore; ■ Het aantal geadopteerde diensten uit de Cloudstore.

■ Beperkte interesse van leveranciers leidt niet tot standaardisatie en rationalisatie; ■ Vertraging in het accreditatieproces. Bron:

G-Cloud Information Assurance Requirements and Guidance; Financial Times; ZDNet;


41 12.I000253 B05F


The U.S. Army Marketplace: applicatie (ontwikkel) platform voor het Amerikaanse leger The U.S. Army Application Marketplace brengt ontwikkelaars en eindgebruikers samen om te werken aan innovatieve oplossingen voor problemen van het Amerikaanse leger. Ontwikkelaars concurreren hier voor het aanbieden van de beste en meest relevante mobiele applicaties voor het leger. De marketplace is een portaal voor het ontdekken, publiceren, raten en bespreken van applicaties.

Het portaal zal in de toekomst ook de ontwikkeling en distributie van apps versnellen door de centrale aansturing, online ontwikkeling en testen en sociale netwerktools die nauwe samenwerking tussen ontwikkelaars en gebruikers faciliteren. Eindgebruikers kunnen aangeven aan welk type applicatie behoefte is, de applicatie kan vervolgens door het leger zelf of een derde partij ontwikkeld worden. Daarnaast wordt er periodiek de ‘Apps for the Army’-competitie georganiseerd waarin ontwikkelaars uitgedaagd worden om een app te bouwen.

Het nieuwe model wijkt af van het traditionele software licentiemodel: niet langer is afzet bij aanvang contractueel vastgelegd maar bepaalt de populariteit van de applicatie hoe vaak het afgenomen wordt.

Voorbeelden van applicaties:  Mobile learn: hiermee kan een gebruiker studeren door quizvragen te beantwoorden  Shok: deze app registreert, passief, extreme schokken in de omgeving, neemt automatisch foto’s en voegt de tijd en locatie toe. De gebruiker kan het rapport vervolgens verzenden. Dit kan gebruikt worden om informatie te verzenden meteen na een IED (improvised explosive device).  Tactical breathing: ademhalingsoefeningen om stress te verlagen.

Bron:

http://architecture.army.mil/technical-view/applications.html; Wired;


42 12.I000253 B05F


Applicatie ontwikkeling en distributie model U.S. Army Marketplace

Bron:

http://architecture.army.mil/technical-view/applications.html


43 12.I000253 B05F


U.S. Army Enterprise Software Development Process

Bron:

http://architecture.army.mil/technical-view/applications.html


44 12.I000253 B05F


Google Play Android Market

Google Play: het digitale distributiekanaal van Google Google Play voorziet in een online store van muziek, films, boeken, magazines en Android-applicaties (in Europa toont de store nu nog enkel applicaties). De dienst is toegankelijk via internet en door middel van de Play Store mobiele applicatie. Google Play is volledig in de cloud, alle muziek, films, boeken en applicaties worden online opgeslagen zodat ze altijd beschikbaar zijn. In de Android Market worden Android-applicaties aangeboden voor telefoons en tablets. Acceptatieproces ■ Applicaties moeten voldoen aan de ‘Core App Quality Checklist’ ■ Ontwikkelaars moeten een Google checkout account aanmaken en zorgdragen voor de juiste gegevens ■ Ontwikkelaars kunnen zelf applicaties publiceren, er vindt geen review plaats door Google Verdienmodel ■ Google Play rekent $ 25 voor het aanbieden van een applicatie ter review ■ Google houdt 30% op de verkoopomzet van applicaties, 30% op in-apppurchases en 30% van reclame-inkomsten Risico’s ■ Beperkte kwaliteitsborging door ontbreken formele Google applicatiereview ■ Een aanzienlijk deel van de applicaties maakt gebruik van privédata of heeft controle over functionaliteiten die niet in het verlengde liggen van de functie van de applicatie (Pausing Google Play: More Than 100.000 Android Apps may pose security risks) Bron:

http://architecture.army.mil/technical-view/applications.html; Wired; Silicon Republic


45 12.I000253 B05F

Bijlage: Publieke bronnen

Bronnenoverzicht

Websites Army Architecture http://architecture.army.mil/technical-view/applications.html HM Government G-Cloud: G-Cloud Information Assurance Requirements and Guidance. http://gcloud.civilservice.gov.uk/files/2012/05/G-Cloud-Services-IA-Requirements-and-Guidance-version-1-0-_forpublication_1-2.pdf  CIO.com www.cio.com

Artikelen / rapporten Army’s app store for war (Wired) http://www.wired.com/dangerroom/2011/04/armys-app-store-for-war/ Army marketplace brings app store to military (Huffington Post) http://www.huffingtonpost.com/2011/04/27/army-marketplace-brings-app-store-to-military_n_854275.html  Army poised to launch cloud computing pilot (Inside Defense) http://insidedefense.com/201202222391326/Inside-Defense-General/Public-Articles/army-poised-to-launch-cloud-computing-pilot-thatdevelops-an-app-mart/menu-id-926.html  Cloud Strategie Rijk: Kamerbrief over Cloud Computing. 2011  Compacte Rijksdienst uitvoeringsprogramma  Doelarchitectuur Gesloten Rijkscloud (concept, versie 0.5)  Exploring the cloud KPMG http://www.kpmg.com/global/en/issuesandinsights/articlespublications/pages/exploring-cloud.aspx G Cloud to cost 4.93 Million (Zdnet) http://www.zdnet.com/g-cloud-to-cost-4-93m-4010026055/  G-Cloud Information Assurance Requirements and Guidance http://gcloud.civilservice.gov.uk/2012/05/11/g-cloud-ia-guidance-v1-0-published/  Google play hits 25bn downloads http://www.siliconrepublic.com/new-media/item/29404-google-play-hits-25bn-downl

 Government ICT getting ahead in the cloud (Cap Gemini) http://capgemini.ft.com/cloud-computing/government-ict-getting-ahead-in-the-cloud_a-25-43.html  Government ICT Strategy - Strategic Implementation Plan: Moving from the ‘what’ to the ‘how’ (Cabinet Office UK) http://www.cabinetoffice.gov.uk/content/government-ict-strategy-strategic-implementationplan  Informatiseringstrategie Rijk (I-Strategie Rijk)  Kosten en baten van shared service centra: ‘De baten als ballast’ (KING) Report Bit9: Pausing Google Play https://www.bit9.com/pausing-google-play/ UK Government Cloud Strategy - A sub strategy of the Government ICT Strategy


46 12.I000253 B05F

Bijlage: geraadpleegde personen

Overzicht geraadpleegde personen

#

Gesproken met

Functie

1 Bart Seesing

CFO DICTU

2 Bob van Graft

Directeur GDI

3 Davied van Berlo

Ambtenaar 2.0 / Stichting Pleio

4 Jan-Willem Brock

Controller TBGI

5 Liesbeth Edelbroek

Directeur TBGI

6 Perry van der Weyden

Directeur ICT SSC

7 Tobias Schaap

Auditor ADR

8 Wietze Geertsma

Auditmanager ADR

9 Xander Bordeaux

IT Auditor ADR


47 12.I000253 B05F

Doorbelasting Rijksapplicatiestore

Recommend Documents