Bewerken pagina: Adviesdocument samenhang koppelvlakkenarchitectuur

U hebt geen toestemming om deze pagina te bewerken, want:

De gevraagde handeling is voorbehouden aan gebruikers in een van de volgende groepen: gebruikers, beheerders.
U hebt geen rechten om de gevraagde handeling te verrichten.

Elementtype^*

Het elementtype waaronder deze pagina valt. U kunt dit niet wijzigen omdat het formulier is afgestemd op het elementtype.

:

Datum planning evaluatie

De afgesproken datum waarvoor een planning wordt geëvalueerd door de Adviesgroep Samenhang Onderwijsarchitecturen

:

Evaluatie inhoud

:

Implementatiestatus^*

:

Ja Nee

Planning-status

:

Registratiedatum^*

Datum waarop het element is toegevoegd aan de ROSA Wiki

:

Realiseert

:

Vrije tekstU kunt hier extra informatie toevoegen. Deze zal onderaan de pagina getoond worden, maar is niet opvraagbaar via query's.

:

{|
!width="24%"| Versie
!width="24%"| Datum
!width="24%"| Auteur
!width="24%"| Omschrijving
!width="0%"|
|-
| 0.5
| 28-02-2024
| Joeri van Es
| Eerste conceptversie
|
|-
| 0.6
| 23-07-2024
| Joeri van Es
| Afgestemde versie met adviesgroep, advies 1 en 3 staan nog ter discussie
|
|-
| 0.7
| 30-10-2024
| Joeri van Es
| Versie ter externe afstemming
|
|}

= Inleiding =

De architectuur binnen het onderwijsveld is een complex samenspel van verschillende aanpakken en modellen, waarbij elke architectuur een eigen benadering heeft voor het modelleren van koppelvlakken. In de MORA worden bijvoorbeeld koppelvlakken op een hoger, referentieniveau uitgewerkt, terwijl in de MOKA (MBO Onderwijs Koppelvlakken Architectuur) een meer concrete uitwerking plaatsvindt. In andere SRA's binnen de onderwijssector worden koppelvlakken weer net iets anders gemodelleerd.

Deze diversiteit in benaderingen maakt het voor bovensectorale gegevensuitwisselingsinitiatieven, zoals bijvoorbeeld groeifond Edu-V, uitdagend om hun koppelvlakkenarchitectuur effectief af te stemmen op de architecturen van de verschillende sectoren. Dit gebrek aan afstemming kan leiden tot verminderde interoperabiliteit en beperkte realisatie van het ROSA-principe &quot;Samenhangend stelsel van architecturen&quot;. Dit op zijn beurt, is essentieel voor het faciliteren van ketensamenwerking en het ondersteunen van een leven lang ontwikkelen binnen het onderwijsdomein.

== Scope ==

Dit adviesdocument richt zich specifiek op de samenhang tussen koppelvlakstandaarden binnen het onderwijs. We beperken ons tot:

* De proces- en gegevenslaag van koppelvlakkenarchitectuur
* Standaarden zoals RIO en OOAPI
* Het logische niveau, niet het implementatieniveau

De infrastructuurlaag (netwerklaag) en de applicatielaag (servicelaag) vallen buiten scope omdat deze al worden afgedekt door andere Edustandaard afspraken.

De beoogde doelgroep van dit document zijn:

* Beheerders van de verschillende SRA's
* Softwareleveranciers die over sectorgrenzen heen werken
* Bovensectorale initiatieven zoals het groeifonds Edu-V

== ==

== Rationale ==

De ROSA streeft naar een samenhangend stelsel van architecturen. In de praktijk leidt het gebrek aan samenhang tussen koppelvlakstandaarden tot concrete problemen:

'''Praktijkvoorbeeld:'''

Een leverancier die zowel voor het mbo als het ho studentinformatiesystemen levert, moet voldoen aan verschillende koppelvlakkenstandaarden (bijvoorbeeld OOAPI en RIO) voor vergelijkbare gegevensuitwisseling. Wanneer moet de leverancier welke standaard gebruiken? En welke gegevensstructuur moet aan worden voldaan om te kunnen uitwisselen?

Door de samenhang tussen koppelvlakstandaarden te verbeteren:

# Ontstaat een gemeenschappelijke taal voor het beschrijven van koppelvlakken
# Verbetert de uitwisselbaarheid van informatie tussen onderwijssectoren
# Wordt het &quot;leven lang ontwikkelen&quot; beter ondersteund door naadloze technische en semantische interoperabiliteit.

== Probleemstelling en oplossingsrichting ==

Het ontbreken van samenhang tussen koppelvlakstandaarden in het onderwijs leidt tot:

* Inconsistenties in de modellering en beschrijving van koppelvlakken
* Belemmering van de interoperabiliteit tussen onderwijssectoren
* Onnodige complexiteit voor leveranciers die over sectorgrenzen werken
* Overlap tussen standaarden met vergelijkbare doelen

De kernvraag is hoe we de samenhang tussen koppelvlakstandaarden kunnen verbeteren zonder de flexibiliteit en sectorspecifieke behoeften uit het oog te verliezen. De adviezen in dit document vormen een vertrekpunt om dit te verwezenlijken, met ruimte voor beredeneerde afwijkingen waar nodig.

Na implementatie zullen we evalueren of deze aanpak het gewenste resultaat oplevert:

* Meer samenhang tussen verschillende koppelvlakstandaarden
* Minder knelpunten tussen verschillende standaarden
* Behoud van flexibiliteit voor sectorspecifieke invulling.

= Huidige situatie koppelvlakkenarchitectuur =

== Samenvatting koppelvlakkenarchitectuur ==

'''De definitie van koppelvlak''': ''Een interface die uitwisseling van gegevens tussen informatiesystemen verzorgt. (Bron: ROSA Begrippenkader)''

In deze context is een interface een gespecificeerd verbindingspunt tussen twee of meer systemen, dat de uitwisseling van gegevens mogelijk maakt volgens vooraf bepaalde standaarden en protocollen. Een koppelvlak werkt met standaarden die zijn vastgesteld door ROSA en Edustandaard. Het aanleverende systeem is verantwoordelijk voor de vertaling van gegevens naar die standaard. Het afnemende systeem zorgt voor omzetting naar haar eigen taal of standaard. Een koppelvlak kan bestaan uit meerdere APIs voor verschillende soorten uitwisselingen.

'''Alignment met onderwijsarchitectuur''': Koppelvlakken maken een integraal onderdeel uit van de ROSA en Edustandaard-afspraken. Hoewel de gedetailleerde uitwerking van koppelvlakken niet direct in de SRA's wordt opgenomen, is het wel wenselijk om de identificatie van koppelvlakken in de SRA's op te nemen. Dit maakt het mogelijk om een duidelijke link te leggen tussen de SRA en de uitwerking van een uitwisseling.

=== Voorbeeld 1: MORA-modellering van koppelvlakken: ===

Binnen de MORA, staat relatie tussen informatieobjecten en generiek beschreven applicaties (referentiecomponenten) centraal. De uitwerking is gemodelleerd in ArchiMate. De referentiecomponenten worden via de ArchiMate access relatie verbonden met informatieobjecten. De “R” en “W” staan voor READ en WRITE acties. Deze informatieobjecten geven aan wat voor soort gegevens worden uitgewisseld. Zo wordt bijvoorbeeld uitgebeeld dat een Toets- en examenplannings- en inschrijfsysteem SCHRIJFT aan een Rooster informatieobject en een Toets- en examen afname systeem LEEST dit object uit.

'''Figuur 1 Het Koppelvlak examinering uit de MORA'''

[[Bestand:Vertopal_83c80e6bc82f4e3685e29528d70ac023-media-image1.png|526x491px|Het Koppelvlak examinering uit de MORA]]

=== Voorbeeld 2 OKE-modellering van een koppelvlak  ===

De OKE-modellering start op een vergelijkbaar abstractieniveau als MORA door ArchiMate toe te passen, maar gaat vervolgens dieper. Voor meer gedetailleerde modellen wordt gebruik gemaakt van UML klassen-diagrammen, UML sequence-diagrammen en berichtspecificaties gebaseerd op OOAPI. OKE past hiermee de AMIGO aanpak toe.

'''Figuur 2 OKE informatiestroom toetscatalogus in het scenario'''

[[Bestand:Figuur_2_OKE_informatiestroom_toetscatalogus_in_het_scenario.png|601x289px|Afbeelding met tekst, schermopname, Lettertype, diagram Automatisch gegenereerde beschrijving]]

=== Voorbeeld 3: AMIGO aanpak: ===

De AMIGO-aanpak wordt toegepast voor een scherpe scoping en risicobeheersing in koppelvlakspecificaties. Het is een aanpak die begint met een conceptueel model (scenario-uitwerking) vergelijkbaar met dat van de MORA-koppelvlakreferentiemodellen. De uitwerking van het koppelvlak gaat echter verder door het ontwikkelen van meet gedetailleerde sequence-diagrammen, UML-diagrammen, en een alomvattende uitwisselingsspecificatie, waartoe ook de keuze van profielen/standaarden op de applicatie- en infrastructuurlaag behoren.

De AMIGO-aanpak voor het modelleren van koppelvlakken, zoals geïllustreerd in de '''Figuur 3''', richt zich in de scenario-analysefase op het creëren van een helder overzicht van de betrokken systemen en hun interacties. In dit stadium zien we applicatiecomponenten (zoals Facet en een LAS) die met elkaar verbonden zijn door ArchiMate flow-relaties. Deze flow-relaties representeren de gegevensstromen tussen de componenten. Een belangrijk aspect van deze modellering is de expliciete weergave van de informatieobjecten (zoals Score, Examenvariant, en Kandidaat) die binnen deze gegevensstromen worden uitgewisseld. Deze informatieobjecten zijn via ArchiMate associatie-relaties gekoppeld aan de flow-relaties. Dit wordt gedaan om een beeld te geven van welke gegevens tussen welke soorten systemen worden uitgewisseld. Hoewel AMIGO verdergaat met meer gedetailleerde uitwerkingen, beperken we ons in dit document tot deze scenario-analysefase.

'''Figuur 3 AMIGO voorbeeld voor scenario-analyse'''

[[Bestand:Figuur_3_AMIGO_voorbeeld_voor_scenario-analyse.png|346x391px|Afbeelding met tekst, Post-it-briefje, schermopname, diagram Automatisch gegenereerde beschrijving]]

De AMIGO modellenmatrix is gebaseerd op de MIM-standaard<ref>https://www.edustandaard.nl/standaard_afspraken/mim-profiel-onderwijs/mim-profiel-onderwijs-0-7/</ref> en is geadopteerd in de AMIGO-aanpak voor de concepten-, gegevens- en berichtenlaag. Deze modellenmatrix biedt inzicht in hoe deze lagen van de koppelvlakkenarchitectuur zich binnen het onderwijsdomein tot elkaar zouden moeten verhouden. Het KOI is een hoog-over conceptueel informatiemodel met als scope het hele onderwijsdomein. Deze vinden we terug in de ROSA<ref>https://rosa.wikixl.nl/index.php/Kernmodel_Onderwijsinformatie</ref>. Per toepassingsgebied worden meer specifieke conceptuele toepassingsscenario's en informatiemodellen ontwikkeld. Een toepassingsgebied in AMIGO komt overeen met een ketenproces of ketensamenwerking in de ROSA, zoals 'Onderwijsuitvoering' of 'Toetsen en examineren'. Per toepassingsgebied worden specifiekere conceptuele toepassingsscenario's en informatiemodellen ontwikkeld, die terug te vinden zijn in de ROSA en SRA's. Deze vinden we terug in de ROSA als het gaat om een referentie te bieden waarop ketensamenwerkingen kunnen worden gebaseerd. Een toepassingsscenario staat in SRA’s als het als doel heeft om een referentie te bieden voor bedrijfsprocessen en –functies van een onderwijsinstelling. Een toepassingsgegevensmodel (op logisch niveau) is nog niet uitgewerkt voor ieder toepassingsgebied.

Voor verdere uitwerking van een toepassingsgebied zijn modellen op conceptueel, logisch nodig, maar ook nog een niveau dieper op technisch niveau. Dit is vooral relevant bij gegevensuitwisseling tussen ketenpartners. OKE is hier een voorbeeld van, met modellen op deze drie niveaus gericht op een specifieke gegevensuitwisseling die betrekking heeft op een aantal toepassingsgebieden. Deze relatie wordt in de modellenmatrix uitgedrukt door de pijlen tussen de verschillende soorten modellen in '''Figuur''' 4. Deze duiden op een wederkerige relatie waarbij modellen elkaar beïnvloeden en op basis van elkaar worden ontwikkeld. Zo vormt het ROSA Begrippenkader de basis voor het Toepassingsscenario-en-informatiemodel, dat vervolgens bijdraagt aan de ontwikkeling van het Uitwisselings-scenario-en-informatiemodel.

'''Figuur 4 AMIGO Modellenmatrix'''

[[Bestand:Figuur_4_AMIGO_Modellenmatrix.png|601x408px|Afbeelding met tekst, schermopname, diagram, Lettertype Automatisch gegenereerde beschrijving]]

'''Kort samengevat:''' De AMIGO-modellenmatrix biedt een geordend kader voor het ontwikkelen van een samenhangende en gestructureerde onderwijskoppelvlakkenarchitectuur, waarbij elk model een bouwsteen vormt voor het volgende niveau van detail en specificatie.

== Modelleertechnieken voor Koppelvlakkenarchitectuur ==

In deze sectie geven we een overzicht van modelleertechnieken die relevant zijn voor het beschrijven van koppelvlakkenarchitectuur binnen het onderwijsdomein. Dit overzicht is niet uitputtend, maar biedt inzicht in de meest gebruikte technieken binnen de verschillende referentiearchitecturen.

'''Gebruik van Modelleertalen:''' De keuze voor specifieke modelleertechnieken, zoals ArchiMate voor conceptuele modellen en UML voor gedetailleerde specificaties (klassen- en sequentiediagrammen), hangt af van de context en het doel van de architectuuruitwerking.

* '''ArchiMate:''' Gebruikt voor het modelleren van business aspecten van koppelvlakken. De nadruk ligt op informatiestromen tussen systemen in begrijpelijke business-taal. Deze modellen worden gebruikt op conceptueel niveau.
* '''UML Klassendiagrammen:''' Ingezet voor het gedetailleerd uitwerken van de structuur van een uitwisseling, inclusief de relaties tussen verschillende gegevensobjecten. Deze modellen worden wordt gebruikt op logisch niveau.
* '''UML Sequencediagrammen''': Toegepast voor het gedetailleerd uitwerken van een specifieke interactie binnen een uitwisseling. Deze modellen worden gebruikt op logisch niveau.

'''Verschillen tussen voorbeelden op het gebied van modelleerkeuzes:'''

* ROSA richt zich op conceptuele modellen en gebruikt een zakelijke taal voor het uitleggen van informatiestromen.
* MORA koppelvlakuitwerkingen en de AMIGO voorbeeldscenariomodellen zijn beide conceptuele modellen, maar verschillen in de gebruikte ArchiMate-elementen.
* OKE kiest voor de uitwerking van Uitwisselings-scenariomodellen voor applicatiefuncties met informatiestromen hiertussen. Hierbij wordt de complexiteit van informatieobjecten bewust vermeden. OKE gaat nog twee stappen dieper door uitwisselings-gegevensmodellen, interactiespecificaties en berichtspecificaties te modelleren.
* Er worden verschillende ArchiMate relaties gebruikt op conceptueel niveau waaronder de: flow-relatie, de access-relatie. Ook bestaat de optie informatieobjecten te associëren met een flow-relatie om aan te geven wat voor soort informatie wordt uitgewisseld.

'''Abstractieniveaus in HOSA en MOSA:''' Binnen de HOSA- en MOSA-architecturen wordt nog geen uitwerking op referentiecomponentniveau gedaan. Er wordt overwogen om ook hier flow relaties te gebruiken. In de HOSA worden interfaces en applicatie services als abstracte lagen gezien.

'''Het gebruik van Informatieobjecten''': Er is discussie over het gebruik van informatie-objecten in modellen. Hoewel deze kunnen bijdragen aan de complexiteit, worden ze soms weggelaten om de helderheid te behouden.

== De MOKA en Koppelvlakkenontwikkeling ==

De MOKA (Mbo Koppelvlakken Architectuur) speelt een belangrijke rol in de ontwikkeling en standaardisatie van koppelvlakken binnen de mbo-sector. De keuze voor een aparte MOKA-architectuur komt voort uit de specifieke behoeften van de mbo-sector op het gebied van koppelvlakken. MOKA is complementair aan de MORA (Mbo Onderwijs Referentie Architectuur) en richt zich specifiek op de uitwerking van koppelvlakken, met inbegrip van principes en een datamodel. Deze focus maakt het mogelijk om dieper in te gaan op koppelvlak-specifieke aspecten dan binnen de bredere referentiearchitectuur mogelijk zou zijn.

Feiten over de MOKA:

* '''Betrokkenheid van Werkgroepen:''' Diverse werkgroepen, waaronder klankbordgroepen, regiegroepen en projectgroepen, zijn betrokken bij de ontwikkeling en afstemming van koppelvlakken.
* '''OOAPI en afstemming''': De OOAPI-werkgroep, georganiseerd door SURF, speelt een sleutelrol in de harmonisatie van koppelvlakken, met name door het afstemmen van de OOAPI (Onderwijsdata API) met de MOKA-principes.
* '''OKE en MOKA''': Hoewel OKE (Onderwijs Kwalificatie Eisen) een belangrijk voorbeeld is binnen MOKA, wordt erkend dat het niet volledig dekkend is voor alle behoeften, met name binnen het MBO (Middelbaar Beroepsonderwijs).
* '''Relatie MORA-MOKA:''' De relatie tussen MORA (Mbo Onderwijs Referentie Architectuur) en MOKA wordt gelegd via de Architectuurraad MBO.

= Knelpunten =

Tijdens onze analyse van de huidige stand van zaken rondom koppelvlakkenarchitectuur in het onderwijsdomein, hebben we verschillende uitdagingen geïdentificeerd. Deze knelpunten belemmeren de effectieve ontwikkeling en implementatie van een samenhangende koppelvlakkenarchitectuur over de verschillende onderwijssectoren heen. In deze sectie beschrijven we de belangrijkste knelpunten en geven we aan wat er nodig is om deze aan te pakken.

<ol style="list-style-type: decimal;">
<li>'''Ontbreken van een geharmoniseerde koppelvlakkenarchitectuur''':
<ol style="list-style-type: lower-alpha;">
<li>'''Knelpunt''': Er is geen eenduidige strategie en samenhangende semantiek voor het modelleren van koppelvlakken binnen het onderwijs.</li>
<li>'''Behoefte''': Ontwikkeling van een heldere strategie en gestandaardiseerde aanpak voor koppelvlakkenarchitectuur om cohesie en consistentie tussen de architecturen te garanderen.</li></ol>
</li>
<li>'''Inconsistentie in abstractieniveaus''':
<ol style="list-style-type: lower-alpha;">
<li>'''Knelpunt''': Er bestaat onenigheid over de mate van abstractie in modellen, wat leidt tot inconsistenties tussen verschillende architecturen.</li>
<li>'''Behoefte''': Afstemming van het abstractieniveau voor zowel specifieke uitwerking van koppelvlakken als voor het behoud van implementatievrijheid.</li></ol>
</li>
<li>'''Onduidelijke overgang van conceptueel naar implementatieniveau''':
<ol style="list-style-type: lower-alpha;">
<li>'''Knelpunt''': Er is onvoldoende begeleiding bij de overgang van conceptuele modellen naar concrete implementaties.</li>
<li>'''Behoefte''': Ontwikkeling van duidelijke richtlijnen voor de overgang van conceptuele modellen naar implementaties, inclusief het modelleren van informatieobjecten.</li></ol>
</li>
<li>'''Complexiteit door diversiteit in modelleringsbenaderingen''':
<ol style="list-style-type: lower-alpha;">
<li>'''Knelpunt''': De diversiteit in modelleringsbenaderingen en variërende abstractieniveaus in referentiearchitecturen leiden tot onnodige complexiteit.</li>
<li>'''Behoefte''': Ontwikkeling van een metamodel voor uitwerken van koppelvlakkenarchitectuur om deze complexiteit in kaart te brengen, eventueel te vereenvoudigen en interoperabiliteit te bevorderen.</li></ol>
</li></ol>

= Uitgangspunten van adviesgroep =

De adviesgroep hanteert de volgende uitgangspunten voor de ontwikkeling van een samenhangende koppelvlakkenarchitectuur:

# '''Standaardisatie van informatiestroom(flow)-relaties''': We hanteren flows als standaard voor het weergeven van informatiestromen, met de optie om informatieobjecten toe te voegen.
# '''Referentiearchitecturen als kader voor koppelvlakken:''' Een SRA biedt het kader waarbinnen koppelvlakken worden geïdentificeerd. In het toepassingssenario representeert elke flow een potentieel koppelvlak. De precieze uitwerking van koppelvlakken vindt plaats op het niveau van uitwisselingsscenario's, niet in de referentiearchitectuur zelf.
# '''Eerst werkingsgebied, dan toepassingsgebied, dan uitwisseling:''' We hanteren een hiërarchie van werkingsgebied (sector), toepassingsgebied, en uitwisseling in de context van een ketensamenwerking. Voor concrete implementatie vertrekken we vanuit een toepassingsscenario, zoals gedefinieerd in de AMIGO-aanpak. Dit scenario wordt beschreven in generieke termen en vervolgens aangepast aan de specifieke context van de uitwisseling, voordat wordt overgegaan tot de technische invulling (zoals berichtdefinities en formaten) van een uitwisseling.
# '''Duidelijke afbakening van koppelvlakken''': Elk koppelvlak heeft een duidelijk gedefinieerd doel en een specifieke scope. Dit bevordert herbruikbaarheid en voorkomt onnodige variaties op implementatieniveau.
# '''Expliciete beschrijving van informatieobjecten:''' Bij de modellering van een koppelvlak in een toepassingsinformatiemodel wordt expliciet beschreven welke informatieobjecten betrokken zijn bij de informatiestroom, ongeacht of deze visueel worden weergegeven. Dit geldt zowel voor flow-gebaseerde als service-gebaseerde benaderingen.
# '''Integratie van Objecten, Attributen en Profielen (OAP):''' OAP wordt gebruikt voor verschillende uitwisselingen, zoals in RIO en EduExchange, en wordt gezien als onderdeel van een groter toepassingsgegevensmodel. Nuttige elementen die relevant zijn voor meerdere uitwisselingen worden bij voorkeur opgenomen in het object zelf in plaats van in een toevoegingsblok.
# '''Centrale governance voor toepassingsgegevensmodel:''' We streven naar centrale governance voor het creëren en beheren van het toepassingsgegevensmodel om duplicatie van werk te voorkomen en consistentie te waarborgen. De precieze invulling van deze governance structuur (centraal of gedistribueerd) moet nog worden bepaald.

= Adviezen =

== Advies 1: ontwikkel een toepassingsgegevensmodel ==

'''Relatie met uitgangspunten: 2, 6, 7'''

De Adviesgroep Samenhang Onderwijsarchitecturen ziet de behoefte aan een toepassingsgegevensmodel voor het onderwijsdomein. Dit model dient als logisch kader voor de samenhang tussen koppelvlakstandaarden zoals RIO en OOAPI. De scope van dit model wordt beperkt tot een aantal van tevoren geselecteerde koppelvlakstandaarden om wildgroei te voorkomen.

In lijn met de AMIGO modellenmatrix, wordt aangeraden het model op logisch niveau te ontwikkelen om hiermee geen restricties op te leggen voor de technische implementatie. Dit respecteert de autonomie van sectoren terwijl het bijdraagt aan samenhang van koppelvlakstandaarden. Het toepassingsgegevensmodel bevat alleen “de grote gemene deler”, van de logische gegevensstructuren van alle relevante koppelvlakstandaarden. Het wordt als flexibel vertrekpunt gepresenteerd met ruimte voor beredeneerde afwijkingen via een 'comply or explain' aanpak.

De huidige situatie, waarbij leveranciers over sectorgrenzen heen aan verschillende standaarden moeten voldoen voor vergelijkbare gegevensuitwisseling, leidt tot onnodige complexiteit. Het toepassingsgegevensmodel kan helpen dit te stroomlijnen zonder strenge regels op te hoeven leggen aan initiatiefnemers. Wel zal voor effectieve ontwikkeling en beheer van dit model nog meer samen moeten worden gewerkt. Alleen als alle initiatiefnemers die zich bezig houden met gestandaardiseerde koppelvlakken samenwerken, dan kan meer samenhang worden gerealiseerd. Om te evalueren of het toepassingsgegevensmodel de gewenste verbetering in samenhang bereikt, worden de volgende adviezen meegegeven:

# Stel voorafgaand aan ontwikkeling samen met alle betrokken partijen een aantal criteria die moeten worden gerealiseerd om de “gewenste verbetering in samenhang van koppelvlakarchitecturen”, te bereiken.
# Maak afspraken over het ontwikkelpad en wanneer gezamenlijke evaluatie van de criteria moet plaatsvinden.

== Advies 2: ontwikkel een gezamenlijk viewpoint ==

'''Relatie met uitgangspunten: 1, 2, 5'''

Er is een noodzaak voor een gezamenlijk viewpoint dat zich richt op de uitwerking van koppelvlakken op toepassingsinformatiemodel-niveau. Dit viewpoint geld voor alle onderwijsreferentiearchitecturen. Het doel hiervan is het bevorderen van samenhang en consistentie tussen de koppelvlakuitwerkingen op een conceptueel toepassingsniveau.

'''Ontwerpkaders voor dit viewpoint:'''

* '''Gebruik flow (informatiestroom) relaties:''' Het concept 'informatiestromen' speelt een cruciale rol in dit viewpoint. Het verwijst naar de interactie tussen referentiecomponenten die men wil uitwerken in koppelvlakspecificaties. Hierin wordt specifieke aandacht besteed aan de regels die deze interacties vormgeven.
* '''Informatieobjecten worden vastgelegd:''' informatieobjecten worden geassocieerd aan flow relaties. Hoewel optioneel in presentatie van een ArchiMate view, moet expliciet zijn vastgelegd op welke informatieobjecten een informatiestroom betrekking heeft. Het is van belang om consistent te zijn in de keuze van representatie, of dit nu via diagrammen of tekst is.
* '''Vastleggen van relaties tussen informatiestroom uit toepassingsinformatiemodel en uitwisselingen:''' Eén informatiestroom kan resulteren in twee of meer technische uitwisselingsspecificaties, afhankelijk van waar de informatie naartoe gaat of vandaan komt. Deze relaties moeten worden vastgelegd bij informatiestromen.
* '''Consistentie met bestaande afspraken:''' De viewpoint-specifieke eisen moeten in lijn zijn met de algemene Edustandaard afspraken en consistent zijn met andere viewpoints binnen het onderwijsdomein.
* '''Opties voor referentiecomponent of applicatieservice:''' Er is een bepaalde mate van vrijheid nodig bij de selectie van het soort elementen voor dit viewpoint. De mogelijkheden voor het modelleren van informatiestromen zijn divers; variërend van applicatieservice naar applicatieservice, van referentiecomponent naar referentiecomponent, of van applicatieservice naar referentiecomponent. Mogelijk is het voor de HOSA en MOSA nodig om uit te gaan van de variant met applicatieservices, aangezien nog geen zicht is op de applicaties van de toekomst.

Er is behoefte aan verdere discussie en overleg om te bepalen hoe viewpoints worden uitgewerkt en welke verdere ontwerpkaders daarvoor kunnen worden opgesteld. Dit wordt een agendapunt voor toekomstige bijeenkomsten van de Adviesgroep Samenhang Onderwijsarchitecturen. Dit viewpoint kan dan als basis dienen voor verdere discussie en verfijning.

== Advies 3 Ketenbrede implementatie van de AMIGO aanpak ==

'''Relatie met uitgangspunten: 2, 3, 4'''

De AMIGO-aanpak biedt een beproefd kader voor het ontwikkelen van koppelvlakstandaarden. De aanpak is al geïntegreerd in de ROSA en toepassing ervan wordt getoetst via de ROSA-scan. De AMIGO-modellenmatrix verbindt verschillende niveaus van modellering - van conceptueel via logisch naar technisch niveau. Deze gelaagde aanpak helpt om samenhang tussen koppelvlakstandaarden te waarborgen, terwijl er ruimte blijft voor sectorspecifieke invulling. De matrix laat bijvoorbeeld zien hoe het ROSA Begrippenkader, toepassingsscenario's en uitwisselingsspecificaties op elkaar aansluiten.

Om gezamenlijk te onderzoeken of deze aanpak de gewenste verbetering in samenhang kan brengen, worden de volgende adviezen meegegeven:

# '''Verkenning van de modellenmatrix:''' We stellen voor de AMIGO-modellenmatrix en bijbehorende terminologie als vertrekpunt te nemen bij het analyseren van koppelvlakken. Begrippen als &quot;toepassingsscenario&quot;, &quot;toepassingsinformatiemodel&quot; en &quot;uitwisselings-informatiemodel&quot; kunnen helpen om samenhang inzichtelijk te maken. Door het gezamenlijk verkennen van de modellenmatrix bij koppelvlakuitwerkingen, kunnen we beoordelen waar deze meerwaarde biedt.
# '''Flexibele toepassing:''' Voor een effectief gezamenlijk onderzoek is het waardevol om de AMIGO-aanpak als gemeenschappelijk vertrekpunt te gebruiken, met ruimte voor sectorspecifieke invulling. Bureau Edustandaard kan hierbij ondersteunen door conceptsjablonen beschikbaar te stellen.
# '''Kennis delen:''' Om de AMIGO-aanpak samen te verkennen, is het zinvol om ervaringen uit te wisselen via kennisdeling en bewustwording. Dit helpt alle betrokkenen de mogelijkheden en aandachtspunten te begrijpen. SRA's kunnen hierbij de AMIGO-terminologie vertalen naar hun eigen context.

Na een jaar evalueren we gezamenlijk of deze aanpak bijdraagt aan:

# Betere samenhang tussen koppelvlakstandaarden
# Minder overlap en redundantie
# Behoud van benodigde sectorale flexibiliteit

== Advies 4 ontwikkel modulaire koppelvlakkenarchitectuur ==

'''Relatie met uitgangspunten: 2, 3, 4'''

Koppelvlakstandaarden hebben de neiging om steeds breder te worden naarmate nieuwe behoeften ontstaan. Een modulaire benadering helpt om dit beheersbaar te houden door eerst bestaande standaarden in kaart te brengen en vervolgens nieuwe ontwikkelingen modulair op te zetten.

Een module is een zelfstandige eenheid binnen een koppelvlakstandaard die:

* Een specifieke service levert aan ketenpartners
* Herbruikbaar is in verschillende contexten
* Onafhankelijk kan worden aangepast
* Een duidelijk afgebakende scope, of toepassingsgebied heeft

Deze modulaire aanpak komt tot uitdrukking in de volgende adviezen:

# '''Inventarisatie per toepassingsgebied:''' De eerste stap is het in kaart brengen van bestaande koppelvlakstandaarden per toepassingsgebied en het analyseren van overlap en raakvlakken tussen deze standaarden. Op basis van deze inventarisatie kunnen knelpunten worden geïdentificeerd die als input dienen voor de ontwikkeling van nieuwe modulaire koppelvlakken.
# '''Scenario-specifieke ontwikkeling''': Bij de ontwikkeling of uitbreiding van koppelvlakken stellen we eerst het doel en het toepassingsscenario vast, gebaseerd op de afbakening van ketenprocesstappen. Dit helpt bij het bepalen van de juiste omvang en specificaties van het koppelvlak. Dit is ook de eerste stap uit de AMIGO-aanpak.
# '''Afhandeling van uitbreidingen:''' Wanneer behoefte ontstaat aan toevoeging van nieuwe attributen of functionaliteiten, moet zorgvuldig overwogen worden of deze binnen het huidige koppelvlak passen of dat er een nieuw koppelvlak of een uitbreiding nodig is. Dit voorkomt dat koppelvlakken te breed groeien buiten hun oorspronkelijke ontwerp, waardoor “wildgroei” problemen kunnen ontstaan.
# '''Documentatie en Richtlijnen:''' We zorgen voor heldere documentatie van API's en specificeren welke afspraken van toepassing zijn op welke referentiecomponenten of applicatieservice. Dit ondersteunt ontwikkelaars en architecten bij het correct implementeren en gebruiken van de modulaire koppelvlakken.
# '''ROSA ontwerpkader:''' We integreren deze aanbevelingen in het ROSA ontwerpgebied interoperabiliteit. Het ROSA beheerteam wordt gevraagd om een ontwerpkader uit te werken voor het ontwikkelen van een modulaire koppelvlakkenarchitectuur, met inachtneming van de bovengenoemde implicaties.

= Conclusie en evaluatie =

Dit adviesdocument geeft vier concrete adviezen voor het verbeteren van samenhang tussen koppelvlakstandaarden in het onderwijs. De adviesgroep samenhang onderwijsarchitecturen wil actief betrokken blijven bij de implementatie van deze adviezen. Daarom zijn per probleemstelling evaluatiecriteria opgesteld die aangeven wanneer de adviezen succesvol zijn geïmplementeerd.

De probleemstellingen en bijbehorende adviezen zijn:

* Vermindering inconsistenties via een gezamenlijk viewpoint en AMIGO-aanpak
* Verbetering interoperabiliteit via een toepassingsgegevensmodel en modulaire opzet
* Reductie complexiteit via modulaire opzet en toepassingsgegevensmodel
* Voorkomen overlap via AMIGO-aanpak en modulaire opzet

De adviesgroep zal de voortgang monitoren aan de hand van de opgestelde criteria. Na de evaluatieperiode beoordeelt de adviesgroep of de adviezen hebben geleid tot:

* Meer samenhang tussen verschillende koppelvlakstandaarden
* Minder knelpunten tussen standaarden
* Behoud van benodigde sectorale flexibiliteit

Op basis van deze evaluatie kan worden bepaald of aanvullende acties nodig zijn om de samenhang verder te verbeteren op het onderwerp van koppelvlakkenarchitectuur. De adviesgroep zal hierover rapporteren aan de Architectuurraad en Standaardisatieraad van Edustandaard.

== Evaluatiecriteria ==

'''Evaluatiecriteria gekoppeld aan probleemstellingen en adviezen:'''

===Vermindering inconsistenties===
* Doel bereikt via: Advies 2 (Gezamenlijk viewpoint) en Advies 3 (AMIGO-aanpak)
* Criterium: Aan het einde van de evaluatieperiode zijn alle ketenpartijen het eens over één manier van modelleren van koppelvlakken, gebruikmakend van:
** Eén viewpoint voor koppelvlakken wordt toegepast in alle SRA's.
** Geharmoniseerde begrippen en definities van elementen in de views die dit viewpoint volgen. (Waarbij afwijkingen zijn vastgelegd en uitgelegd)
** De AMIGO-modellenmatrix kan naadloos worden gebruikt om alle koppelvlakuitwerkingen ten opzichte van elkaar te verhouden.

=== Verbetering interoperabiliteit ===

* Doel bereikt via: Advies 1 (Toepassingsgegevensmodel) en Advies 4 (Modulaire opzet)
* Criterium: Aan het einde van de evaluatieperiode is er:
** Een volledig overzicht van koppelvlakstandaarden per toepassingsgebied binnen het onderwijs.
** Een toepassingsgegevensmodel met hierin “de grote gemene deler”, van de logische gegevensstructuren van alle van tevoren geselecteerde koppelvlakstandaarden binnen het onderwijs.
** Een duidelijke afbakening waar verschillende standaarden overlappen en waar ze op gegevensniveau van elkaar verschillen.

=== Reductie complexiteit ===

* Doel bereikt via: Advies 4 (Modulaire opzet) en Advies 1 (Toepassingsgegevensmodel)
* Criterium: Aan het einde van de evaluatieperiode:
** Zijn nieuwe koppelvlakstandaarden modulair opgezet en specifiek ingericht om nog ontbrekende puzzelstukjes in de puzzel op te vullen.
** Is er een werkend 'comply or explain' mechanisme ingericht voor het toepassingsgegevensmodel.

=== Voorkomen overlap ===

* Doel bereikt via: Advies 3 (AMIGO-aanpak) en Advies 4 (Modulaire opzet)
* Criterium: Aan het einde van de evaluatieperiode:
** Is duidelijk te zien vanuit ROSA scans dat nieuwe standaarden ontwikkeld worden volgens de AMIGO methodiek.
** Is er een effectief proces voor hergebruik van bestaande modules uit reeds uitgewerkte koppelvlakstandaarden.

== Referenties ==
<references />

Meta-informatie

Samenvatting bewerkingU kunt hier een samenvatting of reden van de bewerking opgeven.

:

Samenvatting:

Dit is een kleine wijziging

Volg deze pagina

Annuleren

Bewerken pagina: Adviesdocument samenhang koppelvlakkenarchitectuur

Meta-informatie

Navigatiemenu

Zoeken