1 Introduction

Enterprise models play an important role in the governance and transformation of digital organizations where the business is supported in some degree by information systems and information technology [1–4]. Enterprise model analysis examines the artefacts, properties and dependencies of a model to generate information that can be used to assess, transform or redesign organizational systems [5–7]. Model analysis uses information within the models or information about the models to drive the overall analysis process [8].

A business model describes how an organization creates and delivers value, and depicts the organization from a high level of abstraction [9]. A value network describes how a group of organizational entities, such as suppliers, producers and clients, exchange value across the value network, and how value flows between the entities, while each implements its own business model [10]. Since a business model abstracts the organization from a high-level strategic perspective, it does not to detail how the business is operated or automated. To achieve such a goal, an enterprise model describes business processes and how processes are realized by applications and technology. An enterprise modelling language, such as ArchiMate [11], can be used for this purpose.

Business models, value networks and enterprise architecture models address different organizational concerns and provide different views on an organization: a business model describes the organization’s strategy in terms of value propositions and value creation; an enterprise architecture model describes how an organization operates, often through the description of the relationships between its processes, resources, applications and technology; and a value network model describes the role of each organization within the wider value chain. When the system of interest is a single organization, then modelling these three different concerns entails specifying the three underlying models for that organization. But when the system of interest includes multiple organizations, the model landscape comprises several models: there will be a shared value chain model that represents all the organizations, along with at least one business model and one enterprise architecture model for each individual organization that pertains to the value chain. Although these models address different concerns, being able to jointly represent and analyse them is attractive because it contributes to understand the relationships and dependencies between the concepts that are otherwise distributed across different models. Thus, the integrated models enable to check how the business model of an organization fits into the wider value network, and how the business operations are actually realizing the business model [12–15].

There are different approaches to deal with the specification, integration and analysis of enterprise models. These include multi-perspective enterprise modelling [16–19], model mapping [14, 20, 21], federated enterprise modelling [3, 22–25], as well as the application of knowledge representation techniques to enterprise modelling [26–28]. This paper uses semantic techniques to represent and integrate enterprise models through the definition of mapping functions that relate conceptual schemas. The content and structure of the integrated models can then be analysed with graph querying and logical inference. In other words, this paper assesses the suitability of applying ontologies to represent and analyse federated enterprise models. In particular, the research here reported explores the following avenues:

  • The application of ontologies to represent enterprise models. The paper represents the business model canvas [9], e3value [29], and a subset of ArchiMate’s business layer [11].

  • The application of ontologies to integrate enterprise models. Integration is accomplished through the specification of mapping functions.

  • The application of computational semantic techniques (in particular, graph querying and logical inference) to analyse the integrated enterprise models.

The contribution of this paper is presented as a design artefact [30, 31], containing a set of ontological schemas designed to represent, integrate and analyse federated enterprise models. The artefact is demonstrated through the specification, integration and analysis of a model landscape comprising three enterprise modelling languages: the business model canvas (BMC), e3value and ArchiMate. To produce the design artefact, the different models were specified as individual ontological schemas and then integrated through mapping. The artefact was evaluated with a scenario that analyses the integrated models. The main contribution of the paper is assessing the application of semantic techniques with regard to enterprise model specification, integration and analysis. These techniques provide support for creating and validating models for different but related perspectives of the enterprise [7, 15, 32].

The remainder of this paper is structured as follows. The next section introduces the BMC, e3value and the ArchiMate modelling languages, along with a short introduction to ontology engineering. Section 3 describes the proposed approach to the representation, integration and analysis of enterprise models. Section 4 applies the approach to the integration of the BMC, e3value and ArchiMate languages. Section 5 evaluates the design of the artefact with the analysis of an electronic health service business model. Finally, Sect. 6 concludes the article.

2 Background

This section introduces the business model canvas, e3value and ArchiMate. The combination of these enterprise modelling languages emphasizes their collective capability to represent the complementary perspectives of teleology and ontology. The concept of teleology originates from the Greek telos, which means “end”, “purpose” or “goal”. It concerns the explanation of a thing in terms of the end for which the thing exists or was produced for. The teleological perspective of an enterprise is presented in duality with its ontological perspective. Ontology is defined as the study or description of things as they are. As explained in the following subsections, the business model canvas and e3Value languages mainly focus on the teleological perspective, i.e. on the “purpose” or “goal” of an organization and thus abstract from detailed enterprise operations, whereas ArchiMate focusses on the ontological perspective.

2.1 Business model canvas

A business model describes how an organization creates, delivers and captures value [9]. Since organizations depend on the value they create and on how they capture it, the development of business models is often considered a vector for innovation. In the words of Chesbrough [33], “a company has at least as much value to gain from developing an innovative new business model as from developing an innovative new technology”. The business model canvas (BMC) is a “visual template that represents the business model of an organization and translates it into explicit knowledge” [9]. The focus of the BMC is describing a single organization from a high-level strategic perspective. As depicted in Fig. 1, the canvas comprises nine building blocks, whose content is described in Table 1.

Fig. 1
figure 1

The business model canvas (from [9])

Full size image
Table 1 The concepts of the business model canvas (adapted from [9])
Full size table

The BMC is often populated through collaborative and visual thinking techniques, such as ideation, brainstorming, prototyping and storytelling [9]. These techniques promote communication between the stakeholders and to foster innovation. Although the BMC is presented as a visual template, it is grounded on the business model ontology (v. Fig. 2) that establishes the foundations behind its concepts and relationships [34].

Fig. 2
figure 2

The business model ontology (adapted from [34])

Full size image

2.2 e3value

A value network provides a common understanding of a business idea that is executed by a network of actors that jointly create, distribute and consume value [12]. The e3value considers that value transactions are economically reciprocal, i.e. an actor providing a value object expects to receive a reciprocal value object in return. Value models communicate the role of a single company within the value network, and make possible analysing how the network creates and delivers value as the result of inter-organizational cooperation[10]. Figure 3 depicts the e3value meta-model, and Table 2 describes its main concepts.

Fig. 3
figure 3

The e3value meta-model (adapted from [12, 35])

Full size image
Table 2 The concepts of e3value (adapted from [10, 12])
Full size table

Value networks are abstracted as a set of value transactions occurring between actors. While the business model canvas focuses on a single node of the value network, the e3value encompasses the overall value network [13]. BMC is designed to convey and discuss subjective business ideas while lowering the adoption barriers to its users [9]. The e3value is designed not only to visually communicate a value network model but also to support model checking and numerical computation, e.g. to simulate the economic viability of different value networks. Therefore, combining BMC and e3value models makes possible describing and analysing the same scenario according to complementary perspectives [13, 14, 36, 37].

2.3 ArchiMate

ArchiMate is an enterprise architecture modelling language that describes the relationships between business services, processes and the underlying application and technological infrastructure. To do so, the concepts of ArchiMate are organized according to a framework composed of three layers: business, application and infrastructure [11]. The internal business operations interface with the external environment by providing business services and products to the organization’s external clients. Business services are internally realized by business processes that use and transform business objects, which are assigned or executed by business actors. The application layer describes how automated or semi-automated business process are supported by applications, along with the structure, behaviour and dependencies of the applications. The technological infrastructure layer describes how applications are supported by technology in terms of processing, communication and storage. Thus, each layer isolates a domain and provides services that support the operation of the upper adjacent layer. The ArchiMate framework further classifies all of the concepts found in these three layers according to three types: behaviour, active structure and passive structure. These types conform to the same set of rules: behaviour elements are always assigned to active structure elements, and passive structure elements are only accessed by behaviour elements. This means that active structure elements perform behaviour, while behaviour elements specify how the state of passive structure elements changes. Thus, a passive structure element is only able to change state as the result of behaviour performed on it by some active structure element. Figure 4 shows a simplified view of ArchiMate’s meta-model, and Table 3 summarizes a subset of the concepts found in ArchiMate’s business layer.

Fig. 4
figure 4

The ArchiMate meta-model (adapted from [11, 21])

Full size image
Table 3 A subset of concepts from ArchiMate’s business layer (adapted from [11])
Full size table

2.4 Ontologies

The term ontology originates from the Greek ontos (being) and logos (word). From a philosophical perspective, it is defined as a “systematic explanation of existence”, while in computer science it is often used to convey the notion of a “formal, explicit specification of a shared conceptualisation” [38]. The term conceptualization refers to an “abstract, simplified view of the world” that contains “the objects, concepts, and other entities that are assumed to exist in some area of interest” along with “the relationships that hold among them” [39]. The term explicit refers to the definition of the “type of concepts used, and the constraints on their use” while formal refers to the fact that the conceptualization “should be machine readable”. Finally, shared means that the ontology “captures consensual knowledge” [40].

Ontology integration is about identifying shared concepts and relationships between two or more ontologies. Integration relates these elements and uses the resulting knowledge for some purpose, such as merging a group of ontologies into a single ontology [41]. Integration is closely related to ontology alignment, merging and mapping. Ontology alignment concerns the discovery of contextual correspondences between two or more ontologies. Merging is the creation of a new ontology through the “union of the source ontologies” while capturing “all the knowledge from the original ontologies”. Merging can be challenging since “all correspondences and differences between the ontologies need to be reflected in the merged ontology”. Ontology mapping concerns the “representation of the correspondences between ontologies”. Correspondences are typically “stored separately from the ontologies” since they are not “part of the ontologies themselves”. Thus, mapping often represents the results of aligning different ontologies [42].

Reasoning denotes a mechanism that takes facts that are implicit in an ontology and transforms them to explicit facts. Reasoning can be classified as deductive, inductive and abductive [43]. Deductive reasoning derives a logical consequence from a set of assumptions. For example, if all swans are white, and if a bird is a swan, then, by deduction, the bird is white. Induction produces conclusions with a degree of uncertainty: if all swans observed so far are white, then, by induction, all swans are likely to be white, although that fact may not hold universally true. Abduction infers a condition from a consequence: given that swans can fly and that flying is a means of motion, then if a swan has moved, thus, by abduction, the swan has flown.

Description logics (DL) are “a family of logic-based knowledge representation languages suitable for the representation of ontologies”, which can be seen as “a decidable fragment of first-order logic” [44]. DL describe domains in terms of concepts, roles, and individuals. Roles and concepts are related using logical statements named axioms. Axioms can be of two kinds: terminological and assertional. Terminological axioms describe concepts and properties of the concepts, while assertional axioms are statements about the individuals or instances that are compatible with terminological axioms. A T-Box is a finite set of terminological axioms, and a A-Box is a finite set of assertional axioms. Together, the T-Box and A-Box statements define a knowledge base.

Several varieties of DL exist with differing degrees of expressiveness. The base DL is the Attributive Language with Complements (\({\mathcal {ALC}}\)), which enables relating the concepts with the following functions: union, intersection, complement, universal restriction and existential restriction. The expressiveness of \({\mathcal {ALC}}\) can be augmented with transitive and inverse roles, role hierarchy, cardinality restrictions, qualified cardinality restrictions, concrete domains and enumerated classes.

3 Enterprise model representation and analysis

This section describes fundamentals of the proposed approach, namely schema representation (Sect. 3.1), schema integration (Sect. 3.2) and schema analysis (Sect. 3.3).

3.1 Model representation

A domain model is specified using a conceptual schema that defines its domain-specific entity types and relationship types. Thus, the instances of each entity and relationship are classified according to the types defined in the schema. These conceptual schemas and the underlying information base can be represented as triples (subject, predicate, object) or as ontologies [45, 46].

Enterprise models often involve multiple domains and stakeholders. To manage this fact, ISO 42010 recommends defining viewpoints and generating views according to the viewpoints to promote separation of concerns, i.e. isolating certain aspects of an architecture according to the concerns of its stakeholders [47]. Since ontologies can be analysed with graph-based and semantic queries, a viewpoint can be specified as a set of axioms from which views are derived from. This approach makes possible specifying viewpoints such as “determine all entities of type Business Process that relate with at least two entities of type Business Object via the use relationship”.

3.2 Model integration

Enterprise models cross-cut multiple domains, ranging from strategy, goals and business processes, to information systems, performance indicators and technological infrastructure. One approach to handle multiple-domain models is defining a common meta-model that unifies all the relevant concepts found in the multiple domains being addressed [22]. A benefit is that the meta-model can be designed with conceptual consistency as a principle, but at the expense of specificity and design effort. Moreover, such meta-models often need to generalize or specify concepts at a high level of abstraction in order to make concept unification possible. This approach may prove not to be adequate to address the concerns of the stakeholders of the model in terms of the required granularity or level of detail. As a result, some authors argue that this approach is only appropriate to integrate domains that already share similar concepts at a similar level of abstraction [5, 48–50]. An alternative approach is using federated models or domain-specific modelling languages [4, 18–20, 22, 24, 28, 51]. Domain specificity is also acknowledged by the application of situational modelling to enterprise architecture management as it facilitates the selection of a suitable modelling approach according to the constraints and goals of the project at hand [3, 48, 52, 53].

This article proposes a design artefact that consists of a set of domain-specific ontologies (DSO) that are linked together by functions that act as transformation maps [7, 54, 55]. Each DSO is regarded as a domain-specific modelling language that conceptualizes and represents the concerns bounded to a given domain. The domain-specific ontologies can be complemented by an upper ontology (UO). An UO is a schema that defines generic entity and relationship types from where the domain-specific ontologies can be derived from. Using an UO facilitates the integration of domain-specific ontologies and guides the development of new ontologies [56]. Examples of related upper ontologies include the Unified Foundational Ontology [27], the Simple Knowledge Organization System Reference [57], and the General Formal Ontology [58].

Fig. 5
figure 5

Using four transformation maps to federate five domain-specific ontologies

Full size image

The modelling of multiple domains is addressed through the specification of multiple DSO along with transformation maps that link the domain-specific concepts according to the concerns of the stakeholders. Thus, a transformation map states the contextual relationships between a pair of DSO. As a result, a transformation map cannot be regarded as universal as it is designed to translate how concepts relate in a specific context and for a specific purpose.

A transformation map is defined as a conceptual schema and specifies the semantics behind the relationships between schemas. The same schema may map to more than one schema, which means that the same concept may be mapped to multiple concepts in different schemas. A transformation map describes the transformation functions between the concepts pertaining to a pair of DSO. A function may describe several types of concept relationships, such as isomorphic 1:1 equivalence relationships, 1:n aggregation, concept classification, as well as rule-based or pattern-based transformations [7, 20, 54]. The definition of a function must also consider mapping deficiencies, such as incompleteness, redundancy, excess and overload [59]. There are specific techniques to handle these deficiencies depending on the integration requirements [46, 60].

Figure 5 exemplifies the transformation mapping between five ontological schemas. Each map defines the structural and semantic relationships that are required to match their types.

3.3 Model analysis

Model analysis focuses on the examination of model artefacts, properties and dependencies [5]. Since the conceptualization of multiple domains implies the definition of a landscape of schemas (DSO), the analysis task can be classified as:

  • Intra-schema analysis, when it targets a single schema S,

  • Inter-schema analysis, when it targets a pair of schemas \((S_{1}, S_{2})\), or

  • Chained analysis, when it combines intra- and inter-schema analysis over two or more schemas \((S_{1}, \dots , S_{n})\).

The analysis of schemas can be accomplished through logical inference or graph analysis. Graph analysis is applicable because an ontology intrinsically represents a labelled and directed graph. This means that the corresponding RDF(S) graph of (subject, predicate, object) triples can be analysed using a semantic query language such as SPARQL [61].

Fig. 6
figure 6

The federated BMC, e3value and ArchiMate models

Full size image

Description logics uses inference to provide five types of reasoning: subsumption, instance checking, relation checking, concept consistency, and knowledge base consistency. Reasoning can be used to analyse the entity and relationship types specified in the conceptual schema as well as the individual instances of these types. Subsumption and instance checking analyse model heterogeneity and involve classifying types and its individuals in order to refactor the model. Relation checking determines how entity types relate to each other through a chain of relationship types. Thus, it supports dependency analysis, i.e. checking whether two elements are related to each other and determining the nature of the relationship. It also supports analysing the coverage of a model, e.g. to determine how the model’s artefacts intersect architecture layers. It also plays a role in interface analysis as it enables assessing cohesion and coupling of an artefact. Finally, relation checking aids the computation of metrics, e.g. used for complexity and cost/benefit analysis. Concept consistency can be used to verify the existence of contradictions between the definitions of a type. This can be used to determine whether rules or requirements are met by a schema. Knowledge base consistency checking can be used to verify whether the definition of an individual entity or relationship complies with the definition of the corresponding type, i.e. whether a model is valid against the specification of a meta-model.

The application of reasoning to analyse dependencies is limited to the relationships between different types since it is not possible to analyse relationships between type properties [50]. Reasoning is also not a good candidate to perform the computation of metrics required for complexity analysis and cost/benefit analysis. In these scenarios, reasoning requires to be complemented with other analytical techniques, such as graph analysis.

4 Federating ArchiMate, e3value, and BMC

This section describes an application of the concepts described earlier to the representation, integration and analysis of the ArchiMate, e3value and BMC modelling languages as depicted in Fig. 6. Integrating these models into a federated model landscape proves to be attractive because it contributes to understanding how the business model of an organization fits into a value network, and how the processes of an organization realize the corresponding business model [13, 14, 35]. This goal is achieved by performing three steps: (1) representing schemas that specify the ArchiMate, BMC and e3value modelling languages, (2) defining the transformation maps that integrate these schemas for the purpose of alignment checking and (3) analysing the federated models. These steps are described in the following three sections.

4.1 Model representation

Model representation concerns creating conceptual schemas that specify the domain to be analysed. It entails specifying the concepts behind a modelling language as an ontological schema. This section deals with representing the e3value, business model canvas, and ArchiMate meta-models using ontological schemas. Therefore, the e3value concepts are specified as a OWL-DL schema that represents its T-box. OWL object properties define the constraints from the meta-model, such as the restrictions that e3value defines over the concept of Value Interface as depicted in Fig. 7. ArchiMate entities are specified as OWL Classes, and relationships as Object Properties. Restrictions are specified using Inverse Object Properties and Super Object Properties so that ArchiMate’s derived relationships can be extracted through the use of reasoners. Dependencies between entities are represented with Super Object Property chains. The depends from and depends to Object Property are inverse and transitive Super Object Property relationships that specify ArchiMate’s aggregation, composition, assignment, usage and realization relationships.

Fig. 7
figure 7

The T-box OWL schema of e3value’s Value Interface

Full size image

4.2 Model integration

Schema federation is accomplished through the specification of transformation maps that relate the concepts defined in the domain-specific ontologies. This section describes the integration of the ArchiMate, e3value and BMC schemas using three domain-specific ontologies. But other schema integration configurations are possible, e.g. using ArchiMate as an upper ontology and considering e3value and BMC as two DSO. Other alternatives include using an ontology such as TOVE or the Enterprise Ontology [26] as upper-level ontology and integrating the ArchiMate, e3value and BMC schemas with this UO.

A transformation map defines functions that map the relevant types between a pair of schemas. Table 4 describes the source material that was used to define the transformation functions between e3value, business model canvas and the ArchiMate languages. It is important to remark that is not a goal of this paper to demonstrate the soundness of these mappings but instead to assess whether semantic techniques can be used to represent, integrate and analyse different enterprise models, regardless of the actual mapping functions.

Table 4 Sources used to ground the mapping between BMC, e3value and ArchiMate
Full size table
Fig. 8
figure 8

Relationships between the three enterprise modelling languages from a value exchange perspective and the corresponding DSO representations

Full size image

Schema representation and integration are context dependent as the mappings are designed to address specific concerns. For this demonstration, we set as the primary concern the analysis of business models from a value network perspective. This means that the e3value schema defines the baseline to analyse how value exchange occurs, while the BMC and ArchiMate schemas are used to understand the strategic and operational perspectives of value exchange. Thus, federating these schemas allows to understand the alignment between these domains. Figure 8 depicts the federation strategy here described, where the value network concepts (e3value) are satisfied by the strategic business model (BMC) and realized by the operational business concepts (ArchiMate). One value network model relates to many BMC and ArchiMate models, as there is one BMC and ArchiMate model for each organization that is part of the value network.

An overview of the mapping functions between the three schemas is shown in Fig. 9: e3value: Key Partners and e3value: Customer Segments have direct correspondence to ArchiMate: Actors and to ArchiMate: Business Actors. A BMC: Revenue Stream corresponds to e3value: Value Transmission. Value transmission corresponds to a ArchiMate: Business Service and gets value from BMC: Key Partners using a certain BMC: Key Activity to transmit a BMC: Value Proposition to a certain customer segment through a BMC: Channel. A BMC: Value Proposition corresponds to e3value: Value Interface and ArchiMate: product. A BMC: Key Activity corresponds to e3value: Value Activity and to ArchiMate: Business Process. The BMC: Key Resources correspond to e3value: Value Object that map to tangible ArchiMate: Business Objects. Finally, BMC: Channel corresponds to ArchiMate: Business Interface.

The set of mapping functions between each pair of schemas is implemented as a separate ontology so that the relationships do not become coupled to a specific meta-model. Figure 10 shows part of the OWL-DL mapping functions that specify e3value’s Value Transmission concept. The next sections detail the rationale of the mapping between the e3value, BMC and ArchiMate languages.

Fig. 9
figure 9

Overview of the mapping functions between BMC, e3value and ArchiMate

Full size image
Fig. 10
figure 10

Partial OWL-DL specification of e3value’s value transmission

Full size image

4.2.1 Mapping BMC and e3value

Although modelling an organization from different perspectives, the business model canvas and e3value share a number of similarities. Gordijn et al. [13] compares and maps the concepts between these two languages. Table 5 summarizes how the five core concepts of e3value relate to BMC. Note that the BMC classifies actors as either clients or partners, while that distinction is not evident in e3value. As a result, the BMC defines customer segments, customer relationships, channels, value proposition and revenue streams as client-side building blocks, whereas key partners, key activities, key resources and cost structure are considered partner-side building blocks.

Table 5 Mappings between BMC and e3value
Full size table

4.2.2 Mapping BMC to ArchiMate

The mapping functions described in Table 6 result from prior work on attempting to align the concepts found in the BMC and ArchiMate languages [36, 37, 62]. Not all transformations are considered here. In particular, the relationships between internal Cost Structure and Value were disregarded since only the external business services are visible from a value network perspective.

Table 6 Mapping from BMC to ArchiMate’s business layer
Full size table

4.2.3 Mapping e3value to ArchiMate

The integration of e3value and ArchiMate models is constrained by the semantic gap that derives from the different abstractions used to represent the same economic transactions [14]. One approach to address the abstraction gap is using an intermediate language as described by Pombinho et al. [35], Pombinho and Tribolet [64] and de Kinderen et al. [63], who use DEMO’s transaction model [65, 66] as a bridge between e3value and ArchiMate. The main advantage of using DEMO is exploiting PSI theory’s distinction axiom. This axiom states that the acts performed by an organization are classified either as ontological, infological and datalogical. These classes relate with the three human abilities: ontological acts relate to performa (deciding, judging, etc.), infological acts relate to informa (deducing, reasoning, computing, etc.), and datalogical acts relate to forma (storing, transmitting, etc.). DEMO also separates the teleology of an enterprise from its ontology, and focuses on the later while abstracting from the former. The combination of these two features acts as a filter that reduces complexity and improves model conciseness [66]. Based on these approaches, we use the mapping functions described in Table 7 to integrate e3value’s concepts with ArchiMate’s business layer.

Table 7 Mappings from e3value’s concepts to ArchiMate’s business layer
Full size table

4.3 Model analysis

Analysis generates information from a single model or from a federated set of models. It may focus on (1) the specification of a schema of an enterprise modelling language, (2) an instantiation of a schema of a specific modelling scenario and (3) a case of a modelling scenario. Let us consider the ArchiMate enterprise modelling language to provide an example. The first case of analysis would target ArchiMate’s meta-model, i.e. the representation as an ontological schema of its meta-model. This enables to explore its concepts, direct relationships and derived relationships. Examples of analysis include determining which concepts can be related through ArchiMate’s assignment relationship, or explaining how an actor is involved in the realization of a business service. The second case would target an instance of an ArchiMate model. Consider the model of a business process P containing activities \(P_1, P_1, P_3\) and actors \(A_1, A_2\), along with control flow relationships between activities, and assignment relationships between activities and actors. The analysis of this scenario entails looking at the instances of ArchiMate’s meta-model. For instance, one can determine which actor instance is assigned to activity \(P_1\), or which activities are sequenced after activity \(P_2\). Another example is checking the conformance of the instantiated schema with regard to ArchiMate’s meta-model, i.e. checking whether the instantiated entities and relationships conform with the meta-model. If an activity is assigned to another activity, this would violate the meta-model and would be detected as an inconsistency. Finally, the third case of analysis targets the cases or instances of process P. An example of analysis is determining the actual actors assigned to \(P_1\).

Graph analysis is performed with the SPARQL language [61]. A simple example is using a SPARQL query to traverse the graph and find all business services in an ArchiMate model. SPARQL queries may also make use of nesting and operators such as union, filters, value aggregation and path expressions. SPARQL queries can also be used to analyse multiple schemas using inter-schema analysis or chained queries. An example of a chained query is finding the relationships between BMC’s customer segments and ArchiMate’s business services. As depicted in Fig. 9, a business service has a derived relationship to BMC’s customer segment via e3value’s value transmission. This chained query translates to the following in SPARQL.

figure h

The mapping functions presented in Tables 5, 6 and 7 were translated to further SPARQL queries.

5 Case study

This section evaluates the artefact using competency questions. Competency questions are a means to assess the completeness and consistency of an ontological schema [67–69]. In this paper, the questions are designed to check whether a federated enterprise modelling scenario is consistent with regard to the set of mapping functions described in the previous section.

The scenario describes the business model of ePharmacare, an electronic health initiative. ePharmacare provides health services to chronic medicated patients through an electronic service hub. The services include registering treatment plans, supporting the prescription, ordering and delivery of drugs and other pharmaceutical products, following up the treatments prescribed by doctors to patients, and enabling chronic patients to receive notifications as well as to log drug intake and the effects of medication. ePharmacare is therefore a virtual network of organizations and includes doctors and chronic patients as well as pharmacies, pharmaceutical companies, the national health insurance system, as well as healthcare providers. From a business perspective, the services of ePharmacare are considered to be value-adding to its stakeholders since they are designed to provide economic savings while increasing the traceability of treatments and the ability to perform cause-effect analysis. The enterprise models of ePharmacare used in this case study result from the analysis of existing project documentation and business process models, and from workshops and semi-structured interviews with the project’s stakeholders [70–72]. The subset of models included in this paper is the following:

  • the e3value value network model of ePharmacare that links together the individual business partners (Fig. 11),

  • the BMC of ePharmacare (Fig. 16),

  • the BMC of a subset of ePharmacare’s partners (Fig. 17),

  • the ArchiMate models that describe the business services and processes of ePharmacare (Fig. 14), as well as those of a subset of its business partners (Fig. 15).

These models serve different purposes. The value network model describes the value flow between the partners. Each partner has its own business model canvas describing its individual business model, along with ArchiMate models describing the underlying business services and processes.

Fig. 11
figure 11

The e3value model of ePharmacare

Full size image

5.1 Schema evaluation

The integrated schemas are evaluated by testing the ability to assess the 18 statements described in Table 8. These competency questions are designed so that each of the transformation functions is tested by at least one competency question, thus covering all of the mapping functions.

Table 8 List of competency questions
Full size table

Each question was translated to a SPARQL query. The following query implements question 1 by subtracting the Customer Segments that relate to an e3value Actor from the set of all BMC Customer Segments. The same subtraction is applied to Key Partners. The result is a set of BMC Customer Segment and Key Partner individuals that do not correspond to any Actor individual in the e3value model and thus do not comply with this constraint.

figure i

The remaining questions were implemented in a similar fashion. Figures 18 and 19 in the Appendix illustrate the answers to the first nine questions. Each answer that is a nonempty set of individuals is an inconsistency at instance level because an answer contains the individuals that do not comply with the given constraint. Thus, if all questions produce empty answers, then the scenario is deemed consistent with regard to that set of constraints.

SPARQL queries can be used to analyse individual schemas as well as the integrated schemas. The following query iterates through all Business Object and discovers all Value Objects associated with it. The results of this query are depicted in Fig. 12.

figure j
Fig. 12
figure 12

Results of the SPARQL query showing the relationships between value objects and business objects

Full size image

The models can also be analysed using a logical reasoner instead of SPARQL. In this case, the queries are specified with OWL-DL and a reasoner is used to infer facts from a model. The six statements shown in listing 4 were processed with the HermiT reasoner using the Protégé tool. Figure 13 shows the results of reasoning.

figure k
Fig. 13
figure 13

Results of OWL-DL reasoning, queries 1–6

Full size image

Note that the proposed artefact is not able to resolve the detected inconsistencies. Indeed, some inconsistencies may be simple syntactical mismatches that can be corrected semi-automatically. But contradictory interpretations of the same business concept at semantic level need to be addressed by the stakeholders using techniques such as concept elicitation or workshops. Therefore, the approach described in this paper is not meant to automate the process of resolving the inconsistencies but to automatically detect the inconsistencies with regard to a specific set of constraints.

This section described the ePharmacare scenario to demonstrate the ability of using semantic techniques to (1) represent the meta-models of three enterprise modelling languages, BMC, ArchiMate and e3value, as well as instances of models specified in these languages, (2) federate the models using transformation functions and (3) analyse the integrated models. The results of the integrated model analysis show, on the one hand, the ability to use SPARQL and OWL-DL to analyse individual schemas as well as integrated schemas, and, on the other, the ability to assess the consistency of a model regarding a set of constraints.

6 Conclusions

Enterprise models cross-cut different domains that can be observed from multiple viewpoints. These models enable stakeholders to communicate, understand, analyse, design and transform an enterprise system. This paper explored the application of semantic techniques to integrate and jointly analyse different enterprise modelling languages.

The design artefact presented in this paper is a federated set of schemas that represent domain-specific languages (conceptual schemas), and the instances of those schemas (information bases). Each domain is represented as a domain-specific schema (DSO) that specifies entity and relationship types. A federated model landscape is generated by integrating the schemas using transformation maps that relate the relevant types across the different domains. The specification of a transformation map is situational, i.e. the mapping functions depend on the context and purpose of the integration.

The schemas are formalized with RDFS and the OWL-DL languages, which makes possible analysing the models with graph analysis or with reasoners that perform logical inference. The analysis may target a single domain or a combination of integrated domains. Different types of analysis are possible, including assessing the conformance of a model against a set of constraints.

The utility of the artefact is demonstrated through the integration of three languages that describe an organization from different perspectives, namely the business model canvas, e3value and ArchiMate. This involved specifying the conceptual schemas behind each of these modelling languages, along with the transformation maps between the schemas. A case study was used to define the information base and to assess the ability of semantic techniques to integrate and analyse the different enterprise modelling languages.

The main contribution of this paper is accounting how semantic techniques, in particular ontology-based techniques, can be used to computationally represent, integrate and analyse enterprise models. As such, a fundamental challenge resides in defining mapping functions between the schemas that fit the context and purpose of the integration. Defining such functions may prove to be a complex or even unfeasible task depending on the semantic gap between the languages being mapped. Nevertheless, the application of semantic techniques to enterprise modelling brings value to the enterprise engineering community of practice as it facilitates the integration and analysis of diverse modelling domains.