Het applicatiemodel (ook wel: “applicatie-architectuur”) beschrijft de applicaties die een instelling nodig heeft om haar processen te ondersteunen. Het model beschrijft deze applicaties (ook wel: “applicatiecomponenten”) op een logisch niveau, onafhankelijk van specifieke productkeuzen. Applicaties zijn daarmee logische groeperingen van functionaliteit die de geautomatiseerde ondersteuning bieden van bedrijfsprocessen. Applicaties worden primair gevormd door functionaliteit die ze aanbieden en de gegevens die zij beheren. Het bedrijfsfunctiemodel, het bedrijfsobjectmodel en het applicatiemodel vormen daardoor een soort drie-eenheid die bij elkaar de meest belangrijke informatievoorzieningsaspecten beschrijven. Het onderscheid in technische deelcomponenten is in het applicatiemodel niet relevant.
Het applicatiemodel is meer inrichtingsafhankelijk dan de eerder beschreven modellen. Het geeft aan welke eenheden worden voorgesteld om geautomatiseerd in te richten, waarbij de omvang van een eenheid primair wordt bepaald door de producten die beschikbaar zijn in de markt. Dit maakt het ook lastig te bepalen wat de juiste eenheid is; leveranciers bepalen vooral de omvang en trekken zich daarbij niet direct iets van andere leveranciers aan. Dat betekent dat wat de ene leverancier als één product aanbiedt (bijvoorbeeld een studentinformatiesysteem), door andere leveranciers als drie losse producten wordt aangeboden (inschrijfsysteem, studentvolgsysteem en onderwijscatalogus). In de discussie is gebleken dat we niet tot volledig eenduidige criteria kunnen komen om te bepalen wat de juiste omvang is. In dit specifieke geval hebben we toch gekozen om in het model maar één applicatie op te nemen omdat de markt neigt naar een geïntegreerde oplossing. Dat wil niet zeggen dat instellingen met drie losse applicaties slechter af zijn; zij hebben op basis van voor hen relevante argumenten een andere keuze gemaakt. We hebben er in het model voor gekozen vooral een ideaal applicatielandschap weer te geven. Dit geeft richting voor de toekomst en voorkomt het vasthouden aan suboptimale keuzes uit het verleden. Het model is daarmee dus nadrukkelijk een streefmodel waarbij instellingen zelf bepalen in welke mate en in welk tempo ze bewegen naar dit streefbeeld.
Het applicatiemodel biedt een checklist van concrete eenheden waarvan kan worden bepaald of ze het best in het eigen rekencentrum, in een community cloud of de public cloud kunnen worden geplaatst. De criteria die daarbij gebruikt kunnen worden zijn beschreven in de architectuurvisie. In het algemeen moet de toepassing van het applicatiemodel vooral worden gezocht in het gebruik als vergelijkingsmateriaal met het eigen applicatielandschap van instellingen. Door te kijken waar verschillen liggen tussen het streefmodel en de huidige inrichting ontstaat een beeld van mogelijke verbeteringen. De mate waarin deze verbeteringen voldoende waarde opleveren en aansluiten bij strategische doelstellingen van de instelling kan daarbij sterk verschillen. Het resulterende plan van verschillende instellingen zal dan ook heel verschillend zijn. Het applicatiemodel geeft ook zicht op het beheer en de uitwisseling van gegevens. Per applicatie is aangegeven voor welke gegevens de applicatie de meest logische bron is en de andere gegevens hij nodig heeft. Dit leidt automatisch ook tot inzichten over gewenste informatiestromen en koppelvlakken tussen applicaties. Zo zouden alle applicaties die een bepaald gegeven gebruiken deze moeten ophalen uit de bronapplicatie. Bij het gebruik van het applicatiemodel als meetlat voor het eigen applicatielandschap zouden dus ook de informatiestromen moeten worden meegenomen. Overigens is het niet altijd mogelijk om bedrijfsobjecten eenduidig aan één applicatie toe te wijzen. Dat komt enerzijds door de omvang van de geïdentificeerde bedrijfsobjecten te groot kan zijn om aan één applicatie toe te wijzen. Anderzijds doorlopen bedrijfsobjecten ook stadia waarbij verantwoordelijkheden kunnen veranderen. Zo heeft een prospect deelnemer een geheel andere status dan een actieve deelnemer of een alumnus. Ook de verantwoordelijke eigenaar en data steward kunnen daardoor veranderen.
We maken in het applicatiemodel onderscheid tussen applicaties die de eerder beschreven bedrijfsfuncties direct ondersteunen (Specifieke applicaties) en applicaties die in veel verschillende bedrijfsfuncties worden gebruikt (Generieke applicaties).
Zie ook de volgende gebieden voor meer gedetailleerde informatie:
Ook applicaties kunnen worden voorzien van een BIV-classificatie als basis voor informatiebeveiligingsmaatregelen. De BIV-classificatie van bedrijfsobjecten kan gebruikt worden om een BIV-classificatie voor applicaties af te leiden. Cruciaal voor het bepalen van de BIV-classificatie van een applicatie is de vraag of een applicatie die geen bronsysteem voor een bepaald bedrijfsobject is, de gevoelige attributen van dat bedrijfsobject ontsluit. Als die gevoelige attributen niet ontsloten worden kan de BIV-classificatie van dat bedrijfsobject buiten beschouwing worden gelaten bij de classificatie van die applicatie. Als voorbeeld is in de volgende tabel de BIV-classificatie van het bibliotheeksysteem volgens dat principe uitgewerkt. De bedrijfsobjecten die alleen worden geraadpleegd door het bibliotheeksysteem zijn schuingedrukt weergegeven.
Bedrijfsobject
B-score
I-score
V-score
uitleen
L
L
L
werk
L
L
O
expressie
L
L
O
manifestatie
L
L
O
item
L
L
O
deelnemer
M
H
H
medewerker
M
H
H
vordering
L
M
L
inkomende betaling
L
M
L
kostenplaats
L
M
L
BIV-classificatie
L
L
L
Tabel 1 Voorbeeldclassificatie van het bibliotheeksysteem
Als het bibliotheeksysteem wel gevoelige attributen van deelnemer en/of medewerker ontsluit, moet de classificatie van dit systeem aangepast worden. Het is te overwegen om specifieke attributen die veel impact hebben op de BIV-classificatie van een applicatie te verplaatsen naar een aparte applicatie om te voorkomen dat er mogelijk zware informatiebeveiligingsmaatregelen noodzakelijk zijn voor de applicatie. Zo zouden bijvoorbeeld de gegevens over functiebeperkingen van deelnemers en studie- en deelnemergerelateerde aantekeningen van begeleiders kunnen worden weggelaten uit het studentinformatiesysteem om te voorkomen dat deze een V-score van hoog zou krijgen. Of een dergelijke afsplitsing zinvol is dient per situatie te worden beschouwd.
