When modelling enterprises, for instance as part of an enterprise (re)engineering effort, one typically uses a range of models. These models differ in their intended purpose in terms of the domain which the model should pertain to and the intended usage of the model by its audience. The models are therefore generally created in purpose-specific modelling languages; i.e. not just domain-specific languages. While using purpose-specific modelling languages has clear benefits in terms of the suitability of the language to a purpose at hand, there is also a downside to it. As each of the resulting enterprise models refers to (different aspects of) the same (version of the) enterprise, it is desirable to maintain coherence across the different models. The use of a wide range of purpose-specific models (and modelling languages) can easily lead to a fragmentation of the modelling landscape; i.e. a break up of coherence. This leads to a natural polarity between coherence and purpose-specificity. We argue that this polarity requires careful management, but first and foremost a better understanding. To cope with, or avoid, the consequences of fragmentation, different strategies to achieve the integration of models and languages used in enterprise modelling have been suggested in the literature. These approaches, however, focus mainly on syntactic aspects of the models, while sometimes indeed including their (formal) semantics, and only to some extent their pragmatics. The aim of the research, reported on in this paper, is to achieve a deeper understanding of the needs and challenges of the use of different models in enterprise modelling.
When deliberately changing (parts of an) enterprise, one generally uses models to
understand the current situation of the enterprise, analyse the problems/challenges with
regard to the current situation, sketch potential future scenario’s, and design selected
future desired states of the enterprise, etc. We use the term enterprise modelling
landscape, or simply modelling landscape, to refer to the variety of models (and
corresponding purpose-specific modelling languages) used in such efforts. The developing
field of enterprise engineering [
When modelling enterprises in an enterprise engineering context, one must do so
from the perspective of different domains, such as business processes, value exchanges,
products and services, information systems, etc. The fact that enterprise modelling
needs to deal with different domains, within the context of a specific enterprise is
certainly not new. In the field of information systems engineering, the use of a
multiperspective approach has long since been advocated, e.g. [
We argue that the plethora of models used in enterprise engineering efforts is
brought about by the fact that models are needed for different purposes. In our
current understanding, and based on our earlier work in e.g. [
In other words, the purpose of a specific model is to capture some domain to enable some usage by its audience.
Ideally, such models are created in a purpose-specific modelling language that tunes
the modelling constructs of the language to the domain to be modelled, as well as adjust
the precision/form of the medium, syntax and semantics of the language to the intended
usage of the models. In practical modelling situations we have observed how, depending
on the modelling purpose at hand, generic modelling language, such as UML [
The notion of purpose-specific modelling language is certainly related to the notion
of domain-specific languages [
Since all of the models of an enterprise modelling landscape provide different views
on the same enterprise, it is quite natural (and in line with an engineering perspective) to
expect that the sets of models form a coherent whole; i.e. linked where relevant and
consistent as a whole. Having such coherence among models also enables cross-cutting and
impact of change analysis, traceability analysis, etc. So, while using purpose-specific
modelling languages has clear benefits in terms of suitability of the language (and
models) to a purpose at hand, there is also a potential downside to it. A plethora of
purposespecific models can easily lead to a fragmentation of the modelling landscape; i.e. a
break up of coherence, also addressed as a “Tower of Babel situation” [
In this paper, which is the result of an ongoing research, we present our current understanding of fundamental challenges related to coherent enterprise modelling landscapes. We will start in Section 2 by exploring the polarity between coherence and purpose-specificity in more detail, with the aim of gaining a better appreciation of the forces that are involved. We will then continue in Section 3 by exploring some of the existing strategies to manage this polarity. This discussion is then used as a base to develop the first-most elements of a theory on managing the coherence of modelling landscapes in Section 4.
As already discussed, enterprise modelling is likely to involve a plethora of purposespecific models covering different aspects of the enterprise. At the same time, the diversity of models/languages increases the risk of fragmenting the modelling landscape. This section explores the forces having a potential fragmenting effect on the modelling landscape, by taking two main ingredients of a model’s purpose as a starting point. We discuss our current understanding of the “fragmenting forces”, as exerted by each of these ingredients respectively.
The perspective from which the enterprise is to be modelled is a major force of potential fragmentation. When modelling enterprises, several dimensions exist in which to identify distinct domains (aspects, viewpoints, perspectives) to model. This potentially leads to even so many domain-specific models and languages. To illustrate the diversity, without having the ambition yet to provide an orthogonal set of dimensions, consider the following possible dimensions: Intervention design – This concerns the motivation/rationalisation of a desired intervention3 (e.g. transformation or development effort) in an enterprise. Examples of different models along this dimension include: – Models capturing the goals/motivations for changing the existing enterprise. – Models capturing the requirements on the desired (direction of) change of the enterprise. 3 Note that since an enterprise is a socio-technical system that, by its nature, has a tendency to change due to the initiatives of the humans that ultimately make up the enterprise, we prefer to use the term intervention rather than system development or even implementation. The term intervention more clearly signifies the fact that an enterprise is not just a technological artefact. – Models (plans) of an intervention in the current enterprise to change it in the desired direction.
Within the plans for the intervention, one may also distinguish between different time horizons. In other words, what one might want to achieve in the next year, in five years from now, and beyond.
Enterprise design – This dimension deals with the motivation/rationalisation of the
(existing/planned) design of an enterprise. In this dimension, one could for example
distinguish between:
– Models capturing the goals/motivation for owning/using the (parts of the) enterprise.
– Models capturing the requirements on the enterprise that follow from this.
– Models capturing the design of the enterprise (meeting the requirements).
Design domains – This dimension concerns the domains that are considered relevant
to the design of an enterprise, e.g. Zachman framework cells [
Governance domains – This concerns the domains from which an enterprise wants
to govern itself. As argued in the GEA [
Models are created with an intended usage in mind, e.g. analysis, sketching,
contracting, forecasting, simulation, execution, etc. The intended usage of the model by some
audience will have a direct impact on the requirements on the modelling language used
to capture the model [
Restriction of semantics – refers to the extent to which a language is to be used with
(an enforced!) formalized semantics. Formality in this context refers to the fact that the
modelling language (graphical or textual) has an underlying semantics in some
mathematical domain. See e.g. [
Different strategies can be used to manage this potential fragmentation of the modelling landscape. In this section we discuss some of the strategies suggested in the literature, as well as their involved trade-offs.
A classical approach to enable integrated modelling of the enterprise would involve relying on an all-encompassing and unified modelling language, to integrate all the relevant perspectives on the enterprise. This approach essentially boils down to preventing the fragmentation from occurring in the first place: it involves a single and stable language with an a priori defined set of concepts and their links, to be used uniformly. This would also lead to the standardisation of the language, i.e. vocabulary used for modelling, which in turn should facilitate knowledge transfer and communication about the system being engineered.
Such a line of reasoning can for instance be observed in the definitions of UML [
Secondly, in dealing with an enterprise, one has to acknowledge the
heterogeneity of communities and their (sub)languages [
A more flexible strategy results when allowing the co-existence of different modelling
languages to model different perspectives on an enterprise. Essentially, this approach
acknowledges the benefits of focused modelling languages for particular purposes. The
integration strategy here consists in seeking to establish the links between these
different languages and models used, in general having the ambition of interoperability
of modelling languages at syntactic and semantic levels. For example, the MEMO [
The Unified Enterprise Modelling Language (UEML) [
Even when using a common language to express the syntax and semantics of each
language, bridges between the different languages and models still need to be built. To
enable the creation of such bridges between modelling languages, it has been suggested
in [
One can take this idea of using a common ontology a step further, by (re)designing the
different purpose-specific modelling languages as specializations of a common generic
meta-model. This leads to an approach in between the unified languages and federated
languages approaches, which might be called a family of languages. Note that such a
generic meta-model is not a meta-meta-model. It is a generalized meta-model, where
the meta-models of more specific languages can be seen as specialization/refinements
of the generic meta-model (i.e. not as instantiations of a meta-meta-model). The idea
of using a generic meta-model is akin to older work on the so-called meta-model
hierarchy [
In this section, we develop the first elements of an explanatory theory that aims to gain better insight into the needs and challenges underlying the use of different models/languages in enterprise modelling. We first explore the dimension of domainspecificity in 4.1, by analysing the interplay between domain concepts and normative restrictions on the modelling languages. In 4.2, we discuss the relation between purposebased model/language tuning, model quality dimensions and identified dimensions of fragmentation.
To support this analysis, we introduce the matrix as shown in Figure 1. The
horizontal dimension of the matrix corresponds to the openness to different interpretations of
the domain concepts, i.e. (natural language) concepts used to communicate about the
domain. Its extremes are defined as:
Open – where multiple interpretations of the domain concepts are possible. This is
typically the case in domains with heterogeneous communities, whose practise and use
of language differs significantly, resulting in different environments of discourse within
the domain [
Normative – where there is a single (allowed) interpretation of domain concepts. Typically, domain concepts are defined within the normative documents. For example, in the insurance sector, standardized definitions of the insurance concepts exist within the i.e. Business Glossary4, and are intended to be used as the basis for communication between industry partners, in the development of services, architectures and applications etc.
The vertical dimension of the matrix represents the scale of normative restriction of modelling language. We define the extremes on this scale as follows: Open – with modelling language not being restricted a priori, but being constructed along the process of domain modelling.
Normative – refers to the modelling languages whose both syntax and semantics are formally defined in a mathematical language, resulting in one possible interpretation of the modelling language constructs. 4 http://acord.org/resources/framework/Pages/default.aspx
Normative Modelling language definition
Open
Open s L M P G s L M S
D Domain concepts
Normative
As already discussed, there is a natural drive towards using domain-specific
modelling languages (DSML) in enterprise modelling [
DSMLs can be defined and used at various levels of formality, e.g. as semi-formal
and visual [
However, besides DSMLs, rather general-purpose modelling languages (GPML)
such as i* [
Following these discussions, we position DSMLs across the cells on the right side of the matrix, and GPMLs across the cells on the left side of the matrix. The boundary between a GPML and a DSML is not as straightforward, but what clearly distinguishes these two families is the ambition of DSMLs to exclude as much as possible the potential different interpretations of the domain concepts incorporated in the language. While DSMLs offer advantages of zooming in a particular domain with its specific concepts, they also come with the cost, since they emphasize particular terminologies, do not facilitate cross-domain communication, and exert the fragmenting effect on the enterprise modelling landscape. On the other hand, GPMLs are easier to reuse for modelling different domains, however the interpretation challenge of the models expressed in GPMLs is more pronounced.
The purpose for which the model is to be used influences the requirements on the
information conveyed by the model, but also the way the it should be represented for its
intended audience). Therefore, there is a clear connection between the notions of model
purpose and model quality [
More specifically, in terms of the SEQUAL framework [
Empirical quality – also links to the restriction of notation dimension, though referring more to the way the notation is used, e.g. in terms of comprehensibility and readability.
Syntactic quality – links directly to the restriction of syntax dimension. Semantic quality – links directly to the restriction of semantics dimension. Perceived semantic quality – covers the correspondence between actors’ interpretation of the model and their current knowledge of the domain. The actor’s interpretation of the model will be influenced by a priori choice of the domain and restrictions on notation, syntax, or semantics, in particular if they support the actor’s prior knowledge and abilities to understand model’s representation.
Pragmatic quality – as the correspondence between the model and its interpretation
by the audience links to the spectrum of usage-specific fragmentations. Combined they
enable or restrict the freedom of modellers to influence the pragmatic quality of models.
In this regard, as argued in [
Social quality – is not linked directly to model purpose dimension, in our view, but embedded more in the process of modelling, and therefore linked to the modelling purpose.
Organisational quality – is in our view linked mainly to the domain-specificity dimensions, determining the primary goal of modelling in capturing some domain in terms of a model.
We illustrate these considerations with several more or less typical model purposes
within enterprise modelling:
Collaborative domain modelling in a heterogeneous community – This variation of
domain modelling is typical for the domains with heterogeneous communities, whose
practice and use of language differs significantly, resulting in different environments
of discourse within the domain [
Stakeholder communication – In this context, the models are intended to provide
various stakeholders with needed insight in issues/problems at hand, and aid in human
decision-making. As typically these stakeholders do not have an engineering
background, there is a clear preference towards graphical and rather informal or
‘box-andline style’ representations [
Model execution – When the model is intended to be directly executable by tools (e.g.
specification of the software system), what matters the most is its formality, therefore
the focus is on syntactic and semantic quality of the model. The corresponding
modelling language therefore should be a formal one, covering at least execution semantics
for the model, e.g. [
In this paper we explored the issues involved in assuring the coherence of enterprise modelling landscapes. We argued that while there is a clear need to have coherence among the set of models used to represent different aspects of the same (version of) an enterprise, the purpose-specificity which enables the tuning of models (and languages) to the purpose at hand, has a fragmenting effect on the modelling landscape. We concluded that the polarity between coherence and purpose-specificity should therefore be managed carefully. In this context, we discussed some of the existing strategies to reach integrated use of models and languages in enterprise modelling, including their tradeoffs. Finally, we sketched some elements of an explanatory theory to better understand the use of enterprise models/languages at various level of domain- and usage-specificity. As a next step, we aim to further develop the latter theory, where we will initially focus on model purpose, but in later versions also involve modelling purpose in the equation. With such an explanatory theory in place, we can then endeavour to develop heuristics to balance the needs for purpose-specificity of models and the need for coherence. Acknowledgement. This work has been partially sponsored by the Fonds National de la Recherche Luxembourg (www.fnr.lu), via the PEARL programme.