Skip to content

Use Cases

Scenarios where the knowledge graph approach provides value that traditional document-centric architecture cannot. Each demonstrates a different capability of the ontology ecosystem.

Cross-source architecture queries

The situation: Architecture documentation is spread across an ArchiMate model (Sparx EA), ADRs (Markdown in Git), a Backstage service catalog, and API specs (OpenAPI). Nobody can answer cross-cutting questions without weeks of manual research.

What the graph enables: Once sources are converted to RDF against the shared ontologies, a single SPARQL query can traverse from business capability through application component to architecture decision to API contract:

PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
PREFIX ad:   <https://meta.linked.archi/arch-decision#>
PREFIX bs:   <https://meta.linked.archi/backstage/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

# Which decisions affect applications that serve a specific capability?
SELECT ?app ?appLabel ?decision ?decisionLabel WHERE {
    ?app a am:ApplicationComponent ;
         skos:prefLabel ?appLabel ;
         am:assignedTo ?func .
    ?func am:realizes ?svc .
    ?svc am:realizes ?bizSvc .
    ?bizSvc am:realizes <ex:OrderFulfillment> .
    ?decision a ad:Decision ;
              ad:relatedConcept ?app ;
              skos:prefLabel ?decisionLabel .
}

This traverses ArchiMate elements (application → service → capability) and the decisions extension (decision → affected element) in one query. No single tool holds both.

Modules used: arch:core, ArchiMate ontology, Architecture Decisions extension, Backstage ontology.

Application portfolio rationalization

The situation: An organization with 200+ applications needs to rationalize its portfolio. They have TIME classifications (Tolerate/Invest/Migrate/Eliminate) but can't connect assessments to technology dependencies, business capabilities, or cost data.

What the graph enables: The TIME framework ontology models applications with fit assessments, evidence, and dispositions. Combined with ArchiMate capability mapping and the Financial Architecture extension, you can query:

PREFIX timefw: <https://meta.linked.archi/time-framework/onto#>
PREFIX fina:   <https://meta.linked.archi/financial-architecture/onto#>
PREFIX skos:   <http://www.w3.org/2004/02/skos/core#>

# Migrate-classified apps with highest TCO — prioritize these
SELECT ?app ?label ?tco ?techScore WHERE {
    ?app a timefw:Application ;
         skos:prefLabel ?label ;
         timefw:hasFitAssessment ?assess .
    ?assess timefw:timeDisposition timefw:Migrate ;
            timefw:technicalFitScore ?techScore ;
            timefw:assessmentStatus timefw:Approved .
    ?app fina:hasCostModel ?cost .
    ?cost fina:totalTCO ?tco .
}
ORDER BY DESC(?tco)

The TIME ontology includes OWL equivalent class definitions that automatically classify assessments into quadrants based on fit ratings — High functional + Low technical = Migrate. SHACL shapes validate that every assessment has required fields.

Modules used: TIME framework, Financial Architecture extension, ArchiMate ontology.

Architecture decision traceability

The situation: An architecture review board evaluates 50+ projects annually. Decisions are made but there's no systematic way to trace them to the forces that drove them, the options considered, or the downstream impact on the architecture.

What the graph enables: Decisions become first-class elements linked to everything that influenced them and everything they affect:

ex:ADR-042 a ad:Decision ;
    skos:prefLabel "ADR-042: Read replicas for Orders DB scaling"@en ;
    ad:hasIssue ex:DBScalabilityIssue ;
    ad:hasSelectedOption ex:ReadReplicas ;
    ad:hasAlternative ex:VerticalScaling, ex:CQRSOption ;
    ad:influencedByForce ex:AvailabilityReq, ex:BudgetConstraint ;
    ad:relatedConcept ex:OrdersDB, ex:OrderService ;
    ad:justification "Read replicas provide horizontal read scaling within budget."@en .

ex:AvailabilityReq a ad:QualityAttributeRequirement ;
    ad:onQualityAttribute iso25010:Availability ;
    ad:qasResponseMeasure "99.95% uptime, zero order loss"@en .

Now you can query: "which elements are affected by decisions driven by availability concerns?", "which options were rejected and why?", "which decisions have no documented forces?" (governance gap detection via SHACL).

Modules used: Architecture Decisions extension, Quality Attributes, ADMIT design forces (for systematic force checklists).

Automated compliance validation

The situation: A healthcare organization needs to demonstrate that every system handling patient data has security controls and an owner. Audit preparation currently takes weeks of manual evidence compilation.

What the graph enables: SHACL shapes encode compliance rules as executable constraints:

:SensitiveDataSecurityShape a sh:NodeShape ;
    sh:targetClass am:ApplicationComponent ;
    sh:property [
        sh:path arch:hasQualityMeasure ;
        sh:qualifiedMinCount 1 ;
        sh:qualifiedValueShape [ sh:path arch:measuredQualityAttribute ;
                                  sh:hasValue qa:Cybersecurity ] ;
        sh:message "System handling sensitive data must have a Cybersecurity quality measure."@en ;
    ] .

:OwnershipShape a sh:NodeShape ;
    sh:targetClass am:ApplicationComponent ;
    sh:property [
        sh:path bs:ownedBy ;
        sh:minCount 1 ;
        sh:message "Every Application Component must have an owner."@en ;
    ] .

Run validate.sh --shacl compliance in CI/CD. The output is a structured validation report — which systems are non-compliant and why. Generate a compliance matrix from a SPARQL query. Audit prep goes from weeks to hours.

Modules used: arch:core, ArchiMate ontology, Backstage ontology (ownership), Quality Attributes, SHACL shapes.

Custom metamodel development

The situation: An organization needs to extend ArchiMate with domain-specific concepts — specialized application types (Microservice, SaaS Platform, Legacy Monolith), custom properties (resilience level, deployment pattern), and organization-specific validation rules.

What the graph enables: Create a custom ontology that imports both arch:core and the ArchiMate ontology, then specialize:

@prefix am:   <https://meta.linked.archi/archimate3/onto#> .
@prefix arch: <https://meta.linked.archi/core#> .
@prefix :     <https://model.example.com/custom#> .

:Microservice
    a               owl:Class ;
    rdfs:subClassOf am:ApplicationComponent ;
    skos:prefLabel  "Microservice"@en ;
    skos:definition "A small, independently deployable service."@en .

:SaaSPlatform
    a               owl:Class ;
    rdfs:subClassOf am:ApplicationComponent ;
    skos:prefLabel  "SaaS Platform"@en .

:resilienceLevel
    a                   owl:DatatypeProperty ;
    arch:domainIncludes :Microservice ;
    rdfs:range          xsd:string ;
    skos:prefLabel      "Resilience Level"@en .

Add SHACL shapes for organization-specific rules, a SKOS taxonomy for palette navigation, viewpoints for stakeholder-specific views, and deliverable templates for document generation. The ArchiMate 3.2 implementation (13 files) serves as the reference for what a complete metamodel looks like.

See Build Your Own Metamodel for a full walkthrough.

Modules used: arch:core, ArchiMate ontology (as base), custom ontology, SHACL shapes.

ML-enabled system architecture

The situation: A fintech company builds a fraud detection system combining traditional software (payment service, transaction database) with ML components (model, training pipeline, feature store, serving infrastructure). Software engineers, data scientists, and compliance officers each have different concerns and no unified view.

What the graph enables: The ML-Enabled Systems extension models ML components as architecture elements. The AI Governance extension wraps them with regulatory metadata:

:FraudModel a mlsys:MLModel ;
    skos:prefLabel "Fraud Detection Model v3.1"@en ;
    mlsys:trainedOn :TransactionDataset ;
    mlsys:hasMonitoringPlan :DriftMonitor .

:FraudAISystem a aigov:AISystem ;
    aigov:wrapsMLModel :FraudModel ;
    aigov:hasRiskClassification [
        aigov:classifiedAs aigovrd:HighRisk ;
        aigov:classificationRationale "Credit scoring under EU AI Act Annex III."@en
    ] ;
    aigov:hasHumanOversightPlan [
        aigov:oversightMode aigovrd:HumanOnTheLoop ;
        aigov:oversightResponsible :FraudAnalystTeam
    ] .

Different stakeholders get different views from the same graph: data scientists see model metrics and training pipelines, platform engineers see serving infrastructure and latency budgets, compliance officers see risk classifications and oversight plans.

Motivated by: Moin et al. (2023) arXiv:2308.05239.

Modules used: ML-Enabled Systems extension, AI Governance extension, Architecture Decisions, Quality Attributes.

What these have in common

Every use case follows the same pattern:

  1. Architecture knowledge from multiple sources is converted to RDF against shared ontologies
  2. The shared arch:core foundation enables cross-source traversal
  3. SPARQL queries answer questions that no single tool can answer alone
  4. SHACL shapes automate governance that was previously manual
  5. Different stakeholders consume different views of the same graph

The ontologies don't create this knowledge — they formalize connections that already exist implicitly. The value is making those connections queryable, validatable, and accessible to AI agents.

Other scenarios not detailed here

The six cases above demonstrate distinct capabilities. Many other scenarios follow the same "compose modules, query across them" pattern: