A Semantic Foundation for Role-Related Concepts in Enterprise Modelling

Abstract

In this paper, we provide a semantic foundation for role-related concepts in enterprise modelling. We use a conceptual modelling framework to provide a well-founded underpinning for these concepts. We review a number of enterprise modelling approaches in light of the concepts described. This allows us to understand the various approaches, to contrast them and to identify problems in the definition and/or usage of these concepts.

Full text

A Semantic Foundation for Role-Related Concepts in Enterprise Modelling
*
João Paulo A. Almeida and Giancarlo Guizzardi
Federal University of Espírito Santo, Brazil
jpalmeida@ieee.org, guizzardi@loa-cnr.it
*
This work is partly supported by FAPES (Fundação de Apoio à Ciência e Tecnologia do Espírito Santo) in the context of the INFRA-MODELA
project, and partly supported by FACITEC (Fundo de Apoio à Ciência e Tecnologia do Município de Vitória) in the scope of the MODELA project.
Abstract
In this paper, we provide a semantic foundation for
role-related concepts in Enterprise Modelling. We use a
conceptual modelling framework to provide a well-
founded underpinning for these concepts. We review a
number of Enterprise Modelling approaches in light of
the concepts described. This allows us to understand the
various approaches, to contrast them and to identify
problems in the definition and/or usage of these concepts.
Keywords: roles, actors, enterprise modelling, concep-
tual modelling, object modelling.
1. Introduction
The concept of “role” is present in several Enterprise
Modelling approaches [15, 20, 22, 25]. In most of these
approaches, enterprise activities are performed by entities
which are called “actors”, “agents” or “objects” and that
can be said to play “roles” in these activities. Typically,
the concept of role is used to define the responsibilities
and properties that apply to “actors” while playing “roles”
and what actions (or kinds of actions) are performed by
which “actors”.
“Roles” are also highly relevant when discussing the
actions that are performed by users in interaction with a
service or system and the service behaviour with respect
to user interaction. In this case, it becomes necessary to
define the (kinds of) actions that may be performed by
particular (kinds of) users as well as the representation of
users‟ identities and their properties in the scope of the
service or system.
As discussed in [16] the role concept is based on a
theatrical metaphor: “The text of a play is expressed in
terms of lines and actions associated with various roles,
which are declared initially in a cast-list. Putting the play
on involves assigning actors to the various roles, although
one actor may play several minor roles, and the actor
playing a role may change during the run of the produc-
tion. Identifying the roles rather than the actors obviously
makes the script more reusable.” Similarly, defining an
enterprise or service model in terms of “roles”, allows the
model to remain stable in the presence of dynamic
changes in role playing.
Although the term “role” is significantly present in
Enterprise Modelling approaches, under close inspection,
we can conclude that it often denotes different underlying
concepts with different basic properties. Given the
importance of roles in Enterprise Modelling, a clear
semantic account for roles and role-related concepts is
necessary and would serve as a basis for communication,
consensus and alignment of the various approaches.
In this paper, we provide a semantic foundation for the
role-related concepts for Enterprise Architecture and
Enterprise Modelling language. Our claim is that some
theories of conceptual modelling (as consolidated in [8])
provide a well-founded underpinning for these concepts,
and allow us to harmonize competing proposals for them.
We review a number of Enterprise Modelling ap-
proaches in light of the semantic described, namely,
Archimate, DoDAF, ARIS, BPMN and the RM-ODP
(Enterprise Viewpoint). This allows us to contrast the
approaches and to identify problems in the definition
and/or usage of role-related concepts.
2. Features of the role concept
Steimann [23, 24] has identified a number of features
for roles that appear throughout the object-oriented and
conceptual modelling literature (e.g., [4, 5, 6, 7, 8, 17, 18,
28]). We list each of those and introduce some examples
to provide an intuitive notion of the role concept, prior to
its rigorous definition:
1. “A role comes with its own properties and behav-
iour.” For example, when John is enrolled as a stu-
dent at the University of Twente, he has a grade point
average (GPA), he can register to courses, receive
grades, produce assignments, take exams, etc. This
feature seems to suggest that roles can be regarded as
a “type” characterizing a number of instances.
2. “Roles depend on relationships.” For example, the
roles of husband and wife as well as customer and
supplier depend on the existence of a marriage or a
business relationship. This is confirmed by the usage
of the concept of role in the conceptual modelling
literature as discussed in [8, 24] and as quoted in [5]:
“as suggested by the work of Sowa and Guarino, a
role is meaningful only in the context of a relation-

ship.” This feature makes the concept of role distinct
from that of a phase or a state [24].
3. “An object may play different roles simultaneously.”
For example, John can be a student and a husband at
the same time.
4. “An object may play the same role several times,
simultaneously.” John can be a student at the Univer-
sity of Twente and at the Tai Chi Institute simultane-
ously.
5. “An object may acquire and abandon roles
dynamically.” John is still a Person after he graduates
from the University of Twente.
6. “The sequence in which roles may be acquired and
relinquished can be subject to restrictions.” For
example, John can only register in a graduate school
after he has completed an undergraduate course.
7. “Objects of unrelated types can play the same role.”
For example, both a person (John) and an organiza-
tion (the University of Twente) can play the role of
customer in different business relationships.
8. “Roles can play roles.” For example, John can play
the role of teaching assistant for a particular course
only if he is a student at the University of Twente.
9. “A role can be transferred from one object to
another.” For example, the commitments and respon-
sibilities of the role of president are transferred from
the incumbent president to his/her successor.
10. “The state of an object can be role-specific.” If John
is a student at the University of Twente and at the Tai
Chi Institute simultaneously, John has a GPA for each
of those relations.
11. “Features of an object can be role-specific.” John
attends all classes at this undergraduate course at the
University of Twente but at the same time misses
several classes in a row at the Tai Chi Institute.
12. “Roles restrict access.” We consider this an
implementation-oriented feature, considered by
Steimann since he has surveyed object-oriented ap-
proaches in general. Since we are concerned with
conceptual models for enterprise architectures, we do
not include this feature further in our discussions.
13. “Different roles may share structure and behaviour.”
For example, both graduate students and undergradu-
ate students have a student number, may register to
courses, etc.
Features 14 and 15 contradict each other, showing that
there is lack of agreement with respect to these features in
the literature surveyed by Steimann:
14. “An object and its roles share identity.”
15. “An object and its roles have different identities.”
These features lead to the question of whether “John”,
“John as a student of the University of Twente”, “John as
a student of the Tai Chi Institute” and “John as a husband”
are the same, or whether there should be different
identities for each of the roles John plays.
3. Role-related concepts in conceptual
modelling
We proceed to identify a rigorous definition of the role
concept, which requires some preliminary definitions. We
use an extract from a philosophically and cognitively well-
founded reference ontology (foundational ontology) that
has been developed in [8, 9].
First, we distinguish between conceptual entities called
universals and individuals [8]. The notion of universal
underlies the most basic and widespread constructs in
conceptual modelling. Universals are predicative terms
that can possibly be applied to a multitude of individuals,
capturing the general aspects of such individuals.
Individuals are entities that exist possessing a unique
identity.
Figure 1 shows an extract of the foundational ontology
adopted here (all generalization relations depicted in this
figure are disjoint, forming a simple “tree-like” taxonomic
structure for the entities considered in this model.)
This taxonomic structure reveals that an individual can
be categorized as substantial or moment [10]. A moment
is an individual that existentially depends on another
individual, named its bearer. In the conceptual modelling
literature, a moment is said to inhere in its bearer. For
example, the symptoms of a patient are said to inhere in
the patient, who bears the symptoms. In contrast, a
substantial is an individual that does not inhere in other
individuals, i.e., which is not a moment. Inherence is
much stronger than a one-to-one relationship, since it
implies existential dependence between individuals. We
have that an individual x is existentially dependent on
another individual y if, and only if, as a matter of
necessity, y must exist whenever x exists. (A moment may
also inhere in another moment, the moments forming a
finite chain that ends with a substantial.)
In this paper, we characterize “actors”, “agents” or
“objects” as substantials and we explain the role-related
notions in terms of moments. We use meta-properties of
universals (namely, existential dependence, external
dependence and rigidity) to clarify certain aspects of role-
related concepts.
3.1. Qua individuals and relators
The taxonomic structure presented in Figure 1 reveals
a kind of individual which is of particular importance to
the definition of role (in gray on the right side of the
figure): a “QuaIndividual”.
An example discussed in [10] clarifies this concept.
Suppose that John is married to Mary. John has a number
of properties by virtue of being married to Mary. For

example, imagine all the legal responsibilities that John
has in the context of this relation. These newly acquired
properties are moments of John that inheres in him (and
are hence existentially dependent on John). However,
these moments also depends on the existence of Mary.
This type of moment is called externally dependent
moment. An externally dependent moment is an intrinsic
moment (or quality) that inheres in a single individual but
that is existentially dependent on (possibly a multitude of)
other individuals external to its bearer (i.e., which is not
the bearer‟s parts or intrinsic moments). In the example,
this other individual is Mary.
In the case of an externally dependent moment x there
is always an event which is the foundation of x. Again, in
the given example, we can think of a certain action a1 (the
signing of a social contract) in which both John and Mary
participate and which founds the existence of the
externally dependent moments inhering in John. Now, we
can define an individual that bears all externally depend-
ent moments of John that share the same external
dependencies and the same foundation. This individual is
called a qua individual [17]. Qua individuals are, thus, a
special type of complex externally dependent qualities. In
this case, the complex quality inhering in John that bears
all responsibilities that John acquires by virtue of the
signing of a social contract can be named John-qua-
husband.
To continue with the same example, we can think about
another qua individual Mary-qua-wife which is a complex
moment bearing all responsibilities that Mary acquires by
virtue of the same foundation and that albeit inhering in
Mary are also existentially dependent on John. The qua
individuals John-qua-husband and Mary-qua-wife are
existentially dependent on each other. Now, we can define
an aggregate composed of these two qua individuals that
share the same foundation. This aggregate is called a
relator.
3.2. Role universals
The taxonomic structure in Figure 1 also reveals a
“Role” universal. A “Role” universal applies contingently
to an individual that bears (at least one) qua individual of
a certain type. In the example presented in the previous
sub-section, we can say that John is not only an instance
of a “Person” universal but also an instance of a “Hus-
band” universal, while Mary is both an instance of a
“Wife” universal. All instances of a “Husband” universal
exhibit the behaviour required of a husband in a social
contract (marriage).
At the same time John may play the role of student
with respect to an “Educational Institution” for example,
the University of Twente. In this case, John bears a qua
individual John-qua-student, and is an instance of the
“Student” universal (John can register to courses, receive
grades, produce assignments, take exams, etc.). Further,
John may also play the role of student with respect to
other “Educational Institutions”, for example, the Tai Chi
Institute – bearing then qua individuals: John-qua-student
of the University of Twente and John-qua-student‟ of the
Tai Chi Institute.
We can say that roles universals can be restricted by
certain allowed or admissible types, i.e., certain universals
to which a role universal can apply. For example, in this
case, we can say that the “Student” role can only be
played by an instance of the kind “Person”. A kind is the
substantial universal which supplies a principle of identity
for its instances and that is instantiated necessarily by its
instances. Figure 2 shows a class diagram for this
example, using the profile defined in [8]. The characteri-
zation association represents that instances of “Person-
QuaStudent” inhere in an instance of “Student” (thus
characterizing its behaviour).
Figure 2 A role universal, its allowed type and a
qua individual universal (from [8])
Figure 3 reveals the Enrolment relator universal (an
instance of this universal includes an instance of
Figure 1 Extract of the foundational ontology adopted here from [10]

“PersonQuaStudent”). The relator universal reveals that
both an instance of “Student” and an instance of the
“Education Institution” exhibit particular properties
(shared behaviour) in the relation. Please note that
properties are merely a dual way to represent behaviour.
Figure 3 A role universal, its allowed type and a
relator universal (from [8])
3.3. Role mixin universals
The conceptualization in [8] also allows for a notion of
role mixin universal which captures commonalities in
various role universals. This universal is used in a
conceptual modelling design pattern for “roles with
multiple disjoint allowed types” (see Figure 4). (We omit
the description of role mixins from this paper, please see
[8] for a comprehensive discussion and characterization of
a role mixin as an anti-rigid non-sortal universal.)
Intuitively, a role mixin universal allows us to add
flexibility to a role universal, without tying its definition
to a specific kind. In the example, it is possible to define a
Customer independently of whether Persons or Organiza-
tions play that role.
Figure 4 Modelling roles with multiple disjoint
allowed types (an example from [8])
3.4. Examples
Table 1 summarizes the various examples presented
throughout this paper and the concepts they illustrate.
3.5. Role-related concepts in the foundations and
the features presented by Steimann
We can consider the foundations with respect to each
of the features of role-related concepts as presented by
Steimann:
1. “A role comes with its own properties and behaviour.”
Yes, a qua individual characterizes (with properties
and behaviour) the substantials that play a particular
role.
2. “Roles depend on relationships.” Yes, a qua
individual is externally dependent.
3. “An object may play different roles simultaneously.”
Yes, several qua individuals may characterize the same
substantial.
4. “An object may play the same role several times,
simultaneously.” Yes, several qua individuals that
characterize a substantial may be instances of the same
universal.
5. “An object may acquire and abandon roles dynami-
cally.” Yes, a role universal applies contingently to
substantials. In other words, a qua individual describes
a complex of contingent properties of individuals.
6. “The sequence in which roles may be acquired and
relinquished can be subject to restrictions.” Yes, one
can define conditions for the foundation of relators.
7. “Objects of unrelated types can play the same role.”
Yes, the mixin universal can be used in the design
pattern for “roles with multiple disjoint allowed
types”.
8. “Roles can play roles.” Yes, it is possible to restrict
the admissible type of a role to another role.
9. “A role can be transferred from one object to
another.” Yes, this only requires one to define rules
for the foundations of relators.
10. “The state of an object can be role-specific.” Yes, see
1.
11. “Features of an object can be role-specific.” Yes, see
1.
13. “Different roles may share structure and behaviour.”
Yes, a role universal may specialize another role
universal or role mixin universal.
With respect to contradicting 14 and 15 we can conclude:
14. “An object and its roles share identity.” Yes, if one
considers that roles are ultimately played by a substan-
tial that carries a principle of identity.
15. “An object and its roles have different identities.”
Yes, the qua individuals have identities of their own.
4. Role-related concepts in Enterprise
Modelling
In this section, we review role-related concepts in a
number of enterprise modelling approaches (Archimate,
DoDAF, ARIS, BPMN and RM-ODP). We contrast the
definitions and usage of concepts in these approaches with
the UFO-A conceptualization described in section 3.

4.1. Archimate
In the Archimate Enterprise Architecture language [12,
15], the concepts of “business actor” and “business role”
are introduced. A business actor is defined as an active
entity that performs behaviour [15]. Examples of business
actors include an individual person, a department and a
business unit. A business role is identified with the
purpose of making “the link between actors and behaviour
more flexible.” A business role is defined as that which
“states which business behaviour is performed by a
business actor that fulfils this role.”
Intuitively, the definitions seem to imply that the
business actor concept is a substantial and that the
business role concept is a role universal that may be
applied to actors (although the criteria of external
dependency is not explicitly mentioned).
The language allows “actors” and “roles” to be related
by what is called “assignment”. Figure 5 shows an
example of Archimate model with actors depicting
“actors” and “roles”. In this example, an “actor” named
“Client” is assigned to the “role” named “Insurance
buyer”, which executes the behaviour “Buy insurance”.
Further, the actor “ArchiSurance” is assigned to the “role”
named “Insurer”, which executes the “Take out insurance”
behaviour.
Although the definition for “actor” seems to imply that
an “actor” is an individual, the language makes no
distinction between the “actor” as an individual and a
universal for “actors”. This can be observed in the
example show in Figure 5. The figure shows the “Archi-
Surance” “actor” which denotes a particular insurance
company, i.e., it represents a particular substantial
individual. Nevertheless, it also shows a “Client” “actor”
which is certainly not tied to a particular client (such as
“John”) (otherwise the business process itself would be
client-specific.) We can conclude that a “Client” in this
case represents a universal for actual clients which may
participate in the business process. Based on this example,
we can state that the language lacks expressiveness with
respect to the distinction between universals and
individuals when considering the “actor” concept. Thus,
this lack of expressiveness leads to a construct overload,
which reduces the clarity of the language.
Figure 5 Archimate model (from [14])
UFO-A
Example
role universal (a role universal applies(contingently) to
instances of the role‟s allowed type.)
Husband; Wife; Student; PersonalCustomer; CorporateCustomer.
role mixin universal (These universals apply (contingently)
to instances of disjoint admissible types.)
Customer
instance of the role universal (individual that bears a qua
individual) (instance of an admissible type for the roles
involved)
John;
Mary;
universals of the admissible types for particular roles
Person (admissible type for roles Husband, Wife, Student, Personal
Customer); Organization (for CorporateCustomer);
Customer (for CorporateCustomer and PersonalCustomer);
qua individual (A qua individual is the instance that
characterizes the individual with certain behaviour in the
context of a relation to another individual.)
John-qua-husband; Mary-qua-wife; John-qua-student (of the
University of Twente); John-qua-student‟ (of the Tai Chi Chuan
Institute).
qua individual universal
Person-qua-Student; Person-qua-Husband; Person-qua-Wife.
the foundation of the qua individuals (and hence the
foundation of the relator, i.e. a founding action or behaviour.)
the signing of the social contract; the act of enrolling at the university;
the act of enrolling at the Tai Chi Chuan Institute.
relator (an aggregate of the qua individuals in the relation.)
John and Mary‟s marriage; John‟s enrolment at the University of
Twente; John‟s enrolment at the Tai Chi Chuan Institute.
relator universal
Marriage (this kind of social contract);
Enrolment (this kind of social contract).
individuals that are mediated by a relator
John and Mary; John and the University of Twente;
John and the Tai Chi Chuan Institute.
Table 1 Correspondence between role-related concepts in UFO-A and examples

4.1.1. Concept Analysis: Interpretation A (Actors
denote universals)
A feasible interpretation to enable our analysis is to
consider all “actors” in Archimate to denote universals,
with certain “actors” representing universals that have
only one instance (and, hence, are singletons, such as
“ArchiSurance” in the example presented in Figure 5).
Nevertheless, even with this interpretation, the language
would not allow one to identify which universals are
singletons and which are not.
Under this interpretation, we consider that the “as-
signment” relation represents a specializa-
tion/generalization relation between a role universal and
its admissible type. In this particular example, instances of
“Client” are the individuals that can play the role of
“Insurance buyer”, i.e., that can instantiate the “Insurance
buyer” universal.
4.1.2. Concept Analysis: Interpretation B (Actors
denote individuals )
An alternative interpretation would be to consider that
the actor modelling element indeed represents individuals
and that Figure 5 represents an abuse in notation and that
in this case “Client” should be omitted from the model.
This would be consistent with the usage of the “actor”
modelling element in several examples in the Archimate
documentation. See Figure 6 for an example of an
Archimate model with a nesting of actors, all of which are
individuals (nesting of actors in Archimate implies either
aggregation or composition with no notational distinction
possible).
Figure 6 Organization model (from [12])
Another example that corroborates this interpretation is
presented in Figure 7. The figure shows specific persons
(“A. Smith”, “D. Jones”, and “M. Baker”) as “actors”
which are part of the departments of the insurance
company.
Under interpretation B, we consider the assignment
relation (shown in Figure 7) to show that the actor is an
instance of the role universal represented by the role
modelling element. No statement is thus made about
admissible types in general.
Figure 7 Organization model (from [12])
This interpretation would imply that Archimate cannot
represent universals for actors (the resemblance of Figure
7 with the UML Class Diagram notation is unfortunate in
this case, since the relations should be interpreted as links
that relate the whole to the part).
4.1.3. Generic relations
The Archimate language has a number of generic
relations which can be applied between a number of
modelling elements. Nevertheless, the detailed semantics
of these relations when applied to particular kinds of
concepts is not always clarified. A particular example is
the “specialization” relation.
The Archimate language reference manual [12] defines
that “the specialization relationship can relate any instance
of a [modelling] concept with another instance of the same
concept.” The case of specialization of roles is mentioned
explicitly (e.g., „junior‟ and „senior‟ specializations of the
same role [14]), thus corroborating our claim that roles are
role universals. Nevertheless, the case of specialization of
“actors” is not mentioned explicitly. Specialization of
“actors” would be acceptable under interpretation A, but
would be impossible under interpretation B (the speciali-
zation relation is a relation between universals).
Other relations are “aggregation” and “composition”.
These can be applied between “actors” (as shown in
Figure 6 and Figure 7), between “roles”, and also between
“actors” and “roles” (as shown in Figure 8.) Please note
that from this model it is impossible to derive the
cardinality of the relation (i.e., should we interpret this
model as stating that there can be multiple “Damage
experts” in a “Claim handling department”?)
Figure 8 Relations between actors and roles [1]

Although examples of organigrams such as the one
presented in Figure 9 appear in the Archimate Resource
Tree [1] and in examples of tools such as BizzDesign
Architect [3], the semantics of the “relations” between
“actors” is not discussed in the Archimate language
reference manual. Ideally, these “relations” should be
instances of material relations that are derived from
relator universals. Relator universals would define the
particular attributions of each of the relata, and their
dynamics (creation and destruction) could be defined in
the context of business processes.
Figure 9 Example of Organigram [1]
4.2. DoDAF
The Department of Defense Architecture Framework
(DoDAF) [25] defines two viewpoints that include role-
related concepts. These are Operational Node Connec-
tivity Description (OV-2) and Organizational Relation-
ships Chart (OV-4).
In OV-2, “An operational node is an element of the
operational architecture that produces, consumes, or
processes information. What constitutes an operational
node can vary among architectures, including, but not
limited to, representing an operational/human role (e.g.,
Air Operations Commander), an organization (e.g.,
Office of the Secretary of Defense (OSD)) or organiza-
tion type, i.e., a logical or functional grouping (e.g.,
Logistics Node, Intelligence Node), and so on. The
operational node will also vary depending on the level of
detail addressed by the architecture effort.” [25]
In OV-4, “the Organizational Relationships Chart
illustrates the command structure or relationships among
human roles, organizations, or organization types that are
the key players in an architecture.” [25]
The following definitions are provided for OV-4:
“Human Role - Skills are needed to perform the opera-
tional activities or business processes described in the
architecture”; “Organization - An administrative entity
with a, identity, structure, and mission.”; “Organization
Type - A Class of Organization”; “Organizational
Relationship - relationships can include supervisory
reporting, command and control relationships, and
command-subordinate relationships.”
Based on the definitions, we can, intuitively, interpret
the “Human Role” concept as a role universal with an
implicit admissible universal to represent humans. Further,
we can interpret “Organization” as a substantial, and
“Organization Type” as a kind. There is no concept for
kinds or substantials when applied to model humans.
DoDAF proposes a number of UML styles for repre-
senting an architecture, including the aspects of the
architecture that are related to roles and substantials.
Figure 10 shows the proposed UML style for OV-2.
Similarly to Archimate, “roles” are associated with the
business processes in which they participate. Also,
similarly to Archimate, the structuring of “roles” in
“nodes” with the “aggregation” relationship suggests that
nodes represent organizational units types in the context
of which substantials that play the roles operate. (It is
unclear from the documentation whether roles can be
associated with multiple nodes directly.) We concluded
that a “node” represents a kind and that a “role” represents
a role universal. The representation in the lower part of
Figure 10 confirms that by showing instances of “roles”
and “nodes”.
Figure 10 UML OV-2 template from [25]
Roles can be played by instances of other roles as can
be seen in Figure 11. In this case, we interpret the
relations depicted as representing that the “Mission
Planner” “role” (a role universal) may apply to admissible
type “Role 1”.
Figure 11 UML OV-4 Sample from [25]
The guidelines for UML usage in the DoDAF docu-
mentation are not prescriptive enough, and hence, a
number of tools, represent DoDAF architecture in

different styles. For example, MagicDraw provides a plug-
in for DoDAF using its own modelling elements. Figure
12 shows a screen shot of a model produced with this
plug-in.
Figure 12 DoDAF OV-4 Organizational Relation-
ships Chart in MagicDraw [19]
In the IBM Rational Approach to the DoDAF [27],
there is no semantics associated with OV-4 diagrams. The
document suggests the following with respect to an
organizational structure chart: “Create a Freeform diagram
and name it Organizational Structure. Add rectangles and
label them for each organizational element to be
represented. Use vertical relationships via solid lines to
reflect command relationships, with higher authority at the
top of the diagram. Show coordinating relationships using
dashed lines.”
The UML Profile for DoDAF/MODAF (UPDM) [21]
defines an industry standard UML representation for
DoDAF and MODAF compliant enterprise architectures.
However, with respect to OV-4, the profile states that
“this diagram represents information generally developed
and maintained using techniques and tools better suited to
the task than UML”.
4.3. ARIS
The “Architecture of Integrated Information Systems”
(ARIS) [22] framework is widely employed for the
description of enterprise architectures.
ARIS includes the following role-related concepts:
“Organizational Unit”, “Organizational Unit Type”,
“Position”, “Employee” and “Role”.
The concept of “Organizational Unit” represents a
substantial, instance of the “Organizational Unit Type”,
which we interpret as a kind. A “Position” is defined as
the smallest organizational unit possible (a particular job
position). If we interpret this definition literally, a
“Position” represents an individual similarly to an
organizational unit. “Positions” can be related to
“Organizational Units” to represent responsibility (e.g.,
the CEO of IBM is “responsible for” the entire company)
or to represent a whole-part relation.
An “Employee” is a particular individual (an instance
of a universal that is not explicitly modelled.) A “Role”
represents a role universal, all instances of which are
necessarily “Employees”, i.e., the only admissible type for
“Roles” is the implicit universal that characterizes all
“Employees”.
The relation between “Roles” and “Positions” is rather
indirect: when an “Employee” is related to a “Position”
(the foundation for this relation is the hiring process),
he/she plays the particular “Roles” that are somehow
associated with the “Position”.
Figure 13 shows an example of organigram in Aris,
illustrating the usage of the concepts of “Organizational
Unit”, “Positions”, “Employee” and “Role”.
Figure 13 Example of organigram [22]
“Organizational units”, “organizational unit types”,
“positions”, “employees” and “roles” can be related to a
business process or its activities through an “executed by”
relation, as depicted in Figure 14.
Figure 14 Example of process model with
organization units and a position [22]
The semantics of these concepts and relations are not
clearly documented in [22]. Thus, the analysis we have
provided here must be considered as a first attempt to
establish a consistent interpretation of the constructs based
on usage examples. In future work, we intend to explore
an interpretation of “Position” by using the concept of a

normative description. In this alternative interpretation, a
“Position” would characterize the behavior to which an
“Employee” commits when assigned to a position. This
would allow us to formally characterize not only the
semantics of “Position” but also the semantics of the
relations of “Positions” and other elements in the model.
This alternative has not been explored here since the
concept of normative description is not part of UFO-A,
but rather of an extension of it, UFO-C [11].
4.4. RM-ODP
In our previous work [2], we have discussed the rela-
tion of the foundations presented here and the RM-ODP
foundations. We have concluded that the RM-ODP
provides a rich conceptualization when referring to the
acts which constitute the foundation for roles. In the
Enterprise Viewpoint is possible to describe “enterprise
objects” as “communities” and detail their composition by
using the concepts of “roles” and constituent “objects”.
We refer to [2] for further discussion on the topic.
4.5. BPMN
The Business Process Modelling Notation (BPMN)
[20] focuses on business process modelling, and therefore
does not provide constructs for organization modelling.
Nevertheless, activities in a business process may be
related by using the “Participant” model element to either
an “Entity” or a “Role”. Possible interpretations for these
concepts are kind and role universal or role mixin
universal.
5. Additional Remarks
5.1. Roles versus kinds
Consider the example where “John” studies at the
“University of Twente”. The “University of Twente” is an
instance of the “Education Institution” universal. A
definition of “Education Institution” is that it behaves in a
certain way with respect to students (i.e., it executes some
shared or collaborative behaviour with students.) It does
so, however, necessarily, since the behaviour towards
students is established in the definition of what an
“Education Institution” is. The “University of Twente” is
thus not playing the role of “Education Institution” in the
context of a particular relation with a student. We believe
there is no need to force the designer to use a role here or
to imply that there is a role even if it is not modelled. (Of
course one could always imagine that we could model the
University of Twente as an “Institution” and then define
an “Education Institution” role to be played by the
university. Nevertheless, forcing this kind of construct
would unnecessarily restrict the freedom of modellers.)
5.2. Universals and individuals in models
Consider now the presence of “singletons” in specifica-
tions, such as, e.g., the definition of roles such as
“President of Brazil”, which relates the object “Brazil” to
a “Person” playing the role of “President”. Again, one
could define that there is a country B playing the role of
“Brazil” or that there is an object “Brazil” playing the role
of country, but this is beyond the point being made here –
namely that the modeller should have the freedom to
define roles with respect to a particular object of special
interest to the shared behaviour.)
6. Conclusions
We have contributed a semantic foundation for role-
related concepts in Enterprise Modelling. Our contribu-
tion is well-positioned with respect to the literature in
conceptual and object-oriented modelling
2
, thus possibly
leading to a common foundation for these modelling
domains.
We have found a number of difficulties in evaluating
the selected enterprise modelling approaches, which
reveals certain problems in the definition and potentially
in the usage of some modelling elements in these
approaches:
In the case of Archimate, the main difficulties refer to
the interpretation of the concept of “actor”. It was unclear
from the documentation and from examples, whether the
concept should be interpreted as a universal or an
individual. We believe both universals and individuals for
actors are relevant in enterprise modelling efforts (see
section 5).
In the case of DoDAF, most issues relate to a lack of
consensus on the language representation for the concepts,
which restricts our analysis to the concepts as defined in
the framework. We have concluded based on our analysis
that there is no concept for kind or substantials when
applied to model humans in DoDAF. This would make it
impossible to model the interest in particular individuals
(such as the allocation or deployment of persons to
particular organizational units, as shown in Archimate and
ARIS).
In the case of ARIS, both universals and individuals
are provided for modelling organizational units. Individ-
ual human actors are also represented. The ARIS
documentation has been hard to interpret (especially the
role-related concepts as presented in [22]). Therefore, the
2
For an extensive discussion on roles in the conceptual
modelling literature that justify the UFO-A conceptualization
see [8, 10]. In [8, 10] the conceptualization provided here is
defined formally, in order to allow for unambiguous interpreta-
tion of the intended semantics for concepts.

semantics of the various modelling elements has been
derived based on its usage in examples.
In none of the approaches, we could identify the
distinction between the concepts of role universals and
role mixin universals. In order to be able to model the
design pattern for “roles with multiple disjoint allowed
types” (which is one of the challenges presented in [24]),
the approaches would have to collapse both concepts of
role universals and role mixin universals in a single
concept.
In all approaches, roles are used to represent the
participation of actors in particular behaviours or
processes, decoupling the definition of these behaviour or
processes from particular instances of actors. None of the
approaches, however, discuss the dynamics of role playing
or provide modelling elements to describe how actors are
assigned to roles dynamically (except the RM-ODP). The
concept of qua-individual is very important in this respect
and necessary to enable features 1, 9, 10 and 11 of the list
proposed by Steimann, i.e., those related to the properties
and behaviour that individuals carry when playing a
certain role. Qua individuals are also necessary to clarify
the issue of identity and to solve the so-called “counting
problem” [10].
Further work is needed to discuss the whole part
relations for role-related concepts in details. Some
discussions on this topic can be found in [8]. Further,
some work is needed to relate the concepts discussed here
to social concepts which are also available in enterprise
modelling approaches such as commitments, contracts,
goals, etc. [11]
References
1. Archimate Consortium, Archimate Resource Tree, available
at http://www.telin.nl/NetworkedBusiness/Archimate/ART
2. J.P.A. Almeida, G. Guizzardi, “On the Foundation for Roles
in RM-ODP: Contributions from Conceptual Modelling”,
4
th
WODPEC at EDOC 2007, IEEE CS Press, 2007.
3. BiZZDesigner, BiZZDesign Architect, available at
http://www.bizzdesign.nl/html/bizzdesignarchitect_en.html
4. G. Genilloud, A. Wegmann, “A Foundation for the Concept
of Role in Object Modelling”, Proc. Int’l EDOC Conf.
2004, IEEE Computer Society Press, 2004.
5. G. Genilloud, A. Wegmann, “A New Definition for the
Concept of Role, and Why it Makes Sense”, OOPSLA
Workshop on Behavioural Semantics, Oct. 2000.
6. N. Guarino, C. Welty, “Evaluating ontological decisions
with OntoClean”. Communications of the ACM, 45, 2, Feb.
2002, pp 61-65.
7. N. Guarino, C. Welty, “Identity and Subsumption. In The
Semantics of Relationships: An Interdisciplinary Perspec-
tive”, eds. R. Green, C. Bean and S. Myaeng,. Amsterdam:
Kluwer Academic, 2002, pp. 111-126.
8. G. Guizzardi, Ontological Foundations for Structural
Conceptual Models, PhD Thesis, University of Twente, The
Netherlands. TI-FRS No. 15, 2005.
9. G. Guizzardi, G. Wagner, “Towards Ontological Founda-
tions for Agent Modeling Concepts using UFO”, Lecture
Notes on Artificial Intelligence (LNAI) 3508, Springer-
Verlag, 2005.
10. G. Guizzardi, “Agent Roles, Qua Individuals and The
Counting Problem”, Software Engineering of Multi-Agent
Systems, vol. IV, P. Giorgini, A.Garcia, C. Lucena, R.
Choren (eds.), Springer-Verlag, 2006.
11. R.S.S. Guizzardi, G. Guizzardi, A. Perini, J. Mylopoulos,
“Towards an Ontological Account of Agent Oriented Goals”,
Software Engineering for Multi-Agent Systems, Vol. V,
Springer-Verlag, Berlin, 2007.
12. H. Jonkers et al., Architecture Language Reference Manual,
Enschede: Telematica Instituut, 2003-2005.
13. ISO / ITU-T, Open Distributed Processing - Reference
Model - Part 2: Foundations, International Standard
ISO/IEC 10746-2, ITU-T Recommendation X.902, 1995.
14. H. Jonkers, (ed.), F. de Boer, M. Bonsangue, et al. A
Concepts for Architectural Description TI/RS/2003/007,
(ArchiMate/D2.2.1/v4.0), Telematica Instituut, 2003-2004.
15. M. Lankhorst et al., Enterprise Architecture at Work -
Modelling, Communication and Analysis, Springer, 2005.
16. P.F. Linington and W.F. Frank, “Specification and
Implementation in ODP”, Proc. 1st Int’l Workshop on Open
Distributed Processing: Enterprise, Computation, Knowl-
edge, Engineering & Realisation (ICEIS), 2001, pp. 69-80.
17. C. Masolo, G. Guizzardi, L. Vieu, E. Bottazzi, R. Ferrario,
“Relational Roles and Qua Individuals”, AAAI Fall Sympo-
sium on Roles, an Interdisciplinary Perspective, USA, 2005.
18. K. Mulligan, B. Smith, A Relational theory of the Act. Topoi
(5/2), 115-30, 1986.
19. No Magic, Magic Draw, available at
http://www.magicdraw.com
20. Object Management Group. Business Process Modeling
Notation BPMN 1.0, dtc/06-02-01, Feb. 2006.
21. Object Management Group, UML Profile for the Depart-
ment of Defense Architecture Framework (DoDAF) and the
Ministry of Defence Architecture Framework (MODAF),
dtc/2007-08-02, August 2007.
22. A.-W. Scheer, ARIS – Business Process Modeling, Third
Edition, Springer, 1999.
23. F. Steimann, A Radical Revision of UML‟s Role Concept,
in UML 2000: Proceedings of the 3rd International Confer-
ence, Springer-Verlag, 2000, pp. 194–209.
24. F. Steimann, “On the representation of roles in object-
oriented and conceptual modelling,” Data and Knowledge
Engineering, vol. 35, pp. 83-106, 2000.
25. U.S. Department of Defense, DoD Architecture Framework
Version 1.5, Volume II: Product Descriptions, April 2007.
26. A. Wegmann, G. Genilloud, “The Role of „Roles‟ in Use
Case Diagrams”, UML 2000: Proceedings of the 3rd Inter-
national Conference, Springer-Verlag, 2000.
27. C. Widney, An IBM Rational Approach to the Department
of Defense Architecture Framework (DoDAF), January 2006.
28. R.J. Wieringa, W. de Jonge, P.A. Spruit. “Using dynamic
classes and role classes to model object migration”. Theory
& Practice of Object Systems, 1(1), 1995, pp 61-83.