Ontology-Based Validation of Enterprise Architecture Principles

1. Introduction

Enterprise Architecture Management (EAM) is widely used to address organizational complexity and continuous change by providing shared descriptions of an enterprise and supporting decision-making in transformation initiatives [1,2]. In practice, EAM relies on established frameworks and modeling languages such as The Open Group Architecture Framework (TOGAF) and ArchiMate to structure architectural descriptions and to communicate architectural decisions across stakeholders [3,4,5]. While models make architectural knowledge explicit and support communication and consensus, organizations also use enterprise architecture (EA) principles to prescribe how the architecture should evolve in alignment with strategy and governance [2] p. 20. EA principles therefore have a regulatory role: they justify key design decisions and shape architectural quality by guiding what is acceptable or desirable in the architecture [6,7].

Despite their importance, validating whether an EA model adheres to its stated principles remains largely manual. In many organizations, principle enforcement is embedded in communication-intensive practices (e.g., workshops, reviews, and validation interviews), which are effective for shared understanding but do not scale to continuous, systematic compliance checking [8] p. 70. This reliance on manual interpretation is also reflected in the broader EAM literature: the benefits attributed to EAM—such as improved decision-making and execution of transformation initiatives—typically depend on ongoing human effort to maintain alignment between business and IT concerns and to ensure governance mechanisms are followed [9,10,11]. As a consequence, detecting deviations from EA principles in evolving architecture models is time-consuming and error-prone, and it is difficult to achieve repeatable validation across projects, teams, and time.

A core reason is the representational mismatch between principles and models. EA principles are commonly stated in natural language [12], whereas EA models are predominantly graphical. Human stakeholders can interpret both, but direct machine interpretation is hindered because the semantics needed for automated checking are not explicit [13,14]. Prior research has advanced machine-interpretable representations of EA models through enterprise ontologies, semantic lifting/annotation, and ontology-based modeling [15,16,17]. In this line of work, ontologies can capture both the semantics of a modeling language and domain knowledge, thereby enabling reasoning over model content. Notably, ArchiMEO provides an enterprise ontology that integrates ArchiMate concepts with enterprise semantics [18]. However, what is still missing is a systematic way to extend such formal model representations with formal, machine-interpretable representations of EA principles that can be executed against those models.

The literature on EA principles provides detailed guidance for specifying principles in textual form, including attributes and quality criteria [12,19]. There are also approaches that formalize or analyze principle sets (e.g., identifying conflicts among principles), for example via goal-oriented modeling extensions [20]. Yet these approaches typically do not address the complementary problem that is central for EA governance in practice: validating whether an EA model complies with a set of principles. More generally, the field exhibits diverging directions regarding formalization: principles may be represented informally, semi-formally, or formally [12] p. 69. Semi-formal approaches such as SBVR are attractive because they support controlled vocabularies and structured rule statements [21,22], whereas semantic web technologies (e.g., RDFS/OWL with rule and constraint mechanisms) provide fully formal representations that support automated reasoning and validation [23,24,25,26]. This raises a practical research challenge: how to exploit the strengths of both worlds—the accessibility of structured principle specifications and the rigor of formal semantic validation—to enable automated checking of EA model compliance.

This paper addresses the following research question: How can semantic technologies be harnessed to facilitate the automated validation of enterprise architecture models in accordance with enterprise architecture principles? To answer it, we present an ontology-based validation approach that (i) represents ArchiMate models as ontology instances grounded in ArchiMEO, (ii) structures principles using SBVR Structured English to reduce ambiguity and support traceability, (iii) enriches models with inferred relationships via derivation rules, and (iv) operationalizes compliance checking using SHACL constraints and SPARQL queries that produce explainable violation reports linked to concrete model elements. The approach is developed following a Design Science Research methodology and evaluated in three case studies across organizational and educational settings.

This manuscript consolidates and extends earlier work on ontology-based validation of EA principles [27,28,29]. While prior publications introduced individual building blocks (initial feasibility, a formalization procedure from natural-language principles to executable constraints, and derivation rules for materializing implicit architectural relations), the present paper integrates these elements into a unified and systematically evaluated validation framework.

The contributions of this paper are:

• an end-to-end validation pipeline linking SBVR-structured principles, ontology-grounded ArchiMate models, derivation rule materialization, and SHACL/SPARQL constraint execution;
• a consolidated formalization procedure that preserves traceability from natural-language principle statements to executable constraints;
• a derivation layer that operationalizes implicit ArchiMate relationship semantics to improve robustness of compliance checks; and
• a multi-case evaluation demonstrating feasibility and traceable violation reporting across organizational and educational contexts.

The remainder of this paper is organized as follows: Section 2 reviews related work; Section 3 details the ontology-based validation method and its implementation; Section 6 presents the validation results from the case studies; Section 7 discusses implications, limitations, and threats to validity; and Section 8 concludes with directions for future work.

2. Related Work

This section reviews prior work in three research streams that underpin automated validation of enterprise architecture (EA) principles: (i) EA principles and compliance practices in EA governance, (ii) ontology-based representations of EA and ArchiMate semantics, and (iii) semantic constraint and rule technologies that enable automated checks. The section concludes by synthesizing the research gap addressed in this paper.

2.1. Enterprise Architecture Principles and Compliance

Enterprise Architecture Management (EAM) evolved from predominantly descriptive, modeling-oriented practices into a strategic management function that supports decision-making, governance, and enterprise transformation [1,3,9,11]. EA models contribute value by facilitating communication, training, analysis, compliance support, and alignment between business and IT stakeholders [10]. In contemporary EAM, these benefits are typically realized through governance structures and processes that institutionalize architectural direction and oversight, such as architecture councils and review boards [30,31].

Within this governance context, EA principles provide normative guidance for architecture design and evolution [3,12]. Principles are commonly described as enduring normative rules that guide how an organization fulfills its mission [3]. A comprehensive definition emphasizes that an architecture principle is a declarative, strategy-based statement that normatively prescribes properties of information system design needed to meet essential requirements [19]. Empirical and survey-based research indicates that principles are widely considered important in practice; however, their specification, operationalization, and measurable impact remain uneven [6,32,33].

A consistent theme across frameworks and practitioner guidance is that principles are primarily captured in textual templates including statement, rationale, and implications, with additional attributes such as preconditions or key actions proposed to improve operational usefulness [3,12,19]. At the same time, principle handling is typically embedded in lifecycle processes that include assessing drivers, formulating principles, stakeholder validation, deployment, and compliance management [34,35]. In practice, compliance management often relies on communication- and review-intensive activities (e.g., workshops, validation interviews, committing reviews), which support shared understanding but remain largely manual and thus difficult to scale for continuous validation [8]. This tension between normative governance intent and predominantly manual compliance checking motivates research on machine-interpretable representations of principles and automated validation mechanisms.

2.2. Ontology-Based Enterprise Architecture and ArchiMate Semantics

Formalizing EA knowledge has been approached through semantic technologies that aim to provide explicit, machine-interpretable meaning for models and their elements [36,37]. From a modeling-method perspective, semantics is distinct from syntax and notation; automated checks require that semantics be represented in a formal form rather than remaining implicit in diagrams or informal descriptions [38]. In this context, the knowledge space of models can be characterized along the dimensions of use, form, content, and interpretation, where human interpretation differs fundamentally from machine interpretation [13,14].

Ontologies provide a formal and explicit specification of shared conceptualizations, enabling reasoning, classification, and consistency checking [39,40]. In EA settings, enterprise ontologies can represent domain semantics and complement enterprise models, and a range of enterprise ontologies has been proposed [41,42,43,44]. Specifically for ArchiMate-centered EA, ArchiMEO demonstrates how modeling-language semantics (the form) and enterprise/domain knowledge (the content) can be integrated to support machine-based interpretation [18]. The feasibility of ontology-based representations for EA and related models has also been illustrated in multiple application contexts [45,46,47].

Several complementary techniques operationalize semantic enrichment for EA artifacts. Semantic lifting transforms model structures into ontology representations, enabling uniform query and reasoning over model content [15,48,49]. Semantic annotation links model elements to ontology concepts to enrich discoverability and contextual interpretation [16,50]. Ontology-based metamodeling generalizes this idea by using ontologies as metamodeling languages, separating abstract syntax and semantics from concrete notations and supporting models that are cognitively adequate for humans yet processable by machines [14,17,51,52]. Recent work further emphasizes the value of more coherent applied ontologies for EA modeling to reduce fragmentation in EA model research and improve comparability and evaluation [53].

Despite these advances, the explicit operationalization of EA principles as machine-executable validation logic—particularly in combination with ontology-based ArchiMate representations—remains comparatively underdeveloped.

2.3. Constraint-Based Validation and Semantic Technologies

Automated validation of models can target syntactic correctness, structural or domain constraints, and behavioral properties [38,54]. For EA principle validation, the core challenge is typically not diagram syntax alone, but whether architectural structures and relationships satisfy normative constraints implied by principles. However, principles are typically expressed as natural-language governing statements, and their translation into executable checks requires deliberate formalization choices [20].

The literature offers diverging approaches to principle formalization. Semi-formal rule languages such as RuleSpeak aim to bridge prose and implementation by structuring natural-language rules into practicable statements, yet still require further transformation to become executable [55]. SBVR is commonly highlighted as a promising standard for capturing business vocabulary and rules in a structured, semi-formal form that remains accessible to business stakeholders [12,21,22]. At the same time, semantic web languages provide fully formal representations suitable for machine execution: RDF/RDFS and OWL provide a logic-based foundation, while rule and constraint mechanisms such as SWRL, SPARQL-based approaches, and SHACL enable rule execution, querying, and constraint checking over knowledge graphs [23,24,25,26,56,57].

A key practical bridge between semi-formal SBVR specifications and executable semantic checks is the translation of SBVR statements into OWL-based representations using patterns and transformation rules, which has been explored in multiple studies [58,59,60]. Related work on ontology-based rule checking demonstrates that semantic rule representations can detect errors and inconsistencies in models and rule sets when domain knowledge is represented explicitly [61]. However, within EA governance, a recurring limitation is that these technologies are often applied either to model representation or to rule formalization, but not integrated into an end-to-end approach that (i) formalizes EA principles, (ii) leverages inferred architectural relations, and (iii) validates compliance directly on an ontology representation of ArchiMate models.

2.4. Summary of Research Gap

In summary, prior work establishes (a) the central governance role of EA principles and the predominance of manual, communication-intensive compliance practices [3,8,34], (b) the feasibility and benefits of representing EA and ArchiMate semantics using ontologies and semantic enrichment techniques [15,17,18], and (c) a mature semantic web technology stack for formal rule execution and constraint validation [24,25,26,56]. What remains insufficiently addressed is a unified and practically executable mechanism that connects these strands to enable repeatable automated validation of EA principles against ontology-based ArchiMate model representations, including the derivation of implicit architectural relations required for robust principle checking.

3. Materials and Methods

3.1. Research Design

This research follows a Design Science Research (DSR) methodology [62,63]. The objective is to design and evaluate an artifact that enables the automated validation of enterprise architecture (EA) models against enterprise architecture principles using semantic technologies.

The study adopts a constructive and pragmatist research philosophy [64,65], where knowledge is generated through the development and evaluation of an artifact addressing a relevant practical problem. The artifact is an ontology-based validation approach integrating formal representations of EA models and EA principles.

The DSR process was structured into iterative cycles aligned with the following sub-research questions:

• SRQ1: What knowledge is currently machine-interpretable from EA principles?
• SRQ2: What knowledge is currently machine-interpretable from EA models?
• SRQ3: How can the semantics of EA models be represented?
• SRQ4: How can the semantics of EA principles be represented?
• SRQ5: How can EA principles be automatically validated using ontologies?

SRQ1 and SRQ2 correspond to the awareness of the problem phase. SRQ3 and SRQ4 correspond to the design and suggestion phase. SRQ5 corresponds to the development and evaluation phase. Intermediate versions of the artifact (ontology extensions, derivation rules, and validation shapes) were refined based on the findings of successive evaluations. The three case studies were not only used as final evaluation contexts, but also as iterative feedback sources: early cycles focused on feasibility and semantic lifting, subsequent cycles refined principle formalization and derivation, and later cycles stabilized the SHACL/SPARQL validation patterns and reporting.

3.2. Time Horizon

The study adopts a cross-sectional time horizon [66]. Data were collected from organizational contexts at defined points in time, providing a snapshot of existing EA models, EA principles, and validation practices. The objective was not to study longitudinal change, but to assess feasibility and effectiveness of the designed artifact under real-world conditions.

3.3. Case Study Strategy

The artifact was evaluated through three case studies:

• Case 1: FHNW – A real-world university administration context.
• Case 2: Swiss Bank – An anonymized fintech/banking case.
• Case 3: BestCar – A fictional educational case used in classroom settings.

The two real-world cases were used for qualitative evaluation of applicability, feasibility, and stakeholder acceptance. The fictional BestCar case was used for controlled quantitative analysis of principle patterns and validation behavior. Case selection followed three criteria: (i) availability of EA principles in textual form, (ii) availability or feasibility of creating EA models, and (iii) access to stakeholders for validation review. Data collection comprised semi-structured interviews with domain experts and architects (FHNW and Bank cases), review of internal documentation and EA-related artifacts, collaborative modeling sessions to create or refine EA models, and collection of student-generated models and principles in the BestCar case.

EA models were created or consolidated using ArchiMate as modeling language and managed in the AOAME environment, which supports ontology-based metamodeling and semantic annotation. Principles were collected in textual form and subsequently structured for formalization.

3.4. Artifact Development Procedure

Artifact development followed iterative DSR cycles beginning with analysis of machine-interpretable knowledge in EA models and principles (SRQ1–SRQ2), followed by the design of semantic representation mechanisms for models (SRQ3) and formalization procedures for EA principles (SRQ4). The final phase implemented automated validation mechanisms (SRQ5) and applied them in case-based evaluation contexts.

Each iteration involved validation of intermediate results with stakeholders and refinement of modeling conventions and rule specifications.

3.5. Evaluation Protocol

The evaluation protocol consisted of:

• Collection of EA models and principles.
• Transformation of models into machine-interpretable representations.
• Formalization of selected EA principles.
• Execution of automated validation.
• Review of validation results with domain experts.

Evaluation focused on (i) feasibility of formalizing principles, (ii) ability to detect principle violations, (iii) clarity and traceability of validation output, (iv) stakeholder confirmation of correctness, and (v) reduction of manual validation effort.

3.6. Reproducibility and Availability of Materials

The study is based on enterprise ontology extensions derived from ArchiMEO, EA models used in the three case studies, formalized principle specifications, and validation rules and queries implementing derivation and compliance logic. Where permitted by organizational confidentiality constraints, anonymized models, ontology extensions, and validation artifacts will be made available upon request. Restrictions related to proprietary organizational data apply to the FHNW and Bank cases.

4. Design of the Ontology-Based Validation Approach

Figure 1 summarizes the conceptual stages of the approach: (i) make EA models machine-interpretable, (ii) reduce ambiguity of principles through structured specification, (iii) enrich model knowledge with derived relations required for reliable checking, and (iv) execute automated validation to produce a traceable report. The following subsections detail these stages and the concrete implementation used in this study.

4.1. Design Objectives and Requirements

The design of the ontology-based validation approach was informed by the findings of SRQ1 and SRQ2, which identified a structural mismatch between enterprise architecture (EA) principles expressed in natural language and EA models represented graphically. While both are interpretable by human stakeholders, neither representation alone provides sufficient semantic explicitness for automated compliance checking.

From this analysis, the following design requirements were derived:

• Semantic Explicitness of EA Models. EA models must be represented in a machine-interpretable form that preserves modeling language semantics and enables reasoning over architectural elements and relationships.
• Structured Formalization of EA Principles. EA principles must be transformed from natural-language governance statements into structured and unambiguous representations suitable for machine execution.
• Derivability of Implicit Architectural Knowledge. Architectural relations that are semantically implied but not explicitly modeled must be derivable to ensure completeness of compliance checking.
• Traceable and Explainable Validation Outcomes. The validation mechanism must produce structured outputs linking detected violations to concrete model elements, supporting governance transparency and decision-making.

These requirements guided the development of a multi-stage validation approach integrating ontology-based model representation, structured principle formalization, derivation rules for semantic completion, and constraint-based automated validation.

4.2. Ontology-Based Representation of EA Models

Automated validation requires that enterprise architecture (EA) models expose their semantics explicitly and in a machine-interpretable form. Rather than relying solely on post-hoc semantic lifting, this approach adopts ontology-based metamodeling to ensure that model elements are ontology-native from the moment of creation.

ArchiMate was selected as the reference modeling language due to its widespread adoption in enterprise architecture practice. Its meta-model semantics are grounded in ArchiMEO, which integrates:

• Modeling language semantics (form), and
• Enterprise/domain vocabulary (content).

This integration ensures that both syntactic correctness and domain meaning are represented within a unified enterprise knowledge graph. Where necessary, ArchiMEO was extended to reflect updates in the ArchiMate specification and to incorporate additional relations required for principle validation.

By combining ontology-based metamodeling with domain integration, the approach establishes a semantically coherent representation of EA models that supports reasoning, derivation, and constraint validation.

4.3. Formalization Procedure for Enterprise Architecture Principles

Enterprise architecture (EA) principles are typically formulated as natural-language governance statements. To enable automated validation, these statements must be systematically transformed into machine-executable constraints (extending [28]). Based on the iterative Design Science Research cycles (SRQ4 and SRQ5), this study consolidates the formalization into a structured, multi-stage procedure.

Step 1: Principle Specification and Structuring.

EA principles are first specified using established templates (e.g., statement, rationale, implications). The focus of formalization lies on the normative core expressed in the statement and its operational implications. Ambiguities and implicit assumptions are identified and resolved in collaboration with domain experts.

Step 2: Transformation into SBVR Structured English.

The principle statement is rewritten as a practicable rule using SBVR Structured English. This step introduces explicit classification of:

• Terms (noun concepts representing architectural elements),
• Fact types (verb concepts representing relations or attributes),
• Quantifications and modalities (e.g., “every”, “at most one”, “it is mandatory that”).

This structured representation reduces linguistic ambiguity while preserving stakeholder readability and traceability.

Step 3: Vocabulary Extraction and Ontology Alignment.

Significant SBVR terms and fact types are mapped to ontology constructs. Noun concepts are aligned with ontology classes or individuals, verb concepts with object or datatype properties, and quantifications with cardinality or constraint patterns. Where required, the enterprise ontology (grounded in ArchiMEO) is extended to represent missing domain semantics.

Step 4: Integration of Domain Knowledge and Modeling Conventions.

To ensure that the validation logic can operate on EA models, domain-specific ontologies and modeling conventions are integrated. This includes:

• Extending the enterprise ontology with relevant domain concepts,
• Defining consistent annotation patterns for ArchiMate model elements,
• Ensuring that model elements referenced by principles are explicitly represented and semantically annotated.

This step establishes the semantic preconditions for reliable validation.

Step 5: Encoding as Executable Constraints.

The structured and ontology-aligned rule is encoded as an executable constraint. In this study, SHACL is used as the primary validation mechanism. Node shapes define the target architectural elements, while property constraints and SPARQL-based expressions operationalize cardinality, dependency, and governance conditions. Where inferencing is required, derivation rules are applied prior to constraint evaluation.

Step 6: Validation and Traceability.

The encoded constraints are executed over the enriched enterprise knowledge graph. Validation results are returned as structured SHACL reports linking violations to concrete model individuals and relations. This ensures traceability from natural-language principle to executable rule and back to affected architecture elements.

This multi-stage formalization procedure bridges natural-language governance statements and machine-executable validation logic. By separating structuring (SBVR), semantic alignment (ontology grounding), and execution (SHACL/SPARQL), the approach preserves interpretability while enabling automated compliance checking.

4.4. Derivation and Validation Mechanism

The derivation rules constitute a semantic completion layer that operationalizes implicit knowledge defined in the ArchiMate specification. By systematically analyzing relationship semantics (e.g., transitivity, structural weakening, dependency propagation), the approach formalizes valid derivation patterns as executable SPARQL CONSTRUCT rules.

This enrichment step ensures that validation does not depend solely on explicitly modeled relations but also considers semantically implied architectural dependencies. The separation between derivation and validation enables modular reasoning while preserving transparency of inferred knowledge.

Many EA principles depend on architectural relations that are implicit rather than explicitly modeled (e.g., transitive dependencies, indirect data provisioning).

To support reliable validation, the approach introduces derivation rules that materialize such relations before executing compliance checks.

Validation consists of:

• Enriching the semantic model with inferred relationships,
• Executing formalized principle constraints against the enriched model,
• Generating a validation report listing violations and explanatory traces.

This two-stage mechanism (derivation + validation) ensures both completeness and traceability.

5. Technical Implementation and Instantiation

This section describes the technical realization of the ontology-based validation approach. While the design in Section 4 is conceptually technology-independent, the evaluation in this study required an executable pipeline that operationalizes (i) ontology-native model creation, (ii) ontology grounding and enterprise extensions, (iii) derivation rule materialization, and (iv) constraint-based validation with explainable reporting.

5.1. Semantic Pipeline Overview

The implementation follows the pipeline shown in Figure 2. Enterprise architecture models and principle specifications are represented as RDF/OWL knowledge graphs, enriched through derivation rules, and validated using SHACL constraints complemented by SPARQL-based expressions. The output is a structured validation report that links each violation to the concrete model elements involved.

5.2. Ontology-Native Modeling with AOAME

Enterprise architecture models were created and managed using the Agile Ontology-Aided Modelling Environment (AOAME), which implements the Ontology-Based Metamodeling Approach (OBMMA). In AOAME, every modeling element instantiated in the graphical canvas is directly created as an ontology individual. Consequently, the abstract syntax of the modeling language (e.g., ArchiMate concepts), the graphical notation, and the domain semantics are maintained in linked ontologies and remain synchronized during modeling.

Unlike conventional modeling tools where semantic lifting is performed as a separate export step, AOAME ensures that models are ontology-native from the moment of creation. As a result, rule execution and validation operate directly on the enterprise knowledge graph without requiring an additional model-to-ontology transformation layer.

5.3. Ontology Grounding and Enterprise Extensions

The ontology foundation is grounded in ArchiMEO, which provides (i) a semantically enriched representation of the ArchiMate meta-model and (ii) extensibility for enterprise-specific domain vocabularies. Where required by the evaluated principles, the ontology was extended with additional domain concepts and relations (e.g., governance constructs, stewardship roles, or organization-specific business object types). This grounding enables validation logic to operate over a unified knowledge graph combining modeling-language semantics and enterprise/domain meaning.

5.4. Derivation Rule Execution

Enterprise architecture principles often depend on architectural relations that are implicit in ArchiMate models. Based on a systematic semantic analysis of the ArchiMate specification, derivation rules were formalized to materialize such implicit relations prior to validation. The rules cover transitivity, structural relationship weakening, and interactions between structural, dependency, dynamic, and flow relationships.

The derivation logic was implemented using SPARQL CONSTRUCT queries executed over the RDF graph. Derived relations are stored in the knowledge graph without altering the visual model, preserving readability while enabling machine-complete reasoning. Potential derivation rules suggested by the ArchiMate specification were identified but not always automatically applied, as their validity depends on modeling context and intended interpretation.

5.5. Constraint-Based Validation and Explainable Reporting

Following the derivation phase, principles structured via SBVR and aligned to ontology vocabulary are encoded as SHACL shapes and SPARQL constraints. Validation is executed under a closed-world interpretation, ensuring that compliance is evaluated based on explicitly modeled and derivable knowledge. This interpretation matches governance scenarios where missing assignments (e.g., missing stewardship links) are considered findings requiring clarification or remediation.

The pipeline was executed using Apache Jena for RDF storage, SPARQL processing, derivation rule execution, and SHACL validation. The output consists of structured validation reports in which each violation is linked to the focus node (the element under validation), the violated constraint, and the contributing values or related nodes. This provides traceability back to concrete ArchiMate elements in AOAME and supports governance review and corrective action.

5.6. End-to-End Validation Example

The following simplified example illustrates how derivation rules enable validation that would otherwise fail due to implicit modeling structures. A comprehensive formalization of the derivation patterns is presented in [29]. The example below follows the six-step formalization procedure described in Section 4.3, but condenses intermediate steps for brevity. The focus is on (i) SBVR-based rule structuring, (ii) grounding the rule vocabulary in the enterprise ontology (ArchiMEO) and the AOAME modeling conventions, and (iii) derivation-enabled validation.

Principle statement (informal).

Consider a redundancy-avoidance principle stating that applications supporting the same usage context should not redundantly serve the same business process.

SBVR rule structuring (cf. Step 2 in Section 4.3).

The normative core of the principle is rendered in SBVR Structured English to expose its underlying logical structure, explicitly distinguishing noun concepts, verb concepts, quantifications, and modality:

This SBVR formulation clarifies:

• Noun concepts: Business Process, Application Component, Application Usage.
• Verb concepts:

  –

  Application Component is used for Application Usage.

  –

  Application Component serves Business Process.

• Modality: obligatory (deontic constraint).

Alignment of EA Concepts with the Enterprise Ontology (cf. Steps 3–4).

The SBVR vocabulary is aligned with ontology constructs and modeling conventions used in the ontology-based metamodeling environment:

• Business Process → archi:BusinessProcess
• Application Component → archi:ApplicationComponent
• Application Usage → a domain concept in the domain ontology (e.g., an APQC classification)
• is used for → eo:AppIsUsedFor
• serves / is served by → archi:Serve (Serving relationship) represented in AOAME as a relationship individual using lo:modelingRelationHasSourceModelingElement and lo:modelingRelationHasTargetModelingElement

In AOAME, each modeled element is instantiated as a mod:ConceptualElement and typed with its ArchiMate class. Domain semantics are attached via lo:elementIsMappedWithDOConcept and/or domain-specific properties such as eo:AppIsUsedFor. Consequently, once the vocabulary is aligned, the SBVR rule can be operationalized over the ontology representation of the model without requiring post-hoc semantic lifting.

Derivation layer as a precondition for robust checking.

In many ArchiMate models, an Application Component does not directly serve a Business Process. Instead, the relation may be implicit, for example:

• Application Component realizes Application Service,
• Application Service serves Business Process.

Without semantic enrichment, a validation query that only checks direct archi:Serve relations would miss such cases, resulting in false negatives. The derivation layer therefore materializes implied serving relations by analyzing relationship chains captured in the ontology (e.g., DR3 derivation patterns combining structural and dependency relationships). Derived relations are inserted into the knowledge graph prior to validation, enabling the subsequent constraint evaluation to operate on both explicitly modeled and semantically implied knowledge.

Constraint execution and traceability (cf. Steps 5–6).

After derivation, the SBVR-grounded rule is encoded as a SHACL constraint (optionally complemented by a SPARQL-based constraint expression) and executed over the enriched graph. Violations are reported with references to:

• the involved archi:ApplicationComponent individuals,
• the affected archi:BusinessProcess,
• the shared domain concept representing Application Usage,
• and the (explicit or derived) archi:Serve relations that enable the check.

This ensures that validation results are not only machine-detected but also explainable and traceable back to concrete ArchiMate elements in the AOAME modeling environment.

6. Results

This section reports the results of applying the ontology-based validation approach to three case studies (FHNW, Swiss Bank, BestCar). For each case, we report (i) the principle(s) selected, (ii) the machine-executable formalization (SHACL/SPARQL), and (iii) the validation outcomes produced by the constraint engine, including traceability to violating model elements.

6.1. Overview of Validated Principles and Mechanisms

Table 1 summarizes the evaluated principles, the case contexts, and the primary validation mechanism used. Across cases, principles were formalized into SHACL shapes complemented by SPARQL queries or rules, executed over the ontology representation of ArchiMate models enriched with derived relations.

Across all cases, violations are returned as SHACL validation results that point to the involved focus nodes and contributing model elements, enabling traceability back to the ArchiMate model in AOAME.

6.2. Case 1 (FHNW): Master Data Management and Governance

In the FHNW case, the approach was applied to an ArchiMate model capturing administrative processes and information objects. The selected governance principles focused on ensuring architectural consistency of master data management structures and the presence of required governance constructs.

Unique MDM system validation.

The MDM principle was formalized as a cardinality constraint requiring exactly one application component annotated as the master data management system. Validation was executed on the ontology representation of the model and returned a result indicating whether the architecture contained a single authoritative MDM component. The constraint output provided direct references to the involved application components, allowing stakeholders to verify whether the detected configuration reflected the intended architecture.

MDM governance validation.

The governance principle was validated by checking whether critical business objects were linked to required stewardship and master-data constructs defined in the ontology extension. The SHACL validation identified missing or incomplete governance links for selected objects. Similar to the MDM check, results were returned as traceable constraint violations, enabling the architecture team to review gaps and refine governance assignments.

Overall, stakeholders confirmed that the generated violations were understandable and actionable because each result contained (i) the violated condition, (ii) the specific offending individuals, and (iii) a navigation path back to the original model context.

Each violation record includes the focus node (e.g., an Application Component or Data Object), the violating condition, and the contributing model elements, enabling direct navigation to the originating ArchiMate elements in AOAME.

6.3. Case 2 (Swiss Bank): Redundancy and Single Authoritative Data Updates

In the Swiss Bank case, two complementary principles were validated. First, the redundancy avoidance principle was instantiated as a duplication-detection check: if multiple applications implemented the same domain concept without architectural justification, this indicated potential redundancy. The validation identified several redundancy clusters where the same domain concept was supported by more than one application; these clusters were reviewed with stakeholders as candidates for consolidation or justified exceptions.

Second, a data governance principle required that each data object be updated by only one application component. This constraint operationalizes a single-authoritative-update pattern comparable to a single source of truth interpretation at the operational level. Validation outputs grouped results by data object and listed the responsible applications, allowing architects to quickly identify conflicting update responsibilities.

The output groups results by domain concept or data object and lists the associated application components for each cluster, providing an actionable shortlist for architecture review.

6.4. Case 3 (BestCar): Controlled Validation Behavior Across Many Models

The BestCar case served as a controlled educational setting with multiple independently created ArchiMate models and principle sets. Here, the single-authoritative-update pattern was reused to assess how well the formalization generalizes across heterogeneous model structures and naming conventions. The validation logic remained stable, while model-specific mappings (e.g., term alignment to ontology concepts) required lightweight adjustments. Across student models, the approach consistently produced explainable validation outcomes (compliance or violations) and highlighted where missing modeling links prevented automated checking, thereby making model quality issues explicit.

6.5. Cross-Case Findings

Across the three cases, the results show that the approach enables:

• Repeatable execution: once formalized, the same principle checks can be re-run on evolving models without re-interpreting natural-language statements.
• Traceable outcomes: SHACL reports link violations directly to model individuals, supporting governance review and corrective actions.
• Practical feasibility: principles of different types (data governance and application redundancy) could be expressed as constraints over the ontology representation of ArchiMate models, leveraging inferred relations where needed.

Beyond individual validation outcomes, the cases demonstrate a structured transformation pipeline from natural-language principles to executable constraints. Principles were first structured using SBVR to reduce ambiguity and identify significant terms and fact types. These structured specifications were then aligned with ontology concepts and encoded as SHACL node shapes and SPARQL-based constraints. Derivation rules were applied prior to validation to materialize implicit architectural relations required for reliable checking. This two-stage mechanism (semantic enrichment through derivation followed by constraint-based validation) ensured that both explicit and inferred architectural knowledge were considered during compliance evaluation.

These findings directly address the evaluation criteria defined in Section 3, demonstrating feasibility of principle formalization, reliable violation detection, traceable validation output, and stakeholder-confirmed correctness across contexts. These results motivate the discussion of implications, limitations, and threats to validity in Section 7.

7. Discussion

This study addressed the challenge of reducing manual effort and improving repeatability in enterprise architecture (EA) principle compliance checking by making both sides of the compliance problem machine-interpretable: (i) EA models through ontology-grounded ArchiMate representations, and (ii) EA principles through a traceable transformation from natural language to executable constraints. Across three case studies, the proposed approach operationalized principles as repeatable validation checks and produced explainable violation reports linked to concrete model elements.

A core design choice is the separation of concerns between specification, semantic grounding, semantic completion, and constraint execution. In terms familiar from business rule engineering, EA principles can be seen as governing statements that require refinement into practicable statements and, ultimately, implementation statements. In this work, SBVR Structured English plays the role of a practicable statement: it reduces ambiguity, forces explicit vocabulary and fact types, and preserves stakeholder readability. Executability is then achieved at the implementation level through SHACL/SPARQL constraints grounded in an enterprise ontology (ArchiMEO plus domain extensions). This layered structuring was critical to keep the formalization both feasible in practice and traceable back to the original principle phrasing.

7.1. Interpretation of Findings

Across all cases, validation outputs were considered actionable because they point to (i) the focus node under validation, (ii) the violated condition, and (iii) the contributing values and related nodes. This supports a governance workflow in which automated checking does not replace architectural judgement, but provides a repeatable screening mechanism and a transparent starting point for review and exception handling.

A recurring empirical observation is that derivation is a precondition for robust validation. Several violations (or non-violations) depend on relations that are semantically implied by the ArchiMate specification but not consistently modeled explicitly across views (e.g., indirect serving relations via services, propagated dependencies, or transitive effects). Materializing such implied relations prior to constraint execution reduced false negatives and improved robustness across heterogeneous modeling styles. Importantly, the approach keeps derivation and validation conceptually separate: derived knowledge is made explicit in the knowledge graph to enable checks, while validation remains a constraint evaluation step that produces a report.

7.2. Positioning with Respect to Related Work

Prior research has shown the value of semantic lifting and semantic annotation for machine interpretation of EA models, and the semantic web stack provides mature mechanisms for querying and constraint checking. What is comparatively less mature in the EA governance literature is an integrated, end-to-end approach that connects (i) a structured, stakeholder-readable principle representation, (ii) explicit ontology grounding of the principle vocabulary, (iii) derivation of implicit architectural relations needed for reliable checking, and (iv) execution that yields explainable reports linked to model elements. The contribution of this work is therefore not the introduction of SHACL or SPARQL in isolation, but a validation pipeline that preserves traceability from textual principles to executable checks and back to the affected architecture elements.

7.3. Implications for EA Practice

The results suggest three practical implications for organizations that maintain principle sets and ArchiMate models:

Repeatable compliance checking on evolving models. Once encoded, a principle can be executed repeatedly as models change, reducing reliance on ad-hoc, communication-intensive reviews for detecting basic deviations.

Auditability and governance transparency. SHACL validation reports provide a structured and explainable output that can be used in architecture review boards or design checkpoints, because violations are linked to the concrete model individuals involved.

Feedback on model quality and conventions. Automated checks make missing semantic links visible (e.g., missing annotations or missing governance relations). In this way, validation also functions as a quality feedback loop for modeling conventions and semantic annotation practices.

7.4. Limitations and Threats to Validity

Several limitations should be acknowledged.

Dependence on semantic alignment and model quality. Automated validation presupposes that the modeled elements relevant to a principle are represented and that the vocabulary is aligned to ontology concepts. Incomplete models, inconsistent naming, or missing annotations can lead to non-detections or results that reflect missing modeling information rather than real-world non-compliance.

Expressiveness and operationalization of principles. Not all EA principles are equally amenable to executable constraints. Principles that rely on qualitative judgement, context-specific trade-offs, or exception policies require additional operational definitions and may remain partially manual. The evaluated principles are predominantly governance and data/application consistency rules that can be expressed as structural constraints.

Closed-world interpretation. SHACL validation is typically executed under a closed-world assumption, which may treat absent knowledge as a finding. This is often appropriate for governance (e.g., missing responsibility links), but it requires careful interpretation when communicating results to stakeholders.

Generalizability. The evaluation spans two organizational settings and one educational setting. While this provides evidence of feasibility across contexts and modeling styles, broader generalization requires additional industrial case studies, larger model repositories, and further principle classes.

7.5. Future Work

Future work can extend the approach along four complementary dimensions.

First, stronger tool support for semantic alignment and annotation is required. Semi-automated mapping of model labels and textual principle statements to ontology concepts would reduce manual effort and increase robustness of validation results. Techniques from natural language processing and ontology matching may support this alignment step.

Second, reusable libraries of principle patterns and SHACL/SPARQL constraint templates should be developed. Such libraries could capture recurring governance patterns (e.g., uniqueness, single-authoritative-source, stewardship assignment, separation-of-concerns) and make them adaptable across organizational contexts.

Third, explanation and remediation support should be enhanced. Beyond reporting violations, validation tools could provide structured guidance for exception handling, remediation suggestions, and integration with governance workflows and architecture review processes.

Fourth, scalability and maintenance effort should be systematically evaluated on larger, versioned EA repositories. This includes performance assessments of derivation and validation pipelines, as well as empirical studies on long-term maintenance of ontology extensions and constraint libraries.

Finally, recent advances in large language models (LLMs) suggest opportunities for hybrid architectures in which AI agents support the refinement of governing statements into structured representations through competency-question-driven interactions. Such agents could assist in vocabulary harmonization, ontology alignment, and draft rule generation from textual documents. However, formal enterprise ontologies and executable SHACL/SPARQL constraints remain necessary as the authoritative reasoning layer to ensure transparency, reproducibility, and auditability of compliance decisions.

8. Conclusions

This paper investigated how semantic technologies can support automated validation of enterprise architecture (EA) models in accordance with EA principles. The presented approach combines (i) ontology-grounded ArchiMate model representations, (ii) SBVR Structured English for reducing ambiguity and preserving traceability of principle statements, (iii) a derivation layer to materialize implicit architectural relations required for robust checking, and (iv) SHACL/SPARQL constraint execution that produces explainable, traceable validation reports.

Across three case studies, the approach enabled repeatable compliance checks and produced results that can be inspected and discussed in governance contexts because violations are linked to concrete model elements. The findings highlight that reliable validation often depends on semantic completion: derivation rules are needed to compensate for heterogeneous modeling styles and for relations that are implied by ArchiMate semantics but not explicitly modeled. Overall, the study indicates that a layered transformation from natural-language principles to executable constraints can shift substantial parts of compliance checking from manual interpretation to automated validation, while keeping architectural judgement and exception handling in the loop.

Future research should expand the catalog of supported principle patterns, strengthen automation support for semantic alignment and annotation, and assess scalability and maintenance effort on larger industrial EA repositories and evolving principle sets. In addition, hybrid approaches that combine ontology-based validation with AI-assisted, competency-question-driven knowledge refinement warrant investigation. While large language models may support vocabulary harmonization, semantic alignment, and draft rule generation from textual documents, formal enterprise ontologies and executable SHACL/SPARQL constraints remain essential as the authoritative reasoning and traceability layer for governance auditability.