Spelregels Viewpoints
Welkom op de wikipagina voor de spelregels van views en viewpoints binnen de ROSA (Referentie Onderwijs Sector Architectuur). De ROSA richt zich als ketenreferentiearchitectuur voor het onderwijsdomein op alle onderwijssectoren en op (onderwijs)sector-overstijgende aspecten van informatievoorziening. Centraal staat de gegevensuitwisseling tussen functies/partijen en de invulling daarvan. De ROSA bevat verschillende platen (views) om de architectuur van systeem te beschrijven. Sommige van deze views lijken op elkaar, maar het ontbreekt aan een overkoepelend raamwerk om over deze views te kunnen positioneren ten opzichte van elkaar.
Deze pagina is ontwikkeld om een gestructureerde en eenduidige aanpak te bieden voor het werken met views en viewpoints in de ROSA en ook in andere referentiearchitecturen in de Nederlandse onderwijssector. Het raamwerk voor het beschrijven van viewpoints is tot stand gekomen door een analyse van bestaande literatuur, waarbij de ISO 42010 standaard centraal staat. Uit deze analyse zijn duidelijke richtlijnen voortgekomen voor het beschrijven van viewpoints en welke attributen hiervoor moeten worden vastgelegd. Daarnaast worden de verschillende viewpoints die gebruikt worden in de ROSA in kaart gebracht.
Zie voor een overzicht van alle viewpoints die in de ROSA zijn uitgewerkt: Categorie:Viewpoints
Theoretische Context[bewerken]
De ROSA (Referentie Onderwijs Sector Architectuur) is een ketenreferentiearchitectuur voor de onderwijssector in Nederland, die gebruikmaakt van ArchiMate, een open en onafhankelijke modelleringstaal voor enterprise-architectuur. Volgens de vernieuwde ISO 42010-standaard is een architectuurbeschrijving een werkproduct dat wordt gebruikt om de architectuur van een te beschrijven. Een architectuurbeschrijving bestaat uit views en viewpoints.
Een viewpoint is een selectie van relevante architectuurconcepten (en hun relaties) die een specifiek aspect van de architectuur beschrijven. Daarnaast bevat een viewpoint ook conventies rondom het gebruik van deze concepten. Het kan gezien worden als het recept, of middel om een belang of invalshoek uit te drukken in de architectuur. In het geval van de ROSA zijn deze architectuurconcepten elementen uit het ROSA-metamodel. Een view is de daadwerkelijke visuele representatie van een viewpoint en toont de geselecteerde concepten en relaties op een diagram. Een architectuurview adresseert 1 of meer belangen van een stakeholder bij een systeem. In de 2022 versie van ISO 42010 (2022) is het mogelijk om meerdere views te accommoderen met één viewpoint. Of dit kan is afhankelijk van welke belangen (concerns) van de stakeholders afgedekt worden door de views. In de context van de ROSA-referentiearchitectuur kunnen viewpoints worden gebruikt om de samenhang tussen verschillende views van de architectuur te beschrijven en te analyseren. Zo kan bijvoorbeeld inzichtelijk worden gemaakt dat een “contextuele” kijk op het ketenprocesmodel “Toetsen en Examineren” op een vergelijkbare manier bepaalde vragen afdekt als de “contextuele” kijk op het ketenprocesmodel “Aanmelden en administreren onderwijsdeelname”.
Een architectuur-aspect is een onderdeel van een architectuur dat een bepaald aspect van het systeem beschrijft, gerelateerd aan één of meerdere concerns. Zo op zichzelf is deze definitie best abstract. Op basis van Figuur 1 kan worden vastgesteld dat meerdere architectuur-aspecten kunnen worden weergegeven in een view, maar niet in een viewpoint, dus wat is dit toegepast op de ROSA? Op basis van de definities van view en viewpoint moet een aspect dan een architectuur-inhoudelijk onderwerp zijn dat wordt weergegeven in een view. Een architectuur-aspect in de ROSA is dan bijvoorbeeld “Informatie-uitwisseling". Dit is namelijk een onderwerp waar de ROSA een aantal views voor heeft uitgewerkt vanuit verschillende viewpoints.
Een view component is een scheidbaar onderdeel van een view. Een view kan zijn opgebouwd uit meerdere view components. Een voorbeeld van het gebruik van view components is het ketenprocesmodel voor Toetsen en examineren. Binnen de contextuele weergave (view) op het ketenproces toetsen en examineren, wordt ook de samenhang met andere ketenprocesmodellen zichtbaar. Deze view bestaat dus meerdere modellen en daarmee ook uit meerdere view componenten. Er bestaat verwarring over wat precies het verschil is tussen een model en een view component, want in de praktijk komen deze vaak overeen met elkaar. Het verschil tussen een model en een view component volgens de ISO/IEC/IEEE 42010-2022 standaard is als volgt:
- Een model is een gestructureerde representatie van een deel van de werkelijkheid, ontworpen om bepaalde aspecten van die werkelijkheid te beschrijven of te analyseren.
- Een view component is een scheidbaar onderdeel van een architectuur views. Het hoeft dus niet een gestructureerde representatie te zijn van een deel van de werkelijkheid. Het is een breder begrip dat refereert aan een deel van een architectuuruitwerking of een architectuurproduct dat kan worden gepresenteerd in een view.
Een view component kan dus bijvoorbeeld ook refereren aan een tekstuele analyse van een architectuur aspect, dat terugkomt in meerdere paragrafen van een Project Startarchitectuur (PSA) document. Hierbij zien we de PSA als een view op de architectuurbeschrijving. Misschien is deze tekstuele analyse uitgevoerd volgens een bepaalde methodiek, een bepaald tekst-analysemodel (het modeltype). Dit analysemodel is ontwikkeld vanuit een bepaald viewpoint om bepaalde concerns af te dekken. In het geval van de ROSA is een view component bijna altijd wel een model, aangezien er voor een modelgedreven benadering van Enterprise Architectuur gekozen is.
Elk view component wordt beheerst door een modeltype (model kind), geïdentificeerd door het bijbehorende architecture viewpoint. Een modeltype bepaalt de conventies voor modelgebaseerde view componenten, terwijl een legenda de conventies voor view componenten documenteert. Deze conventies omvatten het beoogde gebruik, de terminologie, de notaties en hun syntaxis en semantiek, en de symboliek van de geregeerde modellen. In het algemeen kunnen View Components worden gebruikt om de complexiteit van een architectuur te beheren door informatie op te splitsen in kleinere, meer beheersbare delen. Dit maakt het gemakkelijker voor belanghebbenden om de architectuur te begrijpen en te analyseren, en om beslissingen te nemen op basis van de gepresenteerde informatie.
Figure 1 ISO42010 (2022) metamodel
Het artikel "Dimensies van architectuurbeschrijvingen" van Danny Greefhorst, Hans van Vliet en Gerrit Muller (2003) biedt een waardevol theoretisch kader voor het beschrijven van views en viewpoints in de ROSA. De voorgestelde basisdimensies kunnen worden gebruikt om het ontwikkelen en beheren van views en viewpoints in de ROSA te structureren en te analyseren. Deze dimensies zijn relevant voor de ROSA, omdat ze helpen bij het identificeren van de behoeften en belangen van stakeholders, het kiezen van het juiste abstractieniveau en modelleertechnieken, en het bepalen van de reikwijdte en het detailniveau van de architectuurbeschrijvingen.
Door alle basisdimensies uit het artikel voor ieder viewpoint in de ROSA in te vullen, wordt duidelijk wat voor viewpoints er allemaal kunnen zijn binnen de ROSA. De volgende dimensies zijn van belang voor viewpoints in de ROSA:
- Type informatie: Deze dimensie betreft de onderwerpen van het architectuurmodel.
- Transformatie: De transformatiedimensie heeft veranderingen in de tijd als indelingscriterium. Dit loopt in stappen van huidige situatie naar lange termijn. Ook de overgang van de ene naar de volgende stap kan het onderwerp zijn van architectuurinformatie.
- Kwaliteitseigenschappen: Deze dimensie benoemt specifieke kwaliteitseigenschappen als waarden, zoals performance of beveiliging. Waarden kunnen ontleend zijn aan kwaliteitsraamwerken, zoals het Extended ISO-model.
- Metaniveau: Deze dimensie maakt het mogelijk om op hogere niveaus over architectuurinformatie te redeneren. Deze niveaus beschrijven niet zozeer domein-specifieke informatie, maar algemene classificaties, regels en relaties die gelden voor dergelijke informatie.
- Aard: Deze dimensie geeft de mate aan waarin architectuurinformatie zich doet gelden. Er worden verschillende niveaus onderscheiden, zoals beleid, principe, richtlijn, model en standaard.
- Bereik: Dit is het gebied waarop de architectuurinformatie betrekking heeft. Mogelijke waarden zijn bedrijfstak, organisatie, business unit, systeemfamilie, systeem en systeemcomponent.
- Detailniveau: Deze dimensie geeft de variatie aan in de mate van detail in de onderdelen van een architectuurbeschrijving. Het hoogste niveau (minste details) geeft het overzicht.
- Belanghebbenden: Deze dimensie deelt de architectuurbeschrijving in naar belanghebbenden. Belanghebbenden zijn vaak alleen geïnteresseerd in bepaalde delen van de informatie.
- Representatie: Deze dimensie biedt de mogelijkheid om architectuurinformatie in te delen naar de manier waarop het gerepresenteerd wordt: informeel, semi-formeel of formeel.
Figure 2 Basisdimensies van architectuurbeschrijvingen (Greefhorst et al., 2003)
Spelregels voor viewpoints in de ROSA[bewerken]
Basisregel: Ieder viewpoint wordt beschreven in alle basisdimensies, binnen de beperkingen van de onderstaande spelregels:
- Type informatie: Benoem voor ieder viewpoint wat het type informatie het bevat. Maak hierbij gebruik van namen in het overzicht op de hoofdpagina en scenariobeschrijvingen uit het ROSA-metamodel en -begrippenkader.
- Transformatie: Sommige ROSA-viewpoints zijn beschrijvend van de huidige situatie andere zijn beschrijvend voor een situatie in de toekomst (vaak met een tijdshorizon van maximaal 5 jaar of korter). Dit hoeft niet per viewpoint te worden beschreven.
- Kwaliteitseigenschappen: Ieder viewpoint bevat een beschrijving van wanneer de view erachter kwalitatief goed is. Een view is kwalitatief goed wanneer concerns zijn afgedekt, dus worden de concerns hier beschreven.
- Metaniveau:
- De ROSA bevat één metamodel, alle viewpoints binnen het ROSA-architectuurmodel moeten binnen dit metamodel passen.
- Er valt onderscheid te maken wat betreft metaniveaus tussen scenario-viewpoints en viewpoints uit de gemeenschappelijke informatievoorziening. Om de metaniveaus duidelijk te onderscheiden we de metaniveaus: instantie (0), model (1), metamodel (2) en metametamodel (3). Zie de tabel voor invulling van de metaniveaus.
| Metaniveau | Naam metaniveau | Invulling voor ROSA |
|---|---|---|
| 0 | instantie | Gemeenschappelijke informatievoorziening |
| 1 | model | Scenariouitwerking |
| 2 | metamodel | ROSA Metamodel |
| 3 | metametamodel | ArchiMate 3 |
- Aard: De aard van het viewpoint wordt geïllustreerd aan de hand van een view met daarin een doorsnede van het metamodel. Hierin worden alle metamodel-elementen en –relaties weergegeven die in een uitwerking van het viewpoint mogen worden gebruikt.
- Bereik: De architectuurinformatie in alle viewpoints van de ROSA is gericht op het bevorderen van samenwerking tussen ketenpartners op het vlak van informatievoorziening, zowel binnen onderwijsdomeinen (werkingsgebieden) als tussen onderwijsdomeinen.
- Detailniveau: Binnen de ROSA kan onderscheid worden gemaakt tussen viewpoints met verschillende detailniveaus:
- Detailniveau 1: Landschap: Een hoogover overzicht van alle elementen in het architectuurmodel van dezelfde soort, zonder getekende relaties.
- Detailniveau 2: Overzicht: Een overzicht van de belangrijkste elementen in de architectuurbeschrijving gerelateerd aan een of meerdere architectuuraspecten, inclusief getekende relaties.
- Detailniveau 3: Contextueel: De belangrijkste architectuurelementen gerelateerd aan een bepaald architectuuraspect om de relatie met een of meerdere andere architectuuraspecten duidelijk te maken.
- Detailniveau 4: Gedetailleerd: Alle architectuurelementen en relaties relevant om een specifiek architectuuraspect weer te geven.
- Belanghebbenden: Voor ieder concern worden de belanghebbenden beschreven die deze vraag hebben gesteld. Een concern wordt opgenomen bij een viewpoint.
- Representatie: In de ROSA wordt architectuurinformatie formeel gerepresenteerd in de vorm van ArchiMate-modellen die specifieke modelleerconventies (spelregeldocumenten) en een metamodel volgen.
Implementatie viewpoints[bewerken]
De implementatie van viewpoints in de ROSA Wiki is gerealiseerd door de viewpoints semantisch te verwerken, op een vergelijkbare manier als de samenhangonderwerpen. Door de viewpoints op deze manier te verwerken, kunnen ArchiMate views worden gelinkt naar viewpoint-elementen in het kennismodel van de wiki. In dit geval zijn de viewpoint-elementen wiki-pagina’s die de semantische relaties tussen de views en de beschreven viewpoints bevatten. Zo hoeft niet in ArchiMate bij iedere view een hele nieuwe beschrijving van alle basisdimensies te worden opgenomen, maar wordt dit centraal gedaan in de wiki.
Waarde van de implementatie
De implementatie van de spelregels voor views en viewpoints in het kennismodel van de semantische ROSA Wiki voegt waarde toe op verschillende manieren:
- Consistentie: Door de spelregels te volgen, worden views en viewpoints op een consistente manier ontwikkeld en beheerd, wat leidt tot een beter begrip van de architectuur en effectievere communicatie tussen stakeholders.
- Flexibiliteit: De semantische relatie tussen views en viewpoints maakt het mogelijk om verschillende views op hetzelfde viewpoint uit te werken, wat bijdraagt aan een beter begrip van de complexiteit en samenhang van de architectuur.
- Traceerbaarheid: Door de spelregels te integreren in het kennismodel, kunnen de relaties tussen views en viewpoints eenvoudig worden getraceerd en geanalyseerd, wat helpt bij het identificeren van afhankelijkheden en het nemen van weloverwogen beslissingen.
- Samenhang met andere architecturen: Mogelijk is dit ook een waardevolle uitwerking voor de samenhang met Sectorale Referentiearchitecturen. Deze zouden mogelijk vergelijkbare regels kunnen hanteren voor het beschrijven van viewpoints of in sommige gevallen zelfs viewpoints hergebruiken. (Mogelijk heeft in de toekomst iedere SRA een Referentiecomponenten-landschap)
Viewpoints in de ROSA[bewerken]
| Beschrijving | |
|---|---|
| Ketenproces-referentiecomponenten | Dit viewpoint laat zien welke referentiecomponenten worden toegepast in specifieke ketenprocesstappen, waardoor inzichtelijk wordt welke applicaties ondersteuning bieden bij welke activiteiten. Dit draagt bij aan een gestroomlijnde inzet van software binnen het onderwijsdomein. |
| Ketenproces-per-rol | Viewpoint dat laat zien welke ketenprocesstappen worden uitgevoerd door welke rollen. Zo wordt duidelijke welke soorten stakeholders samen verantwoordelijkheid dragen voor uitvoering van een ketenprocesstap. |
| Ketenproces-landschap | Deze landschapsweergave is bedoeld om gebruikers een overzicht te geven van welke ketenprocessen inhoudelijk bij elkaar horen. Op deze manier kunnen ze snel in relatie tot elkaar gevonden worden. |
| Ketenproces-in-detail | Dit viewpoint laat zien hoe ketenprocessen zijn opgebouwd uit ketenprocesstappen en geeft zo de inrichting van één of meerdere ketenprocessen in detail weer. Hierbij laat het zien hoe de verschillende onderdelen: ketenprocessen, ketenprocesstappen en informatieobjecten, zich tot elkaar verhouden. De ketenprocesstappen geven expliciete invulling aan de ketenprocessen en ondersteunen op hun beurt de gegevensuitwisselingen die tot uitdrukking komen in de informatieobjecten die van en naar de ketenprocesstappen lopen. Dit viewpoint wordt gebruikt in ketenprocesmodellen. |
| Ketenproces-in-context | Dit viewpoint geeft een overzicht van de ketenprocessen die deel uitmaken van een ketenprocesmodel en de contexten waarin deze ketenprocessen plaatsvinden of waarmee ze verbonden zijn. Het doel is om de samenhang en de voorwaarden van het ketenprocesmodel te verduidelijken. Het viewpoint richt zich op de informatieobjecten die tussen de ketenprocessen worden uitgewisseld. |
| Ketenproces-detail afspraken | Dit viewpoint laat zien op welke ketenprocesstappen Edustandaard afspraken van toepassing zijn. |
| Ketendomein-landschap | Deze beschrijving van het landschap laat op een eenvoudige manier zien hoe verschillende onderdelen van het onderwijs in groepen zijn verdeeld binnen ROSA. Dit helpt om snel te begrijpen welke onderdelen bij elkaar horen. |
Attributen voor Viewpoints[bewerken]
Alle attributen zijn opgenomen als eigenschappen in de ROSA Wiki en kunnen via een formulier worden ingevuld. Zie hiervoor Categorie:Viewpoints
| Attribuut: Naam | |
| Omschrijving | Korte tekstuele beschrijving van het viewpoint. |
| Voorbeelden | Ketenproces-gedetailleerd |
| Kardinaliteit | 1..1 |
| Attribuut: Beschrijving | |
| Omschrijving | Langere tekstuele beschrijving in één of twee zinnen met hierin het doel en voorbeeld van wat voor soort concerns worden afgedekt met het viewpoint. |
| Voorbeelden | Dit viewpoint laat zien hoe ketenprocessen zijn opgebouwd uit ketenprocesstappen en geeft zo de inrichting van één of meerdere ketenprocessen in detail weer. Hierbij laat het zien hoe de verschillende onderdelen: ketenprocessen, ketenprocesstappen en informatieobjecten, zich tot elkaar verhouden. De ketenprocesstappen geven expliciete invulling aan de ketenprocessen en ondersteunen op hun beurt de gegevensuitwisselingen die tot uitdrukking komen in de informatieobjecten die van en naar de ketenprocesstappen lopen. |
| Kardinaliteit | 1..1 |
| Attribuut: Toelichting | |
| Omschrijving | Inhoudelijke toelichting op de beschrijving van het viewpoint en/of nadere details, aangevuld met een aantal voorbeelden van hoe het viewpoint toegevoegde waarde kan hebben gezien vanuit de persona’s: projectleider, een architect of een product owner. |
| Voorbeelden |
Projectleider: Dit viewpoint kan helpen bij het gedetailleerd plannen van een digitaliseringsproject door de stappen in het proces en de benodigde gegevensuitwisselingen duidelijk te maken. Architect: De architect kan dit viewpoint gebruiken om nauwkeurige technische ontwerpen te maken die ervoor zorgen dat alle stappen in het onderwijsproces efficiënt samenwerken en de juiste informatie uitwisselen. Product Owner: Bij het ontwikkelen van een onderwijstoepassing kan de product owner dit viewpoint gebruiken om te waarborgen dat elke stap in de keten de vereiste informatie ontvangt en verzendt, om een vlotte werking en integratie met andere systemen te verzekeren |
| Kardinaliteit | 0..1 |
| Attribuut: Metaniveau | |
| Omschrijving | Een algemene classificatie voor het metaniveau van de architectuurinformatie beschreven binnen een viewpoint. |
| Toelichting | Een metaniveau is een niveau dat over een ander niveau gaat, waarbij er sprake is van reflectie, analyse of kritiek op het onderliggende niveau. |
| Voorbeelden | Een voorbeeld van een metaniveau is de grammatica van een taal. De grammatica gaat over de regels en structuren van de taal, maar is niet zelf een onderdeel van de taal. De grammatica is dus een metaniveau ten opzichte van de taal. |
| Mogelijke waarden |
0 instantie: Gemeenschappelijke informatievoorziening 1 model : Scenariouitwerking 2 metamodel: ROSA Metamodel |
| Kardinaliteit | 1..1 |
| Attribuut: Detailniveau | |
| Omschrijving | Classificatie voor de variatie in de mate van detail binnen viewpoints. |
| Mogelijke waarden |
Detailniveau 1: Landschap: Een hoogover overzicht van alle elementen in het architectuurmodel van dezelfde soort, zonder getekende relaties. Detailniveau 2: Overzicht: Een overzicht van de belangrijkste elementen in de architectuurbeschrijving gerelateerd aan een of meerdere architectuur aspecten, inclusief getekende relaties. Detailniveau 3: Contextueel: De belangrijkste architectuur elementen gerelateerd aan een bepaald architectuur aspect om de relatie met een of meerdere andere architectuur aspecten duidelijk te maken. Detailniveau 4: Gedetailleerd: Alle architectuurelementen en relaties relevant om een specifiek architectuur aspect weer te geven. |
| Kardinaliteit | 1..1 |
Concerns[bewerken]
| Relatie: Concern | |
| Omschrijving | Relatie met één of meerdere concerns die een viewpoint adresseert. |
| Toelichting | Een concern volgens ISO42010 is een interesse of een aandachtspunt van een stakeholder in een systeem of een systeemarchitectuur. Een concern kan betrekking hebben op de doelen, de geschiktheid, de haalbaarheid, de risico’s, de onderhoudbaarheid en de evolueerbaarheid van het systeem of de architectuur. Dit concern kan ook worden gezien als een vraag die een belanghebbende wil beantwoorden over het systeem of de architectuur. |
| Voorbeelden | Bijvoorbeeld, een concern van een gebruiker kan zijn: “Hoe gebruiksvriendelijk is het systeem?” Een vraag van een ontwikkelaar kan zijn: “Hoe modulair is de architectuur?” Een concern van een beheerder kan zijn: "Hoe veilig is het systeem?" |
| Kardinaliteit | 1..* |
| Attribuut: Belanghebbende | |
| Omschrijving | Beschrijvend tekstveld over welke belanghebbenden een concern delen. |
| Toelichting | Een stakeholder volgens ISO/IEC/IEEE 42010 is een individu, groep of organisatie die belangen heeft in een entiteit van belang of in de architectuur daarvan. Een belang is een interesse of een aandachtspunt van een stakeholder in een entiteit of een architectuur. |
| Voorbeelden | |
| Kardinaliteit | 1..* |
Attributen voor views[bewerken]
Alle attributen zijn opgenomen als properties bij views in de ROSA ArchiMate model en kunnen via de modelleeromgeving worden aangepast.
| Attribuut: Naam | |
| Omschrijving | |
| Voorbeelden | |
| Kardinaliteit | 1..1 |
| Attribuut: Hoort bij viewpoint | |
| Omschrijving | |
| Toelichting | |
| Kardinaliteit | 0..1 |
Referenties[bewerken]
- Emery, D., Hilliard, R., & Malavolta, I. (2020). ISO/IEC/IEEE 42010:2022 Conceptual Model. https://www.iso-architecture.org/42010/cm/1
- Greefhorst, D., Koning, H., & Van Vliet, H. (2003). De dimensies in architectuurbeschrijvingen. Informatie, 45(10), 22-27, https://www.cs.vu.nl/~hans/publications/y2003/dimensies.pdf.
- The Open Group. (2020). ArchiMate® 3.2 Specification: 13. Viewpoints and Views. Stakeholders, Architecture Views and Viewpoints: ArchiMate® 3.2 Specification (opengroup.org).
- Yamamoto, S., Zhi, Q., & Zhou, Z. (2019). Aspect analysis towards ArchiMate diagrams. Procedia Computer Science, 159, 973-980. https://doi.org/10.1016/j.procs.2019.09.264