Architectuurkaders: verschil tussen versies

Uit ROSA Wiki
Naar navigatie springen Naar zoeken springen
Geen bewerkingssamenvatting
Geen bewerkingssamenvatting
 
(5 tussenliggende versies door 2 gebruikers niet weergegeven)
Regel 1: Regel 1:
[[Bestand:Architectuurkaders.png|800px]]
{{Status|Intern=In bewerking|Toelichting=Revisie ROSA}}{{Status|Extern=Concept|Toelichting=De structuur van de architectuurkaders is vastgesteld door de Architectuurraad op 2 februari 2023. De uitwerking in de wiki (navigatie, opbouw) op 6 juli 2023. De structuur en de pagina's worden stapsgewijs uitgewerkt.}}


Ontwikkelingen zoals onderwijskundige veranderingen, innovaties, en beleidswijzigingen vormen externe '''[[Drivers en doelen|drivers]]''' voor de ROSA. In de ROSA worden '''[[Drivers en doelen|doelen]]''' geformuleerd die in lijn zijn met dit beleid en die doorvertaald worden naar '''[[architectuurprincipes]]''', waarmee consistentie en samenhang in de keten wordt nagestreefd. Doelen in ROSA zijn geformuleerd als kwaliteitseigenschappen en waarden die vanuit de ROSA worden geadresseerd. Daarmee sluiten we aan bij de indeling die NORA kiest voor bindende architectuurafspraken in kwaliteitsdoelen (in NORA geclusterd onder Kernwaarden van Dienstverlening), architectuurprincipes, en implicaties (in ROSA verder uitgewerkt in '''ontwerpprincipes''' en '''ontwerpkaders''' binnen de verschillende '''ontwerpgebieden'''). Het verschil in perspectief - NORA is gericht op dienstverlening door overheidsorganisaties, ROSA op ketensamenwerkingen in het onderwijsdomein - komt tot uitdrukking in de formulering van doelen. In NORA zijn doelen geformuleerd als bijvoeglijk naamwoorden ('Transparant') die van toepassing zijn op overheidsdienstverlening ('de dienstverlening is transparant'), in ROSA zijn de doelen geformuleerd als zelfstandig naamwoorden ('Transparantie') waaraan ketensamenwerkingen – in meer of mindere mate – bijdragen.
<imagemap>
Bestand:Architectuurkaders.png|800px
 
rect 4 0 812 309 [[Drivers en doelen]]
rect 2 311 814 465 [[Architectuurprincipes]]
rect 0 493 816 645 [[Ontwerpgebieden]]
rect 899 417 1516 700 [[Ontwerpgebieden]]
rect 2 685 810 831 [[IV-domeinen]]
 
desc none
</imagemap>
 
Ontwikkelingen zoals onderwijskundige veranderingen, innovaties, en beleidswijzigingen vormen externe '''[[Drivers en doelen|drivers]]''' voor de ROSA. In de ROSA worden '''[[Drivers en doelen|doelen]]''' geformuleerd die in lijn zijn met dit beleid en die doorvertaald worden naar '''[[architectuurprincipes]]''', waarmee consistentie en samenhang in de keten wordt nagestreefd. Doelen in ROSA zijn geformuleerd als kwaliteitseigenschappen en waarden die vanuit de ROSA worden geadresseerd. Daarmee sluiten we aan bij de indeling die NORA kiest voor bindende architectuurafspraken in kwaliteitsdoelen (in NORA geclusterd onder Kernwaarden van Dienstverlening <ref>https://www.noraonline.nl/wiki/Kernwaarden_van_Dienstverlening</ref>), architectuurprincipes, en implicaties (in ROSA verder uitgewerkt in '''ontwerpprincipes''' en '''ontwerpkaders''' binnen de verschillende '''ontwerpgebieden'''). Het verschil in perspectief - NORA is gericht op dienstverlening door overheidsorganisaties, ROSA op ketensamenwerkingen in het onderwijsdomein - komt tot uitdrukking in de formulering van doelen. In NORA zijn doelen geformuleerd als bijvoeglijk naamwoorden ('Transparant') die van toepassing zijn op overheidsdienstverlening ('de dienstverlening is transparant'), in ROSA zijn de doelen geformuleerd als zelfstandig naamwoorden ('Transparantie') waaraan ketensamenwerkingen – in meer of mindere mate – bijdragen.


Wanneer binnen een project ontwerpbeslissingen worden gemaakt, vindt steeds een belangenafweging plaats op basis van '''concerns'''<ref>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."''</ref> 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.
Wanneer binnen een project ontwerpbeslissingen worden gemaakt, vindt steeds een belangenafweging plaats op basis van '''concerns'''<ref>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."''</ref> 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.


De ontwerpgebieden 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.
De ontwerpgebieden 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.

Huidige versie van 10 aug 2023 om 17:15

Deze pagina bevat een concepttekst die momenteel in bewerking is.
Toelichting: De structuur van de architectuurkaders is vastgesteld door de Architectuurraad op 2 februari 2023. De uitwerking in de wiki (navigatie, opbouw) op 6 juli 2023. De structuur en de pagina's worden stapsgewijs uitgewerkt.

Drivers en doelenArchitectuurprincipesOntwerpgebiedenOntwerpgebiedenIV-domeinenArchitectuurkaders.png

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 architectuurprincipes, waarmee consistentie en samenhang in de keten wordt nagestreefd. Doelen in ROSA zijn geformuleerd als kwaliteitseigenschappen en waarden die vanuit de ROSA worden geadresseerd. Daarmee sluiten we aan bij de indeling die NORA kiest voor bindende architectuurafspraken in kwaliteitsdoelen (in NORA geclusterd onder Kernwaarden van Dienstverlening [1]), architectuurprincipes, en implicaties (in ROSA verder uitgewerkt in ontwerpprincipes en ontwerpkaders binnen de verschillende ontwerpgebieden). Het verschil in perspectief - NORA is gericht op dienstverlening door overheidsorganisaties, ROSA op ketensamenwerkingen in het onderwijsdomein - komt tot uitdrukking in de formulering van doelen. In NORA zijn doelen geformuleerd als bijvoeglijk naamwoorden ('Transparant') die van toepassing zijn op overheidsdienstverlening ('de dienstverlening is transparant'), in ROSA zijn de doelen geformuleerd als zelfstandig naamwoorden ('Transparantie') waaraan ketensamenwerkingen – in meer of mindere mate – bijdragen.

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.

De ontwerpgebieden 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.

  1. https://www.noraonline.nl/wiki/Kernwaarden_van_Dienstverlening
  2. 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."