Scope van het Digitaal Stelsel Gebouwde Omgeving
In de gebouwde omgeving wordt in ketens waarde gecreëerd door en voor diverse partijen. Daartoe voeren (keten)partijen activiteiten uit in bedrijfsprocessen (zowel intern als tussen ketenpartijen), gebruikmakend van bedrijfsspecifieke applicaties. Om het doel van de applicaties te bereiken wordt in deze applicaties data toegepast. Mogelijk wordt de toegepaste data weer beschikbaar gesteld voor andere toepassingen. Onderliggend aan deze bedrijfsprocessen (applicaties) vinden transacties plaats waarbij data wordt gedeeld naar applicaties.
Voorbeelden van waardecreatie in de gebouwde omgeving op basis van bedrijfsprocessen, transacties en gebruikte data:
Tussen partijen zoals opdrachtgever en architect vindt een ‘opdrachtverstrekking’ transactie plaats waarbij (onder andere) een offerte en een opdrachtbevestiging wordt gedeeld.
Tussen partijen zoals ontwikkelaar en woningbouwcorporatie vindt het ‘opleveren van een woning’ plaats waarbij (onder andere) een bouwwerk dossier wordt gedeeld.
Tussen partijen zoals opdrachtgever en aannemer vindt een 'planningsdata' transactie plaats waarbij (onder andere) de actuele leveringstijden wordt gedeeld.
Via het DSGO wordt gezorgd voor makkelijkere, toegang, ontsluiting en beschikbaarheid van en tot data die nodig is bij het voeren van bedrijfsprocessen. Het afsprakenstelsel bestaat uit generieke afspraken en specifieke afspraken. Generieke afspraken gelden voor (de ondersteuning van) alle mogelijke datadiensten, en zijn daarmee data agnostisch (niet afhankelijk van de data die wordt gedeeld). Hiermee zijn bedrijfsprocessen, de toepassingen, de semantiek en de kwaliteit van data buiten scope van de generieke afspraken van het afsprakenstelsel.
Voordat data kan worden gedeeld, moet er invulling gegeven worden aan aspecten buiten de generieke afspraken van het DSGO. Het is de verantwoordelijkheid van een datadienstaanbieder om aanvullende afspraken over deze aspecten te maken met (potentiële) datadienstgebruikers. Het DSGO faciliteert de communicatie over deze aspecten (bijvoorbeeld, in de datadienstspecificatie moet de datadienstaanbieder definiëren wat de semantiek van de bij de datadienst betrokken data is).
Omdat het DSGO streeft om schaalbaar, breed toepasbaar en kostenefficiënt te zijn (zie Richtinggevende principes), kan het waardevol zijn om deze aanvullende afspraken te harmoniseren voor meerdere datadiensten, door deze op te nemen als specifieke afspraken in het DSGO. Hierdoor wordt het nog laagdrempeliger voor een datadienstgebruiker om vergelijkbare datadiensten, van meerdere datadienstaanbieders, te consumeren.
Specifieke afspraken gelden voor een subset van alle datadiensten, en zijn daarmee niet per definitie data agnostisch en alleen relevant voor enkele delen van de gebouwde omgeving. De context van specifieke afspraken worden altijd afgebakend voor een deel van de sector en zijn alleen van toepassing binnen de gedefinieerde context. Specifieke afspraken kunnen een bredere scope hebben dan generieke afspraken, en kunnen bijvoorbeeld afspraken bevatten over bedrijfsprocessen, de toepassingen, de semantiek en de kwaliteit van data die gedeeld wordt. Specifieke afspraken worden gemaakt op basis van concrete toepassingen uit de praktijk (zie het Change en releasemanagement proces).
In het onderstaande voorbeeld worden enkele voorbeeld bedrijfsapplicaties getoond die gebruikt worden in verschillende bedrijfsprocessen.
Multidisciplinaire aanpak
Het afsprakenstelsel is multidiscipliair van aard. Dit houdt in dat afspraken over een onderwerp, meerdere disciplines raken. Deze disciplines kunnen van commerciële, juridische, operationele, functionele, en technische aard zijn. Het BLOFT-raamwerk (geformuleerd door het Centre of Excellence for Data Sharing and Cloud (CoE-DSC) in het Data Sharing Canvas) geeft een eerste indicatie van relevante onderwerpen die onder de verschillende thema’s vallen.
Om vertrouwd en interoperabel data te delen is de samenhang van thema’s binnen deze multidisciplinaire aanpak van belang. Zo worden bijvoorbeeld juridische vereisten (e.g. bewijslast) vaak mogelijk gemaakt door een technische oplossing (e.g. onweerlegbaarheid). Of vragen sommige business requirements (e.g. zekerheid van de wederpartij) een technische/functionele oplossing (e.g. veilige authenticatie) en ontstaat er vertrouwen in andere deelnemers door gecoördineerde operationele processen (e.g. toetreding). Daarom zijn wijzigingen in het stelsel vaak complexer als ze lijken en moet de impact op meerdere disciplines afgewogen worden.