Linked.Archi Architecture Principle Shapes
SHACL shapes encoding common enterprise architecture principles and best practices as executable constraints. These shapes validate architecture models against governance patterns such as redundancy avoidance, single authoritative source, separation of concerns, stewardship, and technology standardization. Inspired by the ontology-based EA principle validation approach described in: Montecchiari, D.; Hinkelmann, K. (2026) "Ontology-Based Validation of Enterprise Architecture Principles", Applied Sciences, 16(7):3352. These shapes are designed to be loaded alongside the standard ArchiMate element and relationship shapes. They operate on instance data (architecture models) and detect violations of common governance principles. All shapes use sh:severity sh:Warning by default — organizations should promote specific shapes to sh:Violation based on their governance policies. Usage: ./validate.sh --shacl archimate-principles Or load manually alongside other shapes: core-shapes.ttl + archimate3.2-principle-shapes.ttl + your-model-data.ttl
Linked.Archi
Redundant Application Serving
Detects business processes served by more than one application component. Multiple applications serving the same process may indicate redundancy that should be consolidated or justified.
Business process {$this} is served by multiple application components ({?app1} and {?app2}), indicating potential redundancy.
SELECT $this ?app1 ?app2 WHERE { $this a am:BusinessProcess . ?app1 a am:ApplicationComponent ; am:serves $this . ?app2 a am:ApplicationComponent ; am:serves $this . FILTER(STR(?app1) < STR(?app2)) }
Redundant Application Realizing Service
Detects application services realized by more than one application component. Multiple components realizing the same service may indicate duplication in the application landscape.
Application service {$this} is realized by multiple application components ({?app1} and {?app2}).
SELECT $this ?app1 ?app2 WHERE { $this a am:ApplicationService . ?app1 a am:ApplicationComponent ; am:realizes $this . ?app2 a am:ApplicationComponent ; am:realizes $this . FILTER(STR(?app1) < STR(?app2)) }
Redundant Function Support
Detects business functions served by more than one application component. Consolidation candidates for application rationalization.
Business function {$this} is served by multiple application components ({?app1} and {?app2}).
SELECT $this ?app1 ?app2 WHERE { $this a am:BusinessFunction . ?app1 a am:ApplicationComponent ; am:serves $this . ?app2 a am:ApplicationComponent ; am:serves $this . FILTER(STR(?app1) < STR(?app2)) }
Single Authoritative Data Writer
Detects data objects accessed with write by more than one application component. Each data object should have a single authoritative source of updates to ensure consistency.
Data object {$this} is written by multiple application components ({?app1} and {?app2}). Designate a single authoritative source.
SELECT $this ?app1 ?app2 WHERE { $this a am:DataObject . ?app1 a am:ApplicationComponent ; am:accesses $this . ?app2 a am:ApplicationComponent ; am:accesses $this . FILTER(STR(?app1) < STR(?app2)) }
Single Business Object Owner
Detects business objects accessed by more than one application component. Shared access without clear ownership creates governance ambiguity.
Business object {$this} is accessed by multiple application components ({?app1} and {?app2}). Clarify ownership.
SELECT $this ?app1 ?app2 WHERE { $this a am:BusinessObject . ?app1 a am:ApplicationComponent ; am:accesses $this . ?app2 a am:ApplicationComponent ; am:accesses $this . FILTER(STR(?app1) < STR(?app2)) }
Application Component Ownership
Every application component should be assigned to at least one business actor or role that owns or operates it.
Application component {$this} has no assigned business actor or role. Assign ownership.
SELECT $this WHERE { $this a am:ApplicationComponent . FILTER NOT EXISTS { { ?actor am:assignedTo $this . ?actor rdf:type/rdfs:subClassOf* am:ActiveStructureElement . ?actor rdf:type/rdfs:subClassOf* am:BusinessLayerElement . } UNION { $this am:assignedTo ?actor . ?actor rdf:type/rdfs:subClassOf* am:ActiveStructureElement . ?actor rdf:type/rdfs:subClassOf* am:BusinessLayerElement . } } }
Business Process Ownership
Every business process should be assigned to at least one business role or actor that is responsible for it.
Business process {$this} has no assigned business role or actor.
SELECT $this WHERE { $this a am:BusinessProcess . FILTER NOT EXISTS { ?role rdf:type/rdfs:subClassOf* am:ActiveStructureElement . ?role rdf:type/rdfs:subClassOf* am:BusinessLayerElement . ?role am:assignedTo $this . } }
Data Object Stewardship
Critical data objects should have at least one application component that realizes or accesses them, establishing a clear system of record.
Data object {$this} has no application component accessing or realizing it. Assign a system of record.
SELECT $this WHERE { $this a am:DataObject . FILTER NOT EXISTS { ?app a am:ApplicationComponent . { ?app am:accesses $this . } UNION { ?app am:realizes $this . } } }
Business Process Direct Technology Dependency
Business processes should not directly depend on technology layer elements. An application layer should mediate between business and technology.
Business process {$this} has a direct serving/realization dependency on technology element {?tech}. Introduce an application layer mediator.
SELECT $this ?tech WHERE { $this a am:BusinessProcess . { ?tech am:serves $this . } UNION { ?tech am:realizes $this . } ?tech rdf:type/rdfs:subClassOf* am:TechnologyLayerElement . }
Technology Serving Business Directly
Technology nodes should not directly serve business layer elements. Services should be exposed through the application layer.
Technology node {$this} directly serves business element {?biz}. Route through the application layer.
SELECT $this ?biz WHERE { $this a am:Node . $this am:serves ?biz . ?biz rdf:type/rdfs:subClassOf* am:BusinessLayerElement . }
Application Component Without Service
Application components should expose at least one application service. Components without services may indicate missing service definitions or tightly coupled integrations.
Application component {$this} does not expose any application service.
SELECT $this WHERE { $this a am:ApplicationComponent . FILTER NOT EXISTS { $this am:realizes ?svc . ?svc a am:ApplicationService . } }
Direct Component-to-Component Serving
Application components should serve other components through services, not directly. Direct serving creates tight coupling that hinders independent evolution.
Application component {$this} directly serves another application component {?target} without an intermediary service.
SELECT $this ?target WHERE { $this a am:ApplicationComponent . $this am:serves ?target . ?target a am:ApplicationComponent . }
Excessive Technology Diversity Per Service
Application services realized by components deployed on many different technology nodes may indicate excessive technology diversity.
Application service {$this} depends on {?nodeCount} distinct technology nodes. Consider standardizing.
SELECT $this (COUNT(DISTINCT ?node) AS ?nodeCount) WHERE { $this a am:ApplicationService . ?app am:realizes $this . ?app a am:ApplicationComponent . ?node am:assignedTo ?app . ?node rdf:type/rdfs:subClassOf* am:TechnologyLayerElement . } GROUP BY $this HAVING (COUNT(DISTINCT ?node) > 3)
Single Point of Failure
Business services realized by exactly one application component with no redundancy may represent a single point of failure.
Business service {$this} is realized by only one application component ({?app}). Consider redundancy for critical services.
SELECT $this ?app WHERE { $this a am:BusinessService . ?app am:realizes $this . ?app a am:ApplicationComponent . FILTER NOT EXISTS { ?app2 am:realizes $this . ?app2 a am:ApplicationComponent . FILTER(?app2 != ?app) } }
Single Deployment Node
Application components deployed on only one technology node may lack resilience. Critical components should be deployed across multiple nodes.
Application component {$this} is deployed on only one node ({?node}). Consider multi-node deployment for resilience.
SELECT $this ?node WHERE { $this a am:ApplicationComponent . ?node am:assignedTo $this . ?node a am:Node . FILTER NOT EXISTS { ?node2 am:assignedTo $this . ?node2 a am:Node . FILTER(?node2 != ?node) } }
Business Service Without Realization
Every business service should be realized by at least one business process or function. Unrealized services indicate incomplete modeling.
Business service {$this} is not realized by any business process or function.
SELECT $this WHERE { $this a am:BusinessService . FILTER NOT EXISTS { ?behavior am:realizes $this . ?behavior rdf:type/rdfs:subClassOf* am:BehaviorElement . ?behavior rdf:type/rdfs:subClassOf* am:BusinessLayerElement . } }
Application Service Without Realization
Every application service should be realized by at least one application component. Unrealized services indicate incomplete modeling or orphaned service definitions.
Application service {$this} is not realized by any application component.
SELECT $this WHERE { $this a am:ApplicationService . FILTER NOT EXISTS { ?app am:realizes $this . ?app a am:ApplicationComponent . } }
Capability Without Business Behavior Realization
Capabilities should be realized by at least one business behavior element (process, function, or interaction). A capability without realization is aspirational only and cannot be assessed for operational readiness.
Capability {$this} is not realized by any business process, function, or interaction.
SELECT $this WHERE { $this a am:Capability . FILTER NOT EXISTS { ?behavior am:realizes $this . ?behavior rdf:type/rdfs:subClassOf* am:BehaviorElement . ?behavior rdf:type/rdfs:subClassOf* am:BusinessLayerElement . } }
Business Behavior Realized by Multiple Application Components
Detects business processes (or functions) realized by more than one application component. Multiple components realizing the same business behavior may indicate redundant automation or unclear application ownership of the process.
Business process {$this} is realized by multiple application components ({?app1} and {?app2}). Clarify which component is authoritative.
SELECT $this ?app1 ?app2 WHERE { $this rdf:type/rdfs:subClassOf* am:BehaviorElement . $this rdf:type/rdfs:subClassOf* am:BusinessLayerElement . ?app1 a am:ApplicationComponent ; am:realizes $this . ?app2 a am:ApplicationComponent ; am:realizes $this . FILTER(STR(?app1) < STR(?app2)) }
Business Function Realized by Multiple Application Components
Detects business functions realized by more than one application component. Same concern as for processes — multiple realizers indicate potential duplication or unclear automation boundaries.
Business function {$this} is realized by multiple application components ({?app1} and {?app2}).
SELECT $this ?app1 ?app2 WHERE { $this a am:BusinessFunction . ?app1 a am:ApplicationComponent ; am:realizes $this . ?app2 a am:ApplicationComponent ; am:realizes $this . FILTER(STR(?app1) < STR(?app2)) }
Orphaned Element
Elements with no relationships to other elements may be orphaned or incompletely modeled. Every element should participate in at least one relationship.
Element {$this} has no relationships to any other element.
SELECT $this WHERE { $this a/rdfs:subClassOf* arch:Element . FILTER NOT EXISTS { { $this ?p ?other . ?other a/rdfs:subClassOf* arch:Element . } UNION { ?other ?p $this . ?other a/rdfs:subClassOf* arch:Element . } } }
Capability Without Goal
Capabilities should be linked to at least one goal or outcome to establish business justification.
Capability {$this} is not linked to any goal or outcome.
SELECT $this WHERE { $this a am:Capability . FILTER NOT EXISTS { { $this am:realizes ?goal . { ?goal a am:Goal . } UNION { ?goal a am:Outcome . } } UNION { ?goal am:serves $this . { ?goal a am:Goal . } UNION { ?goal a am:Outcome . } } UNION { $this am:associatedWith ?goal . { ?goal a am:Goal . } UNION { ?goal a am:Outcome . } } } }
Requirement Without Realization
Requirements should be realized by at least one core element. Unrealized requirements indicate gaps in the architecture.
Requirement {$this} is not realized by any architecture element.
SELECT $this WHERE { $this a am:Requirement . FILTER NOT EXISTS { ?element am:realizes $this . FILTER NOT EXISTS { ?element rdf:type/rdfs:subClassOf* am:MotivationElement . } } }