Linked.Archi

Linked.Archi ArchiMate 3.2 Questions

Question Set

https://meta.linked.archi/archimate3/questions#

v0.1.0 draft amq: Kalin Maldzhanski Linked.Archi Modified: 2026-10-27 License

Questions ArchiMate 3.2 stakeholders ask of a model — impact of change, application dependencies, data access, responsibilities, realisation and traceability — and the findings that show where a concern the ArchiMate 3.2 viewpoints frame is not met. Each is executable SPARQL (see arch:ModelQuestion).

19 model questions: questions the model answers, each with the SPARQL that answers it, bound to the concerns it informs. A finding question's rows are problems against those concerns: none means they are met.

Orientation

How is the model spread over the ArchiMate layers? notation/archimate/elements-by-layer
Elements counted by ArchiMate 3.2 layer, read from the layer classes their types specialise, so specialisations count where they belong.
A row: One row per layer, with the number of elements in it.
Does not prove: Balance. Equipment and facilities are nodes as well as physical, so they count in both the technology and the physical layer; location, grouping and junctions belong to no layer and are not counted.
Concerns: Completeness ReductionOfComplexity Fits: LayeredViewpoint
Reads: Model and metamodel
  • ?model (optional) — The model to count. A modelling tool binds the open model; a deliverable, the model it is produced from.
SPARQL 
SELECT ?layer (COUNT(DISTINCT ?element) AS ?elements)
WHERE {
  # Each layer's types, read once.
  {
    SELECT DISTINCT ?layer ?type
    WHERE {
      VALUES ?layer {
        am:StrategyLayerElement am:MotivationElement am:BusinessLayerElement am:ApplicationLayerElement
        am:TechnologyLayerElement am:PhysicalLayerElement am:ImplementationAndMigrationLayerElement
      }
      { ?layerType rdfs:subClassOf* ?layer } UNION { GRAPH ?ontologyGraph { ?layerType rdfs:subClassOf* ?layer } }
      { ?type rdfs:subClassOf* ?layerType } UNION { GRAPH ?specialisationGraph { ?type rdfs:subClassOf* ?layerType } }
    }
  }
  ?element rdf:type ?type ;
           arch:inModel ?model .
}
GROUP BY ?layer
ORDER BY DESC(?elements)

Analysis

How does each requirement trace to goals and to the elements that realise it? notation/archimate/requirement-traceability
Requirements and constraints with what realises them, below, and the goals, outcomes and principles they realise or influence, above, as a list of links.
A row: One row per traced link: the requirement, the direction, the predicate and the element at the other end.
Does not prove: Verification. A realisation relationship is a design claim; it does not show the requirement is met.
Concerns: ArchitectureTactics Motivation Stakeholders: BusinessAnalyst RequirementsManager Fits: GoalRealizationViewpoint RequirementsRealizationViewpoint
Reads: Model and metamodel
SPARQL 
SELECT DISTINCT ?requirement ?requirementLabel ?direction ?predicate ?other ?otherLabel ?otherType
WHERE {
  {
    SELECT DISTINCT ?requirementType
    WHERE {
      { ?asked rdfs:subClassOf* am:Requirement } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:Requirement } }
      { ?requirementType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?requirementType rdfs:subClassOf* ?asked } }
    }
  }
  ?requirement rdf:type ?requirementType .
  {
    ?other am:realizes ?requirement .
    BIND(am:realizes AS ?predicate)
    BIND("realised by" AS ?direction)
  }
  UNION
  {
    VALUES ?predicate { am:realizes am:influences }
    ?requirement ?predicate ?other .
    BIND("contributes to" AS ?direction)
  }
  ?other rdf:type ?otherType .
  FILTER(?otherType NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
  MINUS { SELECT DISTINCT ?otherType WHERE { { ?otherType arch:isAbstractClass true }
                                             UNION { GRAPH ?abstractClassGraph { ?otherType arch:isAbstractClass true } } } }
  OPTIONAL { ?requirement skos:prefLabel ?requirementLabel . FILTER(lang(?requirementLabel) = "" || langMatches(lang(?requirementLabel), "en")) }
  OPTIONAL { ?other skos:prefLabel ?otherLabel . FILTER(lang(?otherLabel) = "" || langMatches(lang(?otherLabel), "en")) }
}
ORDER BY ?requirementLabel ?direction ?otherLabel
What changes between these two plateaus? notation/archimate/plateau-difference
Elements a later plateau aggregates or is composed of that an earlier one is not (added), and the reverse (removed).
A row: One row per element added or removed.
Does not prove: The migration path. The difference is the gap; the work packages that close it are another question.
Concerns: ArchitectureVision ModelHistory Fits: MigrationViewpoint
Reads: Model and metamodel
  • ?from — The earlier plateau, such as the baseline.
  • ?to — The later plateau, such as the target.
SPARQL 
SELECT DISTINCT ?change ?element ?label ?type
WHERE {
  # Both are plateaus, or a specialisation of one.
  FILTER EXISTS {
    ?from rdf:type ?fromType .
    { ?fromType rdfs:subClassOf* am:Plateau } UNION { GRAPH ?fromGraph { ?fromType rdfs:subClassOf* am:Plateau } }
  }
  FILTER EXISTS {
    ?to rdf:type ?toType .
    { ?toType rdfs:subClassOf* am:Plateau } UNION { GRAPH ?toGraph { ?toType rdfs:subClassOf* am:Plateau } }
  }
  FILTER(?from != ?to)
  { ?to am:aggregates|am:composedOf ?element . BIND("added" AS ?change) }
  UNION
  { ?from am:aggregates|am:composedOf ?element . BIND("removed" AS ?change) }
  # Here, where both are bound: in the other plateau it is not.
  FILTER(IF(?change = "added",
            NOT EXISTS { ?from am:aggregates|am:composedOf ?element },
            NOT EXISTS { ?to am:aggregates|am:composedOf ?element }))
  ?element rdf:type ?type .
  FILTER(?type NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
  MINUS { SELECT DISTINCT ?type WHERE { { ?type arch:isAbstractClass true }
                                        UNION { GRAPH ?abstractClassGraph { ?type arch:isAbstractClass true } } } }
  OPTIONAL { ?element skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?change ?type ?label
What do stakeholders care about? notation/archimate/stakeholder-motivation
Stakeholders and the motivation elements (drivers, assessments, goals, outcomes, principles, requirements, constraints, values, meanings) they are related to, in either direction.
A row: One row per relationship between a stakeholder and a motivation element.
Does not prove: Priority. That a stakeholder is associated with a goal does not rank it among their concerns.
Concerns: ArchitectureMission Motivation Stakeholders: BusinessManager EnterpriseArchitect Fits: StakeholderViewpoint
Reads: Model and metamodel
SPARQL 
SELECT DISTINCT ?stakeholder ?stakeholderLabel ?direction ?predicate ?motivation ?motivationLabel ?motivationType
WHERE {
  {
    SELECT DISTINCT ?stakeholderType
    WHERE {
      { ?asked rdfs:subClassOf* am:Stakeholder } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:Stakeholder } }
      { ?stakeholderType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?stakeholderType rdfs:subClassOf* ?asked } }
    }
  }
  {
    SELECT DISTINCT ?motivationType
    WHERE {
      { ?motivationLayerType rdfs:subClassOf* am:MotivationElement } UNION { GRAPH ?motivationGraph { ?motivationLayerType rdfs:subClassOf* am:MotivationElement } }
      { ?motivationType rdfs:subClassOf* ?motivationLayerType } UNION { GRAPH ?motivationSpecialisationGraph { ?motivationType rdfs:subClassOf* ?motivationLayerType } }
    }
  }
  VALUES ?predicate { am:associatedWith am:influences am:realizes am:aggregates am:composedOf }
  ?stakeholder rdf:type ?stakeholderType .
  { ?stakeholder ?predicate ?motivation . BIND("outgoing" AS ?direction) }
  UNION
  { ?motivation ?predicate ?stakeholder . BIND("incoming" AS ?direction) }
  ?motivation rdf:type ?motivationType .
  MINUS { SELECT DISTINCT ?motivationType WHERE { { ?motivationType arch:isAbstractClass true }
                                                  UNION { GRAPH ?abstractClassGraph { ?motivationType arch:isAbstractClass true } } } }
  OPTIONAL { ?stakeholder skos:prefLabel ?stakeholderLabel . FILTER(lang(?stakeholderLabel) = "" || langMatches(lang(?stakeholderLabel), "en")) }
  OPTIONAL { ?motivation skos:prefLabel ?motivationLabel . FILTER(lang(?motivationLabel) = "" || langMatches(lang(?motivationLabel), "en")) }
}
ORDER BY ?stakeholderLabel ?direction ?motivationLabel
What does each work package deliver, and what does that realise? notation/archimate/work-package-deliverables
Work packages, the deliverables they realise, and the architecture elements those deliverables realise.
A row: One row per work package, deliverable and element realised.
Does not prove: Schedule or progress. ArchiMate records what a work package produces, not when.
Concerns: ArchitecturePolicies ArchitectureVision Stakeholders: EnterpriseArchitect OperationalManager Fits: ImplementationAndMigrationViewpoint ProjectViewpoint
Reads: Model and metamodel
SPARQL 
SELECT DISTINCT ?workPackage ?workPackageLabel ?deliverable ?deliverableLabel ?realized ?realizedLabel ?realizedType
WHERE {
  {
    SELECT DISTINCT ?workPackageType
    WHERE {
      { ?asked rdfs:subClassOf* am:WorkPackage } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:WorkPackage } }
      { ?workPackageType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?workPackageType rdfs:subClassOf* ?asked } }
    }
  }
  {
    SELECT DISTINCT ?deliverableType
    WHERE {
      { ?askedDeliverable rdfs:subClassOf* am:Deliverable } UNION { GRAPH ?deliverableGraph { ?askedDeliverable rdfs:subClassOf* am:Deliverable } }
      { ?deliverableType rdfs:subClassOf* ?askedDeliverable } UNION { GRAPH ?deliverableSpecialisationGraph { ?deliverableType rdfs:subClassOf* ?askedDeliverable } }
    }
  }
  ?workPackage rdf:type ?workPackageType ;
               am:realizes ?deliverable .
  ?deliverable rdf:type ?deliverableType .
  OPTIONAL {
    ?deliverable am:realizes ?realized .
    ?realized rdf:type ?realizedType .
    FILTER(?realizedType NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
    MINUS { SELECT DISTINCT ?realizedType WHERE { { ?realizedType arch:isAbstractClass true }
                                                  UNION { GRAPH ?abstractClassGraph { ?realizedType arch:isAbstractClass true } } } }
    OPTIONAL { ?realized skos:prefLabel ?realizedLabel . FILTER(lang(?realizedLabel) = "" || langMatches(lang(?realizedLabel), "en")) }
  }
  OPTIONAL { ?workPackage skos:prefLabel ?workPackageLabel . FILTER(lang(?workPackageLabel) = "" || langMatches(lang(?workPackageLabel), "en")) }
  OPTIONAL { ?deliverable skos:prefLabel ?deliverableLabel . FILTER(lang(?deliverableLabel) = "" || langMatches(lang(?deliverableLabel), "en")) }
}
ORDER BY ?workPackageLabel ?deliverableLabel
What is affected if this element changes? notation/archimate/impact-of-change
Everything that depends on the element, transitively, by ArchiMate's dependency relationships: what it serves, realises or is assigned to, and what accesses it.
A row: One row per element that depends on the element, directly or through others.
Does not prove: That each is broken by the change. Dynamic relationships (flow, triggering) and structure (composition, aggregation) are not followed, and a dependency may tolerate the change.
Concerns: Dependencies ImpactOfChange Stakeholders: ApplicationArchitect EnterpriseArchitect InfrastructureArchitect Fits: ApplicationCooperationViewpoint LayeredViewpoint TechnologyUsageViewpoint
Reads: Model data
  • ?focus — The element that changes. A modelling tool binds the selected element; a deliverable, the element it is produced for.
SPARQL 
SELECT DISTINCT ?impacted ?label ?type
WHERE {
  ?focus (am:serves|am:realizes|am:assignedTo|^am:accesses)+ ?impacted .
  FILTER(?impacted != ?focus)
  FILTER NOT EXISTS { ?impacted arch:source ?anySource }
  ?impacted rdf:type ?type .
  FILTER(?type NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
  MINUS { SELECT DISTINCT ?type WHERE { { ?type arch:isAbstractClass true }
                                        UNION { GRAPH ?abstractClassGraph { ?type arch:isAbstractClass true } } } }
  OPTIONAL { ?impacted skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?type ?label
What motivates each principle, and what does it constrain? notation/archimate/principle-rationale
Principles with the elements they relate to in either direction: the drivers and goals behind them, the requirements that realise them.
A row: One row per relationship between a principle and another element.
Does not prove: Compliance. A requirement realising a principle states an intent, not that designs follow it.
Concerns: ArchitecturePolicies Motivation Fits: MotivationViewpoint
Reads: Model and metamodel
SPARQL 
SELECT DISTINCT ?principle ?principleLabel ?direction ?predicate ?other ?otherLabel ?otherType
WHERE {
  {
    SELECT DISTINCT ?principleType
    WHERE {
      { ?asked rdfs:subClassOf* am:Principle } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:Principle } }
      { ?principleType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?principleType rdfs:subClassOf* ?asked } }
    }
  }
  VALUES ?predicate { am:realizes am:influences am:associatedWith }
  ?principle rdf:type ?principleType .
  { ?principle ?predicate ?other . BIND("outgoing" AS ?direction) }
  UNION
  { ?other ?predicate ?principle . BIND("incoming" AS ?direction) }
  ?other rdf:type ?otherType .
  FILTER(?otherType NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
  MINUS { SELECT DISTINCT ?otherType WHERE { { ?otherType arch:isAbstractClass true }
                                             UNION { GRAPH ?abstractClassGraph { ?otherType arch:isAbstractClass true } } } }
  OPTIONAL { ?principle skos:prefLabel ?principleLabel . FILTER(lang(?principleLabel) = "" || langMatches(lang(?principleLabel), "en")) }
  OPTIONAL { ?other skos:prefLabel ?otherLabel . FILTER(lang(?otherLabel) = "" || langMatches(lang(?otherLabel), "en")) }
}
ORDER BY ?principleLabel ?direction ?otherLabel
What realises each capability? notation/archimate/capability-realisation
Capabilities with the behaviour, active structure or resources that realise them.
A row: One row per capability and what realises it; a capability nothing realises appears once, with nothing beside it.
Does not prove: Maturity. That a capability is realised says it is delivered somehow, not how well.
Concerns: ArchitectureStrategy StrategyDevelopment Stakeholders: BusinessArchitect CxO Fits: CapabilityMapViewpoint StrategyViewpoint
Reads: Model and metamodel
SPARQL 
SELECT DISTINCT ?capability ?capabilityLabel ?realizer ?realizerLabel ?realizerType
WHERE {
  {
    SELECT DISTINCT ?capabilityType
    WHERE {
      { ?asked rdfs:subClassOf* am:Capability } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:Capability } }
      { ?capabilityType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?capabilityType rdfs:subClassOf* ?asked } }
    }
  }
  ?capability rdf:type ?capabilityType .
  OPTIONAL {
    ?realizer am:realizes ?capability ;
              rdf:type ?realizerType .
    FILTER(?realizerType NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
    MINUS { SELECT DISTINCT ?realizerType WHERE { { ?realizerType arch:isAbstractClass true }
                                                  UNION { GRAPH ?abstractClassGraph { ?realizerType arch:isAbstractClass true } } } }
    OPTIONAL { ?realizer skos:prefLabel ?realizerLabel . FILTER(lang(?realizerLabel) = "" || langMatches(lang(?realizerLabel), "en")) }
  }
  OPTIONAL { ?capability skos:prefLabel ?capabilityLabel . FILTER(lang(?capabilityLabel) = "" || langMatches(lang(?capabilityLabel), "en")) }
}
ORDER BY ?capabilityLabel ?realizerLabel
Which applications depend on which? notation/archimate/application-dependencies
Application components that serve, flow to or trigger one another, directly or through an application service one realises — itself or through the function assigned to it — and the other is served by.
A row: One row per dependency: the provider, how it provides, the relationship or service between, and the consumer.
Does not prove: Runtime coupling or data volume. A modelled flow says that information moves, not how much or how often.
Concerns: ApplicationDependencies ServiceOrchestration Fits: ApplicationCooperationViewpoint ApplicationUsageViewpoint
Reads: Model and metamodel
SPARQL 
SELECT DISTINCT ?provider ?providerLabel ?how ?via ?consumer ?consumerLabel
WHERE {
  # From the relationships to their ends, each branch anchored on its relationships: never every pair of
  # components. Both ends are then checked against the component types, read once each.
  {
    VALUES ?linkType { am:Serving am:Flow am:Triggering }
    ?via rdf:type ?linkType ;
         arch:source ?provider ;
         arch:target ?consumer .
    BIND(REPLACE(STR(?linkType), "^.*[#/]", "") AS ?how)
  }
  UNION
  {
    {
      SELECT DISTINCT ?serviceType
      WHERE {
        { ?askedService rdfs:subClassOf* am:ApplicationService } UNION { GRAPH ?serviceOntologyGraph { ?askedService rdfs:subClassOf* am:ApplicationService } }
        { ?serviceType rdfs:subClassOf* ?askedService } UNION { GRAPH ?serviceSpecialisationGraph { ?serviceType rdfs:subClassOf* ?askedService } }
      }
    }
    ?via rdf:type ?serviceType ;
         am:serves ?consumer .
    ?provider am:realizes|(am:assignedTo/am:realizes) ?via .
    BIND("realises a service serving" AS ?how)
  }
  ?provider rdf:type ?providerType .
  ?consumer rdf:type ?consumerType .
  {
    SELECT DISTINCT ?providerType
    WHERE {
      { ?askedProvider rdfs:subClassOf* am:ApplicationComponent } UNION { GRAPH ?providerGraph { ?askedProvider rdfs:subClassOf* am:ApplicationComponent } }
      { ?providerType rdfs:subClassOf* ?askedProvider } UNION { GRAPH ?providerSpecialisationGraph { ?providerType rdfs:subClassOf* ?askedProvider } }
    }
  }
  {
    SELECT DISTINCT ?consumerType
    WHERE {
      { ?askedConsumer rdfs:subClassOf* am:ApplicationComponent } UNION { GRAPH ?consumerGraph { ?askedConsumer rdfs:subClassOf* am:ApplicationComponent } }
      { ?consumerType rdfs:subClassOf* ?askedConsumer } UNION { GRAPH ?consumerSpecialisationGraph { ?consumerType rdfs:subClassOf* ?askedConsumer } }
    }
  }
  FILTER(?provider != ?consumer)
  OPTIONAL { ?provider skos:prefLabel ?providerLabel . FILTER(lang(?providerLabel) = "" || langMatches(lang(?providerLabel), "en")) }
  OPTIONAL { ?consumer skos:prefLabel ?consumerLabel . FILTER(lang(?consumerLabel) = "" || langMatches(lang(?consumerLabel), "en")) }
}
ORDER BY ?providerLabel ?consumerLabel
Which relationships cross layers, and of which kind? notation/archimate/layer-crossing
Relationships whose ends are in different ArchiMate 3.2 layers, counted by pair of layers and relationship type. The layers are read from the layer classes, not from type names.
A row: One row per source layer, relationship type and target layer, with the number of relationships.
Does not prove: Coupling. A relationship to an element of no layer (location, grouping, junction) is not counted, and one between equipment and a node crosses from the physical to the technology layer though both are nodes.
Concerns: Consistency ImpactOfChange Fits: LayeredViewpoint
Reads: Model and metamodel
SPARQL 
SELECT ?sourceLayer ?relationshipType ?targetLayer (COUNT(DISTINCT ?relationship) AS ?relationships)
WHERE {
  ?relationship arch:source ?source ;
                arch:target ?target ;
                rdf:type ?relationshipType .
  FILTER(?relationshipType NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
  MINUS { SELECT DISTINCT ?relationshipType WHERE { { ?relationshipType arch:isAbstractClass true }
                                                    UNION { GRAPH ?abstractClassGraph { ?relationshipType arch:isAbstractClass true } } } }
  ?source rdf:type ?sourceType .
  ?target rdf:type ?targetType .
  {
    SELECT DISTINCT ?sourceLayer ?sourceType
    WHERE {
      VALUES ?sourceLayer {
        am:StrategyLayerElement am:MotivationElement am:BusinessLayerElement am:ApplicationLayerElement
        am:TechnologyLayerElement am:PhysicalLayerElement am:ImplementationAndMigrationLayerElement
      }
      { ?sourceLayerType rdfs:subClassOf* ?sourceLayer } UNION { GRAPH ?sourceOntologyGraph { ?sourceLayerType rdfs:subClassOf* ?sourceLayer } }
      { ?sourceType rdfs:subClassOf* ?sourceLayerType } UNION { GRAPH ?sourceSpecialisationGraph { ?sourceType rdfs:subClassOf* ?sourceLayerType } }
    }
  }
  {
    SELECT DISTINCT ?targetLayer ?targetType
    WHERE {
      VALUES ?targetLayer {
        am:StrategyLayerElement am:MotivationElement am:BusinessLayerElement am:ApplicationLayerElement
        am:TechnologyLayerElement am:PhysicalLayerElement am:ImplementationAndMigrationLayerElement
      }
      { ?targetLayerType rdfs:subClassOf* ?targetLayer } UNION { GRAPH ?targetOntologyGraph { ?targetLayerType rdfs:subClassOf* ?targetLayer } }
      { ?targetType rdfs:subClassOf* ?targetLayerType } UNION { GRAPH ?targetSpecialisationGraph { ?targetType rdfs:subClassOf* ?targetLayerType } }
    }
  }
  FILTER(?sourceLayer != ?targetLayer)
}
GROUP BY ?sourceLayer ?relationshipType ?targetLayer
ORDER BY DESC(?relationships)
Who is responsible for what? notation/archimate/responsibility-assignments
Assignment relationships: which actor, role, collaboration, component or node performs which behaviour or plays which role.
A row: One row per assignment, with both ends and their types.
Does not prove: Accountability in the RACI sense. An ArchiMate assignment states who performs, not who answers for the outcome.
Concerns: CompetenciesAuthorityResponsibilities Responsibilities Stakeholders: Manager ProcessArchitect Fits: BusinessProcessCooperationViewpoint OrganizationViewpoint
Reads: Model and metamodel
SPARQL 
SELECT DISTINCT ?performer ?performerLabel ?performerType ?assignment ?assigned ?assignedLabel ?assignedType
WHERE {
  {
    SELECT DISTINCT ?assignmentType
    WHERE {
      { ?asked rdfs:subClassOf* am:Assignment } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:Assignment } }
      { ?assignmentType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?assignmentType rdfs:subClassOf* ?asked } }
    }
  }
  ?assignment rdf:type ?assignmentType ;
              arch:source ?performer ;
              arch:target ?assigned .
  ?performer rdf:type ?performerType .
  ?assigned rdf:type ?assignedType .
  FILTER(?performerType NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
  FILTER(?assignedType NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
  MINUS { SELECT DISTINCT ?performerType WHERE { { ?performerType arch:isAbstractClass true }
                                                 UNION { GRAPH ?abstractClassGraph { ?performerType arch:isAbstractClass true } } } }
  MINUS { SELECT DISTINCT ?assignedType WHERE { { ?assignedType arch:isAbstractClass true }
                                                UNION { GRAPH ?abstractClassGraph { ?assignedType arch:isAbstractClass true } } } }
  OPTIONAL { ?performer skos:prefLabel ?performerLabel . FILTER(lang(?performerLabel) = "" || langMatches(lang(?performerLabel), "en")) }
  OPTIONAL { ?assigned skos:prefLabel ?assignedLabel . FILTER(lang(?assignedLabel) = "" || langMatches(lang(?assignedLabel), "en")) }
}
ORDER BY ?performerLabel ?assignedLabel
Who reads and writes which information? notation/archimate/data-access
Access relationships by kind: ArchiMate 3.2 types the kind (am:ReadAccess, am:WriteAccess, am:ReadWriteAccess, and am:Access when it is not stated).
A row: One row per access: what accesses, the kind of access, and the object accessed.
Does not prove: Ownership of the data. Write access is not mastery; arch:masterDataSource says where that is recorded.
Concerns: Consistency InformationStructure Stakeholders: InformationArchitect Fits: ApplicationCooperationViewpoint InformationStructureViewpoint
Reads: Model data
SPARQL 
SELECT DISTINCT ?accessor ?accessorLabel ?access ?accessKind ?object ?objectLabel ?objectType
WHERE {
  VALUES ?accessKind { am:Access am:ReadAccess am:WriteAccess am:ReadWriteAccess }
  ?access rdf:type ?accessKind ;
          arch:source ?accessor ;
          arch:target ?object .
  # am:Access only when no kind is stated: the kinds are its subclasses.
  FILTER(?accessKind != am:Access || NOT EXISTS {
    ?access rdf:type ?statedKind .
    FILTER(?statedKind IN (am:ReadAccess, am:WriteAccess, am:ReadWriteAccess))
  })
  ?object rdf:type ?objectType .
  FILTER(?objectType NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
  MINUS { SELECT DISTINCT ?objectType WHERE { { ?objectType arch:isAbstractClass true }
                                              UNION { GRAPH ?abstractClassGraph { ?objectType arch:isAbstractClass true } } } }
  OPTIONAL { ?accessor skos:prefLabel ?accessorLabel . FILTER(lang(?accessorLabel) = "" || langMatches(lang(?accessorLabel), "en")) }
  OPTIONAL { ?object skos:prefLabel ?objectLabel . FILTER(lang(?objectLabel) = "" || langMatches(lang(?objectLabel), "en")) }
}
ORDER BY ?objectLabel ?accessKind ?accessorLabel

Quality

Which application components run on no technology? finding · Warning notation/archimate/applications-without-technology
Application components that no element of the technology layer serves or realises, directly or by realising a service that serves them. Equipment and facilities are nodes, so they count as technology.
A row: One row per application component with no technology under it.
Does not prove: That it runs nowhere. Where it is hosted may be outside the model, or recorded only in a deployment model that is not loaded.
Concerns: ApplicationPlatforms InfrastructureQuality Stakeholders: ApplicationArchitect InfrastructureArchitect Fits: ImplementationAndDeploymentViewpoint TechnologyUsageViewpoint
Reads: Model and metamodel Each finding is about: ?application
  • ?model (optional) — The model to look in. A modelling tool binds the open model; a deliverable, the model it is produced from.
SPARQL 
SELECT DISTINCT ?application ?label
WHERE {
  {
    SELECT DISTINCT ?componentType
    WHERE {
      { ?asked rdfs:subClassOf* am:ApplicationComponent } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:ApplicationComponent } }
      { ?componentType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?componentType rdfs:subClassOf* ?asked } }
    }
  }
  ?application rdf:type ?componentType ;
               arch:inModel ?model .
  MINUS {
    # The technology layer's types, read once.
    {
      SELECT DISTINCT ?technologyType
      WHERE {
        { ?layerType rdfs:subClassOf* am:TechnologyLayerElement }
        UNION { GRAPH ?layerGraph { ?layerType rdfs:subClassOf* am:TechnologyLayerElement } }
        { ?technologyType rdfs:subClassOf* ?layerType }
        UNION { GRAPH ?layerSpecialisationGraph { ?technologyType rdfs:subClassOf* ?layerType } }
      }
    }
    ?technology rdf:type ?technologyType ;
                am:serves|am:realizes|(am:realizes/am:serves) ?application .
  }
  OPTIONAL { ?application skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?label
Which capabilities does nothing realise? finding · Info notation/archimate/unrealised-capabilities
Capabilities realised neither directly nor through any capability they are composed of or aggregate.
A row: One row per capability with no realisation anywhere beneath it.
Does not prove: That the enterprise lacks the capability; only that the model does not say what delivers it.
Concerns: Completeness StrategyDevelopment Fits: CapabilityMapViewpoint
Reads: Model and metamodel Each finding is about: ?capability
  • ?model (optional) — The model to look in. A modelling tool binds the open model; a deliverable, the model it is produced from.
SPARQL 
SELECT DISTINCT ?capability ?label
WHERE {
  {
    SELECT DISTINCT ?capabilityType
    WHERE {
      { ?asked rdfs:subClassOf* am:Capability } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:Capability } }
      { ?capabilityType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?capabilityType rdfs:subClassOf* ?asked } }
    }
  }
  ?capability rdf:type ?capabilityType ;
              arch:inModel ?model .
  FILTER NOT EXISTS {
    ?capability (am:composedOf|am:aggregates)* ?part .
    ?realizer am:realizes ?part .
  }
  OPTIONAL { ?capability skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?label
Which information is read but never written? finding · Warning notation/archimate/data-never-written
Data objects, business objects (contracts too) and artifacts that something reads and nothing writes. Access of an unstated kind (am:Access) counts as a possible write.
A row: One row per object, with how many elements read it.
Does not prove: That the data has no source. It may be written by a system outside the model; that boundary is what the finding asks to discuss.
Concerns: Completeness InformationStructure Fits: InformationStructureViewpoint
Reads: Model and metamodel Each finding is about: ?object
SPARQL 
SELECT ?object ?label ?readers
WHERE {
  {
    SELECT ?object (COUNT(DISTINCT ?reader) AS ?readers)
    WHERE {
      {
        SELECT DISTINCT ?objectType
        WHERE {
          VALUES ?askedObject { am:DataObject am:BusinessObject am:Artifact }
          { ?asked rdfs:subClassOf* ?askedObject } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* ?askedObject } }
          { ?objectType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?objectType rdfs:subClassOf* ?asked } }
        }
      }
      ?read rdf:type am:ReadAccess ;
            arch:source ?reader ;
            arch:target ?object .
      ?object rdf:type ?objectType .
    }
    GROUP BY ?object
  }
  # Written: a write, a read-write, or an access whose kind is not stated.
  FILTER NOT EXISTS {
    VALUES ?writeKind { am:WriteAccess am:ReadWriteAccess am:Access }
    ?write rdf:type ?writeKind ;
           arch:target ?object .
    FILTER NOT EXISTS { ?write rdf:type am:ReadAccess }
  }
  OPTIONAL { ?object skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY DESC(?readers) ?label
Which principles has no requirement made concrete? finding · Info notation/archimate/principles-without-requirements
Principles that no requirement or constraint realises.
A row: One row per principle no requirement realises.
Does not prove: That the principle is ignored. It may be applied by review rather than through stated requirements.
Concerns: ArchitecturePolicies Fits: MotivationViewpoint
Reads: Model and metamodel Each finding is about: ?principle
  • ?model (optional) — The model to look in. A modelling tool binds the open model; a deliverable, the model it is produced from.
SPARQL 
SELECT DISTINCT ?principle ?label
WHERE {
  {
    SELECT DISTINCT ?principleType
    WHERE {
      { ?asked rdfs:subClassOf* am:Principle } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:Principle } }
      { ?principleType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?principleType rdfs:subClassOf* ?asked } }
    }
  }
  ?principle rdf:type ?principleType ;
             arch:inModel ?model .
  FILTER NOT EXISTS {
    {
      SELECT DISTINCT ?requirementType
      WHERE {
        { ?askedRequirement rdfs:subClassOf* am:Requirement } UNION { GRAPH ?requirementGraph { ?askedRequirement rdfs:subClassOf* am:Requirement } }
        { ?requirementType rdfs:subClassOf* ?askedRequirement } UNION { GRAPH ?requirementSpecialisationGraph { ?requirementType rdfs:subClassOf* ?askedRequirement } }
      }
    }
    ?requirement am:realizes ?principle ;
                 rdf:type ?requirementType .
  }
  OPTIONAL { ?principle skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?label
Which processes and functions has nobody been assigned to? finding · Warning notation/archimate/unassigned-behaviour
Business, application and technology processes and functions that no active structure element is assigned to.
A row: One row per process or function without a performer, with the kind asked about.
Does not prove: That nobody performs it. The performer may be assigned to an enclosing process, or the model may stop above that level of detail.
Concerns: Completeness Responsibilities Fits: BusinessProcessCooperationViewpoint OrganizationViewpoint
Reads: Model and metamodel Each finding is about: ?behaviour
  • ?model (optional) — The model to look in. A modelling tool binds the open model; a deliverable, the model it is produced from.
SPARQL 
SELECT DISTINCT ?behaviour ?label ?type
WHERE {
  {
    SELECT DISTINCT ?type ?behaviourType
    WHERE {
      VALUES ?type {
        am:BusinessProcess am:BusinessFunction am:ApplicationProcess am:ApplicationFunction
        am:TechnologyProcess am:TechnologyFunction
      }
      { ?asked rdfs:subClassOf* ?type } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* ?type } }
      { ?behaviourType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?behaviourType rdfs:subClassOf* ?asked } }
    }
  }
  ?behaviour rdf:type ?behaviourType ;
             arch:inModel ?model .
  FILTER NOT EXISTS { ?performer am:assignedTo ?behaviour }
  OPTIONAL { ?behaviour skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?type ?label
Which requirements does no architecture element realise? finding · Warning notation/archimate/unrealised-requirements
Requirements and constraints that no element outside the motivation elements realises: realisation by another motivation element does not count.
A row: One row per requirement or constraint without a realising design element.
Does not prove: That the requirement is unmet; only that the model does not show what meets it.
Concerns: ArchitectureTactics Motivation Stakeholders: RequirementsManager Fits: RequirementsRealizationViewpoint
Reads: Model and metamodel Each finding is about: ?requirement
  • ?model (optional) — The model to look in. A modelling tool binds the open model; a deliverable, the model it is produced from.
SPARQL 
SELECT DISTINCT ?requirement ?label
WHERE {
  {
    SELECT DISTINCT ?requirementType
    WHERE {
      { ?asked rdfs:subClassOf* am:Requirement } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* am:Requirement } }
      { ?requirementType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?requirementType rdfs:subClassOf* ?asked } }
    }
  }
  ?requirement rdf:type ?requirementType ;
               arch:inModel ?model .
  # Realised by a design element: one whose own type is not a motivation element.
  MINUS {
    ?realizer am:realizes ?requirement ;
              rdf:type ?realizerType .
    FILTER(?realizerType NOT IN (arch:ModelConcept, arch:Element, arch:QualifiedRelationship))
    MINUS { SELECT DISTINCT ?realizerType WHERE { { ?realizerType arch:isAbstractClass true }
                                                  UNION { GRAPH ?abstractClassGraph { ?realizerType arch:isAbstractClass true } } } }
    MINUS {
      SELECT DISTINCT ?realizerType
      WHERE {
        { ?motivationType rdfs:subClassOf* am:MotivationElement }
        UNION { GRAPH ?motivationGraph { ?motivationType rdfs:subClassOf* am:MotivationElement } }
        { ?realizerType rdfs:subClassOf* ?motivationType }
        UNION { GRAPH ?motivationSpecialisationGraph { ?realizerType rdfs:subClassOf* ?motivationType } }
      }
    }
  }
  OPTIONAL { ?requirement skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?label
Which services does nothing realise? finding · Warning notation/archimate/unrealised-services
Business, application and technology services that no behaviour or active structure element realises.
A row: One row per service nothing realises, with the kind of service.
Does not prove: That the service is not delivered: it may be bought in, or realised in a model that is not loaded.
Concerns: AddedValueOfProcesses Completeness Fits: BusinessProcessCooperationViewpoint ServiceRealizationViewpoint
Reads: Model and metamodel Each finding is about: ?service
  • ?model (optional) — The model to look in. A modelling tool binds the open model; a deliverable, the model it is produced from.
SPARQL 
SELECT DISTINCT ?service ?label ?type
WHERE {
  {
    SELECT DISTINCT ?type ?serviceType
    WHERE {
      VALUES ?type { am:BusinessService am:ApplicationService am:TechnologyService }
      { ?asked rdfs:subClassOf* ?type } UNION { GRAPH ?ontologyGraph { ?asked rdfs:subClassOf* ?type } }
      { ?serviceType rdfs:subClassOf* ?asked } UNION { GRAPH ?specialisationGraph { ?serviceType rdfs:subClassOf* ?asked } }
    }
  }
  ?service rdf:type ?serviceType ;
           arch:inModel ?model .
  FILTER NOT EXISTS { ?realizer am:realizes ?service }
  OPTIONAL { ?service skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?type ?label
Source: linked-archi-meta • Linked.Archi