Aanschaf en vervanging applicaties
Gemeenten maken om goede redenen verschillende keuzes bij het ontwikkelen en kopen van applicaties. Daarbij kunnen allerlei overwegingen een rol spelen. Lokale uitgangspunten zoals ‘herbruiken voor kopen voor ontwikkelen’ of ‘bij voorkeur open source software’ bepalen mee welke applicaties binnen een bepaalde context het meest geschikt zijn.
We gebruiken hier de term 'applicatie' als aanduiding van 'een eenheid van software'. In de praktijk worden ook andere termen gebruikt om min of meer hetzelfde aan te duiden, zoals: (software)pakket, (software)component, (informatie)systeem, programma of toepassing.
Er zijn verschillende factoren die een rol spelen bij het maken van keuzes voor applicaties. Om dit te illustreren maken maken we onderscheid in 2 soorten, fundamenteel verschillende, applicaties. De tweedeling is afgeleid van het door Gartner ontwikkelde pace layering model dat 3 categorieën onderscheidt:
- Systems of Innovation: Innovatieve applicaties waarmee is in te spelen op nieuwe eisen of kansen; deze applicaties kennen vaak een relatief korte levensduur.
- Systems of Differentiation: Sector-specifieke Applicaties die unieke bedrijfsprocessen ondersteunen waarmee organisaties zich van elkaar kunnen onderscheiden.
- Systems of Record: Stabiele applicaties die basisgegevens bijhouden en gestandaardiseerde bedrijfsprocessen afhandelen; wetgeving speelt vaak een rol en beveiliging en robuustheid zijn cruciaal; deze applicaties kennen een lange levensduur.
Voor gebruik binnen de gemeentelijke context onderscheiden we innovatieve-applicaties ('systems of innovation') en meer traditionele-applicaties (’systems of record'). Beide soorten applicaties kunnen worden toegepast binnen een van de GEMMA afgeleide architectuur.
Onderstaande tabel toont een aantal kenmerken waarin beide soorten applicaties van elkaar verschillen. Het doel is om te illustreren dat contextuele factoren een belangrijke rol spelen bij het het ontwikkelen en kopen van gemeentelijke applicaties en er geen one-size-fits-all aanpak is. Uiteraard geldt dat het onderscheid tussen beide soorten applicaties in de praktijk niet zo zwart-wit is als hier wordt geschetst.
| Traditionele-applicaties | Innovatieve-applicaties | ||
| A | Karakter | Traditioneel, bewezen | Innovatief, nieuw |
| Bedrijfsprocessen | Bekend, Stabiel | Nieuw, Dynamisch | |
| Prioriteit | Data, Back-end | Interactie, Front-end | |
| Ontwerp | Wetgevingseisen | Gebruikerswensen | |
| Focus | Betrouwbaarheid | Gebruiksvriendelijkheid | |
| Aanpak | Waterval, Inkoop | Agile, Samenwerking | |
| Wijzigingen | Wetgeving, gebruikersgroep | Gebruikerswensen | |
| Levensduur | > 5 jaar | < 3 jaar | |
| B | Functionaliteit-clustering | Verticaal, monoliet | Horizontaal, (micro)services |
| Functionaliteit-granulariteit | Grofmazig, Service-orientatie | Fijnmazig, Microservices | |
| C | Software | Closed source | Open source |
| Technologie | Bewezen | Modern | |
| Bepalend | Leveranciers | Gemeenten | |
| D | Voorbeelden | DMS, Financien, Burgerzaken, Monumenten | Chatbot, ID-Wallet, Apps |
Toelichting[bewerken]
A - Voor de bedrijfsvoering van gemeenten is het belangrijk dat applicaties op een robuuste manier, conform wetgeving, kritische en gestandaardiseerde bedrijfsprocessen ondersteunen. Daarvoor wordt vaak gebruik gemaakt van traditionele taakgerichte applicaties die, steeds vaker via een SAAS-model, door marktpartijen worden aangeboden. Dit type applicaties functioneel wordt vaak langere tijd gebruikt en vervanging vindt plaats via een formeel project.
Als gemeenten hun dienstverlening aan burgers en bedrijven fundamenteel willen verbeteren, gaan zij vaker op zoek naar Innovatie-applicaties . Meestal gaat het daarbij om front-end applicaties om op een moderne manier met burgers en bedrijven te interacteren. Ontwikkeling ervan vindt vaak in samenwerking plaats via een agile aanpak waarbij gebruikerswensen centraal staan.
B - Applicaties kunnen meerdere soorten of juist hele specifieke soorten functionaliteit. In het eerste geval kan een applicatie bijvoorbeeld alle benodigde functionaliteit bevatten: van interactie met eindgebruikers tot en met functionaliteit om data vast te leggen en verstrekken. Als zo'n applicatie vastgelegde data niet voor extern gebruik beschikbaar is ze te typeren als een 'silo-applicatie'. Dat 1 applicatie/leverancier alle functionaliteit levert ontzorgt een gemeente, maar leidt ook tot een zekere leverancier afhankelijkheid.
Aan de andere kant van het spectrum bevinden zich applicaties die specifieke afgebakende functionaliteit leveren. Ze zijn meer bedoeld als 'component' om samen met andere applicaties alle benodigde functionaliteit te leveren. Deze benadering leidt tot een flexibeler informatievoorziening waarin applicaties gemakkelijker zijn te vervangen en minder leveranciersafhankelijkheid bestaat. Om te zorgen dat applicaties goed op elkaar zijn afgestemd en samenwerken moet een gemeente zelf regie voeren.
C - Meer traditionele applicaties zijn specialistisch van aard en worden veelal door leveranciers ontwikkeld en als closed source software aangeboden. Voor gemeenten is vooral belangrijk dat de applicatie betrouwbaar werkt en betaalbaar is.
Bij applicaties die bedoeld zijn om te innoveren is vaak sprake van samenwerking tussen gemeenten, die inhoudelijke kennis inbrengen, en leveranciers die software ontwikkelen. Er wordt daarbij meestal gebruik gemaakt van moderne technologie en de software wordt als open source beschikbaar gesteld.
De GEMMA beschrijft op een generieke manier de gemeentelijke bedrijfs- en informatiearchitectuur en kent daarbij een aantal fundamentele uitgangspunten. Er worden ook handvatten gegeven om in lijn daarmee de gemeentelijke bedrijfsvoering en informatievoorziening in te richten. Een belangrijk uitgangspunt is bijvoorbeeld dat applicaties via gestandaardiseerde API's in staat moeten zijn om data en functionaliteit met elkaar uit te wisselen. De GEMMA schrijft niet voor in welke mate en op welke manier dat precies moet gebeuren. Globaal programma van eisen voor pakketsoftware licht toe hoe dat er in praktijk verschillende ambitieniveaus zijn en de context meebepaalt wat wenselijk is. Bij meer traditionele applicaties, waar zorgvuldig beheer van data cruciaal is, zullen API's bijvoorbeeld vaker alleen raadplegen van data ondersteunen. Innovatieve applicaties zullen (ook) het wijzigen van data via API's ondersteunen.
Gemeenten hebben ook te maken met overheidsbrede en gemeentelijke programma's die duidelijke voorkeur hebben voor gebruik van bepaalde type applicaties. Het programma Common Ground heeft bijvoorbeeld als doel om de gemeentelijke informatievoorziening fundamenteel te verbeteren. Om de onderliggende Informatiekundige visie Common Ground te kunnen realiseren zijn vaker innovatieve applicaties nodig. Het liefst in samenwerking tussen gemeenten en leveranciers ontwikkeld en gepubliceerd als open source software.
Het is uiteindelijk aan gemeenten om keuzes te maken die goed passen binnen hun specifieke situatie. De verwachting is dat het aantal innovatieve applicaties stapsgewijs toeneemt, maar dat beide type applicaties een rol blijven spelen binnen het gemeentelijk informatielandschap.