De afgelopen zes maanden is in de expert- en regiegroep naar aanleiding van het koppelvlak BAG-WOZ en StUF-Lite gediscussieerd over de vraag in hoeverre sectormodellen uitgebreid moeten kunnen worden met extra koppelvlakken. In de gecombineerde vergadering van de expert- en regiegroep van 23 maart 2011 is besloten dat dergelijke toevoegingen aan een sectormodel gewenst zijn zonder dat er een nieuwe versie van het sectormodel gemaakt hoeft te worden en zonder dat dergelijke uitbreidingen ondergebracht hoeven te worden in een nieuw sectormodel. Tijdens deze vergadering bleek ook dat er nog veel onduidelijkheid was over begrippen als sectormodel, koppelvlak, berichtencatalogus en dergelijke.
Overeenstemming over wat dit soort termen betekenen en overeenstemming over de wijze waarop een sectormodel is opgebouwd zijn van essentieel belang voor de definitie van een beheermodel voor een sectormodel, omdat deze begrippen de te beheren objecten mede bepalen. Overeenstemming over deze begrippen maakt ook een discussie over het beheerregime voor de te beheren objecten eenvoudiger.
Ik heb getracht in deze discussie lijn aan te brengen door het schrijven van een document. Dit document doet uitgaande van de vertaling van een domeinmodel naar koppelvlakdefinities en gegeven de randvoorwaarden die StUF stelt een voorstel voor de te beheren objecten en een het regime waaronder deze objecten beheerd zouden moeten worden.
Ik hoop dat dit document in de komende expertgroep behandeld kan worden en dat daardoor een fundament wordt gelegd onder het nieuwe beheermodel. Het document is te vinden in de folder DOCUMENTEN/BEHEER en heeft als naam AanzetBeheermodelStUFenBestPracticesSectormodellen.pdf.
Ik wil de deelnemers aan de expertgroep en andere geinteresseerden in de discussie over het beheermodel uitnodigen om via deze forum post of via documenten in de beheer-folder voorafgaand aan de vergadering alvast te reageren. De discussie over dit onderwerp is lastig genoeg en heeft alle belang bij een goede schriftelijke voorbereiding.
Ik ben benieuwd naar de reacties,
Maarten
Het document is te vinden via het folderpad:
documenten => stuf => 6_stuf_beheermodel
Maarten,
Zoals gebruikelijk heb jij de aanzet voor de oplossing gelijk gegoten in de vorm van een leerboek hoe het in detail moet werken. Dat geeft in ieder geval het vertrouwen dat jij er goed over hebt nagedacht, maar het is voor een hoop mensen wel gelijk een heel inhoudelijk document om te doorgronden.
Als wij dit "nieuwe leerboek StUF structureren" goed begrepen hebben, zijn we het helemaal met je eens. Maar dan maar even in onze eigen woorden:
Er is een laag bestaande uit het inhoudelijke informatiemodel. Dat staat buiten StUF en buiten de sectormodellen. Denk aan RSGB, Informatiemodel WOZ etc. Het beheer van deze informatiemodellen valt buiten het beheermodel StUF. Wel zal je in de StUF modellen concreet moeten aangeven welke versie van het informatiemodel het uitgangspunt is.
Een (horizontaal of verticaal) sectormodel binnen StUF bestaat dan uit de vertaling van het informatiemodel naar berichtentiteiten, met elementen voor relaties naar andere entiteiten en elementen voor attributen. Dit resulteert in een (goed gestructureerd) samenstel van complexType die de bouwstenen vormen voor berichtdefinities. Voor het beheermodel is relevant dat dit deze "definitie van berichtentiteiten" de kern vormt van een sectormodel en dat wijzigingen en toevoegingen hierin betekent dat de er sprake is van een "nieuwe versie".
Daarnaast bevat het (horizontale of verticale) sectormodel binnen StUF enkele berichtcatalogi. In beginsel zijn dat er tenminste twee (één voor kennisgevingen en synchronisatie en één voor vraag/antwoord). Daarnaast kunnen er extra berichtcatalogi worden toegevoegd aan een sectormodel. Extra berichtcatalogi kunnen bijvoorbeeld specificaties geven voor "vrije berichten" of "samengestelde berichten". Voor het beheermodel is van belang dat wijzigingen in de twee basis berichtencatalogi leiden tot een nieuwe versie van het sectormodel. Het toevoegen van een nieuwe berichtcatalogus of het uitbreiden van een "extra" berichtcatalogus binnen een bestaande versie van het sectormodel is wel mogelijk.
De specificatie van koppelvlakken is gebaseerd op de berichtcatalogi. Voor het beheermodel is van belang dat (het beheer van) deze koppelvlakspecificaties niet tot (het beheer van) het sectormodel behoren en dat toevoegingen van en wijzigingen van koppelvlakspecificaties mogelijk zijn zonder verandering van versienummer van het sectormodel. Wel moet natuurlijk helder zijn op welke versie van het sectormodel de koppelvlakspecificatie is gebaseerd. Koppelvlakspecificaties vervallen daarmee "automatisch" wanneer de versie van het sectormodel waarop zij zijn gebaseerd niet langer ondersteund wordt.
Er zijn daarbij twee typen koppelvlakspecificaties. De beschrijvende koppelvlakken beschrijven in de vorm van services hoe een bepaalt systeem werkt. Iedere aanbieder van services beschrijft met dit type koppelvlak de werking van zijn systeem voor zover relevant voor de gebruikers van de services. Deze beschrijvende koppelvlakken worden dus beheerd door de aanbieders van systemen. De normatieve koppelvlakken geven eisen waaraan een systeem moet voldoen om op bepaalde services te mogen aansluiten. Deze normatieve koppelvlakken zijn alleen van belang wanneer een organisatie ook verplicht is om via een bepaald koppelvlak te communiceren. Voorbeelden van normatieve koppelvlakken zijn de specificaties voor de aansluiting van gemeenten op de LV BAG en de LV WOZ. Beheer van deze normatieve koppelvlakken ligt bij de "eisende" instantie (Kadaster als beheerder BAG, Waarderingskamer).
Volgens ons is hiermee de kern van het beoogde flexibele beheermodel gelegd. Hopelijk lukt het inderdaad via een schriftelijke voorbereiding nu snel het beheermodel definitief vast te leggen.
Wij zijn benieuwd naar de reacties van de anderen.
Ruud,
Hartelijk dank voor deze heldere samenvatting van hetgeen ik inderdaad maar gelijk in detail heb uitgewerkt, omdat ik op die manier voor mezelf zeker stel dat het kan werken.
Op het punt van de koppelvlakspecificatie heb ik iets anders beoogd dan wat jij in de vierde alinea van onderen zegt. Wat mij betreft zijn de voorbeeld webservices behorend bij een berichtcatalogus en de normatieve koppelvlakken wel degelijk een onderdeel van het beheermodel. De hoofdspelregel hier is dat er alleen kan worden toegevoegd en nooit iets kan worden verwijderd. Een nieuwe versie van een koppelvlak met extra of gewijzigde functionaliteit staat op het niveau van het beheermodel evenwaardig naast de oorspronkelijke versie. Het beheermodel doet geen uitspraken over de verplichting om over te gaan naar een hogere versie. Hier is voor gekozen, omdat koppelvlakken mogen worden toegevoegd en je gedane investeringen in een ouder koppelvlak wilt beschermen. Als overgang naar nieuwe versies afgedwongen moet worden, dan kan dit nog altijd door over te gaan naar een nieuwe versie van het sectormodel, waarbinnen bepaalde koppelvlakken niet meer worden ondersteund. De beslissing hierover is aan de regiegroep.
Beste Maarten,
bedankt voor je post. Je hebt een belangrijke slag gemaakt om begrippen als sectormodel, koppelvlak en berichtencatalogus meer scherpte te geven. Dat is heel belangrijk in de verdere discussie en doorontwikkeling van de standaard. Bovendien kan ik me prima vinden in bijna alle practises die je hebt beschreven.
Wat betreft je voorstel omtrent het aanpassen van het beheermodel heb ik een vraag:
Wat zijn nu de concrete voordelen van het aanpassen van het beheermodel?
In je document heb ik geen argumentatie of antwoorden kunnen vinden op deze vraag.
Een voorbeeld: indien de opstellers van het BAG-WOZ koppelvlak ervoor hadden gekozen om de schema's te definiëren buiten het sectormodel BG in een eigen namespace dan was er geen stro in de weg gelegd voor een flexibele en snelle vaststelling.
Waarom is het in jouw visie zo belangrijk om BAG-WOZ binnen het sectormodel BG te definiëren? Is het wellicht lastig voor software om met nieuwe namespaces te werken? Waarom…? Of zijn er zelfs andere redenen…?
Voor KING is het belangrijk om de voordelen af te kunnen wegen ten opzichte van de nadelen. Het nadeel van je voorstel is dat het beheermodel een behoorlijk stuk complexer wordt en lastiger te begrijpen voor belanghebbenden die wat verder afstaan en geen lid zijn van de expert- of regiegroep. Een duidelijke en eenvoudige familiestructuur is voor ons van groot belang om de beheerverantwoordelijkheden goed te kunnen organiseren, beleggen en uitleggen.
Mvg,
Henri Korver
Hallo Henri,
In mijn model heb ik een belangrijke eis gesteld aan de aan een sectormodel toe te voegen berichtcatalogi, namelijk dat er geen kennisgevingen in gedefinieerd worden met een omvang groter dan de kennisgeving gedefinieerd in de mutatie-berichtcatalogus in het sectormodel. Deze eis geldt ook voor het gebruik van het update element in vrije berichten. Dezelfde eis geldt voor vraag/antwoord functionaliteit. Ook deze mag niet groter worden dan de berichten gedefinieerd in de vraagAntwoord berichtcatalogus. Dit geldt ook voor het vraag element in vrije berichten. Hiermee is er een goed gedefinieerde link tussen de toe te voegen berichtcatalogi en een sectormodel. Voor een berichtcatalogus in een nieuwe namespace lijkt het bovenstaand me geen zinnige eis.
Deze eis is belangrijk, omdat erdoor gewaarborgd wordt dat functionaliteit die vraag/antwoord of kennisgevingen voor een sectormodel kan verwerken ook altijd zonder aanpassingen nieuw gedefinieerde kennisgevingen en vraag/antwoord berichten en vrije berichten voorzover het gaat om vrije berichten met een zuiver update- of vraag-element kan verwerken. Bij het toevoegen van een berichtcatalogus hoeft alleen nagegaan te worden welke extra eisen er gesteld worden en kan in veel gevallen met beperkte uitbreidingen in de software een nieuwe berichtcatalogus ondersteund worden.
Mijn inschatting is dat de extra kosten van het beheer die het door mij voorgestelde model met zich meebrengen in het niet vallen bij de extra kosten die softwareleveranciers moeten maken, als elke nieuwe berichtcatalogus een nieuwe namespace krijgt. Wat mij betreft is dit een puur financiële afweging. Ik realiseer me dat in de door mij voorgestelde variant de kosten bij King een stuk zichtbaarder zijn dan de kosten die gemeenten moeten maken bij het aanschaffen van software.
Om een en ander voor iedereen inzichtelijker te maken, zou ik King willen verzoeken om een schatting te geven van de in de toekomst te maken kosten voor beide varianten van het beheermodel. Softwareleveranciers zouden ook een schatting kunnen maken van de extra kosten per nieuwe berichtencatalogus in beide modellen.
Met vriendelijke groet,
Maarten