Linked.Archi

Linked.Archi ArchiMate 4.0 Questions

Question Set

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

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

Questions ArchiMate 4.0 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 4.0 viewpoints frame is not met. Each is executable SPARQL (see arch:ModelQuestion).

20 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 domains? notation/archimate4/elements-by-domain
Elements counted by ArchiMate 4.0 domain, read from the domain classes their types specialise, so specialisations count where they belong.
A row: One row per domain, with the number of elements in it.
Does not prove: Balance. Behaviour of the common domain (process, function, service, event, role …) is counted under am4:CommonDomainElement, because ArchiMate 4.0 gives it no domain of its own.
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 ?domain (COUNT(DISTINCT ?element) AS ?elements)
WHERE {
  # Each domain's types, read once.
  {
    SELECT DISTINCT ?domain ?type
    WHERE {
      VALUES ?domain {
        am4:StrategyElement am4:MotivationElement am4:BusinessDomainElement
        am4:ApplicationDomainElement am4:TechnologyDomainElement am4:ImplementationAndMigrationDomainElement
        am4:CommonDomainElement
      }
      { ?domainType rdfs:subClassOf* ?domain } UNION { GRAPH ?ontologyGraph { ?domainType rdfs:subClassOf* ?domain } }
      { ?type rdfs:subClassOf* ?domainType } UNION { GRAPH ?specialisationGraph { ?type rdfs:subClassOf* ?domainType } }
    }
  }
  ?element rdf:type ?type ;
           arch:inModel ?model .
}
GROUP BY ?domain
ORDER BY DESC(?elements)

Analysis

How does each requirement trace to goals and to the elements that realise it? notation/archimate4/requirement-traceability
Requirements 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 data
SPARQL 
SELECT DISTINCT ?requirement ?requirementLabel ?direction ?predicate ?other ?otherLabel ?otherType
WHERE {
  ?requirement rdf:type am4:Requirement .
  {
    ?other am4:realizes ?requirement .
    BIND(am4:realizes AS ?predicate)
    BIND("realised by" AS ?direction)
  }
  UNION
  {
    VALUES ?predicate { am4:realizes am4: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/archimate4/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 data
  • ?from — The earlier plateau, such as the baseline.
  • ?to — The later plateau, such as the target.
SPARQL 
SELECT DISTINCT ?change ?element ?label ?type
WHERE {
  {
    ?from rdf:type am4:Plateau .
    ?to rdf:type am4:Plateau ;
        am4:aggregates|am4:composedOf ?element .
    FILTER NOT EXISTS { ?from am4:aggregates|am4:composedOf ?element }
    BIND("added" AS ?change)
  }
  UNION
  {
    ?to rdf:type am4:Plateau .
    ?from rdf:type am4:Plateau ;
          am4:aggregates|am4:composedOf ?element .
    FILTER NOT EXISTS { ?to am4:aggregates|am4:composedOf ?element }
    BIND("removed" AS ?change)
  }
  FILTER(?from != ?to)
  ?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/archimate4/stakeholder-motivation
Stakeholders and the motivation elements (drivers, assessments, goals, outcomes, principles, requirements, 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 data
SPARQL 
SELECT DISTINCT ?stakeholder ?stakeholderLabel ?direction ?predicate ?motivation ?motivationLabel ?motivationType
WHERE {
  VALUES ?predicate { am4:associatedWith am4:influences am4:realizes am4:aggregates am4:composedOf }
  VALUES ?motivationType {
    am4:Stakeholder am4:Driver am4:Assessment am4:Goal am4:Outcome
    am4:Principle am4:Requirement am4:Meaning am4:Value
  }
  ?stakeholder rdf:type am4:Stakeholder .
  { ?stakeholder ?predicate ?motivation . BIND("outgoing" AS ?direction) }
  UNION
  { ?motivation ?predicate ?stakeholder . BIND("incoming" AS ?direction) }
  ?motivation rdf:type ?motivationType .
  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/archimate4/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 data
SPARQL 
SELECT DISTINCT ?workPackage ?workPackageLabel ?deliverable ?deliverableLabel ?realized ?realizedLabel ?realizedType
WHERE {
  ?workPackage rdf:type am4:WorkPackage ;
               am4:realizes ?deliverable .
  ?deliverable rdf:type am4:Deliverable .
  OPTIONAL {
    ?deliverable am4: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/archimate4/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 (am4:serves|am4:realizes|am4:assignedTo|^am4: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/archimate4/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 data
SPARQL 
SELECT DISTINCT ?principle ?principleLabel ?direction ?predicate ?other ?otherLabel ?otherType
WHERE {
  VALUES ?predicate { am4:realizes am4:influences am4:associatedWith }
  ?principle rdf:type am4:Principle .
  { ?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/archimate4/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 data
SPARQL 
SELECT DISTINCT ?capability ?capabilityLabel ?realizer ?realizerLabel ?realizerType
WHERE {
  ?capability rdf:type am4:Capability .
  OPTIONAL {
    ?realizer am4: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/archimate4/application-dependencies
Application components that serve, flow to or trigger one another, directly or through a service one realises 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 data
SPARQL 
SELECT DISTINCT ?provider ?providerLabel ?how ?via ?consumer ?consumerLabel
WHERE {
  # From the relationships to their ends, each branch checking its own: never every pair of components.
  {
    VALUES ?linkType { am4:Serving am4:Flow am4:Triggering }
    ?via rdf:type ?linkType ;
         arch:source ?provider ;
         arch:target ?consumer .
    ?provider rdf:type am4:ApplicationComponent .
    ?consumer rdf:type am4:ApplicationComponent .
    BIND(REPLACE(STR(?linkType), "^.*[#/]", "") AS ?how)
  }
  UNION
  {
    ?via rdf:type am4:Service ;
         am4:serves ?consumer .
    ?consumer rdf:type am4:ApplicationComponent .
    ?provider am4:realizes ?via .
    ?provider rdf:type am4:ApplicationComponent .
    BIND("realises a service serving" AS ?how)
  }
  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 domains, and of which kind? notation/archimate4/cross-domain-relationships
Relationships whose ends are in different ArchiMate 4.0 domains, counted by pair of domains and relationship type. The domains are read from the domain classes, not from type names.
A row: One row per source domain, relationship type and target domain, with the number of relationships.
Does not prove: Coupling. Relationships touching elements of the common domain are not counted: ArchiMate 4.0 assigns those no domain, so whether they cross one is undefined.
Concerns: Consistency ImpactOfChange Fits: LayeredViewpoint
Reads: Model and metamodel
SPARQL 
SELECT ?sourceDomain ?relationshipType ?targetDomain (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 ?sourceDomain ?sourceType
    WHERE {
      VALUES ?sourceDomain {
        am4:StrategyElement am4:MotivationElement am4:BusinessDomainElement
        am4:ApplicationDomainElement am4:TechnologyDomainElement am4:ImplementationAndMigrationDomainElement
      }
      { ?sourceDomainType rdfs:subClassOf* ?sourceDomain } UNION { GRAPH ?sourceOntologyGraph { ?sourceDomainType rdfs:subClassOf* ?sourceDomain } }
      { ?sourceType rdfs:subClassOf* ?sourceDomainType } UNION { GRAPH ?sourceSpecialisationGraph { ?sourceType rdfs:subClassOf* ?sourceDomainType } }
    }
  }
  {
    SELECT DISTINCT ?targetDomain ?targetType
    WHERE {
      VALUES ?targetDomain {
        am4:StrategyElement am4:MotivationElement am4:BusinessDomainElement
        am4:ApplicationDomainElement am4:TechnologyDomainElement am4:ImplementationAndMigrationDomainElement
      }
      { ?targetDomainType rdfs:subClassOf* ?targetDomain } UNION { GRAPH ?targetOntologyGraph { ?targetDomainType rdfs:subClassOf* ?targetDomain } }
      { ?targetType rdfs:subClassOf* ?targetDomainType } UNION { GRAPH ?targetSpecialisationGraph { ?targetType rdfs:subClassOf* ?targetDomainType } }
    }
  }
  FILTER(?sourceDomain != ?targetDomain)
}
GROUP BY ?sourceDomain ?relationshipType ?targetDomain
ORDER BY DESC(?relationships)
Who is responsible for what? notation/archimate4/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: OrganizationViewpoint ProcessCooperationViewpoint
Reads: Model data
SPARQL 
SELECT DISTINCT ?performer ?performerLabel ?performerType ?assignment ?assigned ?assignedLabel ?assignedType
WHERE {
  ?assignment rdf:type am4:Assignment ;
              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/archimate4/data-access
Access relationships by kind: ArchiMate 4.0 types the kind (am4:ReadAccess, am4:WriteAccess, am4:ReadWriteAccess, and am4: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 { am4:Access am4:ReadAccess am4:WriteAccess am4:ReadWriteAccess }
  ?access rdf:type ?accessKind ;
          arch:source ?accessor ;
          arch:target ?object .
  ?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/archimate4/applications-without-technology
Application components that no element of the technology domain serves or realises, directly or by realising a service that serves them.
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 ?application ?label
WHERE {
  ?application rdf:type am4:ApplicationComponent ;
               arch:inModel ?model .
  MINUS {
    # The technology domain's types, read once.
    {
      SELECT DISTINCT ?technologyType
      WHERE {
        { ?domainType rdfs:subClassOf* am4:TechnologyDomainElement }
        UNION { GRAPH ?ontologyGraph { ?domainType rdfs:subClassOf* am4:TechnologyDomainElement } }
        { ?technologyType rdfs:subClassOf* ?domainType }
        UNION { GRAPH ?specialisationGraph { ?technologyType rdfs:subClassOf* ?domainType } }
      }
    }
    ?technology rdf:type ?technologyType ;
                am4:serves|am4:realizes|(am4:realizes/am4: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/archimate4/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 data 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 ?capability ?label
WHERE {
  ?capability rdf:type am4:Capability ;
              arch:inModel ?model .
  FILTER NOT EXISTS {
    ?capability (am4:composedOf|am4:aggregates)* ?part .
    ?realizer am4: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/archimate4/data-never-written
Data objects, business objects and artifacts that something reads and nothing writes. Access of an unstated kind (am4: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 data Each finding is about: ?object
SPARQL 
SELECT ?object ?label ?readers
WHERE {
  {
    SELECT ?object (COUNT(DISTINCT ?reader) AS ?readers)
    WHERE {
      VALUES ?objectType { am4:DataObject am4:BusinessObject am4:Artifact }
      ?read rdf:type am4:ReadAccess ;
            arch:source ?reader ;
            arch:target ?object .
      ?object rdf:type ?objectType .
    }
    GROUP BY ?object
  }
  FILTER NOT EXISTS {
    VALUES ?writeKind { am4:WriteAccess am4:ReadWriteAccess am4:Access }
    ?write rdf:type ?writeKind ;
           arch:target ?object .
  }
  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/archimate4/principles-without-requirements
Principles that no requirement 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 data 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 ?principle ?label
WHERE {
  ?principle rdf:type am4:Principle ;
             arch:inModel ?model .
  FILTER NOT EXISTS {
    ?requirement am4:realizes ?principle ;
                 rdf:type am4:Requirement .
  }
  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/archimate4/unassigned-behaviour
Processes and functions that no active structure element is assigned to.
A row: One row per process or function without a performer.
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: OrganizationViewpoint ProcessCooperationViewpoint
Reads: Model data 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 ?behaviour ?label ?type
WHERE {
  VALUES ?type { am4:Process am4:Function }
  ?behaviour rdf:type ?type ;
             arch:inModel ?model .
  FILTER NOT EXISTS { ?performer am4: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/archimate4/unrealised-requirements
Requirements that no element outside the motivation domain realises: realisation by another motivation element does not count.
A row: One row per requirement 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 ?requirement ?label
WHERE {
  ?requirement rdf:type am4:Requirement ;
               arch:inModel ?model .
  # Realised by a design element: one whose own type is outside the motivation domain.
  MINUS {
    ?realizer am4: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 {
        { ?domainType rdfs:subClassOf* am4:MotivationElement }
        UNION { GRAPH ?ontologyGraph { ?domainType rdfs:subClassOf* am4:MotivationElement } }
        { ?realizerType rdfs:subClassOf* ?domainType }
        UNION { GRAPH ?specialisationGraph { ?realizerType rdfs:subClassOf* ?domainType } }
      }
    }
  }
  OPTIONAL { ?requirement skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?label
Which services does nothing realise? finding · Warning notation/archimate4/unrealised-services
Services that no behaviour or active structure element realises.
A row: One row per service nothing realises.
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: ProcessCooperationViewpoint ServiceRealizationViewpoint
Reads: Model data 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 ?service ?label
WHERE {
  ?service rdf:type am4:Service ;
           arch:inModel ?model .
  FILTER NOT EXISTS { ?realizer am4:realizes ?service }
  OPTIONAL { ?service skos:prefLabel ?label . FILTER(lang(?label) = "" || langMatches(lang(?label), "en")) }
}
ORDER BY ?label

Views

What in the model belongs in a view of this ArchiMate viewpoint? notation/archimate4/viewpoint-scope
What belongs in a view of an ArchiMate 4.0 viewpoint. ArchiMate 4.0 places process, function, service, event and role in a common domain, and viewpoints such as the Technology Viewpoint admit them; listed whenever their type is admitted, every business process would belong in a technology view. An element of the common domain therefore belongs when a relationship connects it, in either direction, to an element of a domain-specific type the same viewpoint admits; every other element belongs when the viewpoint admits its type.
A row: One row per element: name, type, definition and a "relationship → target" summary of what it points to.
Does not prove: That an element of the common domain left out is irrelevant to the viewpoint; only that nothing of a domain-specific type the viewpoint admits is related to it.
Reads: Model and metamodel
  • ?viewpoint — A viewpoint. A modelling tool binds the open view's viewpoint; a deliverable, the section's.
  • ?model (optional) — The model to look in. A modelling tool binds the open model; a deliverable, the model it is produced from.
SPARQL 
SELECT ?element (SAMPLE(?anyLabel) AS ?label) ?type (SAMPLE(?anyDefinition) AS ?definition)
       (GROUP_CONCAT(DISTINCT ?link; separator = "; ") AS ?outgoing)
WHERE {
  {
    # Elements of a domain-specific type the viewpoint admits.
    {
      SELECT DISTINCT ?viewpoint ?type
      WHERE {
        { ?viewpoint arch:includesConcept ?admitted } UNION { GRAPH ?admittingGraph { ?viewpoint arch:includesConcept ?admitted } }
        { ?type rdfs:subClassOf* ?admitted } UNION { GRAPH ?hierarchyGraph { ?type rdfs:subClassOf* ?admitted } }
        MINUS {
          SELECT DISTINCT ?type
          WHERE {
            { ?commonType rdfs:subClassOf* am4:CommonDomainElement } UNION { GRAPH ?commonGraph { ?commonType rdfs:subClassOf* am4:CommonDomainElement } }
            { ?type rdfs:subClassOf* ?commonType } UNION { GRAPH ?commonSpecialisationGraph { ?type rdfs:subClassOf* ?commonType } }
          }
        }
      }
    }
    ?element rdf:type ?type ;
             arch:inModel ?model .
  }
  UNION
  {
    # Elements of a common-domain type the viewpoint admits, connected to one of a domain-specific type it
    # admits. The connected elements are found as a set first: per viewpoint, the elements at the other end
    # of a relationship from an element of an admitted domain-specific type.
    {
      SELECT DISTINCT ?viewpoint ?element
      WHERE {
        {
          SELECT DISTINCT ?viewpoint ?anchorType
          WHERE {
            { ?viewpoint arch:includesConcept ?anchorAdmitted } UNION { GRAPH ?anchorAdmittingGraph { ?viewpoint arch:includesConcept ?anchorAdmitted } }
            { ?anchorType rdfs:subClassOf* ?anchorAdmitted } UNION { GRAPH ?anchorHierarchyGraph { ?anchorType rdfs:subClassOf* ?anchorAdmitted } }
            MINUS {
              SELECT DISTINCT ?anchorType
              WHERE {
                { ?anchorCommonType rdfs:subClassOf* am4:CommonDomainElement } UNION { GRAPH ?anchorCommonGraph { ?anchorCommonType rdfs:subClassOf* am4:CommonDomainElement } }
                { ?anchorType rdfs:subClassOf* ?anchorCommonType } UNION { GRAPH ?anchorCommonSpecialisationGraph { ?anchorType rdfs:subClassOf* ?anchorCommonType } }
              }
            }
          }
        }
        ?anchor rdf:type ?anchorType .
        { ?connection arch:source ?anchor ; arch:target ?element }
        UNION
        { ?connection arch:target ?anchor ; arch:source ?element }
      }
    }
    ?element rdf:type ?type ;
             arch:inModel ?model .
    {
      SELECT DISTINCT ?viewpoint ?type
      WHERE {
        { ?viewpoint arch:includesConcept ?admitted } UNION { GRAPH ?admittingGraph { ?viewpoint arch:includesConcept ?admitted } }
        { ?type rdfs:subClassOf* ?admitted } UNION { GRAPH ?hierarchyGraph { ?type rdfs:subClassOf* ?admitted } }
        {
          SELECT DISTINCT ?type
          WHERE {
            { ?commonType rdfs:subClassOf* am4:CommonDomainElement } UNION { GRAPH ?commonGraph { ?commonType rdfs:subClassOf* am4:CommonDomainElement } }
            { ?type rdfs:subClassOf* ?commonType } UNION { GRAPH ?commonSpecialisationGraph { ?type rdfs:subClassOf* ?commonType } }
          }
        }
      }
    }
  }
  FILTER NOT EXISTS { ?element arch:source ?anySource }
  OPTIONAL { ?element skos:prefLabel ?anyLabel . FILTER(lang(?anyLabel) = "" || langMatches(lang(?anyLabel), "en")) }
  OPTIONAL { ?element skos:definition ?anyDefinition . FILTER(lang(?anyDefinition) = "" || langMatches(lang(?anyDefinition), "en")) }
  OPTIONAL {
    ?relationship arch:source ?element ;
                  arch:target ?other ;
                  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 } } } }
    OPTIONAL { ?other skos:prefLabel ?otherLabel . FILTER(lang(?otherLabel) = "" || langMatches(lang(?otherLabel), "en")) }
    BIND(CONCAT(REPLACE(STR(?relationshipType), "^.*[#/]", ""), " → ",
                COALESCE(STR(?otherLabel), STR(?other))) AS ?link)
  }
}
GROUP BY ?element ?type
ORDER BY ?type ?label
Source: linked-archi-meta • Linked.Archi