Technische inrichting

PDM is ontworpen rondom het principe van datasoevereiniteit. We maken bewust geen gebruik van zware, gesloten of cloud-afhankelijke procesmodelleringstools. De gehele technische inrichting rust op open standaarden, platte tekstbestanden (Markdown), een lokale Git-historie en een razendsnelle ontwikkelomgeving.

Dit garandeert dat de documentatie altijd 100% eigendom blijft van de organisatie, volledig offline werkt en onafhankelijk is van specifieke softwareleveranciers.

Technische inrichting in kaart

Onderstaand diagram toont de volledige lokale datastroom: van de hand van de Model Steward naar de lokale Hugo-structuur en de Git-tijdmachine, tot de publicatie op het intranet en de fysieke back-up.

graph TB
    
    MS([Model Steward]):::actor

    subgraph A[Lokale computer]
        E["Markdown Editor <br/><i>(VSCodium)</i>"]:::editor

        subgraph G[Lokale Git Repository]
            subgraph H[Hugo Projectstructuur]
                subgraph C[Content folder]
                    F["Markdown files <br/><i>(SSoT met PDM-metadata)</i>"]:::folder
                end
                
                subgraph L[Layouts folder]
                    M["Macro's & Sjablonen <br/><i>(Validatielogica & Shortcodes)</i>"]:::folder
                end

                D("Deploy / Build-proces"):::process
                P["Public folder <br/><i>(Gegenereerde HTML/CSS)</i>"]:::folder
            end
            
            GT[".git folder <br/><i>(Lokale versiehistorie & audit-trail)</i>"]:::process
        end
    end

    W["Webserver <br/><i>(Intranet / Portal)</i>"]:::external
    B["Externe USB / SSD Drive <br/><i>(Fysieke offline backup)</i>"]:::external

    %% Connecties en datastromen
    MS -->|gebruikt| E
    E -->|bewerkt direct| F
    
    F -.->|handmatige commit / snapshot| GT
    M -.->|handmatige commit / snapshot| GT
    
    F & M --> D
    MS -.-|triggert handmatig via terminal of script| D
    
    D -->|genereert projecties en documenten| P
    P -->|verstuurt / synchroniseert| W
    
    H & GT -->|"periodieke handmatige of scripted backup"| B

  style A fill:#202020,stroke:#ffffff
  style H fill:#202020,stroke:#ffffff
  style G fill:#151515,stroke:#00aa00,stroke-width:2px

De componenten ontleed

1. De Auteur-omgeving (Markdown Editor)

De Model Steward en procesanalisten werken volledig lokaal. Omdat de database van PDM uitsluitend bestaat uit platte tekstbestanden, is de keuze voor een editor volledig vrij en aan te passen aan de systeembronnen van de gebruiker.

• Editor-agnostisch (VSCodium als standaard): Er wordt bij voorkeur gekozen voor een lichte, telemetry-vrije open-source code-editor zoals VSCodium. Zolang het programma platte tekst met YAML/TOML front-matter kan opslaan, functioneert de keten direct.

• Geen database-overhead: Er is geen databaseverbinding nodig om processen te documenteren. Wijzigingen aanbrengen is een kwestie van bestanden openen, typen en opslaan.

2. De SSoT (content folder)

De map content/ binnen het Hugo-project fungeert als SSoT.

• Elk document (een Werkdomein, Proces of Processtap) is een afzonderlijk .md-bestand.

• De relationele grammatica (wie is verantwoordelijk, wat is de input/output, welke systemen worden gebruikt) wordt opgeslagen als gestructureerde metadata in de YAML- of TOML-front-matter van deze bestanden.

• Dit garandeert referentiële integriteit: een handmatige wijziging in de metadata van één stap stroomt direct door naar alle weergaven.

3. De Versiehistorie (Lokale Git Tijdmachine)

In plaats van een centrale databaseserver die wijzigingen bijhoudt, gebruikt PDM een lokale Git-repository.

• 100% Offline & Privé: Git draait volledig op de eigen machine. Er is geen cloudverbinding met platformen zoals GitHub of GitLab vereist om de geschiedenis bij te houden. Alle snapshots (commits) leven in de verborgen .git/-map op de lokale harde schijf.

• Foutloze Audit-trail: Elke wijziging aan een procesbeschrijving of metadata-veld kan met een handmatige commit van een korte omschrijving worden voorzien. Dit geeft een waterdichte, onomstotelijke geschiedenis van hoe processen door de tijd heen zijn geëvolueerd.

• Veilig Experimenteren: Analisten kunnen een aparte ‘branch’ (aftakking) aanmaken om een ingrijpende proceswijziging uit te werken, zonder dat de live-documentatie in de main-branch wordt verstoord. Voldoet de nieuwe structuur aan de eisen, dan wordt deze handmatig samengevoegd.

4. De Intelligentie (layouts folder & macro’s)

De map layouts/ bevat de PDM-intelligentie. Hier staan de Hugo-sjablonen, shortcodes en macro’s.

• Deze logica is strikt gescheiden van de content. De lay-out “leest” de metadata uit de content-bestanden en genereert ter plekke de dynamische projecties.

• Kwaliteitsvalidaties: Tijdens het compileren controleren de macro’s via handmatig ingerichte validatielogica of de ingevoerde data voldoet aan de PDM-regels. Als een processtap de Waardetoets niet doorstaat (voldoet_aan_waardetoets: false conform Regel M17), vlagt de lay-out dit direct visueel aan op de portal.

5. De Generatie (deploy / build-proces)

Zodra de Model Steward de deployment triggert (handmatig via de terminal met het simpele commando hugo, of via een lokaal script), start de compiler.

• Hugo is de snelste statische site-generator ter wereld: honderden procesbestanden worden in milliseconden verwerkt en omgezet naar een statische website in de public/ folder.

• Tijdens dit build-proces worden alle kruisrelaties gelegd en worden Mermaid-diagrammen, RACI-tabellen en werkinstructies opgebouwd op basis van de ingevoerde metadata.

6. Distributie & Fysieke Back-up

• Publicatie: De gegenereerde statische HTML-bestanden uit de public/ folder worden gesynchroniseerd naar de webserver van het intranet. Omdat de website volledig statisch is, is de hosting extreem veilig, stabiel en heeft deze geen actieve backend of database nodig op de server.

• Soevereine Fysieke Back-up: Omdat het gehele project inclusief de Git-historie als een reguliere, platte mappenstructuur leeft, is de back-up vrij van complexe export-procedures. Het periodiek kopiëren van de projectmap naar een externe USB- of SSD-drive (handmatig of via een lokaal back-upscript zoals rsync of Déjà Dup) volstaat om een 100% herstelbare, offline back-up in eigen fysiek bezit te hebben.

Voordelen van deze inrichting