bra0 / Docs / Guides / IT Systems Diagnostic
Guide

IT Systems Diagnostic Diagnostic SI

Model an application portfolio as RDF, validate it against SHACL governance rules, query findings with SPARQL. This guide uses a fictional mid-size company ("Médiplus") with deliberate weaknesses: obsolete apps, missing data owners, undocumented integrations, shadow IT. Modélisez un portefeuille applicatif en RDF, validez-le avec des règles de gouvernance SHACL, interrogez les constats en SPARQL. Ce guide utilise une ETI fictive (« Médiplus ») avec des faiblesses délibérées : applications obsolètes, propriétaires de données manquants, intégrations non documentées, shadow IT.

Prerequisites: rudof installed (github.com/rudof-project/rudof). Alternatively, use bra0 in the browser with built-in SHACL validation. No server, no account. rudof installé (github.com/rudof-project/rudof). Alternativement, utilisez bra0 dans le navigateur avec la validation SHACL intégrée. Aucun serveur, aucun compte.

What this guide produces Ce que ce guide produit

A complete IT systems audit from two text files: a Turtle model (the application portfolio) and SHACL shapes (the governance rules). The diagnostic identifies obsolescence, shadow IT, GDPR gaps, and undocumented integrations — the same categories an external auditor would check. Un audit SI complet à partir de deux fichiers texte : un modèle Turtle (le portefeuille applicatif) et des shapes SHACL (les règles de gouvernance). Le diagnostic identifie l'obsolescence, le shadow IT, les lacunes RGPD et les intégrations non documentées — les mêmes catégories qu'un auditeur externe vérifierait.

Steps Étapes

1

Model the application portfolio Modéliser le portefeuille applicatif

Each application, data store, and integration is an RDF resource with typed properties. The model uses SKOS for criticality levels and data classification, DCAT for metadata, and PROV-O for provenance. Chaque application, base de données et intégration est une ressource RDF avec des propriétés typées. Le modèle utilise SKOS pour les niveaux de criticité et la classification des données, DCAT pour les métadonnées, et PROV-O pour la provenance.

si-model.ttl (excerpt)
# An application with lifecycle and governance metadata
si:app-hr-legacy a si:Application ;
    rdfs:label "PeopleSoft HR 9.1" ;
    si:vendor       "Oracle" ;
    si:version      "9.1" ;
    si:endOfSupport "2023-06-30"^^xsd:date ;
    si:criticality  si:critical ;
    si:rto          "24h" ;
    si:rpo          "1 week" ;
    si:annualCost   "120000"^^xsd:decimal .

# A data store missing its owner (deliberate gap)
si:db-qlik-warehouse a si:DataStore ;
    rdfs:label "QlikView Data Warehouse" .
    # No si:dataOwner — GDPR Art. 30 violation
    # No si:dataClassification — compliance gap
    # No si:backupFrequency — data loss risk

The full model contains 7 applications, 5 data stores, 3 integrations, and 7 business capabilities. All in a single .ttl file, versionable with Git. Le modèle complet contient 7 applications, 5 bases de données, 3 intégrations et 7 capacités métier. Le tout dans un seul fichier .ttl, versionnable avec Git.

2

Define governance rules as SHACL shapes Définir les règles de gouvernance en shapes SHACL

Each rule encodes one check an auditor would perform. A SHACL violation = a finding in the audit report. Chaque règle encode une vérification qu'un auditeur effectuerait. Une violation SHACL = un constat dans le rapport d'audit.

RuleTargetCheckCategory
R1ApplicationEnd-of-support date requiredDate de fin de support requiseObsolescence
R2ApplicationMaintainer team requiredÉquipe de maintenance requiseShadow IT
R3ApplicationRTO and RPO declaredRTO et RPO déclarésResilience
R4DataStoreData owner assignedPropriétaire de données assignéGDPR
R5DataStoreData classification declaredClassification de données déclaréeCompliance
R6DataStoreBackup frequency declaredFréquence de sauvegarde déclaréeResilience
R7IntegrationIntegration documentedIntégration documentéeGovernance
diagnostic-rules.ttl (Rule 4)
si:Rule-DataOwner-Required a sh:NodeShape ;
    rdfs:label "R4: Data owner required"@en ;
    sh:targetClass si:DataStore ;
    sh:property [
        sh:path si:dataOwner ;
        sh:minCount 1 ;
        sh:message "DATA STORE HAS NO OWNER — GDPR accountability gap."
    ] .
3

Run the validation Exécuter la validation

One command. The model is validated against all 7 rules. Each violation is a structured finding with the offending resource, the violated shape, and the diagnostic message. Une commande. Le modèle est validé contre les 7 règles. Chaque violation est un constat structuré avec la ressource en cause, la shape violée et le message de diagnostic.

Terminal
$ rudof shacl-validate \
    -s diagnostic-rules.ttl \
    si-model.ttl

# Output: 14 violations across 5 categories
# R1: 0 violations (all apps have EOS dates)
# R2: 1 violation  (Shopify — no maintainer)
# R3: 2 violations (Shopify, Confluence — no RTO/RPO)
# R4: 3 violations (QlikView DW, Excel Pricing, PeopleSoft DB)
# R5: 2 violations (QlikView DW, Excel Pricing)
# R6: 2 violations (QlikView DW, Excel Pricing)
# R7: 2 violations (SAP↔PeopleSoft, TIBCO→QlikView)
4

Query specific findings Interroger des constats spécifiques

SPARQL queries extract structured findings from the model. Each query corresponds to one section of an audit report. Les requêtes SPARQL extraient des constats structurés du modèle. Chaque requête correspond à une section d'un rapport d'audit.

01-obsolete-apps.rq
PREFIX si: <urn:demo:si#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

# Applications past end-of-support
SELECT ?app ?label ?vendor ?endOfSupport
WHERE {
    ?app a si:Application ;
         rdfs:label ?label ;
         si:endOfSupport ?endOfSupport .
    FILTER (?endOfSupport < "2026-04-12"^^xsd:date)
}
ORDER BY ?endOfSupport

9 queries cover: obsolete apps, single points of failure, data governance gaps, shadow IT, undocumented integrations, disaster recovery risk, cost overview, prescriptions, and remediation impact. 9 requêtes couvrent : applications obsolètes, points uniques de défaillance, lacunes de gouvernance des données, shadow IT, intégrations non documentées, risque de reprise, vue des coûts, prescriptions et impact de remédiation.

5

Generate prioritized prescriptions Générer des prescriptions priorisées

A dedicated SPARQL query produces a prioritized remediation plan directly from the model — structured by criticality (P1 Critical, P2 High, P3 Medium, P4 Low), with the affected entity, the recommended action, and the rationale. Une requête SPARQL dédiée produit un plan de remédiation priorisé directement depuis le modèle — structuré par criticité (P1 Critique, P2 Haut, P3 Moyen, P4 Bas), avec l'entité concernée, l'action recommandée et la justification.

08-prescriptions.rq (excerpt)
# P1 — Critical: apps past EOS on infra without failover
(1 "CRITICAL" si:app-tibco "TIBCO BusinessWorks 5.x"
 "DECOMMISSION: migrate integrations to REST API or Apache Camel"
 "EOS 2021, RTO 72h, zero users, 65K EUR/yr wasted, no failover")

# P2 — High: data governance gaps with personal data
(2 "HIGH" si:db-peoplesoft "PeopleSoft Oracle DB"
 "ASSIGN DATA OWNER: designate HR Team (GDPR Art. 30)"
 "Personal data store without data owner — regulatory liability")

What this demonstrates Ce que cela démontre

The diagnostic relies on three capabilities from bra0's 3-layer architecture: Le diagnostic repose sur trois capacités de l'architecture 3 couches de bra0 :

Semantic Layer — the application portfolio is modeled as OWL/RDF with SKOS vocabularies for criticality and classification. Concepts have formal definitions, not spreadsheet columns. Semantic Layer — le portefeuille applicatif est modélisé en OWL/RDF avec des vocabulaires SKOS pour la criticité et la classification. Les concepts ont des définitions formelles, pas des colonnes de tableur.

Control Plane — governance rules are SHACL shapes, not checklists. They are machine-executable, versionable, and produce structured violation reports. Control Plane — les règles de gouvernance sont des shapes SHACL, pas des checklists. Elles sont exécutables par machine, versionnables, et produisent des rapports de violation structurés.

Data Plane — everything runs locally. The Turtle files, the SHACL shapes, and the SPARQL queries are plain text files in a Git repository. No server, no SaaS, no data exfiltration. Data Plane — tout tourne en local. Les fichiers Turtle, les shapes SHACL et les requêtes SPARQL sont des fichiers texte dans un dépôt Git. Aucun serveur, aucun SaaS, aucune exfiltration de données.

Source files Fichiers source

All files used in this guide are available in the repository under demos/si-diagnostic/: Tous les fichiers utilisés dans ce guide sont disponibles dans le dépôt sous demos/si-diagnostic/ :

FileContent
si-model.ttlApplication portfolio (7 apps, 5 data stores, 3 integrations)Portefeuille applicatif (7 apps, 5 bases, 3 intégrations)
diagnostic-rules.ttl7 SHACL governance rules7 règles de gouvernance SHACL
queries/*.rq9 SPARQL diagnostic queries9 requêtes SPARQL de diagnostic
run-diagnostic.shShell script to run the full diagnosticScript shell pour le diagnostic complet