ROSA metamodel
Het ROSA-metamodel beschrijft de onderlinge samenhang tussen architectuurelementen in het architectuurmodel. Het metamodel is gebaseerd op de ArchiMate-standaard. Zie voor regels en afspraken rondom het beheer van metamodelelementen Spelregels beheer. Het ROSA Metamodel sluit aan op het NORA vijflaagsmodel
Metamodel op hoofdlijnen[bewerken]
Ontwikkelingen zoals onderwijskundige veranderingen, innovaties, en beleidswijzigingen vormen externe drivers voor de ROSA. In de ROSA worden doelen geformuleerd die in lijn zijn met dit beleid en die doorvertaald worden naar principes, waarmee consistentie en samenhang in de keten wordt nagestreefd[1].
Wanneer binnen een project ontwerpbeslissingen worden gemaakt, vindt steeds een belangenafweging plaats op basis van concerns[2] van belanghebbenden. Daarbij geldt dat geen enkel concern ‘absoluut’ is – in de afweging tussen verschillende belangen vinden trade-offs plaats. Met het maken van ontwerpbeslissingen worden ontwerpproblemen (‘design issues’) opgelost.
ROSA omvat een aantal Ontwerpgebieden. De ontwerpgebieden zijn opgebouwd uit doelen, principes en ontwerpkaders. Ze representeren generieke ontwerppatronen die in enige vorm op (nagenoeg) alle projecten van toepassing zijn om ontwerpproblemen aan te pakken. De ontwerpkaders bieden concrete kaders en richtlijnen voor (keten)projecten om op dat gebied aan de doelen en principes van ROSA te voldoen.
ROSA deelt de onderwijsketen in in, inhoudelijk samenhangende, ketendomeinen, waarbinnen ketenprocessen zijn uitgewerkt in ketenprocesstappen. Elke ketenprocesstap is onderdeel van een overkoepelend ketenproces. Sommige ketenprocessen komen in zijn geheel als ketenprocesstap voor in een ander ketenproces. Voorbeelden van ketenprocessen zijn Toetsen en examineren.
Een ketensamenwerking realiseert één of meer ketenprocesstappen. Dat kan een gedeeltelijke realisatie zijn, en andersom kunnen er meerdere (bijvoorbeeld sectorspecifieke) realisaties zijn van dezelfde ketenprocesstap(pen)[3].
De ketenprocessen worden ondersteund vanuit IV-domeinen ("Informatievoorzieningsdomeinen"), zoals het IV-domein Toegang, waarin ondersteunende processen invulling geven aan ondersteunende functies. Patronen, zoals Federatieve toegang, bieden standaardoplossingen voor de realisatie van één of meer ondersteunende processen. Ketensamenwerkingen kunnen gebruik maken van patronen om de benodigde ondersteunende functies in te vullen, of (deels) zelf de ondersteunende processen realiseren.
Gemeenschappelijke Informatievoorziening[bewerken]
Vanuit de gemeenschappelijke informatievoorziening zijn concrete afspraken en voorzieningen beschikbaar die onderdeel kunnen zijn van bepaalde ketensamenwerkingen of patronen. Een ketensamenwerking respectievelijk een patroon is op zichzelf ook een invulling van een afspraak, en is daarmee ook onderdeel van de gemeenschappelijke informatievoorziening.
Scenarios[bewerken]
Ketenprocessen, ketensamenwerkingen, ondersteunende functies en patronen kunnen allemaal worden gespecificeerd volgens hetzelfde 'scenario'-metamodel, waarin het beoogde gedrag in relatie wordt gebracht tot de daarvoor benodigde gegevenssoorten, referentiecomponenten, rollen en zeggenschappen - in relatie tot de bijbehorende werkingsgebieden en KOI-begrippen.
- De scope van een toepassingsscenario (cf. AMIGO) is een referentiemodel van ketenprocesstappen binnen een ketenproces met bijbehorende referentiecomponenten, gegevenssoorten, rollen en zeggenschappen, etc.;
- De scope van een uitwisselingsscenario (cf. AMIGO) is de ketenprocesstappen binnen een ketensamenwerking met bijbehorende - op de ketensamenwerking toegespitste - referentiecomponenten, gegevenssoorten, rollen, zeggenschappen, etc, aangevuld met voorzieningen en afspraken uit de gemeenschappelijke informatievoorziening.
- De scope van een ondersteuningsscenario is een referentiemodel van ondersteunende processen binnen een ondersteunende functie met bijbehorende referentiecomponenten, gegevenssoorten, rollen en zeggenschappen, etc.;
- De scope van een patroonuitwerking is een configuratie van referentiecomponenten, voorzieningen, rollen, zeggenschappen, etc. t.b.v. de invulling van een of meer ondersteunende processen.
Volledig model[bewerken]
Dit diagram toont het totale metamodel van ROSA. In dit diagram zijn alle elementen uit de vorige deelfiguren samengebracht.
Voetnoten[bewerken]
- ↑ We volgen hierbij grotendeels de lijn van NORA, waar in 2021/22 (tot aan de zomer) een publieke review openstond voor een voorgestelde wijziging van de structuur van NORA-principes. Na deze wijziging wordt in NORA de basis van de architectuurafspraken gevormd door 5 Kernwaarden van Dienstverlening, ontleend aan beleid en wet- en regelgeving. Hieruit komen kwaliteitsdoelen voort die geconcretiseerd worden in architectuurprincipes. In NORA vervalt daarmee het onderscheid tussen Basisprincipes en Afgeleide principes. In ROSA hanteren we dat laatste onderscheid ook niet meer, maar omdat de herstructurering van NORA vooralsnog een concept is en de opbrengsten uit de publieke review nog niet uitgekristalliseerd zijn, is er nu wel voor een eigen invulling gekozen.
- ↑ cf. ISO/IEC/IEEE 42010: "A concern could be manifest in many forms, such as in relation to one or more stakeholder needs, goals, expectations, responsibilities, requirements, design constraints, assumptions, dependencies, quality attributes, architecture decisions, risks or other issues pertaining to the system."
- ↑ Bijvoorbeeld: centrale examens vo vs. logistiek proces eindtoets po