8 Ontology and Enterprise Engineering

Now that the distinction between black-box models and white-box models
has been made clear, the question about their roles in enterprise engineer-
ing can be addressed. By enterprise engineering we mean the whole body
of knowledge regarding the development, implementation, and operational
use of enterprises, as well as its practical application in engineering pro-
jects. The term “engineering” is used here in the broad sense, as in me-
chanical engineering and civil engineering. It should not be confused with
the use of same term in the narrow sense, namely as a phase in the devel-
opment process of systems (enterprises, information systems, etc.), which
we will address shortly. Enterprise engineering is not a discipline yet,
comparable to electrical engineering or civil engineering. It is our convic-
tion however that this discipline is badly needed, now, and certainly in the
near future. With this book we hope to demonstrate the need for develop-
ing the discipline of enterprise engineering and to address a part of its con-
tents.

8.1 Design and Engineering

Enterprise engineering is not an entirely new field, and we do certainly not

claim to have invented it. Some well-known books in the area are [35] and
[44]. However, it is not a scientific discipline yet, although a number of
universities run research programs that aim at making the field more scien-
tific. In spite of these efforts, the current literature on enterprise engineer-
ing consists merely of best practices, without an integrating theory and
without a clear definition of the field. Similar remarks can be made for the
related field of organization(al) engineering. Like the practice-based area
of enterprise engineering, it aims at studying enterprises or organizations
in a multidisciplinary and engineering-driven way, but without much sci-
entific foundation. Although it will be a hard job to develop an all-
encompassing theoretical foundation of enterprise engineering, it is needed
for any real progress. Whatever it will turn out to be, we are convinced that
72 8 Ontology and Enterprise Engineering

the notion of enterprise ontology, as defined and developed in this book, is

an indispensable pillar.
The goal of this chapter is to clarify the notion of ontology in enterprise
engineering, in relationship with several other key notions in the develop-
ment of systems. To start with, let us have a closer look at the process of
designing a system in a very general way, so not only applicable to enter-
prises. Figure 8.1 exhibits the basic view that we consider the appropriate
one for deeply understanding the notion of design.

Fig. 8.1 The system design process (1)

In every design process there are two systems involved, which we shall
call the using system (US) and the object system (OS). The OS is the sys-
tem to be designed; the US is the system that will use the functions or serv-
ices offered by the OS once it is operational. Let us for the sake of clarifi-
cation take as the US the accounting department of a company, and as the
OS an (automated) accounting system. Figure 8.1 tells us that there are two
major phases in the design of the OS. The first one is called “determining
requirements” and the second one “devising specifications”. The phase or
subprocess determining requirements starts from the construction of the
US and ends with the function of the OS. The function of the OS is consid-
ered to be a black-box model of the OS. In line with what has been said
about black-box models in the previous chapter, this means that the speci-
fied function of the OS does not contain any information about or even any
clue to the construction of the OS. In other words, the function of the OS
must be specified only in terms of the construction of the US. Why the
construction of the US, and not its function? The answer is that there must
always be an alternation of function and construction in designing; a func-
tion cannot support another function directly, because functions do not
have needs; only constructions do. To exemplify this, the accounting de-
partment as a part of the construction of the enterprise can have needs for
an accounting system because the accountants are components of this con-
struction and they can be in need of such a support. The department as a
 8.1 Design and Engineering 73

blackbox is a functional abstraction that may be useful for some construc-

tion above it, but it is not anymore about the operational activities of ac-
counting. Conversely, the function of the OS is always, and necessarily,
expressed in terms of the construction of the US. So, for example, the ac-
countants in (the construction of) the US may have a need to know the
monthly turnover of the enterprise. The notion of turnover is an economic
notion that takes its real meaning from the larger economic context in
which the enterprise operates. The value of the monthly turnover is some-
thing by which people in the enterprise may become excited or depressed.
In specifying the function of the OS, it is this rich meaning of turnover that
the accountants will express to the functional designers of the OS. Need-
less to say, the functional designers must possess sufficient knowledge of
the enterprise in order to be well-matched opponents to the accountants in
the process of determining requirements.
The nature of the second design phase or subprocess, thus devising
specifications, is quite different from determining requirements. It starts
with the specified function of the OS and it ends with the construction of
the OS. Without intending to wrong the functional designers, the job of the
constructional designers is definitely more creative. The constructional de-
signers have to bridge the mental gap between function and construction,
which is nothing less than establishing a correspondence between systems
of different categories: the category of the US (where the function of the
OS is defined) and the category of the OS. To illustrate this, the notion of
turnover must now be understood as the result of a calculation. The con-
structional designer is aware of the fact that the (automated) information
system that he or she is going to design will never have any ‘understand-
ing’ of turnover. The name “turnover” will be only a label that he or she
will assign to the outcome of a calculation. It is the task of the construc-
tional designer to get the right calculation rule from the functional de-
signer. Basically this means that the real semantics of the notion of turn-
over is replaced by its formal semantics, which is some algorithm.

Fig. 8.2 The system design process (2)

74 8 Ontology and Enterprise Engineering

In [2], design is understood as a process of alternate analysis and syn-

thesis steps. An analysis step is one in which the problem is better under-
stood; a synthesis step is one in which the solution becomes more clear.
This idea is expressed in Fig. 8.2. It clarifies that designing is not a one-
way process but that there will always be iteration. The determining of the
requirements and the devising of the specification will normally take place
incrementally and alternately. The distinction between analysis and syn-
thesis is a perfect example of the separation of concerns in the design
process ([23]). During an analysis step, the concerns are the correct under-
standing of the semantics, the completeness, and the consistency of the
function of the OS. In a synthesis step, the concerns are the correct re-
placement of functional semantics by formal semantics and the efficiency
of the construction of the OS. This view on the design process supports
clearly the recognition that a good design is always a balanced compro-
mise between reasonable requirements and feasible specifications [19].
As an almost logical consequence, it means that one already needs a
substantial amount of technical knowledge for fulfilling adequately the
role of functional designer. This outcome corresponds with our
observation that consultants who have only an economic or managerial or
business education commonly have little added value in the design phase,
but often delay. In general, people with both an organization- and a
technology-oriented education appear to play a crucial role in design
processes since they are able to understand the distinction between the two
phases and also their interconnection. Lastly, determining requirements
includes the validation of the requirements, something that can be achieved
only in thorough discussions with people ‘in the business’.
Let us focus now on the role of ontology in the design process. To this
end, we use the picture shown in Fig. 8.3. It clarifies the notions of engi-
neering (in the narrow sense) and implementation. As we know from the
previous chapters, the ontology or the ontological model of a system is a
model of its construction that is completely independent of the way in
which it is realized and implemented (We will discuss the distinction be-
tween realization and implementation later; for now, we will regard im-
plementation only). The engineering of a system is the process in which a
number of white-box models are produced, such that every model is fully
derivable from the previous one and the available specifications. Contrary
to designing, engineering is not a matter of creativity but of craftsmanship.
Engineering starts from the ontological model and ends with the imple-
mentation model. This implementation model is by definition sufficiently
detailed for implementing it using some chosen technology. By implemen-
tation is understood the assignment of technological means to the elements
 8.2 The System Development Process 75

in the implementation model, so that the system can be put into operation.
In practice, it is often the case that one or more constructional models are
missing. A typical situation is that only the implementation model is avail-
able. The process of reconstructing the higher level models from the im-
plementation model is known as reverse engineering. Lastly, reengineer-
ing a system means redoing the engineering process, starting from the
ontological model, which may or may not have been changed as a result of
redesigning the system. Let us consider our US and OS in order to clarify
the notions of engineering and implementation. First the US.

system
construction
reverse engineering

engineering

ontology
entation
implem-

technology

Fig. 8.3 The role of ontology in the construction of a system

8.2 The System Development Process

From the introduction to the notion of ontology in Chap. 2, we have learnt

that the core elements in the ontological model of an enterprise are actor
roles, coordination acts/facts, and production acts/facts. Let us call the
technology needed to implement each of these three kinds of elements ac-
tor technology, communication technology11, and production technology,
respectively. The (only possible) actor technology is human beings, since
they are the only ‘things’ that are able to decide, judge, etc., and to enter

11
As will be explained in Part C, coordination takes place in communication;
therefore, we speak of communication technology instead of coordination tech-
nology.
76 8 Ontology and Enterprise Engineering

into and comply with commitments. The engineering of actor roles con-
sists of mapping them first to organizational functions and next to individ-
ual people.
As will become clear in Part C, performing a coordination act, such as a
request or a promise, includes performing a number of infological acts, and
each of these includes performing a number of datalogical acts. So, the en-
gineering of the coordination acts on the ontological level results in par-
ticular sentence types that have to be uttered (by speaking or writing),
transmitted, and perceived (by listening or reading) in the implementation
model. There is a wealth of communication technology for recording spo-
ken and written sentences, transmitting them, and presenting them for per-
ception, ranging from voice communication (e.g., face-to-face or by tele-
phone), to text communication (e.g., by postal mail or by electronic
documents and Internet).
As stated earlier, and as will be justified later in this book, only human
beings can perform production acts on the ontological level of an enter-
prise. For immaterial acts, like deciding and judging, the only available
production technology, therefore, is human beings. Of course, they can be
supported by information systems that provide them with the necessary
knowledge; we will address this issue shortly. With reference to material
acts, like manufacturing things, the basic production technology consists of
the manual skills of human beings. However, as everybody knows, there
are numerous supporting systems, such as vacuum cleaners, cars, drilling
machines and screw drivers, of which these human beings can make use.
With reference to our OS, the accounting system, the ontological model
is one that can be made by applying the SMART meta model [18]. The en-
gineering of such a model consists of producing a set of subsequently more
detailed white-box models up to the implementation model12. If the tech-
nology to be applied is IT (information technology), then the implementa-
tion model generally is a computer program in a programming language
that can be compiled or interpreted by the platform on which the OS is go-
ing to be operational.
The result of combining Fig. 8.2 and 8.3 is presented in Fig. 8.4, which
we will refer to as the system development process. The system to be de-
veloped is the OS. It is meant to be used by the US and is thus going to
support the US. The support of the US by the OS is called a way of realiza-
tion of the US. The distinction between realization and implementation
will be elaborated on in Chap. 13.

12
Note that engineering is meant here in the narrow sense of the term, contrary to
its use in enterprise engineering, mechanical engineering, etc.
 8.2 The System Development Process 77

Fig. 8.4 The system development process

Since enterprise ontologies are hardly applied in practice, the first step
in the development of a supporting system for (a part of) an enterprise is
producing the ontological model of the enterprise on the basis of one or
more lower level constructional models. A candidate for such a model is
the Flow Chart that we used in Chap. 3. A reliable methodology to produce
an enterprise ontology in this way is presented and discussed in Part D of
this book. Although it will rarely occur, one can imagine the case where a
brand new enterprise has to be created. From the development process of
Fig. 8.4, this means that the OS is the enterprise to be designed and engi-
neered. The US is the commercial environment in which the enterprise is
going to be operational, and the functional model of the OS contains the
services that the enterprise will deliver to its customers. This way of pro-
ducing the ontology of an enterprise is not covered by the methodology in
Part D of this book.