Standards Alignment — Tracing ISO Standards to Live Architecture Models¶

Enterprise architecture teams often struggle to maintain formal traceability between the ISO standards they cite in governance documents and the models they actually build. This guide shows how Linked.Archi bridges that gap — mapping ISO 42010, 42020, 12207, 15288, and the SQuaRE quality family (25010/25011/25012) into queryable OWL vocabularies linked to your live architecture models.

If your architecture governance board asks "which ISO 42010 concepts does our model actually cover?", this page gives you the semantic plumbing and the SPARQL queries to answer that question directly from your triplestore.

How Standards Are Used — Traceability from Governance Documents to Live Models¶

Standards serve as reference vocabularies — they define the formal terminology that the modelling languages, extensions, and core ontology align to. They are not modelling languages themselves; they provide the conceptual foundation.

Standard	What it provides	Used by
ISO/IEC/IEEE 42010	Architecture description concepts (System, Architecture, Viewpoint, View, Stakeholder, Concern)	Core ontology (`arch:Viewpoint`, `arch:Stakeholder`, `arch:Concern`)
ISO/IEC/IEEE 42020	Architecture processes (Governance, Management, Conceptualization, Evaluation, Elaboration, Enablement)	Architecture processes extension, TOGAF metamodel
ISO/IEC/IEEE 12207	Software lifecycle processes (Agreement, Technical Management, Technical) + lifecycle stages	Architecture processes extension, TIME framework
ISO/IEC/IEEE 15288	System lifecycle processes (same structure as 12207 but for systems)	Architecture processes extension
ISO/IEC 25010	Software product quality model (8 characteristics, 31 sub-characteristics)	Quality attributes extension, ArchiMate principle shapes
ISO/IEC 25011	IT service quality model (9 characteristics)	Quality attributes extension
ISO/IEC 25012	Data quality model (15 characteristics)	Quality attributes extension

Simplest alignment — one triple linking a core class to its ISO source¶

Copy this into any model file to establish the canonical traceability link between a Linked.Archi class and its ISO origin:

@prefix arch:     <https://meta.linked.archi/core#> .
@prefix iso42010: <https://meta.linked.archi/iso42010#> .

arch:Viewpoint rdfs:seeAlso iso42010:ArchitectureViewpoint .

Semantic Modelling Patterns¶

Architecture & Systems Engineering Standards (ISO 42010, 42020, 12207, 15288 in OWL)¶

These standards are modelled as reference vocabularies — they are owl:Class hierarchies that do not subclass arch:Element. They are not model elements; they define the formal terminology that the core ontology and extensions align to.

ISO 42010 concepts are pure owl:Class with SKOS labels and definitions, linked via rdfs:seeAlso to core ontology classes. ISO 42020, 12207, and 15288 define owl:Class types (Process, Activity, Task, InformationItem, Deliverable) that subclass the arch-processes extension (ap:ArchitectureProcess, ap:ProcessActivity, ap:ProcessTask, ap:InformationItem, ap:ProcessDeliverable). This grounds the ISO standard terminology in the shared governance vocabulary — a SPARQL query for ?p a ap:ArchitectureProcess returns process instances from all three standards via subsumption, and ISO process individuals inherit all AP linking properties (ap:governs, ap:hasActivity, ap:input/ap:output).

Use this pattern when defining a new ISO concept in a standards vocabulary file:

# In standards/iso42010/iso42010.ttl
:ArchitectureViewpoint
    a               owl:Class ;
    skos:prefLabel  "Architecture Viewpoint"@en ;
    skos:definition "A work product establishing the conventions for the construction,
                     interpretation, and use of architecture views..." ;
    rdfs:seeAlso    arch:Viewpoint .   # ← links to the core ontology class

Note: Standards do not subclass arch:Element because they are reference vocabularies, not model elements. Similarly, the architecture processes extension (ap:) does not subclass arch:Element — processes are governance infrastructure that acts upon architecture elements via linking properties (ap:governs, ap:input, ap:output), not constituents of the architecture itself.

Quality Models (SQuaRE Family) — Linking ISO 25010/25011/25012 to Architecture Elements¶

These standards use a class/individual hybrid pattern:

Root classes (e.g., iso25010:SoftwareProductQuality) are owl:Class with rdfs:subClassOf arch:QualityAttribute
Top-level characteristics (e.g., iso25010:Reliability) are owl:Class with rdfs:subClassOf the root — they are categories that group sub-characteristics
Leaf sub-characteristics (e.g., iso25010:Availability) are owl:NamedIndividual typed as their parent class — they are the vocabulary terms you reference in models

This pattern reflects how quality attributes are actually used: the leaf sub-characteristics are named concepts from the standard, not types you instantiate. Per-component quantification is done via arch:QualityMeasure.

Standards root classes do not subclass arch:Element — they are reference vocabulary terms, not model elements. The arch:QualityAttribute superclass provides the semantic bridge to the core ontology.

flowchart TD
    SPQ["iso25010:SoftwareProductQuality<br/><i>owl:Class (rdfs:subClassOf arch:QualityAttribute)</i>"]
    Rel["iso25010:Reliability<br/><i>owl:Class (category)</i>"]
    Av["iso25010:Availability<br/><i>owl:NamedIndividual</i>"]
    FT["iso25010:FaultTolerance<br/><i>owl:NamedIndividual</i>"]
    Rec["iso25010:Recoverability<br/><i>owl:NamedIndividual</i>"]
    Mat["iso25010:Maturity<br/><i>owl:NamedIndividual</i>"]

    SPQ --> Rel
    Rel --> Av & FT & Rec & Mat

Text summary: The ISO 25010 quality model hierarchy flows from SoftwareProductQuality (owl:Class, subClassOf arch:QualityAttribute) → Reliability (owl:Class category) → Availability, FaultTolerance, Recoverability, Maturity (owl:NamedIndividual instances). Leaf individuals are the terms you reference in quality measures; category classes exist only for grouping.

Traceability Queries — Answering "Which ISO Concepts Does Our Model Cover?"¶

Each standard vocabulary uses rdfs:seeAlso to link its concepts to the corresponding OWL classes in the core ontology. This enables queries like "which ISO 42010 concepts does this ontology implement?".

Run this against your triplestore to list every ISO concept that has a corresponding core ontology class:

PREFIX iso42010: <https://meta.linked.archi/iso42010#>
PREFIX arch:     <https://meta.linked.archi/core#>

SELECT ?isoConcept ?isoLabel ?coreClass WHERE {
    ?isoConcept rdfs:seeAlso ?coreClass ;
                skos:prefLabel ?isoLabel .
    ?coreClass a owl:Class .
}

Architecture & Systems Engineering Standards (ISO 42010, 42020, 12207, 15288 in OWL)¶

ISO 42010 in OWL — Architecture Description Concepts as Linked Data¶

The foundational standard for architecture description. Defines the conceptual model that Linked.Archi's core ontology implements: System, Architecture, Architecture Description, Stakeholder, Concern, Architecture Viewpoint, Architecture View, Architecture Model, Architecture Decision, Architecture Rationale, Correspondence, and Correspondence Rule.

Namespace: https://meta.linked.archi/iso42010#

ISO 42020 in OWL — Architecture Governance Processes¶

Defines the six architecture processes for governing and managing architecture: Architecture Governance, Architecture Management, Architecture Conceptualization, Architecture Evaluation, Architecture Elaboration, and Architecture Enablement. The enablement process establishes and maintains the architecture repository (iso42020:ArchitectureRepository). Classes subclass the arch-processes extension (iso42020:Process rdfs:subClassOf ap:ArchitectureProcess), inheriting the full AP governance vocabulary. See Processes Modelling Guide for usage.

Namespace: https://meta.linked.archi/iso42020#

ISO 12207 in OWL — Software Lifecycle Processes as Linked Data¶

Framework of processes for the software life cycle: Agreement Processes, Organizational Project-Enabling Processes, Technical Management Processes, and Technical Processes. Classes subclass the arch-processes extension. Also defines the generic software lifecycle stage model (Concept, Development, Production, Utilization, Support, Retirement) as instances of ap:LifecycleStage. See Processes Modelling Guide for usage.

Namespace: https://meta.linked.archi/iso12207#

ISO 15288 in OWL — System Lifecycle Processes as Linked Data¶

Same structure as 12207 but for systems engineering. Covers the full system life cycle from concept through retirement. Classes subclass the arch-processes extension. See Processes Modelling Guide for usage.

Namespace: https://meta.linked.archi/iso15288#

Quality Models (SQuaRE Family) — Linking ISO 25010/25011/25012 to Architecture Elements¶

ISO 25010 — Product Quality Model (8 Characteristics, 31 Sub-Characteristics in OWL)¶

The most comprehensive quality model. Defines 8 top-level quality characteristics as owl:Class categories, with 31 leaf sub-characteristics as owl:NamedIndividual vocabulary terms: Functional Suitability (3), Performance Efficiency (3), Compatibility (2), Usability (6), Reliability (4), Security (5), Maintainability (5), and Portability (3). Also defines Quality in Use as a separate root class and three user types (PrimaryUser, SecondaryUser, IndirectUser).

Namespace: https://meta.linked.archi/iso25010#

ISO 25011 — IT Service Quality Model (9 Characteristics in OWL)¶

Quality characteristics for IT services. ITServiceQuality is the root owl:Class, with 9 characteristics as owl:NamedIndividual instances: Availability, Responsiveness, Integrity, Usability, Portability, Recoverability, Capacity, Continuity, and Security.

Namespace: https://meta.linked.archi/iso25011#

ISO 25012 — Data Quality Model (15 Characteristics in OWL)¶

Quality characteristics for data. DataQuality is the root owl:Class, with 15 characteristics as owl:NamedIndividual instances grouped into inherent (Accuracy, Completeness, Consistency, Credibility, Currentness), inherent/system-dependent (Accessibility, Compliance, Confidentiality, Efficiency, Precision, Traceability, Understandability), and system-dependent (Availability, Portability, Recoverability).

Namespace: https://meta.linked.archi/iso25012#

Using Standards in Your Models¶

How to Measure Quality Attributes Per Component (ISO 25010 + OWL)¶

The core ontology provides arch:QualityMeasure for per-component quantification. A QualityMeasure links a named quality attribute (the owl:NamedIndividual from the standard) to a specific architecture element.

Paste this into your model to attach availability and security quality measures to a service:

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

# The architecture element
ex:PaymentService a am:ApplicationService ;
    skos:prefLabel "Payment Processing Service"@en ;
    arch:hasQualityMeasure ex:payment-availability, ex:payment-security .

# Quality measures — per-component quantification
ex:payment-availability a arch:QualityMeasure ;
    arch:measuredQualityAttribute iso25010:Availability ;   # ← the NamedIndividual
    arch:measuredEntity           ex:PaymentService ;       # ← the Element
    skos:prefLabel "Payment Service Availability Target"@en .

ex:payment-security a arch:QualityMeasure ;
    arch:measuredQualityAttribute iso25010:Confidentiality ;
    arch:measuredEntity           ex:PaymentService ;
    skos:prefLabel "Payment Service Confidentiality Target"@en .

Quality Attribute Requirements — Formal Decision Records with QAS¶

The architecture decisions extension uses ad:QualityAttributeRequirement with Quality Attribute Scenarios (QAS) to capture quality requirements formally.

Paste this into a decision record to formalize a quality attribute requirement with a measurable response:

@prefix ad:       <https://meta.linked.archi/arch-decision#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .
@prefix ex:       <https://model.example.com/myarch#> .

ex:QAR-001 a ad:QualityAttributeRequirement ;
    skos:prefLabel "Payment Availability Under Peak Load"@en ;
    ad:onQualityAttribute   iso25010:Availability ;         # ← the NamedIndividual
    ad:qasSourceOfStimulus  "External users" ;
    ad:qasStimulus          "Black Friday peak load (10x normal traffic)" ;
    ad:qasEnvironment       "Normal operation, all regions active" ;
    ad:qasArtifact          ex:PaymentService ;
    ad:qasResponse          "Service continues processing transactions" ;
    ad:qasResponseMeasure   "99.95% uptime, p99 latency < 500ms" .

SPARQL Queries for ISO 25010 Quality Attributes¶

Run this query to find all elements with reliability-related quality measures:

PREFIX arch:     <https://meta.linked.archi/core#>
PREFIX iso25010: <https://meta.linked.archi/iso25010#>

SELECT ?element ?elementLabel ?qa ?qaLabel WHERE {
    ?measure a arch:QualityMeasure ;
             arch:measuredEntity ?element ;
             arch:measuredQualityAttribute ?qa .
    ?element skos:prefLabel ?elementLabel .
    ?qa      skos:prefLabel ?qaLabel .
    ?qa      a iso25010:Reliability .
}

Run this query to find quality attribute requirements that lack a response measure (governance gap detection):

PREFIX ad: <https://meta.linked.archi/arch-decision#>

SELECT ?qar ?label WHERE {
    ?qar a ad:QualityAttributeRequirement ;
         skos:prefLabel ?label .
    FILTER NOT EXISTS { ?qar ad:qasResponseMeasure ?_ }
}

Validate Architecture Quality Compliance with SHACL Shapes¶

Use this SHACL shape to enforce that critical systems have required quality measures. Paste it into a shapes file and run validation against your model graph:

@prefix sh:       <http://www.w3.org/ns/shacl#> .
@prefix arch:     <https://meta.linked.archi/core#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .

ex:CriticalSystemSecurityShape a sh:NodeShape ;
    sh:targetClass ex:CriticalSystem ;
    sh:property [
        sh:path arch:hasQualityMeasure ;
        sh:qualifiedValueShape [
            sh:property [
                sh:path arch:measuredQualityAttribute ;
                sh:hasValue iso25010:Confidentiality ;
            ] ;
        ] ;
        sh:qualifiedMinCount 1 ;
        sh:message "Critical systems must have a Confidentiality quality measure." ;
    ] .