Skip to content

ArchiMate 4.0 Primer & Modelling Guide — Enterprise Architecture with Linked.Archi

Tailor · Model · Validate · Derive · Present · Link

ArchiMate 4 Hexagonion — as a linked-data ontology for enterprise architecture modelling

This guide introduces ArchiMate 4.0 (the "Hexagonion") as formalised in Linked.Archi, and walks through everything the language and its semantic assets let you do: read a model, author one, validate it, derive new facts from it, present it to different audiences, tailor it to your organisation, and link it to other notations.

It is both breadth-complete and self-contained: every capability is demonstrated here with enough depth to be actionable, including the full reference patterns, the derivation mechanics, and the validation pipeline.

Orientation

What ArchiMate 4.0 is

ArchiMate is an open and independent enterprise architecture modeling language published by The Open Group. Version 4.0 — nicknamed the "Hexagonion" — introduces a fundamental restructuring from the layer-based model of 3.x to a domain-based organisation.

Key changes from 3.x:

  • Layers → Domains — Business, Application, Technology layers replaced by Common, Business, Application, Technology, Strategy, Motivation, and Implementation & Migration domains
  • Merged behaviour elements — per-layer duplicates (BusinessProcess, ApplicationProcess, TechnologyProcess) merged into single cross-domain elements (Process, Function, Event, Service)
  • Common Domain — new domain for generic, domain-independent concepts (Role, Collaboration, Path, Grouping, Location)
  • Merged Technology & Physical — the Physical layer from 3.x is merged into the Technology Domain (Equipment, Facility, Distribution Network, Material)
  • Removed elements — Interaction, Contract, Representation, Gap, ImplementationEvent, Constraint removed

ArchiMate 4.0 specification: https://pubs.opengroup.org/architecture/archimate4-doc/

What Linked.Archi adds

In Linked.Archi, ArchiMate 4.0 is not a diagramming convention — it is a formally defined modeling language whose definition is a queryable knowledge graph. The language is published as a set of W3C-standard semantic assets, tied together by a single manifest. Each W3C standard plays one role, with no overlap:

  • OWL defines what the concepts mean — the element and relationship vocabulary and its hierarchy.
  • SHACL defines what a conforming model must satisfy — closed-world validation rules.
  • SKOS defines how concepts are classified and navigated — the taxonomies behind palettes, filters, and views.
  • SPARQL is how you query and traverse the model.

This is what turns "boxes and arrows" into something a machine can validate, reason over, and generate documents from.

The manifest is your map

A Linked.Archi metamodel (arch:Metamodel) is a manifest — a single resource that aggregates all the assets making up the language. The ArchiMate 4.0 manifest lives at https://meta.linked.archi/archimate4/metamodel# and ties together the resources below. Keep this picture in mind; every section of this guide "lights up" one node of it.

ArchiMate 4 Metamodel Manifest Map The manifest aggregates all semantic assets making up the language definition. Browse the live manifest ▶

am4mm:ArchiMate4
    a                              arch:Metamodel ;
    arch:modelConcepts             <https://meta.linked.archi/archimate4/onto#> ;
    arch:conceptClassification     <https://meta.linked.archi/archimate4/tax#> ;
    arch:formalRules               <https://meta.linked.archi/archimate4/shapes#> ,
                                   <https://meta.linked.archi/archimate4/element-shapes#> ,
                                   <https://meta.linked.archi/archimate4/principle-shapes#> ;
    arch:derivationRules           <https://meta.linked.archi/archimate4/derivation#> ;
    arch:architectureViewpoints    <https://meta.linked.archi/archimate4/viewpoints#> ;
    arch:viewpointLibrary          am4vp:ViewpointCatalog ;
    arch:hasDeliverableTemplate    am4dt:ArchitectureDefinitionDocument ,
                                   am4dt:ArchitectureRequirementsSpec ,
                                   am4dt:ArchitecturePrinciplesDocument ;
    arch:referenceData             am4rd:ArchiMateReferenceData ;
    arch:referenceModels           am4rm:ArchiMateReferenceModels ;
    arch:presentationContextScheme am4pc:ArchiMatePresentationContexts ;
    arch:notationSet               am4not:ArchiMate40StandardNotation .

File structure

File Purpose
archimate4-metamodel.ttl Metamodel manifest aggregating all constituent resources
archimate4-onto.ttl Element classes, abstract hierarchy, and 11 relationship types (three-declaration pattern)
archimate4-tax.ttl SKOS taxonomy classifying elements by domain and aspect
archimate4-element-shapes.ttl SHACL shapes for structural integrity
archimate4-relationship-shapes.ttl SHACL shapes for valid source/target pairs (relationship validity matrix)
archimate4-principle-shapes.ttl SHACL shapes for architecture governance principles
archimate4-viewpoint-shapes.ttl SHACL shapes validating viewpoint conformance
archimate4-viewpoints.ttl Viewpoint definitions with allowed concepts and stakeholder targeting
archimate4-derivation-rules.ttl SPARQL-based derivation rules with PROV-O provenance
archimate4-deliverable-templates.ttl Document templates (ADD, ARS, APD)
archimate4-reference-data.ttl Reference data (access types, etc.)
archimate4-reference-models.ttl Architecture patterns
archimate4-presentation-contexts.ttl Stakeholder-specific rendering themes
archimate4-notation.ttl Visual notation set
icons/ SVG icons for all element types

Prerequisites

To author and validate a model, load the assets in this order (foundation first):

core/core-onto.ttl                                       # shared foundation (arch:*)
modelingLanguages/archimate/4.0/archimate4-onto.ttl      # elements + relationships
modelingLanguages/archimate/4.0/archimate4-tax.ttl       # SKOS taxonomy
modelingLanguages/archimate/4.0/archimate4-element-shapes.ttl
modelingLanguages/archimate/4.0/archimate4-relationship-shapes.ttl
modelingLanguages/archimate/4.0/archimate4-viewpoints.ttl
modelingLanguages/archimate/4.0/archimate4-notation.ttl
modelingLanguages/archimate/4.0/archimate4-metamodel.ttl # the manifest (entry point)

Throughout, these prefixes are assumed:

@prefix owl:     <http://www.w3.org/2002/07/owl#> .
@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix sh:      <http://www.w3.org/ns/shacl#> .
@prefix prov:    <http://www.w3.org/ns/prov#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix arch:    <https://meta.linked.archi/core#> .
@prefix am4:     <https://meta.linked.archi/archimate4/onto#> .
@prefix am4vp:   <https://meta.linked.archi/archimate4/viewpoints#> .
@prefix am4rd:   <https://meta.linked.archi/archimate4/reference-data#> .

Part 1 — The Language

ArchiMate 4.0 classifies every element along two orthogonal dimensions: by aspect (what kind of thing it is) and by domain (where it belongs). In Linked.Archi both dimensions are real, queryable structures, not just prose — they are the tax SKOS concept scheme.

By Aspect (what kind of thing)

ArchiMate 4 Elements by Aspect The aspect hierarchy — see the full ArchiMate 4 Taxonomy for all elements under each aspect.

ArchiMate 4 Aspect Dimensions The six aspect dimensions of ArchiMate 4.

By Domain (where it belongs)

ArchiMate 4 Elements by Domain Seven architecture domains replace the traditional layer model — see the full ArchiMate 4 Taxonomy for all elements under each domain.

Domain Scope Key elements
Common Domain-independent Process, Function, Event, Service, Role, Collaboration, Path, Grouping, Location
Business Business-specific Business Actor, Business Interface, Business Object, Product
Application Software systems Application Component, Application Interface, Data Object
Technology Infrastructure & physical Node, Device, System Software, Technology Interface, Communication Network, Distribution Network, Equipment, Facility, Artifact, Material
Strategy Strategic planning Resource, Capability, Value Stream, Course of Action
Motivation Why architecture exists Stakeholder, Driver, Assessment, Goal, Outcome, Principle, Requirement, Meaning, Value
Implementation & Migration Change management Work Package, Deliverable, Plateau

The bridge — these dimensions are an asset. Both dimensions are published as one SKOS concept scheme (tax). Each element is classified twice — once under a domain, once under an aspect — so a single SPARQL query can ask "every Behaviour element" or "every Common-Domain element" without enumerating types by hand:

am4:ArchiMateConceptScheme a skos:ConceptScheme ;
    skos:prefLabel "ArchiMate 4.0 Concept Scheme"@en ;
    skos:hasTopConcept am4:CommonDomain , am4:BusinessDomain , am4:ApplicationDomain ,
                       am4:TechnologyDomain , am4:StrategyDomain , am4:MotivationDomain ,
                       am4:ImplementationMigrationDomain ,
                       am4:BehaviourAspect , am4:ActiveStructureAspect , am4:PassiveStructureAspect ,
                       am4:MotivationAspect , am4:CompositeAspect , am4:StrategyAspect .

# "Process" is classified on BOTH axes:
am4:ProcessConcept a skos:Concept ;
    skos:prefLabel "Process"@en ;
    skos:broader am4:CommonDomain , am4:BehaviourAspect ;
    rdfs:seeAlso am4:Process .          # links the SKOS concept to the OWL class (no punning)

Note the rdfs:seeAlso bridge: the SKOS concept and the OWL class are kept as separate resources (Linked.Archi never puns an IRI as both). The class carries logical semantics for reasoners and shapes; the concept carries navigation for palettes and filters.

Elements by Domain — Visual Notation

Below, each domain's concrete elements are shown with their notation. Under each table is one representative OWL declaration so you can see the shape of an element class.

Common Domain

Element Notation Aspect IRI
Process Process Internal Behaviour am4:Process
Function Function Internal Behaviour am4:Function
Event Event Event am4:Event
Service Service External Behaviour am4:Service
Role Role Internal Active Structure am4:Role
Collaboration Collaboration Internal Active Structure am4:Collaboration
Path Path Active Structure am4:Path
Grouping Grouping Composite am4:Grouping
Location Location Composite am4:Location 
am4:Process a owl:Class ;
    rdfs:subClassOf am4:CommonDomainElement , am4:BehaviourElement ;
    arch:isAbstractClass false ;
    skos:prefLabel "Process"@en ;
    skos:definition "A sequence of behaviours that achieves a specific outcome."@en .

The 4.0 headline. am4:Process, am4:Function, am4:Event, and am4:Service are single Common-Domain classes — the merge of the per-layer duplicates from 3.x. A process in the business and a process in the application use the same class, distinguished (if you wish) by what they are assigned to and what they serve, not by their type.

Business Domain

Element Notation Aspect IRI
Business Actor Business Actor Internal Active Structure am4:BusinessActor
Business Interface Business Interface External Active Structure am4:BusinessInterface
Business Object Business Object Passive Structure am4:BusinessObject
Product Product Composite am4:Product 
am4:BusinessObject a owl:Class ;
    rdfs:subClassOf am4:BusinessDomainElement , am4:PassiveStructureElement ;
    arch:isAbstractClass false ;
    skos:prefLabel "Business Object"@en .

Application Domain

Element Notation Aspect IRI
Application Component Application Component Internal Active Structure am4:ApplicationComponent
Application Interface Application Interface External Active Structure am4:ApplicationInterface
Data Object Data Object Passive Structure am4:DataObject 
am4:ApplicationComponent a owl:Class ;
    rdfs:subClassOf am4:ApplicationDomainElement , am4:InternalActiveStructureElement ;
    arch:isAbstractClass false ;
    skos:prefLabel "Application Component"@en .

Technology Domain

Element Notation Aspect IRI
Node Node Internal Active Structure am4:Node
Device Device Internal Active Structure am4:Device
System Software System Software Internal Active Structure am4:SystemSoftware
Technology Interface Technology Interface External Active Structure am4:TechnologyInterface
Communication Network Communication Network Active Structure am4:CommunicationNetwork
Distribution Network Distribution Network Active Structure am4:DistributionNetwork
Equipment Equipment Internal Active Structure am4:Equipment
Facility Facility Internal Active Structure am4:Facility
Artifact Artifact Passive Structure am4:Artifact
Material Material Passive Structure am4:Material 
am4:Node a owl:Class ;
    rdfs:subClassOf am4:TechnologyDomainElement , am4:InternalActiveStructureElement ;
    arch:isAbstractClass false ;
    skos:prefLabel "Node"@en .

Strategy Domain

Element Notation Aspect IRI
Capability Capability Strategy Behaviour am4:Capability
Resource Resource Structure am4:Resource
Value Stream Value Stream Strategy Behaviour am4:ValueStream
Course of Action Course of Action Strategy Behaviour am4:CourseOfAction 
am4:Capability a owl:Class ;
    rdfs:subClassOf am4:StrategyDomainElement , am4:StrategyElement ;
    arch:isAbstractClass false ;
    skos:prefLabel "Capability"@en .

Motivation Domain

Element Notation Aspect IRI
Stakeholder Stakeholder Motivation am4:Stakeholder
Driver Driver Motivation am4:Driver
Assessment Assessment Motivation am4:Assessment
Goal Goal Motivation am4:Goal
Outcome Outcome Motivation am4:Outcome
Principle Principle Motivation am4:Principle
Requirement Requirement Motivation am4:Requirement
Meaning Meaning Motivation am4:Meaning
Value Value Motivation am4:Value 
am4:Requirement a owl:Class ;
    rdfs:subClassOf am4:MotivationDomainElement , am4:MotivationElement ;
    arch:isAbstractClass false ;
    skos:prefLabel "Requirement"@en .

Implementation & Migration Domain

Element Notation Aspect IRI
Work Package Work Package Behaviour am4:WorkPackage
Deliverable Deliverable Passive Structure am4:Deliverable
Plateau Plateau Composite am4:Plateau 
am4:WorkPackage a owl:Class ;
    rdfs:subClassOf am4:ImplementationMigrationDomainElement , am4:BehaviourElement ;
    arch:isAbstractClass false ;
    skos:prefLabel "Work Package"@en .

Abstract vs Concrete Classes

The two hierarchies above are anchored by abstract classes — marked arch:isAbstractClass true. They are not instantiable (you never type an element as am4:BehaviourElement); they exist so that queries, shapes, and tool palettes can generalise. Because rdfs:subClassOf carries monotonic inference, anything typed as am4:Process is automatically an am4:BehaviourElement, an am4:CommonDomainElement, and an arch:Element — without you asserting it.

Abstract (by aspect) Abstract (by domain) Concrete examples
BehaviourElement CommonDomainElement Process, Function, Event, Service
ActiveStructureElement BusinessDomainElement Business Actor, Business Interface
InternalActiveStructureElement ApplicationDomainElement Application Component
ExternalActiveStructureElement TechnologyDomainElement Node, Device, System Software
PassiveStructureElement StrategyDomainElement Resource, Capability, Value Stream
MotivationElement ImplementationMigrationDomainElement Work Package, Plateau
CompositeElement Grouping, Location

Relationships (11 types)

ArchiMate 4 Relationship Types Eleven relationship types organised by category.

Category Relationship Meaning IRI
Structural Composition Element consists of other elements (existence dependency) am4:composedOf
Structural Aggregation Element combines other elements am4:aggregates
Structural Assignment Active structure performs behaviour am4:assignedTo
Structural Realization Element plays a critical role in creation or operation of another am4:realizes
Dependency Serving Element provides its functionality to another am4:serves
Dependency Access Behaviour or active structure observes or acts upon passive structure am4:accesses
Dependency Influence Element affects the implementation or achievement of a motivation element am4:influences
Dynamic Triggering Temporal or causal relationship between elements am4:triggers
Dynamic Flow Transfer from one element to another am4:flowsTo
Other Specialization Element is a particular kind of another element am4:specializes
Other Association Unspecified relationship, or one not represented by another type am4:associatedWith

The Three-Declaration Relationship Pattern

This is the single most distinctive Linked.Archi pattern. Every relationship type has three representations, because enterprise architecture needs both cheap graph traversal and rich relationship management. Using Serving as the example:

## 1. Direct predicate — for fast SPARQL traversal and analytics
am4:serves a owl:ObjectProperty ;
    skos:prefLabel "Serves"@en ;
    arch:domainIncludes arch:Element ;          # tooling hint, not a constraint
    arch:rangeIncludes  arch:Element .

## 2. Qualified relationship class — a reified resource carrying metadata, lifecycle, provenance
am4:Serving a owl:Class ;
    rdfs:subClassOf arch:QualifiedRelationship ;
    arch:unqualifiedForm am4:serves ;
    skos:prefLabel "Serving"@en .

## 3. Qualified property — navigates from a source to its qualified resource
am4:qualifiedServes a owl:ObjectProperty ;
    rdfs:range am4:Serving ;
    arch:unqualifiedForm am4:serves .

Why three? The direct predicate (am4:serves) answers "what serves what?" in one cheap triple pattern. But suppose the same component serves the same process in two different ways, each with its own lifecycle state and owner — a bare predicate cannot tell those edges apart. The qualified am4:Serving resource can, because it is a thing in its own right with arch:source, arch:target, and any metadata you attach. The RDF 1.2 reification bridge ties the two together:

# The cheap edge — always present
ex:BookingService am4:serves ex:FreightOperations .

# The same fact as a managed resource, with metadata
ex:serving-001 a am4:Serving ;
    arch:source  ex:BookingService ;
    arch:target  ex:FreightOperations ;
    arch:lifecycleState "production" ;
    dcterms:created "2025-06-27"^^xsd:date ;
    rdf:reifies <<( ex:BookingService am4:serves ex:FreightOperations )>> .   # RDF 1.2 bridge

Rule of thumb: write the direct predicate by default. Promote an edge to a qualified resource only when you need to say something about the relationship itself (provenance, lifecycle, multiple distinct edges, confidence). The full rationale is in the Relationship Modeling Guide.

Part 2 — Authoring a Model

Everything from here on uses one running example, NordFreight Logistics — a Scandinavian freight company modernising its shipment-tracking platform and integrating with EU customs systems for post-Brexit trade compliance. The complete, validatable model is at examples/nordfreight/nordfreight-model.ttl.

Model Header

A model is an arch:Model that declares which metamodel it conforms to:

@prefix : <https://model.nordfreight.example/> .

:NordFreightModel
    a                             arch:Model ;
    skos:prefLabel                "NordFreight Logistics — Architecture Model"@en ;
    arch:modelConformsToMetamodel <https://meta.linked.archi/archimate4/metamodel#ArchiMate4> ;
    dcterms:created               "2025-06-27"^^xsd:date .

Element Patterns

Each element needs only rdf:type and a language-tagged skos:prefLabel to be valid. Grouped by domain:

## Motivation
:EUCustomsCompliance a am4:Requirement ; skos:prefLabel "EU Customs Compliance"@en .
:OperationalEfficiency a am4:Goal ; skos:prefLabel "Operational Efficiency"@en .
:ShipperStakeholder a am4:Stakeholder ; skos:prefLabel "Shipper"@en .

## Strategy
:ShipmentTracking a am4:Capability ; skos:prefLabel "Shipment Tracking"@en .
:FreightBooking a am4:Capability ; skos:prefLabel "Freight Booking"@en .
:CustomsClearance a am4:Capability ; skos:prefLabel "Customs Clearance"@en .

## Business + Common-Domain behaviour
:BookingProcess a am4:Process ; skos:prefLabel "Booking Process"@en .
:TrackingService a am4:Service ; skos:prefLabel "Shipment Tracking Service"@en .
:FreightOperations a am4:Role ; skos:prefLabel "Freight Operations"@en .
:Shipment a am4:BusinessObject ; skos:prefLabel "Shipment"@en .

## Application — Functions (behaviour performed by components)
:BookingFunction a am4:Function ; skos:prefLabel "Booking Function"@en .
:TrackingFunction a am4:Function ; skos:prefLabel "Tracking Function"@en .
:CustomsFunction a am4:Function ; skos:prefLabel "Customs Processing"@en .

## Application — Services (exposed to consumers)
:BookingService a am4:Service ; skos:prefLabel "Booking Service"@en .

## Application — Components (active structure)
:TMS a am4:ApplicationComponent ; skos:prefLabel "Transport Management System"@en .
:TrackingPortal a am4:ApplicationComponent ; skos:prefLabel "Tracking Portal"@en .
:CustomsGateway a am4:ApplicationComponent ; skos:prefLabel "Customs Gateway"@en .
:ShipmentData a am4:DataObject ; skos:prefLabel "Shipment Data"@en .

## Technology
:AzureCloud a am4:Node ; skos:prefLabel "Azure North Europe"@en .
:K8sCluster a am4:SystemSoftware ; skos:prefLabel "AKS Kubernetes Cluster"@en .
:IoTGateway a am4:Device ; skos:prefLabel "IoT Tracking Gateway"@en .

## Implementation & Migration
:PlatformModernisation a am4:WorkPackage ; skos:prefLabel "Platform Modernisation"@en .
:TargetState a am4:Plateau ; skos:prefLabel "Target Architecture 2027"@en .

Relationship Patterns

Direct predicates for the bulk of the model:

## Assignment — active structure performs behaviour
:FreightOperations am4:assignedTo :BookingProcess .

## Application layer — the proper Component → Function → Service → Consumer pattern
:TMS           am4:assignedTo :BookingFunction .     # component performs function
:BookingFunction am4:realizes :BookingService .      # function provides service
:BookingService  am4:serves   :FreightOperations .   # service serves the role

:TrackingPortal  am4:assignedTo :TrackingFunction .
:TrackingFunction am4:realizes :TrackingService .
:TrackingService  am4:serves   :FreightOperations .

:CustomsGateway  am4:assignedTo :CustomsFunction .   # component performs function
:CustomsFunction am4:realizes :CustomsClearance .    # function realizes capability directly

## Realization — process/service realizes a capability
:BookingProcess am4:realizes :FreightBooking .
:TrackingService am4:realizes :ShipmentTracking .

## Serving — technology layer (valid: infra serves component)
:K8sCluster am4:serves :TMS .          # system software serves the application
:AzureCloud am4:serves :K8sCluster .   # node serves the system software

## Access — behaviour accesses passive structure
:BookingProcess am4:accesses :Shipment .
:TMS am4:accesses :ShipmentData .

## Structural + dynamic
:AzureCloud am4:composedOf :K8sCluster .
:TMS am4:flowsTo :CustomsGateway .
:BookingProcess am4:triggers :TrackingService .
:CustomsGateway am4:realizes :EUCustomsCompliance .
:PlatformModernisation am4:aggregates :TargetState .

Read One Fragment Three Ways

To make the pairing concrete, here is the Customs Gateway corner of the model — as a diagram, as direct predicates, and as a qualified resource:

NordFreight Customs Gateway Fragment The Customs Gateway corner — component realizes requirement, component assigned to function, function realizes capability, flow from TMS. View source model · Try it out ▶

# Direct predicates (the diagram, literally)
:CustomsGateway am4:realizes :EUCustomsCompliance .
:CustomsGateway      am4:assignedTo :CustomsFunction .
:CustomsFunction     am4:realizes   :CustomsClearance .
:TMS                 am4:flowsTo    :CustomsGateway .

# The assignment promoted to a managed resource, because we want to record why and since when
:cg-assigned-customs-fn a am4:Assignment ;
    arch:source :CustomsGateway ;
    arch:target :CustomsFunction ;
    arch:lifecycleState "planned" ;
    dcterms:created "2025-06-27"^^xsd:date ;
    rdf:reifies <<( :CustomsGateway am4:assignedTo :CustomsFunction )>> .

A Cross-Domain View

NordFreight Layered View A cross-domain layered view spanning motivation, strategy, business, application, and technology. View source model · Try it out ▶

This view conforms to the Cross-Domain (Layered) viewpoint — we will make that conformance checkable in Part 5.

Layered View

NordFreight Layered View A complete layered architecture view spanning motivation, strategy, business, application, and technology. View source model · Try it out ▶

Part 3 — Validating the Model

ArchiMate semantics that constrain a model live in SHACL, not OWL. This is deliberate: OWL works under the open-world assumption (a missing fact is merely unknown), whereas governance needs the closed-world opposite — "every application must have an owner" should be a checkable rule whose violation is an error, not an invitation to infer a missing owner. The manifest publishes three shape families, each answering a different question.

3.1 Element & Metamodel Validation (element-shapes)

Are the elements well-formed? The simplest shape requires every element to carry exactly one language-tagged label:

am4:ElementShape a sh:NodeShape ;
    sh:targetClass arch:Element ;
    sh:property [
        sh:path skos:prefLabel ;
        sh:minCount 1 ;
        sh:datatype rdf:langString ;
        sh:message "Every element must have at least one language-tagged skos:prefLabel."@en ;
    ] .

Passing: :TMS a am4:ApplicationComponent ; skos:prefLabel "Transport Management System"@en .

Failing, and the report it produces:

# Offending data
:Orphan a am4:ApplicationComponent .     # no prefLabel

# Validation result
[ a sh:ValidationResult ;
  sh:focusNode            :Orphan ;
  sh:resultPath           skos:prefLabel ;
  sh:sourceShape          am4:ElementShape ;
  sh:resultSeverity       sh:Violation ;
  sh:resultMessage        "Every element must have at least one language-tagged skos:prefLabel."@en ] .

3.2 Relationship-Validity Validation (shapes)

Is this edge legal? ArchiMate's relationship rules state which element types may connect via which relationship — the validity matrix in Appendix B of the specification. Linked.Archi generates SHACL from that matrix. For example, Assignment runs from an active-structure element to a behaviour element:

am4:AssignmentValidityShape a sh:NodeShape ;
    sh:targetSubjectsOf am4:assignedTo ;
    sh:property [
        sh:path am4:assignedTo ;
        sh:class am4:BehaviourElement ;        # target must be behaviour
        sh:message "Assignment target must be a Behaviour element."@en ;
    ] ;
    sh:class am4:ActiveStructureElement .       # source must be active structure

:FreightOperations am4:assignedTo :BookingProcess passes (Role → Process). The following fails, because a Data Object is passive structure, not behaviour:

:ShipmentData am4:assignedTo :BookingProcess .   # ✗ source is passive structure
# → sh:ValidationResult: "Assignment source must be an Active Structure element."

The complete Appendix B matrix — all 11 relationships against all element pairs — is published as SHACL in archimate4-relationship-shapes.ttl. The shapes are generated directly from the specification's validity tables.

3.3 Principle Validation (principle-shapes)

Does the model satisfy our governance rules? This is where SHACL becomes architecture compliance as code — rules you run in CI/CD on every commit, not in a quarterly review. A common principle: every Application Component must have an owner.

am4:AppComponentOwnerPrinciple a sh:NodeShape ;
    sh:targetClass am4:ApplicationComponent ;
    sh:property [
        sh:path arch:owner ;
        sh:minCount 1 ;
        sh:severity sh:Violation ;
        sh:message "Every Application Component must declare an owner."@en ;
    ] .

Run against NordFreight as authored so far, :TMS, :TrackingPortal, and :CustomsGateway all fail — none has an owner. We will fix this in Part 7 without editing the ArchiMate model at all, by linking to the Backstage catalog that already knows the owners.

3.4 Viewpoint Conformance (viewpoint-shapes)

Does this view show only what its viewpoint allows? A arch:View that declares conformance to a viewpoint can be checked against the element types that viewpoint permits — data-driven, reading the viewpoint definition from the graph. (See Part 5 for the viewpoint definitions this checks against.)

Running It

.scripts/validate.sh --shacl nordfreight-model.ttl \
    core/core-shapes.ttl \
    modelingLanguages/archimate/4.0/archimate4-element-shapes.ttl \
    modelingLanguages/archimate/4.0/archimate4-relationship-shapes.ttl \
    modelingLanguages/archimate/4.0/archimate4-principle-shapes.ttl

You now understand every file passed to it: element well-formedness, relationship legality, and governance principles, in one pass.

Part 4 — Deriving and Inferring New Facts

A model states some relationships explicitly; many more are implied. ArchiMate's derivation rules say that a valid chain of relationships permits a derived relationship between its endpoints. In Linked.Archi these are sh:SPARQLRules, and every derived fact is annotated with provenance (PROV-O) and a confidence level — so inferred knowledge never silently masquerades as asserted knowledge.

One Derivation Rule

If an application component is assigned to a function, and that function realizes a capability, then the component realizes the capability:

am4:AssignRealizeDerivation a sh:NodeShape ;
    sh:rule [
        a sh:SPARQLRule ;
        sh:construct """
            PREFIX am4: <https://meta.linked.archi/archimate4/onto#>
            PREFIX prov: <http://www.w3.org/ns/prov#>
            PREFIX arch: <https://meta.linked.archi/core#>
            CONSTRUCT {
                ?comp am4:realizes ?cap .
                ?d a am4:Realization ;
                   arch:source ?comp ; arch:target ?cap ;
                   arch:confidence "derived" ;
                   prov:wasGeneratedBy am4:AssignRealizeDerivation ;
                   prov:wasDerivedFrom ?fn .
            }
            WHERE {
                ?comp am4:assignedTo ?fn .
                ?fn   am4:realizes ?cap .
                BIND(IRI(CONCAT(STR(?comp), "-realizes-", STRAFTER(STR(?cap), "#"))) AS ?d)
            }
        """ ;
    ] .

Before and After

NordFreight — Derivation Example The red edge (Portal realizes Capability) is derived from the chain: Portal assigned to Function, Function realizes Capability. View source model · Try it out ▶

The derived edge is produced by the rule, carrying its lineage:

:TrackingPortal am4:realizes :ShipmentTracking .         # the derived triple

:TrackingPortal-realizes-ShipmentTracking a am4:Realization ;
    arch:source :TrackingPortal ;
    arch:target :ShipmentTracking ;
    arch:confidence "derived" ;
    prov:wasGeneratedBy am4:AssignRealizeDerivation ;
    prov:wasDerivedFrom :TrackShipment .

Querying — Including Impact Analysis

A short SPARQL warm-up on the model:

# 1. List every Application Component
PREFIX am4: <https://meta.linked.archi/archimate4/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?c ?label WHERE {
    ?c a am4:ApplicationComponent ; skos:prefLabel ?label .
}

# 2. Capabilities with no realizing behaviour (a gap-finder)
SELECT ?cap WHERE {
    ?cap a am4:Capability .
    FILTER NOT EXISTS { ?x am4:realizes ?cap }
}

# 3. Impact analysis — which capabilities ride on a given technology node?
#    Works over the DERIVED graph: AzureCloud serves K8s serves TMS assignedTo BookingFunction
#    realizes BookingService ... traversed transitively.
PREFIX am4: <https://meta.linked.archi/archimate4/onto#>
SELECT DISTINCT ?capability WHERE {
    :AzureCloud (am4:serves|am4:assignedTo|am4:composedOf|am4:realizes|am4:triggers)+ ?capability .
    ?capability a am4:Capability .
}

Query 3 is the home-page promise made literal: "what breaks if we retire this node?" becomes a property-path query rather than a week of manual tracing.

The derivation rules support two materialisation strategies: eager (run all rules at load time, store derived triples alongside asserted ones) or lazy (derive on query, using SPARQL property paths). Eager gives fast reads but requires re-materialisation on every model change; lazy has zero maintenance cost but slower queries on large graphs. The arch:confidence annotation ("derived" vs "asserted") ensures consumers can always distinguish inferred from authored facts regardless of strategy.

Part 5 — Viewpoints and Generating Presentations

A model is one source of truth; stakeholders need many tailored views of it. Linked.Archi separates viewpoints (the specification of a kind of view), presentation contexts (how a view is styled and filtered for an audience), and deliverable templates (SPARQL-driven documents) — all generated from the single model.

Viewpoints as First-Class Resources

A viewpoint is an arch:Viewpoint individual that names the element types it admits, the stakeholders it targets, and the concerns it frames:

am4vp:OrganizationViewpoint a arch:Viewpoint ;
    skos:prefLabel "Organization Viewpoint"@en ;
    arch:includesConcept am4:BusinessActor , am4:Role , am4:Collaboration , am4:BusinessInterface ;
    arch:targetsStakeholder am4vp:EnterpriseArchitect ;
    arch:viewpointFramesConcern am4vp:OrgStructureConcern ;
    arch:viewpointCoversAspect am4:ActiveStructureAspect ;
    arch:viewpointAddressesPerspective am4:OperationalPerspective .

A arch:View declares conformance to one viewpoint — and that conformance is exactly what the viewpoint-shapes from Part 3.4 check:

:NordFreightLayeredView a arch:View ;
    skos:prefLabel "NordFreight Cross-Domain View"@en ;
    arch:viewConformsToViewpoint am4vp:CrossDomainViewpoint .

Selected viewpoints (the full catalog is the SKOS ViewpointCatalog):

Viewpoint Focus
Organization Business actors, roles, collaborations
Application Structure Application components, interfaces, data objects
Technology Nodes, devices, system software, networks, equipment, facilities
Information Structure Business objects, data objects, and their relationships
Process Cooperation Processes, triggering, information exchange, supporting services
Service Realization How services are realized by processes and active structure
Stakeholder Stakeholders, drivers, assessments, goals, principles
Goal Realization Goals refined into sub-goals and realized by requirements
Requirements Realization Requirements realized by processes, components, services
Motivation Full motivation structure (stakeholders through values)
Strategy Resources, capabilities, value streams, courses of action
Capability Map Capability hierarchy and composition
Outcome Realization Outcomes realized by capabilities and core elements
Resource Map Resources assigned to capabilities
Implementation and Deployment Artifacts deployed on technology infrastructure
Migration Baseline-to-target transition via plateaus and work packages
Cross-Domain (Layered) Cross-domain traceability across all domains

Presentation Contexts — One Model, Many Renderings

A presentation context is a "theme" — it selects appropriate visual notations, templates, and abstraction levels for a given stakeholder audience. Rather than creating separate models, you query the same knowledge graph through different lenses. Presentation contexts are a SKOS concept scheme; each concept names the audience and describes what they need:

am4pc:ExecutiveContext
    a skos:Concept ; skos:topConceptOf am4pc:ArchiMatePresentationContexts ;
    skos:prefLabel "Executive / C-Level"@en ;
    skos:definition "High-level overview with minimal technical detail. Focus on business capabilities, strategic alignment, cost, and risk."@en ;
    arch:usesNotationSet am4not:ArchiMate40StandardNotation ;
    skos:inScheme am4pc:ArchiMatePresentationContexts .

am4pc:OperationsContext
    a skos:Concept ; skos:topConceptOf am4pc:ArchiMatePresentationContexts ;
    skos:prefLabel "Operations / Infrastructure"@en ;
    skos:definition "Focus on technology domain and deployment. Nodes, devices, networks, environments."@en ;
    arch:usesNotationSet am4not:ArchiMate40StandardNotation ;
    skos:inScheme am4pc:ArchiMatePresentationContexts .

Both use the standard notation set out of the box. Organisations that want a simplified visual treatment for executives can define their own notation set (e.g. flat boxes without ArchiMate icons) and reference it via arch:usesNotationSet. The skos:definition text on each context drives tooling decisions about which viewpoints to apply and what level of detail to include.

Presentation Contexts Same NordFreight model, two audiences — executives see capabilities and goals, tech-ops sees nodes and deployment.

Deliverable Templates — Model to Document

A deliverable template is a document structure whose sections are populated by SPARQL. The manifest ships three (Architecture Definition Document, Architecture Requirements Specification, Architecture Principles Document):

am4:ArchitectureDefinitionDocument a arch:DeliverableTemplate ;
    skos:prefLabel "Architecture Definition Document"@en ;
    arch:hasSection [
        skos:prefLabel "Application Portfolio"@en ;
        arch:populatedBy """
            SELECT ?c ?label WHERE {
                ?c a am4:ApplicationComponent ; skos:prefLabel ?label .
            } ORDER BY ?label
        """ ;
    ] .

Run the toolbox generator over NordFreight and the Application Portfolio section materialises as Markdown:

## Application Portfolio
- Customs Gateway
- Tracking Portal
- Transport Management System

The generator itself lives in the toolbox repository; see the Deliverable Generator Spec.

Part 6 — Tailoring and Extending the Language

The semantic assets are raw material, not a sealed package. Tailoring means adding resources the manifest already knows how to aggregate — never forking the language.

Add a Custom Element Type

Suppose NordFreight wants to single out regulatory integration points. Define :RegulatoryGateway as a subclass of am4:ApplicationComponent, register it for navigation, and constrain it — touching several assets coherently:

# onto — the class
:RegulatoryGateway a owl:Class ;
    rdfs:subClassOf am4:ApplicationComponent ;
    arch:isAbstractClass false ;
    skos:prefLabel "Regulatory Gateway"@en ;
    skos:definition "An application component that integrates with an external regulatory authority."@en .

# tax — so palettes and filters pick it up
:RegulatoryGatewayConcept a skos:Concept ;
    skos:prefLabel "Regulatory Gateway"@en ;
    skos:broader am4:ApplicationDomain , am4:ActiveStructureAspect ;
    rdfs:seeAlso :RegulatoryGateway .

# shapes — a tailored governance rule
:RegulatoryGatewayShape a sh:NodeShape ;
    sh:targetClass :RegulatoryGateway ;
    sh:property [
        sh:path am4:influences ;
        sh:minCount 1 ;
        sh:message "A Regulatory Gateway must be influenced by at least one Requirement."@en ;
    ] .

Now reclassify the Customs Gateway:

:CustomsGateway a :RegulatoryGateway ; skos:prefLabel "Customs Gateway"@en .

Because of rdfs:subClassOf, everything already written for am4:ApplicationComponent still applies — the owner principle (Part 3.3), the serving derivation (Part 4), the queries (Part 4), and the Application Structure viewpoint all continue to see :CustomsGateway, with no changes. That is the payoff of monotonic subsumption.

Compose with Extensions

Cross-cutting extensions import arch:core, so they attach to ArchiMate elements with no integration code. Record why the Customs Gateway pattern was chosen, and how the legacy TMS scores in portfolio terms:

@prefix ad:     <https://meta.linked.archi/arch-decision#> .
@prefix timefw: <https://meta.linked.archi/time-framework/onto#> .

:UseDedicatedCustomsGateway a ad:Decision ;
    skos:prefLabel "Use a dedicated Customs Gateway"@en ;
    ad:addresses :EUCustomsCompliance ;
    ad:affects   :CustomsGateway ;
    ad:status    "accepted" .

:TMSFitAssessment a timefw:FitAssessment ;
    timefw:assesses :TMS ;
    timefw:functionalFit "low" ;
    timefw:technicalFit  "low" ;
    timefw:classifiedAs  timefw:Migrate .   # → flagged for migration

Custom viewpoints, custom relationships (full three-declaration), and organisation-specific notation follow the same patterns shown above — subclass existing types, register in the taxonomy, and constrain with SHACL. See Build Your Own Metamodel for the full workflow.

Part 7 — Linking with Other Notations and Frameworks

Because every Linked.Archi language imports arch:core, an ArchiMate ApplicationComponent, a C4 Container, and a Backstage Component are all arch:Element instances. They coexist in one graph, share SHACL shapes, and answer the same SPARQL queries.

Cross-Notation Linking via arch:core All languages import arch:core, enabling cross-notation linking in one graph.

NordFreight's running estate is catalogued in Backstage, which knows ownership and lifecycle that the ArchiMate model does not. Link the two representations of the same system:

@prefix bs: <https://meta.linked.archi/backstage/onto#> .

# The Backstage catalog entry, with the owner ArchiMate lacked
bs:tracking-portal a bs:Component ;
    skos:prefLabel "tracking-portal"@en ;
    bs:lifecycle "production" ;
    arch:owner "team-shipment-tracking" .

# Establish that these are the same thing
:TrackingPortal owl:sameAs bs:tracking-portal .

Now ask a question no single tool could answer — and re-run the owner principle from Part 3.3:

# Which ArchiMate Application Components lack an owner, even after consulting Backstage?
PREFIX am4: <https://meta.linked.archi/archimate4/onto#>
PREFIX arch: <https://meta.linked.archi/core#>
SELECT ?c WHERE {
    ?c a am4:ApplicationComponent .
    FILTER NOT EXISTS { ?c arch:owner ?o }
}

With owl:sameAs reasoning, :TrackingPortal inherits arch:owner from bs:tracking-portal, so it now passes the principle — the governance gap was closed by linking, not by re-modelling. (:TMS and :CustomsGateway remain flagged until they too are catalogued.)

Other Pairings, in Brief

  • ArchiMate ↔ C4 — map an am4:ApplicationComponent to a C4 Container for developer-facing zoom-in. See Application Layer vs C4 Containers.
  • ArchiMate ↔ BPMN — drill a single am4:Process down into an executable BPMN flow when order, gateways, and exceptions matter.
  • ArchiMate ↔ TOGAF — cross-map elements to the TOGAF content metamodel so a NordFreight element participates in an ADM deliverable. See the TOGAF Modeling Guide.

The cross-mapping mechanics use owl:sameAs for identity (as shown above) or arch:relatedElement for weaker correspondence. Cross-boundary SPARQL queries then traverse the unified graph regardless of which notation originated each element.

Where to Go Next

You have now exercised every capability of ArchiMate 4.0 in Linked.Archi, each once: you read the language, authored a model, validated it three ways, derived new facts with provenance, rendered it for two audiences and a document, tailored it with a custom type and two extensions, and linked it to another notation. Re-reading the manifest map, every node is now lit.

Two things worth remembering. First, you never have to write SPARQL by hand: the Linked.Archi MCP server exposes this whole graph to AI agents, so a natural-language question ("what breaks if we retire Azure North Europe?") is translated to the query in Part 4 and answered against your real model. Second, every topic introduced here has a dedicated deep-dive article — the Relationship Modeling Guide, the Validation Guide, and the Design Decisions expand on the patterns shown above.

Further Reading

Disclaimer: This is a community semantic representation of ArchiMate for interoperability purposes. It is not produced by, endorsed by, or affiliated with The Open Group. "ArchiMate" is a registered trademark of The Open Group.