Workshop koppelen/2016-12-05

Uit NORA Online
Ga naar: navigatie, zoeken

Bijeenkomst op maandag 5 december 2016, 11.00u-13.00, locatie: ICTU, Den Haag. .



Op 5 december zijn een aantal beheerders van architecturen bij elkaar geweest om te bespreken hoe familieleden van NORA aan kunnen sluiten bij de inhoud van NORA, en hoe NORA afgestemd kan worden op onderliggende architecturen.

Het was een nuttige bijeenkomst om elkaar te inspireren bij het toepassen van referentie-architecturen, en het koppelen met NORA. Het blijkt dat er bij de aanwezigen maar ook bij andere overheidsarchitecturen interesse is om elementen uit NORA over te nemen, met name principes, standaarden en voorzieningen. Gerelateerde architecturen kunnen vaak hun eigen vertaalslag maken zolang duidelijk is wat de definities in het NORA kennismodel zijn, welke scope de inhoud van NORA heeft, filtering mogelijk is, en wijzigingen in NORA voorzichtig worden doorgevoerd.

De workshop is niet alleen nuttig geweest om kennis uit te wisselen; het resulteerde ook in een paar vervolgacties die NORA beheer met de betrokken architecturen op zal pakken. Aan het eind van dit verslag staat een actielijst.

De presentatie en dit verslag zijn te vinden op: http://noraonline.nl/wiki/Workshop_koppelen/2016-12-05


Onderwerpen die behandeld werden:

  • De verschillende manieren om te koppelen
  • ROSA: ervaring met overerven met NORA Dashboard, en inhoud
  • Wat biedt NORA?
    Inhoudelijk inbedden en omgaan met verschillen
  • Proces: hoe hou je het actueel?

Aanwezigen[bewerken]

  • Toine Schijvenaars (KING Gemeenten)
  • René Luyten (Raad voor de Kinderbescherming)
  • Buddy Joe Groeneveld (Nationaal Archief)
  • Jos van der Heijden (Logius)
  • Sergio Richardson (GGD/GHOR)
  • Bram Gaakeer (MinOCW)

Andere geïnteresseerden konden niet aanwezig zijn. Met hun zullen vervolgafspraken gemaakt worden.

Feedback[bewerken]

De deelnemers hebben een wens voor duidelijke definiëring van de elementen in NORA. Dit helpt om de elementen van NORA te kunnen plaatsen ten opzichte van de eigen elementen. Een sterke voorkeur is er voor beschrijvingen conform ArchiMate omdat veel kennismodellen daar ook op afgestemd zijn. Naast een uitleg van de definitie, is ook explicitering van scope van in NORA beschreven elementen gewenst.

Voor Standaarden wil GEMMA méér standaarden dan alleen die van de lijst van het Forum Standaardisatie. De behoefte is vooral aan diepere informatie in tegenstelling tot paraplu-termen als 'Aquo-standaarden' of 'Geo-standaarden'. GEMMA ziet NORA daarbij als de aangewezen plek als centrale registratie van standaarden.

Alle aanwezigen lijken standaarden het best te kunnen koppelen aan functies (of aan processen). Daarnaast merkt OC&W op dat in het standaardisatieproces van Forum Standaardisatie, zij op veel momenten worden betrokken bij en geconfronteerd met het standaardisatieproces. Mogelijk kan NORA met Bureau Forum Standaardisatie een rol spelen bij het stroomlijnen van het proces van impactanalyse, de juiste experts uit het veld betrekken en de standaard opnemen in referentie-architecturen.

Voor voorzieningen en bouwstenen ontstond een discussie over de definitie en is meer helderheid gewenst. In NORA zijn bouwstenen gespecificeerd als landelijk vastgestelde voorzieningen, waarbij voorziening niet verder is gedefinieerd dan 'standaardoplossing'. De herkomst van sommige delen van NORA verklaart waarom ze voor architectuur niet altijd één op één bruikbaar zijn. Bouwstenen bij voorbeeld, zijn in NORA overgenomen van de NUP-bouwstenen (en nu GDI-voorzieningen). Bij ROSA bij voorbeeld is een ‘bouwsteen’ een TOGAF building block, welke kan worden gerealiseerd door een voorziening. Bij GEMMA is een voorziening gemodelleerd als een applicatiecomponent. Ook bedrijfs-/applicatiefuncties of –services lijken, afhankelijk van de interne of externe benadering van een voorziening, ook een voor de hand liggend concept om ArchiMate-conform te modelleren.

We hebben het gehad over de mogelijkheden om filters te kunnen maken die voor de eigen doelgroep nuttig zijn. Zo is in ROSA is voor veel elementen het werkingsgebied als (filterbare) eigenschap opgenomen.

Er was bij de aanwezigen ook interesse in het krijgen van meldingen zodra bepaalde zaken wijzigen, en de mogelijkheden om gegevens uit NORA over te nemen zonder gebruik van een semantische wiki.. Een belangrijk punt voor aanwezigen is duurzaamheid en voorspelbaarheid bij veranderingen in NORA. Veranderingen in het kennismodel hebben een impact voor dochters, in het bijzonder wanneer ze geautomatiseerd overerven. Dochters hebben ook behoefte aan duidelijke status van items (zowel in ‘verplicht’ versuss ‘informatief’ als ‘huidig’/ versus ‘verouderd’).

Vervolgafspraken[bewerken]

  • NORA levert de aanwezigen:
  • Beheerders van afgeleide architecturen maken duidelijk wat ze over willen nemen, wat hun prioriteit heeft, en waar ze een mismatch zien en sturen deze naar NORA beheer (nora@ictu.nl).
    • NORA beheer geeft op korte termijn aan wat er aan beide kanten nodig kan is om aan de wensen te voldoen. Waar technische oplossing nodig is aan de kant van de afgeleide architectuur, geeft NORA beheer een aanzet voor vraagformulering naar leveranciers toe.
  • NORA beheer levert een voorbeeld hoe gebruikers automatisch op de hoogte kunnen komen van wijzigingen in principes.
  • NORA beheer zegt toe dat onderdelen van NORA niet verdwijnen uit de wiki, maar de status ‘vervallen’ krijgen wanneer van toepassing zodat dit bij koppelingen expliciet wordt.

Bijlagen[bewerken]