Dit is de multi-page printable view van deze sectie. Klik hier om te printen.

Terug naar normale view van deze pagina.

Keuzes

Lijst van uitgangspunten met afwegingen en onderbouwing

Dit is de sectie waar onze ‘DRs’, Decision Records worden vastgelegd. Decision Records zijn een methode om gestructureerd besluiten te maken op onderwerpen en deze vast te leggen. We noemen dit echter met opzet keuzes om verwarring in onze omgeving te voorkomen. Deze DRs betekenen namelijk niet dat er formele besluiten genomen zijn in officiële overleggen, maar dat dit nu ontwerp- en inrichtingsuitgangspunten zijn die we als programma hanteren. Als er over deze DRs vragen zijn dan kun je te allen tijde daar nog vragen over stellen.

Hieronder vind je het overzicht van alle uitgangspunten, Decision Records, in chronologische volgorde. Meer toelichting over Decision Records vind je in het besluit om deze methode toe te passen: 00002 Gebruik van Markdown Decision Records in Git

1 - 00005 Gebruik van Versies en Labels

Bij het bijhouden en aanmaken van nieuwe pagina’s werken we met labels en versionering, om ervoor te zorgen dat iedereen dit op dezelfde manier doet hebben we besloten hoe we dit de komende tijd willen inregelen.

Context en probleemstelling

Momenteel komen er onwijs veel nieuwe pagina’s bij in deze samenwerkingsomgeving en dat is goed nieuws! Daarmee wordt het gebruik van versie nummers en labels extra belangrijk en met name het uniform toepassen van de juiste updates in de versionering. Geconstateerd werd dat er verschillen waren in het gebruik van versie updates, waardoor een nieuw besluit is genomen om dit te voorkomen. We leggen hier uit hoe we hiermee om gaan.

Overwogen opties

Eerst is er gekeken of git geautomatiseerd de versienummers kan aanpassen, dit is helaas niet mogelijk. Vervolgens is na analyse geconcludeerd dat versionering met name is berust op updates in de software volgens het major.minor principe. Deze gedachtegang passen we nu handmatig toe bij bepaalde pagina’s.

Aangezien automatisering niet mogelijk is hebben we ervoor gekozen om een proces te bepalen waarin we de randomness van het aanpassen van versienummers verwijderen. Dit leidt tot de besluiten hieronder.

Besluit gebruik versienummers

Vanaf heden maken we niet gebruik van versienummers, alleen bij specifiek gekozen pagina’s waaronder het basisconcept. Bij deze pagina’s is het goed om te zien welke wijzigingen we doen. Dit doen we in de versionering van major.minor wijzigingen. Alle grote inhoudelijke wijzigingen zijn major wijzigingen, alle kleinere inhoudelijke aanpassingen zijn minor aanpassingen. Spelfouten en grammaticale verbeteringen leiden niet tot een nieuw versie nummer.

Voor alle andere pagina’s is een versienummer niet nodig, in Git loggen we namelijk automatisch alle changes en kunnen we ten alle tijden zien welke versies en acties er in het verleden zijn geweest.

Besluit gebruik labels in het Nederlands

In decision record 0002 is er een visuele weergave gemaakt van de labels en staat er een uitgebreide legenda waarin alle labels worden gedefinieerd.

We werken met de volgende labels:

flowchart LR
    draft([concept])
    style draft fill:#fff

    proposed([voorstel])
    style proposed fill:#fff
    
    rejected([afgewezen])
    style rejected fill:#fff,stroke-dasharray: 5 5
    
    accepted([definitief])
    style accepted fill:#fff,stroke-dasharray: 5 5
    
    deprecated([verouderd])
    style deprecated fill:#fff,stroke-dasharray: 5 5
    
    superseded([vervangen])
    style superseded fill:#fff,stroke-dasharray: 5 5
    
    draft --> proposed
    proposed --> accepted
    accepted --> deprecated
    accepted --> superseded
    proposed ---> rejected

Op dit moment is het besluit genomen om alleen met de volgende twee labels te werken:

  1. Concept: dit betekent dat de pagina informatie biedt die in concept is. Kortom, deze informatie behoeft juist nog input en expertise van een ieder die zich daartoe geroepen voelt!
  2. Voorstel: dit betekent dat het stuk is voorgesteld aan het Tactisch Overleg van het FDS en is besproken. Hierdoor heeft er een inhoudelijke discussie heeft kunnen plaatsvinden met eventuele inhoudelijke aanvullingen en/of wijzigingen.

Deze labels gaan we vanaf heden in het Nederlands toevoegen aan een nieuwe pagina. Bij bestaande pagina’s zullen we komende tijd de wijzigingen doorvoeren. In de toekomst zullen ook de labels geaccepteerd en geweigerd worden toegevoegd, dit hangt ook samen met de verdere inrichting van het Federatief Datastelsel.

Pros en cons van de oplossingen

  • Op deze wijze is het gebruik van versienummers uniform afgesproken, dit voorkomt verwarring tussen de auteurs
  • Op deze wijze is het helder welke labels we in de huidige fase van het FDS gebruiken
  • Dit biedt ruimte om in de toekomst ook de andere labels toe te passen, bij verscherping en aanvulling op het besluitvormingsproces rondom ‘FDS producten’
  • We zijn sneller in staat om vragen te beantwoorden van buitenaf welke status bepaalde kennispagina’s hebben en hoe we daarmee om gaan

2 - 00004 Capabilities NL

We gebruiken de OpenDEI building blocks als capabilities, maar hoe vertalen we deze naar het Nederlands?

Context en probleemstelling

Gegeven de context van de DR 00001 Basisstructuur waarin we bepalen dat we met capabilities gaan werken volgens de building blocks van OpenDEI, hoe noemen we de capabilities dan in het Nederlands? Nemen we de OpenDEI building blocks letterlijk over? Geven we nog een andere context aan onze capabilities? (Waarmee ook de vertaling naar het Engels anders wordt?)

Beslissingsfactoren

Overwogen opties

Besluit

We kiezen voor een zo kort en eenvoudig mogelijke duiding en daarom nemen we voornamelijk Mike’s vertaling over. Daarbij voegen we wel een zin per capability / woord toe om te zorgen voor een juiste en gedeelde ’lading’ van elke capability.

  • Governance
    • Bestuurlijk: Bestuurlijke overeenkomsten en juridische constructen
    • Operationeel: Operationele overeenkomsten en afspraken
    • Beheer: Continuïteit en doorontwikkeling van het stelsel
  • Interoperabiliteit
    • Modellen: Data- en informatiemodellen en -formaten
    • Dataservices: API’s voor data uitwisseling
    • Traceerbaarheid: Traceerbaarheid en herleidbaarheid
  • Datawaarde
    • Metadata: Metadata in brede zin met beschrijvingen, verwijzingen en meer
    • Verantwoording: Verantwoording van datagebruik
    • Publicatie: Publicatie- en marktplaatsdiensten
  • Vertrouwen
    • Identiteit: Identiteitsbeheer
    • Toegang: Toegangscontrole en gebruikscontrole
    • Veiligheid: Vertrouwde uitwisseling

Positieve gevolgen

  • …

Negatieve Consequences

  • …

Pros en Cons van de oplossingen

OpenDEI oorspronkelijk

  • Governance

    Business building blocks are artifacts that regulate the business relationships between all roles.

    • Overarching cooperation agreement

      All data space participants need to agree on certain functional, technical, operational and legal aspects. While some agreements are reusable in a generic or sector-specific way (e. g. rule books), others are use-case specific.

    • Operational (e.g. SLA)

      Operational agreements regulate policies that need to be enforced during data space operation. For example, they comprise terms and conditions dealing with the ever-growing importance of compliance with mandatory regulations like GDPR or the 2nd Payment Services Directive (PSD2) in the finance sector.

    • Continuity model

      The Continuity Model describes the processes for the management of changes, versions, and releases for standards and agreements. This also includes the governance body for decision-making and conflict resolution.

  • Interoperability

    Data interoperability, covering aspects such as data exchange APIs, data representation formats, as well as provenance and tracebility

    • Data models and formats

      This building block establishes a common format for data model specifications and representation of data in data exchange payloads. Combined with the Data Exchange APIs building block, this ensures full interoperability among participants

    • Data exchange APIs

      This building block facilitates the sharing and exchange of data (i.e., data provision and data consumption/use) between data space participants. An example of a data interoperability building block providing a common data exchange API is the ‘Context Broker’ of the Connecting Europe Facility (CEF)50, which is recommended by the European Commission for sharing right-time data among multiple organisations.

    • Provenance and traceability

      This building block provides the means for tracing and tracking in the process of data provision and data consumption/use. It thereby provides the basis for a number of important functions, from identification of the lineage of data to audit-proof logging of transactions. It also enables implementation of a wide range of tracking use cases at application level, such as tracking of products or material flows in a supply chain.

  • Data value

    Data value creation, covering aspects such as publication of data offerings, discovery of such offerings based on metadata, and data access/usage accounting, which are essential to handle data as an economic asset

    • Metadata and Discovery Protocol

      This building block incorporates publishing and discovery mechanisms for data resources and services, making use of common descriptions of resources, services, and participants. Such descriptions can be both domain-agnostic and domain-specific. They should be enabled by semantic-web technologies and include linked-data principles.

    • Data usage accounting

      This building block provides the basis for accounting access to and/or usage of data by different users. This in turn is supportive of important functions for clearing, payment, and billing (including data-sharing transactions without involvement of data marketplaces).

    • Publication and marketplace services

      To support the offering of data resources and services under defined terms and conditions, marketplaces must be established. This building block supports publication of these offerings, management of processes linked to the creation and monitoring of smart contracts (which clearly describe the rights and obligations for data and service usage), and access to data and services.

  • Trust

    Data sovereignty, covering aspects such as identity management, trustworthiness of participants, as well as data access and usage control

    • Identity management

      The IM building block allows identification, authentication, and authorisation of stakeholders operating in a data space. It ensures that organisations, individuals, machines, and other actors are provided with acknowledged identities, and that those identities can be authenticated and verified, including additional information provisioning1, to be used by authorisation mechanisms to enable access and usage control. The IM building block can be implemented on the basis of readily available IM platforms that cover parts of the required functionality. Examples of open-source solutions are the KeyCloak infrastructure, the Apache Syncope IM platform, the open-source IM platform of the Shibboleth Consortium, or the FIWARE IM framework. Integration of the IM building block with the eID building block of the Connecting Europe Facility (CEF)55, supporting electronic identification of users across Europe, would be particularly important. Creation of federated and trusted identities in data spaces can be supported by European regulations such as EIDAS.

    • Access and usage control / policies

      This building block guarantees enforcement of data access and usage policies defined as part of the terms and conditions established when data resources or services are published (see ‘Publication and Services Marketplace’ building block below) or negotiated between providers and consumers. A data provider typically implements data access control mechanisms to prevent misuse of resources, while data usage control mechanisms are typically implemented on the data consumer side to prevent misuse of data. In complex data value chains, both mechanisms are combined by prosumers. Access control and usage control rely on identification and authentication.

    • Trusted exchange

      This building block facilitates trusted data exchange among participants, reassuring participants in a data exchange transaction that other participants really are who they claim to be and that they comply with defined rules/agreements. This can be achieved by organisational measures (e.g. certification or verified credentials) or technical measures (e.g. remote attestation).

OpenDEI letterlijke vertaling

(vertaald mbv Google Translate)

  • Bestuur

    Governance capabilities zijn artefacten die de zakelijke relaties tussen alle rollen regelen.

    • Overkoepelend samenwerkingsakkoord

      Alle deelnemers aan de dataspace moeten het eens zijn over bepaalde functionele, technische, operationele en juridische aspecten. Hoewel sommige overeenkomsten op een generieke of sectorspecifieke manier herbruikbaar zijn (bijv. Regelboeken), zijn anderen gebruiksspecifiek.

    • Operationeel (bijv. SLA)

      Operationele overeenkomsten reguleren beleid dat moet worden afgedwongen tijdens de dataspace operatie. Ze omvatten bijvoorbeeld voorwaarden die betrekking hebben op het steeds groter wordende belang van naleving van verplichte voorschriften zoals GDPR of de 2e Payment Services Richtlijn (PSD2) in de financiële sector.

    • Continuïteitsmodel

      Het continuïteitsmodel beschrijft de processen voor het beheer van wijzigingen, versies en releases voor normen en overeenkomsten. Dit omvat ook het bestuursorgaan voor besluitvorming en conflictoplossing.

  • Interoperabiliteit

    Gegevensinteroperabiliteit, met betrekking tot aspecten zoals gegevensuitwisseling API’s, formaten voor gegevensrepresentatie, evenals herkomst en traceerbaarheid

    • Datamodellen en formaten

      Deze bouwsteen stelt een gemeenschappelijk formaat vast voor specificaties voor gegevensmodel en weergave van gegevens in de payloads van gegevensuitwisseling. Gecombineerd met de Building Builder van de Data Exchange API’s, zorgt dit voor volledige interoperabiliteit bij deelnemers

    • API’s voor gegevensuitwisseling

      Deze bouwsteen vergemakkelijkt het delen en uitwisselen van gegevens (d.w.z. gegevensvoorziening en dataconsumptie/gebruik) tussen gegevensruimte -deelnemers. Een voorbeeld van een bouwsteen voor gegevensinteroperabiliteit die een gemeenschappelijke gegevensuitwisseling API biedt, is de ‘contextmakelaar’ van de Connecting Europe Facility (CEF), die door de Europese Commissie wordt aanbevolen voor het delen van juiste gegevens over meerdere organisaties.

    • Herkomst en traceerbaarheid

      Deze bouwsteen biedt de middelen voor tracering en tracking in het proces van gegevensvoorziening en gegevensverbruik/gebruik. Het biedt daardoor de basis voor een aantal belangrijke functies, van identificatie van de lijn van gegevens tot auditbestendige logboekregistratie van transacties. Het maakt ook de implementatie van een breed scala aan tracking -use cases op applicatieniveau mogelijk, zoals het volgen van producten of materiaalstromen in een supply chain.

  • Gegevenswaarde

    Gegevenswaardecreatie, met betrekking tot aspecten zoals publicatie van gegevensaanbiedingen, ontdekking van dergelijke aanbiedingen op basis van metadata en gegevenstoegang/gebruiksboekhouding, die essentieel zijn om gegevens als een economisch asset te verwerken

    • Metagegevens en ontdekkingsprotocol

      Deze bouwsteen omvat publicatie- en ontdekkingsmechanismen voor gegevensbronnen en -services, waarbij gebruik wordt gemaakt van gemeenschappelijke beschrijvingen van bronnen, diensten en deelnemers. Dergelijke beschrijvingen kunnen zowel domein-agnostisch als domeinspecifiek zijn. Ze moeten worden ingeschakeld door semantische-WEB-technologieën en bevatten principes met gekoppelde gegevens.

    • Accounting van gegevensgebruik

      Deze bouwsteen biedt de basis voor boekhoudkundige toegang tot en/of gebruik van gegevens door verschillende gebruikers. Dit ondersteunt op zijn beurt belangrijke functies voor het wissen, betalen en factureren (inclusief transacties voor het delen van gegevens zonder betrokkenheid van gegevensmarktplaatsen).

    • Publicatie- en marktplaatsdiensten

      Ter ondersteuning van het aanbod van gegevensbronnen en -diensten onder gedefinieerde algemene voorwaarden, moeten marktplaatsen worden vastgesteld. Deze bouwsteen ondersteunt de publicatie van deze aanbiedingen, het beheer van processen die gekoppeld zijn aan het maken en monitoren van slimme contracten (die duidelijk de rechten en verplichtingen voor gegevens en servicegebruik beschrijven) en toegang tot gegevens en diensten.

  • Vertrouwen

    Gegevenssoevereiniteit, met betrekking tot aspecten zoals identiteitsbeheer, betrouwbaarheid van deelnemers, evenals gegevenstoegang en gebruikscontrole

    • Identiteitsbeheer

      De IM -bouwsteen maakt identificatie, authenticatie en autorisatie mogelijk van belanghebbenden die in een gegevensruimte actief zijn. Het zorgt ervoor dat organisaties, individuen, machines en andere actoren worden voorzien van erkende identiteiten, en dat die identiteiten kunnen worden geauthenticeerd en geverifieerd, inclusief aanvullende informatievoorziening, kunnen worden gebruikt door autorisatiemechanismen om toegang en gebruikscontrole mogelijk te maken. De IM -bouwsteen kan worden geïmplementeerd op basis van direct beschikbare IM-platformen die delen van de vereiste functionaliteit behandelen. Voorbeelden van open-source oplossingen zijn de Keycloak-infrastructuur, het Apache Syncope IM-platform, het open-source IM-platform van het Shibboleth Consortium of het Fiware IM-framework. Integratie van de IM -bouwsteen met de eID-bouwsteen van de Connecting Europe Facility (CEF), ter ondersteuning van elektronische identificatie van gebruikers in heel Europa, zou met name belangrijk zijn. Creatie van federale en vertrouwde identiteiten in gegevensruimtes kan worden ondersteund door Europese voorschriften zoals EIDAS.

    • Toegangs- en gebruikscontrole / beleid

      Deze bouwsteen garandeert de handhaving van gegevenstoegang en gebruiksbeleid gedefinieerd als onderdeel van de algemene voorwaarden die zijn vastgesteld wanneer gegevensbronnen of -diensten worden gepubliceerd (zie hieronder ‘Publication and Services Marketplace’ bouwsteen) of onderhandeld tussen providers en consumenten. Een gegevensaanbieder implementeert doorgaans mechanismen voor gegevenstoegang om misbruik van middelen te voorkomen, terwijl het besturingsmechanismen voor gegevensgebruik meestal aan de gegevens van de gegevens van de gegevens worden geïmplementeerd om misbruik van gegevens te voorkomen. In complexe gegevenswaardeketens worden beide mechanismen gecombineerd door prosumeurs. Toegangscontrole en gebruikscontrole vertrouwen op identificatie en authenticatie.

    • Vertrouwde uitwisseling

      Deze bouwsteen faciliteert de vertrouwde gegevensuitwisseling onder deelnemers, waardoor deelnemers in een gegevensuitwisselingstransactie geruststellen die andere deelnemers echt zijn wie zij beweren te zijn en dat zij voldoen aan gedefinieerde regels/overeenkomsten. Dit kan worden bereikt door organisatorische maatregelen (bijv. Certificering of geverifieerde referenties) of technische maatregelen (bijv. Attesting op afstand).

Mike’s vertaling

  • Governance
    • Bestuurlijk
    • Operationeel
    • Organisatie
  • Interoperabiliteit
    • Modellen
    • Interoperabiliteit
    • Traceerbaarheid
  • Data met waarde
    • Beschrijving
    • Verantwoording
    • Diensten
  • Vertrouwen
    • Identiteit
    • Toegang
    • Veiligheid

FDS overwegingen:

  • Enkel één woord is wel erg prettig!
  • Enkel één woord geeft weinig ’lading’ en verdient wel duidelijke beschrijvingen van wat er dan wel en niet onder valt. Hier ligt het gevaar dat ‘men’ alleen de woorden als uitgangspunt neemt en verschillende lading daar aan geeft. Hoewel een enkel woord eenvoudig lijkt en duidelijkheid lijkt te geven, zou het ook juist tot verwarring kunnen leiden. Dat is slechts een risico zo lang de woorden nog niet goed geladen zijn. Zodra dat wel het geval is, draagt het zeker bij aan een eenvoudig en duidelijk model!
  • Interoperabiliteit > Interoperabiliteit … is niet heel duidelijk. Zou de capability niet ‘iets met API’s’ moeten bevatten … alléén ‘API’s’?
  • ‘Data met waarde’ is anders dan ‘Data value’. Dat beschrijft meer de waarde van data. De capabilities verwijzen meer naar de bekwaamheden die de data waarde gaan geven en/of duiden. Waarom niet directer vertalen met ‘Data waarde’?
  • Data met waarde > Beschrijving verwijst vooral naar de metadata. Is ‘Metadata’ beter dan ‘Beschrijving’?
  • Data met waarde > Diensten gaat vooral over de publicatie en het gebruik van die publicatie in een marktplaats, terwijl diensten zelf ook kan duiden op de API’s. Is ‘Publicatie’ beter?

Peter’s vertaling

  • Governance
    • Standaard generieke samenwerkovereenkomst
    • Standaard operationele overeenkomst (SLA)
    • Regie op en continuïteit van het stelsel
  • Interoperabiliteit
    • Datamodellen en -formaten
    • Datadeel services (API’s)
    • Herkomst en traceerbaarheid
  • Waarde van data
    • Protocol voor metadata en zoeken
    • Verantwoording data gebruik
    • Services voor datapublicatie en datamarktplaats
  • Vertrouwen
    • Identiteit management
    • Beleid toegang en gebruik
    • Vertrouwd data delen

Capabilities sessies

  • Governance
    • [nog consolideren]
  • Interoperabiliteit
    • Datamodellen en formaten
    • Data uitwisseling en APIs
    • Herleidbaarheid en traceerbaarheid
    • [extra] Ontwikkelen en beheren meta-data-standaarden
  • Data waarde
    • Metadata en discovery
    • Verantwoording datagebruik
    • Publicatie en marktplaats-services
  • Vertrouwen
    • Identiteitsbeheer
    • Toegangs- en gebruikerscontrole/beleid
    • Vertrouwd uitwisselen

FDS overwegingen:

Tijdens de capabilities sessies zijn we steeds afgeweken van de OpenDEI building blocks. Dat heeft geleid tot goede discussies en uitwerking van diverse (bijv.) rollen van het federatief datastelsel. Echter … wijkt dat dusdanig af dat het niet meer herkenbaar is naar het oorspronkelijke model van OpenDEI. Aangezien we in DR 00001 Basisstructuur hebben besloten om juist wél dicht bij het OpenDEI model te blijven, moeten we herzien wat we tijdens de sessies bedacht hebben.

Vergelijkingstabel

OpenDEI oorspronkelijk OpenDEI letterlijke vertaling Mike’s vertaling Peter’s vertaling Capabilities sessies
Governance Bestuur Governance Governance Governance
Overarching cooperation agreement Overkoepelend samenwerkingsakkoord Bestuurlijk Standaard generieke samenwerkovereenkomst [nog consolideren]
Operational (e.g. SLA) Operationeel (bijv. SLA) Operationeel Standaard operationele overeenkomst (SLA)
Continuity model Continuïteitsmodel Organisatie Regie op en continuïteit van het stelsel
Interoperability Interoperabiliteit Interoperabiliteit Interoperabiliteit Interoperabiliteit
Data models and formats Datamodellen en formaten Modellen Datamodellen en -formaten Datamodellen en formaten
Data exchange APIs API’s voor gegevensuitwisseling Interoperabiliteit Datadeel services (API’s) Data uitwisseling en APIs
Provenance and traceability Herkomst en traceerbaarheid Traceerbaarheid Herkomst en traceerbaarheid Herleidbaarheid en traceerbaarheid
[extra] Ontwikkelen en beheren meta-data-standaarden
Data value Gegevenswaarde Data met waarde Waarde van data Data waarde
Metadata and Discovery Protocol Metagegevens en ontdekkingsprotocol Beschrijving Protocol voor metadata en zoeken Metadata en discovery
Data usage accounting Accounting van gegevensgebruik Verantwoording Verantwoording data gebruik Verantwoording datagebruik
Publication and marketplace services Publicatie- en marktplaatsdiensten Diensten Services voor datapublicatie en datamarktplaats Publicatie en marktplaats-services
Trust Vertrouwen Vertrouwen Vertrouwen Vertrouwen
Identity management Identiteitsbeheer Identiteit Identiteit management Identiteitsbeheer
Access and usage control / policies Toegangs- en gebruikscontrole / beleid Toegang Beleid toegang en gebruik Toegangs- en gebruikerscontrole/beleid
Trusted exchange Vertrouwde uitwisseling Veiligheid Vertrouwd data delen Vertrouwd uitwisselen

Links

3 - 00006 Capabilities en Stelselfuncties

We gebruiken de OpenDEI building blocks als capabilities, maar hoe laten we dat aansluiten op FDS en de stelselfuncties

Probleemstelling en context

Momenteel hanteren we op Open DEI gebaseerde capabilities en vanuit FDS gedefinieerde stelselfuncties. De capabilities en stelselfuncties hebben voor een belangrijk hetzelfde doel (structureren van functies binnen het stelsel). Dit werkt verwarrend en is lastig uit te leggen.

In de Decision Records 00001 Basisstructuur en 00004 Capabilities NL bepalen we dat we met capabilities gaan werken volgens de building blocks van OpenDEI. Hoe laten we de capabilities goed aansluiten op het FDS en de daarin benoemde organisatorische en technische stelselfuncties.

Overwogen opties

aansluitende (deel)opties met betrekking tot capability ‘verantwoording’:

aansluitende (deel)opties met betrekking tot kwaliteit:

aansluitende (deel)opties met betrekking tot dssc capability ‘value added services’:

aansluitende (deel)opties met betrekking tot een alternatieve betekenis van ‘verantwoording’:

Besluit

We laten uitlegbaarheid, inhoudelijke consistentie en eenvoud prevaleren boven vormgeving of het volgen van OpenDEI.

Daarmee kiezen we voor:

Positieve gevolgen

  • We hebben een goed uitlegbaar stelselfunctiemodel dat ruimte biedt voor alle belangrijke aspecten van FDS.

Negatieve gevolgen

  • We moeten de vormgeving en content van de huidige organisatorische stelselfuncties en OpenDEI capabilities herzien (ook bij Digilab) om de nieuwe indeling te accommoderen.

Algemene beslissingsfactoren

  • Context:
  • Decision Records:
  • Overwegingen:
    • Building blocks (onze capabilities) zijn in het OpenDEI paper opgedeeld in ‘Technical Building Blocks’ en ‘Governance Building Blocks’
    • De OpenDEI indeling wordt niet onderhouden in nieuwere revisies.
    • De dssc blueprint 1.0 is een doorontwikkeling van het OpenDEI model.
    • In het dssc model zijn de OpenDEI ‘Technical Building Blocks’ grotendeels gehandhaafd.
    • In het dssc model zijn de OpenDEI ‘Governance Building Blocks’ vervangen door andere building blocks en aangevuld tot ‘Business and Organisational Building Blocks’.
    • De FDS organisatorische stelselfuncties lijken te overlappen met de OpenDEI ‘Governance’ building blocks, maar lijken niet direct goed op elkaar te passen.
    • De FDS organisatorische stelselfuncties hebben naamsbekendheid en zijn voor een deel (bv poortwachter) al vrij ver uitgewerkt / uitgedacht.
    • De FDS technische stelselfuncties lijken goed onder te brengen binnen de OpenDEI ’technical building blocks’ met uitzondering van de ’terugmeldfunctie’ (of datakwaliteit in het algemeen).
    • Het OpenDEI building block ‘Verantwoording’ is in OpenDEI bedoeld als financiële verantwoording ten behoeve van het in rekening brengen van dataleveringen.
    • Het dssc model voegt de capability ‘value added services’ toe onder de de capabilitygroep ‘datawaarde’.
    • Onder value added services verstaan we het toevoegen bij het beschikbaar stellen van gegevens, bijvoorbeeld aggregratie, compilatie, translatie of bv het verhogen van beschikbaarheid, responsetijden, zoekmogelijkheden etc.
    • Geen van de OpenDEI capabilities lijkt betrekking te hebben op kwaliteit (servicekwaliteit en/of datakwaliteit). Daarmee heeft bv terugmelding ook geen logische plek.
    • GDI werkt in de Domeinarchitectuur Gegevensuitwisseling met capabilities gerelateerd aan (groepen van) business functions.

Voordelen en nadelen van de oplossingen

Technisch OpenDEI en Organisatorisch FDS

  • We handhaven de de technische capabilities (building blocks) van Open DEI en verlaten de technische FDS stelselfuncties door de inhoud onder te brengen bij de technische capabilities:
    • FDS Verantwoordingsfunctie onderbrengen bij OpenDEI Traceerbaarheid
    • FDS Catalogusfunctie onderbrengen bij OpenDEI Publicatie
    • FDS Monitoringsfunctie onderbrengen bij OpenDEI Metadata
    • FDS Notificatiefunctie onderbrengen bij OpenDEI Dataservices
    • FDS Terugmeldfunctie onderbrengen bij nieuwe capability Kwaliteit onder Datawaarde of alleen verwijzen vanuit capability Metadata.
    • FDS Toegang onderbrengen bij OpenDEI Identiteit, Toegang, Veiligheid en Traceerbaarheid
  • Voor organisatorische aspecten verlaten we de OpenDEI indeling en hanteren we de FDS organisatorische stelselfuncties.
  • Daarmee hanteren we technische OpenDEI capabilities icm organisatorische FDS stelselfuncties.
  • We hernoemen de technische OpenDEI capabilities naar technische stelselfuncties zodat we alleen nog (organisatorische en technische) stelselfuncties hebben en geen capabilities meer.

Voordelen

  • We hoeven niet te definiëren wat het verschil is tussen een capability en een stelselfunctie.
  • We hoeven niet te definiëren wat een capability is.
  • Het resulterende architectuurmodel is eenvoudiger en daarmee eenvoudiger te volgen en te communiceren.

Nadelen

  • We verlaten de herkenbaarheid van OpenDEI voor organisatorische diensten. Dit nadeel is beperkt tot architecten met kennis van OpenDEI.
  • We moeten (wellicht) wel uitleggen wat de verhouding is van FDS stelsel functies ten opzichte van capabilities en building blocks in andere architecturen.
  • We kunnen in de architectuur geen gebruik maken van verschillen in betekenis tussen een capability en een stelselfunctie.

Capabilities naast stelselfuncties

  • We stellen een definitie op die duiden wat het verschil is tussen een stelselfunctie en een capability.
  • We creëren stelselfuncties als niveau onder/naast de OpenDEI Capabilities:
    • FDS Regisseur onder OpenDEI Bestuurlijk?, OpenDEI Operationeel? en OpenDEI Beheer?
    • FDS Poortwachter onder OpenDEI Operationeel?
    • FDS Marktmeester onder ?
    • FDS Helpdesk onder Beheer?
    • FDS Expertisecentrum onder ?
    • FDS Toezichthouder onder Beheer?
    • FDS Verantwoordingsfunctie onder OpenDEI Traceerbaarheid
    • FDS Catalogusfunctie onder OpenDEI Publicatie
    • FDS Monitoringsfunctie onder OpenDEI Metadata
    • FDS Notificatiefunctie onder OpenDEI Dataservices
    • FDS Terugmeldfunctie onder nieuwe capability Datakwaliteit onder Datawaarde
    • FDS Toegang(sfunctie) onder OpenDEI Identiteit, Toegang, Veiligheid en Traceerbaarheid

Voordelen

  • We handhaven de herkenbaarheid van OpenDEI voor organisatorische diensten.
  • We kunnen verschillen in betekenis toekennen aan een capability en een stelselfunctie.

Nadelen

  • De architectuurbeschrijving wordt complexer en daarmee moeilijker uit te leggen.
  • We moeten definiëren wat een capability is en uitleggen wat het verschil is met een stelselfunctie.
  • We moeten de relatie gaan leggen tussen individuele stelselfuncties en capabilities.
  • Het totaal aan stelselfuncties en capabilities levert een groter aantal te beschrijven definities op met meer niet direct zichtbare of begrijpelijke verschillen.
  • We moeten uitleggen wat de verhouding of relatie is tussen de stelselfuncties en de OpenDEI governance building blocks. Deze verhouding is voor organisatorische stelselfuncties niet eenvoudig te maken of toe te lichten.

Schrappen van verantwoording

  • We schrappen (financiële) verantwoording als capability onder datawaarde
  • We leggen in het overzicht van capabilities uit waarom we de capability niet hebben opgenomen.

Voordelen

  • De term ‘verantwoording’ kan niet meer tot verwarring met de capability ’traceerbaarheid’ leiden.
  • We maken ruimte voor een andere capability zonder het frame van 3x3 of 4x3 capabilities te hoeven aanpassen.

Nadelen

  • We hebben geen plaats om eventueel nu nog niet voorziene eigenschappen van FDS tbv de verantwoording van financiële verrekening onder te brengen.
  • De capabilities zijn enigzins minder herkenbaar als OpenDEI voor architecten met kennis van OpenDEI.

Verantwoording wordt bekostiging

  • We hernoemen (financiële) verantwoording als capability naar bekostiging

Voordelen

  • De term ‘verantwoording’ kan niet meer tot verwarring met de capability ’traceerbaarheid’ leiden.
  • ‘Bekostiging’ bestaat uit één woord en is daarmee in lijn met de overige capabilities als één woord.
  • We blijven aansluiten bij de OpenDEI indeling en het 4x3 of 3x3 frame van capabilities.

Nadelen

  • Bekostiging dekt de lading nog niet heel goed: in OpenDEI is het bedoeld als verantwoording ten behoeve van van bekostigings- of verrekeningsconstructies. Bekostiging(sconstructies) zou beter onder de organisatorische / governance capabilities vallen.
  • Bekostiging wordt als technische capability waarschijnlijk leeg: er is (vooralsnog) waarschijnlijk technisch gezien weinig af te spreken binnen FDS.

Verantwoording wordt financiële verantwoording

  • We hernoemen (financiële) verantwoording als capability naar bekostiging

Voordelen

  • De term ‘financiële verantwoording’ kan niet meer tot verwarring met de capability ’traceerbaarheid’ leiden.
  • ‘Financiële verantwoording’ blijft heel dicht bij de OpenDEI betekenis.
  • We blijven aansluiten bij de OpenDEI indeling en het 4x3 of 3x3 frame van capabilities.

Nadelen

  • ‘Financiële verantwoording’ bestaat uit twee woorden waar de overige capabilities uit één woord bestaan. Dit levert uitdagingen in de vormgeving.
  • ‘Financiële verantwoording’ wordt als technische capability waarschijnlijk leeg: er is (vooralsnog) waarschijnlijk technisch gezien weinig af te spreken binnen FDS.

Handhaven capability verantwoording

  • We handhaven de naam ‘verantwoording’
  • We lichten in de text duidelijk toe dat dit ‘financiële verantwoording betreft’

Voordelen

  • We blijven aansluiten bij de OpenDEI indeling en het 4x3 of 3x3 frame van capabilities.

Nadelen

  • We dienen bij herhaling en in bij de weergave van de set capabilities moeten blijven uitleggen wat het verschil is met ’traceerbaarheid’.
  • ‘Financiële verantwoording’ wordt als technische capability waarschijnlijk leeg: er is (vooralsnog) waarschijnlijk technisch gezien weinig af te spreken binnen FDS.

Kwaliteit toevoegen

  • We beschrijven kwaliteitsaspecten en kwaliteitsverbeteringsintiatieven zoals terugmelding onder een nieuwe capability Kwaliteit onder Datawaarde.
  • De capability metadata beschrijft het ontsluiten van kwaliteitskenmerken.

Voordelen

  • Dit creeert een goed uit te leggen en prominente plek voor datakwaliteit en servicekwaliteit in het OpenDEI model.

Nadelen

Verwijs kwaliteit vanuit metadata

  • We verwijzen vanuit de capability metadata (via het ontsluiten van kwaliteitskenmerken) naar content met betrekking tot kwaliteit binnen het FDS.

Voordelen

  • We blijven aansluiten bij de OpenDEI indeling en het 4x3 of 3x3 frame van capabilities.

Nadelen

  • We een binnen het FDS belangrijk onderwerp van datakwaliteit enigszins buiten ons architectuurmodel.

Waardediensten toevoegen

  • We voegen onder datawaarde de capability Waardediensten toe tbv dssc ‘value added diensten’.

Voordelen

  • ‘Waardediensten’ bestaat uit één woord en is daarmee in lijn met de overige capabilities als één woord.

Nadelen

  • ‘Waardediensten’ is een enigszins ‘gekunstelde’ vertaling voor ‘value added services’.
  • We doorbreken het 4x3 of 3x3 frame van capabilities (eventueel te mitigeren met We schrappen capability verantwoording).
  • Hoe ‘value added services’ te concretiseren is naar afspraken en standaarden binnen FDS is nog niet helder. Daarmee is ook nog niet duidelijk wat we zouden willen beschrijven.

Waardetoevoegende diensten toevoegen

  • We voegen onder datawaarde de capability Waardetoevoegende diensten toe tbv dssc ‘value added diensten’.

Voordelen

  • ‘Waardetoevoegende diensten’ blijft dicht bij het oorspronkelijke ‘value added services’.

Nadelen

  • ‘Waardetoevoegende diensten’ is een relatief lang en bestaat uit twee woorden. Dit levert uitdagingen in de vormgeving.
  • We doorbreken het 4x3 of 3x3 frame van capabilities (eventueel te mitigeren met We schrappen capability verantwoording).
  • Hoe ‘value added services’ te concretiseren is naar afspraken en standaarden binnen FDS is nog niet helder. Daarmee is ook nog niet duidelijk wat we zouden willen beschrijven.

Value added services onder dataservices

  • We beschrijven ‘value added services’ onder ‘dataservices’ onder interoperabiliteit voor zover we daar duidelijkheid over hebben. We kunnen altijd nog op een later moment deze beschrijvingen lostrekken en verplaatsen naar een eigen capability.

Voordelen

  • We blijven aansluiten bij de OpenDEI indeling en het 4x3 of 3x3 frame van capabilities.

Nadelen

  • De kern van ‘value added services’ heeft geen betrekking op interoperabiliteit, maar het toevoegen van waarde aan bestaande gegevens en staat daarmee in de verkeerde kolom.
  • Als we op een later moment ‘value added services’ toch los willen trekken leidt tot aanpassingen in het hoofdmodel.

Verantwoording onder vertrouwen

  • We voegen ‘verantwoording’ toe onder ‘vertrouwen’. Dit betreft vertrouwen in de zin van onderbouwing van registratie, niet (financiële) verantwoording zoals opgenomen in OpenDEI.

Voordelen

  • We vergroten de herkenbaarheid van het belang van verantwoording als onderdeel van het vertrouwensraamwerk.

Nadelen

  • Verschillende aspecten van verantwoording en de daarbij horende afspraken en standaarden zijn al goed te plaatsen onder ’traceerbaarheid’, ‘identiteit’, ’toegang’ en ‘veiligheid’. Dit leidt tot dubbeling van benoeming van aspecten.

Verantwoording niet opnemen

  • We voegen ‘verantwoording’ niet toe als capability. Om het belang te onderstrepen kunnen we eventueel een thematische (overzichts)beschrijving opnemen. Daarin zouden we dan toelichten in welke onderdelen verantwoording uiteenvalt en onder welke capabilities / stelselfuncties dat is beschreven.

Voordelen

  • We krijgen geen (minder) dubbele beschrijving van standaarden en afspraken met betrekking tot verantwoording.

Nadelen

  • Verantwoording als belangrijk onderdeel van FDS is niet direct herkenbaar in het functiemodel.

Links

4 - 00003 Werkomgeving voor ontwikkeling

Besluit voor de inrichting van de werkomgeving voor ontwikkeling gebaseerd op Git, Markdown, produceren van de website en meer

Context en probleemstelling

Gegeven de context van de Realisatie van de Interbestuurlijke Datastrategie en de aanpak daarvan, dient het programma invulling te geven aan het aanjagen van de ontwikkelingen, verbinding en samenwerking tot stand te brengen en te bevorderen en partijen over ketens heen bij elkaar te brengen. Dat is nogal een ambitie.

Wat is hiervoor nodig? Wat is hier een goede invulling van? Welke voorzieningen dienen er te zijn om dit allemaal tot stand te brengen?

Beslissingsfactoren

Overwogen opties

Besluit

In het federatief datastelsel faciliteren wij samenwerking en besluitvorming. Dat is gebaat bij of is zelfs alleen mogelijk door open te werken.

  • Wij werken open
  • Wij werken community gedreven
  • Wij verbinden
  • Wij nemen faciliterend initiatief

Om al deze stellingen goed te kunnen ondersteunen, is tooling nodig om samenwerking goed mogelijk te maken. Dat is vooral tooling ter ondersteuning van open communities. Daarom kijken we hiervoor naar de ervaringen van open source werken. Een open source community onderkent vier communicatie vormen / kanalen:

  1. Publicatie -> de landingsplaats voor iedereen en formele(re) communicatie van binnen naar buiten en met elkaar
  2. Interactie -> Chat & Online video conferencing; korte, vluchtige en toegankelijke communicatie
  3. Documenten -> onderwerpen waar samengewerkt wordt in documenten, waar bijdragen voor iedereen geleverd moeten kunnen worden
  4. Issue tracking -> vragen, opmerkingen, suggesties, inhoudelijke discussies en vooral de opvolging daarvan

Wij kiezen graag voor best of breed tools, welke dan wél zoveel mogelijk geïntegreerd werken en toegankelijk zijn. Aangezien wij community gedreven zijn en faciliterend initiatief nemen, maken wij de werkomgeving beter, werkend en tot een prettige werkervaring voor zoveel mogelijk mensen. Vanaf het begin zal dat nog niet helemaal zo beschikbaar zijn, maar daar werken we wel actief aan!

Community tools

Voor Publicatie gebruiken we Pleio én een eigen website:

Voor de publicatie is het onhandig om twee locaties aan te bieden. Dit is een open punt dat nog opgelost moet worden.

Voor Documenten gebruiken we Markdown met Git en deze beheren we in GitLab. Voor de content van deze website kiezen we voor gitlab.com/datastelsel.nl/federatief/website. Er zullen meer (git) repositories bijkomen en dit is nog open voor contributies.

[nog onder discussie] Voor Chat gebruiken we Mattermost: digilab.overheid.nl/chat/fds. Intern is MS Teams (nog?) veelgebruikt.

Voor Issue tracking hebben we (nog) geen oplossing gekozen.

Positieve gevolgen

  • …

Negatieve Consequences

  • …

Pros en Cons van de oplossingen

Microsoft 365

// TODO …

Cons:

  • Gesloten omgeving
  • Gesloten en betaalde tools (Microsoft Office Suite)
  • Amerikaanse cloud omgeving
  • Microsoft betrokkenheid

Google Workspace

// TODO …

Cons:

  • Gesloten omgeving
  • Gesloten en betaalde tools (Google Docs)
  • Amerikaanse cloud omgeving
  • Google betrokkenheid

The Good Cloud

// TODO …

Pros:

  • Europese cloud omgeving

Cons:

  • Gesloten omgeving
  • Gesloten en betaalde tools (Libre Office?)

Pleio

// TODO …

Pros:

  • Nederlandse cloud omgeving

Cons:

Markdown met Git

Bij de ontwikkeling van content, het zij op internet, het zij in documenten, is er behoefte aan opmaak. Opmaak in Microsoft Word is specifiek en direct afhankelijk van de tool MS Word. Op internet is de afhankelijkheid naar een tool er niet. Hoogstens van de HTML (+ CSS + JavaScript) standaarden voor visualisatie mogelijkheden.

Om voor de ontwikkeling van content op internet niet afhankelijk te zijn van technische experts die HTML+ kunnen schrijven, wordt er al lang gezocht naar manieren om met ‘pseudo codes’ opmaak aan te geven in platte tekst. Wikitekst, zoals in de NORA Wiki, is daar een voorbeeld van. Het vroegere Wordperfect had daar ook mogelijkheden voor. Voor software documentatie is Markdown de de facto standaard.

Markdown is een vrij eenvoudige specificatie van speciale codes die opmaak betekenis hebben. Door een conversiestap van bron (source) document naar HTML kan een mooie HTML website gepubliceerd worden. Doordat Markdown redelijk gestandaardiseerd is, zijn er vele (😳) tools beschikbaar die een website kunnen genereren. Hier is enorme keuze om een geschikte tool te vinden afhankelijk van de situatie.

Doordat Markdown bestanden platte tekst bestanden zijn, is versiebeheer mbv Git makkelijk, logisch en veel toegepast. Daarom is dit ook een prettige oplossing voor software developers documentatie. Tools als GitHub en GitLab hebben standaard ook ondersteuning voor Markdown incl. presentatie als HTML.

  • Goed, omdat Markdown eenvoudige codes gebruikt, zodat ook minder-technische mensen er mee uit de voeten kunnen (zie onze Docs/Markdown)
  • Goed, omdat Markdown redelijk gestandaardiseerd is
  • Goed, omdat versiebeheer per Markdown bestand zeer mogelijk is mbv Git
  • Goed, omdat versiebeheer over een collectie Markdown bestanden ook zeer mogelijk is door de toepassing van Git
  • Goed, omdat de brondocumenten in Markdown echt ontkoppeld zijn van de tool voor publicatie in HTML
  • Slecht, omdat de brondocumenten op enige afstand kunnen staan door de ontkoppeling met de publicatie tool
  • Slecht, omdat het versiebeheer geen onderdeel is van Markdown en extra toegevoegd moet worden. Git is daarvoor zeer geschikt … maar ook zo uitgebreid, dat minder-technische mensen daar moeite mee hebben. Dit verhoogt de barrière voor minder-technische mensen om Markdown (plus Git) te gebruiken
  • Vergelijkbaar met Wikitekst, omdat het platte tekst is waarin met codes opmaak wordt geproduceerd

GitHub

// TODO …

Pros:

  • Wel primaire oplossing voor de ontwikkeling van open source producten

Cons:

  • Zelf geen open source oplossing

GitLab

// TODO …

Pros:

  • In de basis zelf een open source oplossing
  • GitLab.com is secundaire oplossing voor de ontwikkeling van open source producten
  • GitLab is ook zelf te hosten, maar dan is externe user management ons probleem

Cons:

  • GitLab is ook zelf te hosten, maar dan is externe user management ons probleem

NORA Wiki

Een wiki is een manier om online content te publiceren én tegelijk dat te beheren met meerdere mensen. Het biedt de mogelijkheid om door content te bladeren, te zoeken en links tussen pagina’s te maken. Een ‘What You See Is What You Get’ (WYSIWYG) editor ondersteunt niet-technische gebruikers. Dit is waar Wikipedia mee ontstaan en groot geworden is.

De Nederlandse Overheids Referentie Architectuur, NORA, maakt gebruik van dezelfde technologie als Wikipedia: Mediawiki. Het doel is vergelijkbaar als met Wikipedia, namelijk dat het beheer van content eenvoudig is en door iedereen gedaan kan worden.

  • Goed, omdat gepubliceerde content en het wijzigen van content dicht bij elkaar staan en te vinden zijn
  • Goed, omdat niet-technische gebruikers gemakkelijk kunnen bijdragen (na aanmaken van een account, dat zelfstandig gedaan kan worden)
  • Slecht, omdat versiebeheer per pagina niet zo duidelijk is
  • Slecht, omdat versiebeheer van meerdere en samenhangende pagina’s eigenlijk niet goed ondersteund worden (er zijn wel wat mogelijkheden … maar allemaal suboptimaal)
  • Vergelijkbaar met Markdown, omdat het onderliggende formaat waarmee een wiki werkt, ondanks de WYSIWYG editor, gebaseerd is op ‘wikitekst’. Dat is de facto standaard van Mediawiki en lijkt op Markdown. Wikitekst is minder gestandaardiseerd dan Markdown en alleen (in deze vorm) ondersteund door Mediawiki.

Static website

Voor het beschikbaar maken van de static website (zie ook Markdown met Git) is een (host)naam, een URL nodig. Wat zou een goede en toekomstbestendige naam zijn? De volgende alternatieven zijn overwogen.

  • datastelsel.nl
    • het doel waar we naartoe werken, het Nederlandse datastelsel (💪)
    • doel klopt, maar daar zijn we nog niet
    • branding is het nog te vroeg voor …
  • ontwikkeling.datastelsel.nl
    • de ontwikkeling van het Nederlandse Datastelsel
    • Realisatie IBDS zou dan te vinden moeten zijn onder datastrategie.datastelsel.nl?
    • past bij het einddoel
    • ontwikkeling is geen herkenbare brand op dit moment
  • federatief.datastelsel.nl <- keuze
    • de ontwikkeling van het Nederlandse federatief datastelsel
    • Realisatie IBDS zou dan te vinden kunnen zijn onder datastrategie.datastelsel.nl?
    • huidige branding blijft gelijk !!
  • ontwikkelingfds.nl
    • de ontwikkeling van FDS, het federatief datastelsel
    • helemaal losstaande URL … kan zowel positief als negatief gezien worden
  • overheidsdatastelsel.nl
    • het doel waar we (dan) naartoe werken, is het Nederlandse Overheids datastelsel … maar dat is niet zo. Ja, het is / begint bij overheid, maar het einddoel is weldegelijk overstijgend cq te kunnen verbinden met andere stelsels
  • ontwikkeling.overheidsdatastelsel.nl
    • combinatie van bovenstaande … met combinatie van die afwegingen
  • datastelsel.overheid.nl
    • het doel waar we naartoe werken, het Nederlandse Overheids datastelsel
    • onder overheid.nl is goed
    • maar het einddoel is niet alleen overheid …
  • ontwikkeling.datastelsel.overheid.nl
    • bovenstaande, maar dan de ontwikkeling daarvan datastelsel
  • federatiefdatastelsel.realisatieibds.nl
    • FDS als onderdeel van Realisatie IBDS (onder eigen URL)
    • Realisatie IBDS zou dan te vinden moeten zijn onder realisatieibds.nl
    • Tja … wel heel andere en losstaande richting …

Links

5 - 00001 Basisstructuur

We gebruiken de Soft Infrastructure Building Blocks van OpenDEI als basis voor onze structuur

Context en probleemstelling

Als Nederlands federatief datastelsel hebben we de Strategie van samenwerken. Dat betekent dat we verbinding nodig hebben en moeten ondersteunen. Het helpt als daar een herkenbare en eenvoudige structuur aan ten grondslag ligt. Dit wordt ook wel ‘structure follow strategy’ genoemd. Er zijn echter vele architecturen, architectuur frameworks en … fêtes rondom architecturen. Wat is wijs? Wat is herkenbaar? Wat zou grote verschillen kunnen overbruggen? En hoe blijven we buiten of ontwijken we ‘architectuur fêtes’?

Beslissingsfactoren

Overwogen opties

Besluit

We kiezen voor een Capabilities model gebaseerd op het OpenDEI building blocks model gecombineerd met een vijf lagen model gebaseerd op de NORA vijf lagen model en Archimate. We kiezen voor een Nederlandse vertaling en eigen bewoordingen. Tegelijk zorgen we ervoor dat de verbinding met de oorspronkelijke modellen heel zichtbaar en herkenbaar blijft.

Basisstructuur / Raamwerk

Het raamwerk / de basisstructuur wordt in het raamwerk voor ontwikkeling in samenwerking verder uitgebreid beschreven.

De basisstructuur is de ‘kapstok’ om alle ontwikkelingen en aspecten van het federatief datastelsel aan ‘op te hangen’. Het biedt een ’landkaart’ om aan te geven waar een bepaalde functionaliteit, functie, techniek zich bevindt. De verbinding naar omliggende zaken is als volgt te zien:

Basisstructuur als kapstok

Positieve gevolgen

  • De OpenDEI building blocks, bij ons capabilities genoemd, geven herkenbaarheid en verbinding naar Europese ontwikkelingen en initiatieven.
  • De capabilities bieden ook verbinding naar capabilities in andere Nederlandse initiatieven, aangezien ook zij ‘capabilities’ gebruiken. Hoe de verschillende capabilities zich tot elkaar verhouden kan nog wel verschillen en/of uitzoekwerk betekenen. Wij denken dat de OpenDEI building blocks bruikbare capabilities zijn.
  • De vijf lagen van ons model zijn duidelijk te verbinden met de vijf lagen van NORA en Archimate. Daarmee worden veel verbindingen duidelijk en eenvoudig.
  • Verbindingen zijn met deze basisstructuur eenvoudig, duidelijk en herkenbaar. Dat geeft de mogelijkheid om met vele initiatieven om het federatief datastelsel heen te verbinden. Dat sluit aan bij onze Strategie van samenwerken

Negatieve Consequences

  • We introduceren een nieuw raamwerk (framework) en dat zal daarom op moment van introductie nergens helemaal mee aansluiten. Dit vergt tijd en werk om verbindingen te maken en per verbinding te onderzoeken en aan te geven hoe relaties precies gemaakt kunnen worden. (We denken wel dat ons model zo herkenbaar en eenvoudig is, dat dit niet echt tot problemen zal leiden)

Pros en Cons van de oplossingen

Design Principles for Data Spaces by OpenDEI

De Position Paper: Design Principles for Data Spaces by the OpenDEI Workforce heeft al veel voorwerk en uitzoekwerk gedaan over datastelsels, oftewel Data Spaces. Dit raamwerk is dan ook al veel gebruikt voor Europees gerelateerde ontwikkelingen en initiatieven. Ook de samenwerking en vergelijk met IDSA en GAIA-X worden hierin benoemd.

Voor het federatief datastelsel is de vergelijking door Geonovum van groot belang en ook hier worden de ‘building blocks’ van OpenDEI gebruikt. In de Geonovum Verkenning Dataspaces wordt het OpenDEI model als ‘conceptueel model’ gebruikt voor de ‘quick-scan (zie H2.4).

OpenDEI building blocks

Voor de vergelijking van het federatief datastelsel helpt dit model vooral in de verbinding naar Europa en Europese ontwikkelingen en initiatieven. Aangezien dit een belangrijk gebied is voor het federatief datastelsel, is ook dit moment belangrijk.

NORA Vijflaagsmodel

In de NORA, de Nederlandse Overheid Referentie Architectuur, wordt het Vijflaagsmodel beschreven. Dit is de basis van veel overheidsarchitecturen en daarom erg herkenbaar. Tegelijk is het afwijkend van Archimate, welke ook veel gebruikt wordt (ook buiten de overheid).

NORA Vijflaagsmodel

Archimate

Archimate is een architectuur taal. Een visuele taal met een rijke set aan gegronde en doordachte mogelijkheden. Dit is een veelgebruikte basis voor architecturen, ook als deze ’niet-Archimate’ heten. De rijkheid van Archimate en volledigheid biedt veel mogelijkheden. Tegelijk is dat wellicht de zwakte; er is zoveel mogelijk … dat overzicht verloren gaat aan eigen succes.

Om vanuit het federatief datastelsel wel gemakkelijk verbinding te maken vanuit architecturen die (direct of indirect) gebaseerd zijn op Archimate, hebben wij in de basisstructuur daar duidelijk verbinding en overeenkomst gemaakt in de lagen.

Archimate 3.1 Full Framework

Capabilities

Veel architecturen kennen het woord ‘capability’, ‘bekwaamheid’, iets dat ‘het moet kunnen’. Dit komt voor in zowel TOGAF als in de NORA.

Daarnaast wordt bouwblok (building block) veel gebruikt in architecturen. Soms zijn het synoniemen, soms duidt het op verschillende zaken. Dit is (helaas) niet altijd duidelijk. Dat komt ook doordat het in verschillende architectuur frameworks verschillend gebruikt wordt.

In de basisstructuur / raamwork wordt ‘capability’ vooral op de bovenste laag van het vijflagen model gezien. Dit komt overeen met hoe capabilities in Archimate gebruikt worden.

6 - 00002 Gebruik van Markdown Decision Records in Git

Voor het vastleggen en ondersteunen van discussies leggen we besluiten en voorgenomen besluiten vast als ‘decision records’. Dit is onze eigen afleiding van ‘Architecture Decision Records’.

Context en probleemstelling

In het algemeen zijn er veel termen, woorden, begrippen, principes, concepten die niet eenduidig vastliggen. Om discussies te kunnen beslechten, vast te leggen en (ook) later op terug te kunnen komen en naar te verwijzen, is een methode nodig om dat vast te leggen. Wat is een goede methode? Hoe en waar leggen we dat dan vast?

Overwogen opties

Besluit

We maken gebruik van Decision Records volgens onze eigen, in het Nederlands vertaalde template decision-record.md. We hanteren daarbij het gebruik van Markdown aangezien dat (redelijk) mensvriendelijk is en tegelijkertijd machine leesbaar. We maken daarbij gebruik van Git versiebeheer, aangezien dit subliem is en de facto standaard.

Decision records hebben een uniek, oplopend nummer. De volgorde is niet van belang. Het is een nummer uit alleen cijfers en uit vijf karakters: 00000

Decision records doorlopen het door Log4brains bedachte proces:

Decision record workflow

flowchart LR
  s1([Concept])
  s2([Voorstel])
  s3([Geaccepteerd])
  s4([Verouderd])
  s5([Vervangen])
  s6([Verworpen])
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s3 --> s5
  s2 --> s6

Legenda labels

Voor wie nog minder bekend is met het gebruik van labels en Decision records, lichten we hieronder toe wat de status van een pagina is. De eerste drie labels zullen in de huidige fase van eht FDS het meest voorkomen.

  • Concept: dit betekent dat de pagina informatie biedt die in concept is. Kortom, deze informatie behoeft juist nog input en expertise van een ieder die zich daartoe geroepen voelt. Een draft kan al meerdere versienummers hebben, omdat ook de draft in ontwikkeling kan zijn.

  • Voorstel: dit betekent dat het stuk is voorgesteld aan het Tactisch Overleg van het FDS en is besproken. Hierdoor heeft er een inhoudelijke discussie heeft kunnen plaatsvinden met eventuele inhoudelijke aanvullingen en/of wijzigingen. Deze feedback kan ook leiden tot een nieuwere versie van het voorstel OF, afhankelijk van de feedback, gaat weer terug naar de conceptfase als het gaat om grote vraagstukken. Nieuwere versies kunnen dan ten alle tijden op dit platform gevonden worden.

Inhoudelijke verwerking van expertise kan plaatsvinden, maar kent een lagere frequentie dan de pagina’s die in concept zijn.

  • Definitief: dit betekent dat de content afgerond is en voor nu geen verdere aanvulling behoeft. Vragen stellen is altijd mogelijk, maar deze informatie is al door meerdere iteratieslagen heen gegaan waarbij er voldoende ruimte was voor inspraak vanuit de omgeving. Op dit moment is er nog weinig content formeel vastgesteld en daarmee definitief. Het wordt pas echt definitief wanneer een nog nader te bepalen stuurgroep deze status kan vaststellen.

  • Verouderd: dit betekent dat het stuk verouderde informatie bevat. Het is ooit definitief geweest (of misschien zelfs niet eens) maar het verliest relevantie. Toch kan het nuttige informatie bevatten over hoe er eerder naar zaken gekeken werd. Vaak zijn er aanleidingen of andere beslisnotities die de reden zijn dat informatie als verouderd aangeduid kan worden. Als dat zo is, dan wordt dat boven in de pagina toegevoegd. Verouderde informatie kan nog steeds actueel geldend zijn, maar voor nieuwe oplossingen niet meer relevant. Als er echt vervangende oplossingen zijn, dan is de status Superseded/Vervangen passender.

  • Vervangen: dit betekent dat het stuk vervangen is door andere beslisnotities en keuzes. Dit is niet alleen verouderd (zie vorige status) maar ook nog eens opgevolgd door een nieuwe versie of vervolg beslisnotitie. Deze status betekent dat de opvolgende beslisnotities de actueel te volgen richtingen zijn en dat dit stuk komt te vervallen. Het is alleen nog terug te vinden als archiefstuk. Dit in tegenstelling tot de status Deprecated/Verouderd welke nog steeds geldend kan zijn, maar voor nieuwe oplossingen niet meer relevant.

Decision records hebben de volgende indeling, naar aanleiding en geïnspireerd van de overige overwogen opties.

  • Context en probleemstelling
  • Beslissingsfactoren
  • Overwogen opties
  • Besluit
    • Positieve gevolgen
    • Negatieve Consequences
  • Pros en Cons van de oplossingen
    • Optie 1
    • Optie 2
  • Links (naar andere decision records)

Deze template is als Markdown template beschikbaar in de repository: archetypes/decision-record.md

Het gebruik van Markdown betekent dat de template er ongeveer zo uit zal zien:

## Context en probleemstelling

## Beslissingsfactoren

## Overwogen opties

## Besluit

### Positieve gevolgen

### Negatieve Consequences

## Pros en Cons van de oplossingen

### Optie 1

### Optie 2

## Links

Positieve gevolgen

  • Impliciete aannames zouden expliciet gemaakt moeten zijn Ontwerp documentatie is belangrijk voor mensen om besluiten later te kunnen begrijpen. Zie ook A rational design process: How and why to fake it.
  • Markdown is klein, compact en eenvoudig en tegelijk rijk aan mogelijkheden
  • Bovenstaande structuur is eenvoudig, krachtig en faciliteert gebruik en onderhoud
  • Oorspronkelijke basis hiervan, namelijk Markdown Architecture Decision Records (MADR), is een actieve en sterk groeiende methode van vastlegging van besluiten
  • Het proces (workflow) is eenvoudig en duidelijk
  • Een nieuw decision record heeft status draft, wat de mogelijkheid biedt voor anderen om suggesties te doen en bijdragen te leveren
  • Markdown decision records hebben het bestandsformaat NNNNN-decision-naam
  • Decision records zijn met hun nummer te refereren … hoewel met naam meer context geeft (en dus beter is / voorkeur heeft)

Pros en Cons van de oplossingen

NORA Wiki

Een wiki is een manier om online content te publiceren én tegelijk dat te beheren met meerdere mensen. Het biedt de mogelijkheid om door content te bladeren, te zoeken en links tussen pagina’s te maken. Een ‘What You See Is What You Get’ (WYSIWYG) editor ondersteunt niet-technische gebruikers. Dit is waar Wikipedia mee ontstaan en groot geworden is.

De Nederlandse Overheids Referentie Architectuur, NORA, maakt gebruik van dezelfde technologie als Wikipedia: Mediawiki. Het doel is vergelijkbaar als met Wikipedia, namelijk dat het beheer van content eenvoudig is en door iedereen gedaan kan worden.

  • Goed, omdat gepubliceerde content en het wijzigen van content dicht bij elkaar staan en te vinden zijn
  • Goed, omdat niet-technische gebruikers gemakkelijk kunnen bijdragen (na aanmaken van een account, dat zelfstandig gedaan kan worden)
  • Slecht, omdat versiebeheer per pagina niet zo duidelijk is
  • Slecht, omdat versiebeheer van meerdere en samenhangende pagina’s eigenlijk niet goed ondersteund worden (er zijn wel wat mogelijkheden … maar allemaal suboptimaal)
  • Vergelijkbaar met Markdown, omdat het onderliggende formaat waarmee een wiki werkt, ondanks de WYSIWYG editor, gebaseerd is op ‘wikitekst’. Dat is de facto standaard van Mediawiki en lijkt op Markdown. Wikitekst is minder gestandaardiseerd dan Markdown en alleen (in deze vorm) ondersteund door Mediawiki.

Markdown in enige vorm

Bij de ontwikkeling van content, het zij op internet, het zij in documenten, is er behoefte aan opmaak. Opmaak in Microsoft Word is specifiek en direct afhankelijk van de tool MS Word. Op internet is de afhankelijkheid naar een tool er niet. Hoogstens van de HTML (+ CSS + JavaScript) standaarden voor visualisatie mogelijkheden.

Om voor de ontwikkeling van content op internet niet afhankelijk te zijn van technische experts die HTML+ kunnen schrijven, wordt er al lang gezocht naar manieren om met ‘pseudo codes’ opmaak aan te geven in platte tekst. Wikitekst, zoals in de NORA Wiki, is daar een voorbeeld van. Het vroegere Wordperfect had daar ook mogelijkheden voor. Voor software documentatie is Markdown de de facto standaard.

Markdown is een vrij eenvoudige specificatie van speciale codes die opmaak betekenis hebben. Door een conversiestap van bron (source) document naar HTML kan een mooie HTML website gepubliceerd worden. Doordat Markdown redelijk gestandaardiseerd is, zijn er vele (😳) tools beschikbaar die een website kunnen genereren. Hier is enorme keuze om een geschikte tool te vinden afhankelijk van de situatie.

Doordat Markdown bestanden platte tekst bestanden zijn, is versiebeheer mbv Git makkelijk, logisch en veel toegepast. Daarom is dit ook een prettige oplossing voor software developers documentatie. Tools als GitHub en GitLab hebben standaard ook ondersteuning voor Markdown incl. presentatie als HTML.

  • Goed, omdat Markdown eenvoudige codes gebruikt, zodat ook minder-technische mensen er mee uit de voeten kunnen
  • Goed, omdat Markdown redelijk gestandaardiseerd is
  • Goed, omdat versiebeheer per Markdown bestand zeer mogelijk is mbv Git
  • Goed, omdat versiebeheer over een collectie Markdown bestanden ook zeer mogelijk is door de toepassing van Git
  • Goed, omdat de brondocumenten in Markdown echt ontkoppeld zijn van de tool voor publicatie in HTML
  • Slecht, omdat de brondocumenten op enige afstand kunnen staan door de ontkoppeling met de publicatie tool
  • Slecht, omdat het versiebeheer geen onderdeel is van Markdown en extra toegevoegd moet worden. Git is daarvoor zeer geschikt … maar ook zo uitgebreid, dat minder-technische mensen daar moeite mee hebben. Dit verhoogt de barrière voor minder-technische mensen om Markdown (plus Git) te gebruiken
  • Vergelijkbaar met Wikitekst, omdat het platte tekst is waarin met codes opmaak wordt geproduceerd
  • […]