EKD Userguide

HyperKnowledge
IST–2000-28401
Hypermedia and Pattern Based Knowledge

Management for Smart Organisations
D3:
Appendix B
EKD User Guide
Date:
Preparation Date: 30.10.01
Place: Stockholm, Sweden
Project Classification: Trial
Contract Start Date: 01.07.01 Duration: 18 months
Project Co-ordinator: Verbundplan GmbH (VPL)
Partners: Royal Institute of Technology (KTH)
Siemens AG Österreich (Siemens)
Riga City Council (Riga)
Authors: Anne Persson, Janis Stirna (KTH)
Project funded by the European Community
under the “Information Society Technology”
Programme (1998-2002)
28401 HyperKnowledge
TABLE OF CONTENTS
1. ENTERPRISE MODELLING – BACKGROUND AND OVERVIEW ......................... 6
1.1 INTRODUCTION ...................................................................................................................6
1.2 ENTERPRISE MODELLING – OVERVIEW ...............................................................................7
1.3 THE PURPOSE OF ENTERPRISE MODELLING ........................................................................9
1.3.1 Business development goals.................................................................................. 10
1.3.2 Quality assurance goals........................................................................................ 11
1.4 ACTORS IN ENTERPRISE MODELLING................................................................................11
1.5 THE ADVANTAGES OF USING A PARTICIPATIVE APPROACH TO EM ....................................13
1.6 MEASURING THE SUCCESS OF APPLYING EKD ..................................................................14
1.7 EKD AND COMPETENCY...................................................................................................15
1.7.1 The competency of domain experts ....................................................................... 15
1.7.2 The competency of the method provider ............................................................... 17
2. THE LIBRARY CASE STUDY ....................................................................................... 20
2.1 BACKGROUND ..................................................................................................................20
2.2 THE CURRENT SITUATION ................................................................................................20
3. OVERVIEW OF EKD ...................................................................................................... 22
3.1 WHAT IS EKD? ................................................................................................................22
3.2 THE ENTERPRISE MODEL AND ITS COMPONENTS .............................................................24
3.3 EXAMPLE OF AN ENTERPRISE MODEL...............................................................................27
4. TECHNICAL DESCRIPTION OF ENTERPRISE MODELLING.............................. 29
4.1 GOALS MODELLING ..........................................................................................................29
4.1.1 The Purpose of Goals Modelling .......................................................................... 29
4.1.2 Components of Goals Model................................................................................. 29
4.1.3 Notation ................................................................................................................ 33
4.1.4 Example of a Goals Model.................................................................................... 33
4.1.5 Developing the Goals Model................................................................................. 35
4.1.6 Driving Questions ................................................................................................. 35
4.1.7 Naming the Goals Model components .................................................................. 36
4.1.8 Goal Refinement and Operationalisation ............................................................. 37
4.2 BUSINESS RULES MODELLING ..........................................................................................39
4.2.1 Purpose of Business Rules Modelling ................................................................... 39
4.2.2 Components of Business Rules Modelling ............................................................ 39
4.2.3 Notation ................................................................................................................ 41
4.2.4 Example of Business Rules Model......................................................................... 41
4.2.5 Developing the Business Rules Model .................................................................. 42
4.3 CONCEPTS MODELLING ....................................................................................................44
4.3.1 Purpose of Concepts Modelling ............................................................................ 44
4.3.2 Component Types.................................................................................................. 45
4.3.3 Notation ................................................................................................................ 48
4.3.4 Example of a Concepts Model .............................................................................. 49
4.3.5 Developing the Concepts Model ........................................................................... 50
4.4 BUSINESS PROCESS MODELLING ......................................................................................52
4.4.1 Purpose of Business Processes Modelling ............................................................ 52
4.4.2 Component Types.................................................................................................. 52
4.4.3 Notation ................................................................................................................ 54
4.4.4 Example of the Business Processes Model............................................................ 54
4.4.5 Process Decomposition......................................................................................... 55
4.4.6 Developing the Business Processes Model ........................................................... 56
iii
4.5 ACTORS AND RESOURCES MODELLING ............................................................................58

4.5.1 Components of Actors and Resources Model........................................................ 58
4.5.2 Notation ................................................................................................................ 61
4.5.3 An example of the Actors and Resources Model ................................................... 61
4.5.4 Developing the Actors and Resources Model ....................................................... 62
4.6 TECHNICAL COMPONENTS AND REQUIREMENTS MODELLING ..........................................63
4.6.1 Component of the Technical Components and Requirements Model.................... 63
4.6.2 Notation ................................................................................................................ 65
4.6.3 Example of the Technical Components and Requirements Model ........................ 66
4.6.4 Developing the Technical Components and Requirements Model........................ 68
4.7 RELATIONSHIPS BETWEEN THE EKD SUB-MODELS ..........................................................69
4.8 AUXILIARY MODELLING COMPONENTS .............................................................................72
5. WORKING WITH THE EKD APPROACH.................................................................. 75
5.1 INTRODUCTION .................................................................................................................75
5.2 POSSIBLE TARGETS OF EKD .............................................................................................75
5.3 A TYPICAL PROJECT OUTLINE ...........................................................................................76
5.4 PRECONDITIONS FOR SETTING UP THE FIRST PROJECT .......................................................79
5.5 ESTABLISHING THE DIRECTIVES FOR THE PROJECT ............................................................79
5.6 ESTABLISHING THE PROJECT ORGANISATION ....................................................................80
5.7 PREPARING FOR THE FIRST MODELLING SEMINAR .............................................................81
5.7.1 Selecting the right domain experts to participate in the seminar.......................... 81
5.7.2 The purpose of interviewing of domain experts .................................................... 82
5.7.3 Possible interview questions ................................................................................. 82
5.7.4 How to use and take advantage of the interviews ................................................. 83
5.8 THE FIRST MODELLING SEMINAR .....................................................................................83
5.8.1 Setting up the Seminar Room................................................................................ 84
5.8.2 Making an introduction to the participants .......................................................... 85
5.8.3 Stimulating and Structuring the Modelling Activity.............................................. 85
5.8.4 Structuring and analysing results of the first seminar .......................................... 87
5.9 THE ”WALK-THROUGH” SEMINAR ...................................................................................89
5.9.1 The Presentation ................................................................................................... 90
5.10 THE RESPONSIBILITY OF THE MODELLING GROUP - NEED FOR DOMAIN EXPERTS .......90
6. THE QUALITY OF THE ENTERPRISE MODEL....................................................... 91
7. REFERENCES .................................................................................................................. 97
APPENDIX A: THE ELECTRUM LIBRARY CASE STUDY .............................................. 98
A.1 TOP LEVEL EKD MODEL........................................................................................ 98
A.2 ELECTRUM LIBRARY GOALS MODEL ............................................................... 99
A.3 ELECTRUM LIBRARY CONCEPTS MODEL ..................................................... 102
A.4 ELECTRUM LIBRARY BUSINESS RULE MODEL............................................ 103
A.5 ELCTRUM LIBRARY ACTORS AND RESOURCES MODEL .......................... 105
A.6 ELECTRUM LIBRARY BUSINESS PROCESS MODEL .................................... 106
A.7 ELECTRUM LIBRARY IS REQUIREMENTS MODEL...................................... 114
iv
TABLE OF FIGURES
FIGURE 1 EM AS A ONE-OFF ACTIVITY IN A DEVELOPMENT PROJECT ........................................ 8
FIGURE 2 PEM AS A RECURRING ACTIVITY IN A DEVELOPMENT PROJECT ................................. 9
FIGURE 3: GOAL HIERARCHY OF THE MOST COMMON INTENSIONS FOR USING ENTERPRISE
MODELLING [PER01B] ............................................................................................ 10
FIGURE 4 SOME ROLES IN AN EM PROJECT ............................................................................. 12
FIGURE 5 MAIN CATEGORIES OF DOMAIN EXPERTS IN AN EM PROJECT................................... 15
FIGURE 6 COMPETENCIES OF A MODELLING GROUP - RELATIONSHIPS BETWEEN REQUIREMENTS
AND CONSTRAINTS .................................................................................................. 16
FIGURE 7 THREE LEVELS OF METHOD PROVIDER COMPETENCY .............................................. 18
FIGURE 8: CONTENTS OF THE EKD FRAMEWORK .................................................................... 22
FIGURE 9: TYPES OF ACTIVITIES INVOLVED IN THE EKD PROCESS .......................................... 24
FIGURE 10: THE SUB-MODELS COMPRISING THE ENTERPRISE MODEL........................................ 26
FIGURE 11: EXAMPLE OF THE GRAPHICAL REPRESENTATION OF A SUB-MODEL .......................... 27
FIGURE 12: FRACTION OF A GOALS MODEL CONTAINING AND RELATIONSHIPS ........................ 32
FIGURE 13. FRACTION OF A GOALS MODEL CONTAINING OR RELATIONSHIPS ........................... 32
FIGURE 14. NOTATION FOR GOALS MODELS .............................................................................. 33
FIGURE 15. FRACTION OF THE INITIAL GOALS MODEL OF THE LIBRARY CASE ........................... 34
FIGURE 16. THE SAME GOAL EXPRESSED IN TWO DIFFERENT WAYS ........................................... 36
FIGURE 17. INITIAL PROBLEM CONTAINS TWO STATEMENTS – PROBLEM AND OPPORTUNITY ..... 36
FIGURE 18. THE NOTATION USED IN THE BUSINESS RULES MODEL IS SIMILAR TO THAT FOR THE
GOALS MODEL........................................................................................................ 41
FIGURE 19. THE INTERACTION BETWEEN BUSINESS RULES AND COMPONENTS OF THE GOALS
MODEL ARE DISPLAYED BY THE DASHED-LINES ...................................................... 42
FIGURE 20. RULES REFER TO CONCEPTS IN THE CONCEPTS MODEL AND ARE SUPPORTED BY
PROCESSES IN BUSINESS PROCESSES MODEL. ......................................................... 43
FIGURE 21. THE CONCEPT “PUBLISHER” IS RELATED, BY BINARY RELATIONSHIP "PRINTS", TO
CONCEPT “BOOK” THAT HAS ATTRIBUTES: TITLE, AUTHOR, AND ISBN. ................. 46
FIGURE 22. THE CONCEPT “CUSTOMER” CAN BE SPECIALISED IN DIFFERENT WAYS................... 47
FIGURE 23. AN EXAMPLE OF A PARTOF RELATIONSHIP STRUCTURE. THE CONCEPT “DOCUMENT”
CONSISTS OF SEVERAL PARTS. ................................................................................. 48
FIGURE 24. NOTATION FOR MODELLING COMPONENTS AND RELATIONSHIPS IN THE CONCEPTS
MODEL.................................................................................................................... 48
FIGURE 25. NOTATION FOR GENERALISATION AND AGGREGATION RELATIONSHIPS IN THE
CONCEPTS MODEL .................................................................................................. 49
FIGURE 26. AN EXAMPLE OF THE LIBRARY’S CONCEPTS MODEL............................................... 50
FIGURE 27. NOTATION FOR THE ACTORS AND RESOURCES MODEL ........................................... 54
FIGURE 28. AN EXAMPLE OF A BUSINESS PROCESSES MODEL ................................................... 55
FIGURE 29. THE PROCESS ”CUSTOMER’S ADDRESS VERIFICATION” IS NOT DECOMPOSED.......... 56
FIGURE 30. A PROCESS ”CUSTOMER’S ADDRESS VERIFICATION” IS DECOMPOSED INTO FOUR SUB-
PROCESSES, EACH OF THEM PERFORMING A DIFFERENT PART OF THE MAIN PROCESS.56
FIGURE 31. THE NOTATION FOR THE ACTORS AND RESOURCES MODEL COMPONENTS.............. 61
FIGURE 32: AN EXAMPLE OF THE LIBRARY’S ACTORS AND RESOURCES MODEL ....................... 62
FIGURE 33. THE NOTATION FOR THE TECHNICAL COMPONENTS AND REQUIREMENTS MODEL
COMPONENTS. ......................................................................................................... 65
FIGURE 34. THE TECHNICAL COMPONENTS AND REQUIREMENTS MODEL OF THE LIBRARY CASE
SHOWN IN THE CONTEXT OF THE OTHER SUB-MODELS. ............................................ 66
FIGURE 35. THE RELATIONSHIP BETWEEN THE INFORMATION SYSTEM GOALS AND REQUIREMENTS,
AND THE INFORMATION SYSTEM TECHNICAL COMPONENTS ..................................... 68
FIGURE 36. RELATIONS BETWEEN SUB-MODELS......................................................................... 70
FIGURE 37. A FRAGMENT OF THE LIBRARY CASE ENTERPRISE MODEL. THIS DEMONSTRATES SOME
LINKS BETWEEN THE SUB-MODELS. ......................................................................... 72
FIGURE 38: A FRACTION OF A GOALS MODEL CONTAINING AUXILIARY MODELLING COMPONENTS
................................................................................................................................ 74
FIGURE 39: AN UNSTABLE CONCEPTS MODEL ........................................................................... 94
FIGURE 40: A STABLE CONCEPTS MODEL.................................................................................. 94
v
1. Enterprise Modelling –
background and overview
1.1 Introduction
The activity called modelling is defined and described by Bubenko [Bub92]:
"Modelling means essentially to describe a set of abstract or concrete
phenomena in a structured and, eventually, in a formal way."
"Describing, modelling, and drawing is a key technique to support
human understanding, reasoning, and communication."
In Enterprise Modelling (EM) we focus on modelling an enterprise. Typical
examples of enterprises are private companies, public authorities or bodies,
academic institutions or other organisations. There are different views of EM.
Furthermore, Enterprise Modelling is a structured technique to describe different
aspects of an enterprise.
In Scandinavia, Langefors [Lang68] made early contributions to EM. An EM
method, the ABC method, was introduced in the beginning of the eighties by
Plandata, Sweden [Will88], and refined by SISU (The Swedish Institute for
System Development) in the late eighties. A significant contribution was the
notion of considering intentional components of an Enterprise Modelling
language, e.g. the goals (intentions) of a business, in addition to traditional data
and process model components. SISU’s version of the modelling language,
denoted Business Modelling, was later extended into an Enterprise Modelling
method in the ESPRIT project F3 – “From Fuzzy to Formal.” The F3 Enterprise
Modelling method [F394] was then further elaborated in the ESPRIT project
ELKD. The more recent modelling method is denoted EKD – “Enterprise
Knowledge Development” [EKD98, Louc97], which includes Enterprise
Modelling as a part. Versions of EM methods from this “school” have been
successfully applied in a number of European companies, e.g. British Aerospace
(UK), Capital Bank (UK), National Bank of Greece, PostGirot (Sweden), Public
Power Corporation (Greece), Sema Group (France), Telia (Sweden), Vattenfall
(Sweden), Volvo (Sweden), etc. In addition to the “Scandinavian” school of EM, a
variety of other methods have been suggested (See e.g. [Yu94, Fox93, AIAI94b,
Dob94]).
One of the advantages of modelling is the effect on the participants. In a well-
performed modelling project, the effects maybe an improved understanding of
essential parts of the enterprise, the finding of solutions to practical problems or a
consensus about issues that earlier were hard to define, reason about, and agree
upon. We may then say that models of this kind are effective means to improve
communication as well as organisational learning.
EKD User Guide page 6 of 114

Despite this, a model can never be an exact reflection of the real world. It is only a
collective perception of the real world, reflecting the frames of reference,
experiences and backgrounds of the contributors.
This user guide is organised as follows. Chapter 1 introduces the concept of
Enterprise Modelling (EM) and gives a general overview of the field of EM. To
simplify the presentation of the EKD method for EM, a case study is used. This
case study is presented in Chapter 2. In Chapter 3 provides an overview of the
EKD method, while Chapter 4 provides a detailed description. The approach to
working with EKD is presented in Chapter 5. Finally, the quality of Enterprise
Models are discussed in Chapter 6.
1.2 Enterprise Modelling – overview

EM is a process where an integrated and negotiated Enterprise Model is created,
describing a specific enterprise from several different perspectives. The
perspectives vary, depending on the focus of the EM method and the problem that
is being addressed using the method. Examples of such perspectives are processes,
business rules, concepts/information/data, goals, actors, and requirements. An
Enterprise Model shows the negotiated view of the stakeholders in an enterprise
regarding a certain problem within that organisation.
A method for EM consists of two main components:
1) A meta-model, which defines the modelling constructs, syntax, semantics
and graphical notation used to create an Enterprise Model. This is the
modelling language. The multi-perspective view means that the meta-
model comprises a number of inter-related sub-model types, each focusing
on one perspective
2) A suggested process for creating an Enterprise Model. During this process
different ways of working are applied in order to elicit and develop the
knowledge of business stakeholders or domain experts. Typical examples
of ways of working are facilitated group sessions and interviews.
The EM process is typically iterative. The sub-models are developed in parallel,
meaning that they are on different levels of "completeness" at a certain point in
time. During the process, stakeholders from the organisation being modelled may
participate to varying degrees. In the participative approach to EM the
stakeholders in question collaboratively develop Enterprise Models in facilitated
group sessions. This type of participation is consensus-driven in the sense that it is
the stakeholders who “own” the model and hence decide its contents. In contrast,
consultative participation means that analysts create models and that stakeholders
are then consulted in order to validate the models. In the EKD EM method the
participative approach to EM is preferred.
Setting up and carrying out modelling sessions using a participative approach to
EM can briefly be described as follows:
1. Before the first modelling session the domain experts/participants are
selected and interviewed.

2. The modelling session is then prepared. It is vital that this preparation is

thorough. Objectives are defined and a schedule for the session is prepared.
3. The modelling session is carried out following the prepared schedule.
During the session the facilitator is a crucial actor as manager of the group
communication process and as keeper of the method knowledge.
4. After the modelling session, the models are documented by using some
computer tool and a walk-through session is carried out with the participants
in order to validate the models.
5. Based on the documented models, new modelling sessions are prepared and
carried out until the problem at hand has been sufficiently analysed.
EM is typically used as one of many different instruments in a development
process. This means that the product of EM relates to other products in that
process. In addition, other development processes (past, ongoing or future) may be
related to the EM product.
Within a development project, EM can be a single activity (Figure 1), which the
following quote illustrates:
Ongoing
parallel
project
Planned
Past
Development project future
project
project
EM
activity
Planned
Past future
project project
Ongoing
parallel
project
Figure 1 EM as a one-off activity in a development project
In this situation the planning and alignment with other projects or activities lies
beyond the EM activity. Another type of project is where EM is a recurring
activity throughout a development project (Figure 2).

Ongoing
parallel
project
Planned
Past
Development project future
project
project
EM
activity
EM
activity Planned
Past future
project project
Ongoing
parallel
project
Figure 2 PEM as a recurring activity in a development project
Here the requirements are high on keeping the modelling product together
throughout the whole project life cycle: This type of EM project requires a skilled
and highly experienced method provider for co-ordination and planning.
1.3 The purpose of Enterprise Modelling

Enterprise Modelling can be used for a number of purposes. The goal hierarchy in
Figure 3 shows the common objectives that organisations have for using
Enterprise Modelling. It contains two main branches. One dealing with developing
the business, e.g. developing business vision, strategies, redesigning the way the
business operates, developing the supporting information systems, etc. The other
dealing with ensuring the quality of the business, primarily focusing on two
issues: 1) sharing the knowledge about the business, its vision, the way it operates
and 2) ensuring the acceptance of business decisions through committing the
stakeholders to the decisions made.

Business goals
Ensure the
quality of Develop the
business business
operations
Ensure acceptance Maintain and share

Develop visions and Design/Redesign Develop information
for business knowledge about the
strategies business systems
decisions business
Convince
stakeholders to
commit to
decisions/results
Design/ redesign Elicit business

business processes requirements
Create, document,
Resolve differences
Encourage active maintain a
in perceptions about
participation from "complete" and
the business
involved multi-faceted view
between
stakeholders (Enterprise Model) of
stakeholders
the business
Legend:
AND
Stimulate Acquire knowledge
communication and AND/OR
about the business
collaboration from different supports
between stakeholders
stakeholders
Figure 3: Goal hierarchy of the most common intensions for using Enterprise
Modelling [Per01b]
1.3.1 Business development goals

Business development is one of the most common objectives for using EM.
Business development frequently involves change management – determining
how to achieve visions and objectives from the current state in organisations.
Enterprise Modelling is used in this process with great success.
Business process orientation is a specific case of business development – the
organisation wants to restructure/redesign its business operations.
Also, EM is commonly used in the early stages of system development (e.g. see
[Nell92], [Nils99], [Bub99]). A common view among business consultants is that
EM can effectively be used for gathering the business needs and high-level

1.3.2 Quality assurance goals

Another common reason why many organisations decide to adopt EM is to ensure
the quality of its operations. Two important success factors for ensuring quality,
mentioned by interviewees were that stakeholders understand the business and
that they accept/are committed to business decisions.
Recently, organisations have taken an increased interest in Knowledge
Management, which is concerned with creating, maintaining and disseminating
organisational knowledge between stakeholders in order for them to understand
the business. EM has a role to play here, since its aim is to create a multifaceted
view of the business. As one interviewee expressed:
To maintain and share knowledge about the business becomes extra important in
the situation where two organisations are integrated or where different
organisations collaborate and have different roles in carrying out a business
process. One of the knowledge management perspectives is keeping the
employees informed with regard to how the business is done.
If Enterprise Models are to play a role in the maintenance and dissemination of
business knowledge there is a need for supporting tools.
Most modern organisations subscribe to the view that the commitment of
stakeholders to carry out business decisions is a critical success factor for
achieving high quality business operations. To this effect, differences in opinions
about the business must be resolved; in turn requiring that communication
between stakeholders is stimulated. EM, particularly using a participative way of
working, is effective to obtain commitment from stakeholders.
1.4 Actors in Enterprise Modelling

There are a number of possible roles in an EM project. They fall into two main
categories: domain experts and method providers (Figure 4). An Enterprise Model
comprises knowledge regarding different aspects of some organisation. Domain
experts provide and develop this knowledge in modelling sessions. To create the
Enterprise Models, using a participative approach, a method provider is needed.
The method provider has the necessary knowledge with regard to the EM method
used and the participative approach to modelling.

Domain
expert
Customer
negotiates
can be can Problem PEM project
be owner with
Modelling
participant
Method provider
consists
of
moderates Method
Modelling is part
the work Facilitator provider
group of
of team
can
has
be Method
provider
team leader
Figure 4: Some roles in an EM project
The customer is the main responsible party for the modelling project on the
domain expert side. In the modelling sessions, the modelling groups consist of
modelling participants, which are domain experts concerned with the problem at
hand. These domain experts may also be involved in other projects that are related
to the one being planned. The customer may also participate in modelling groups.
The main problem being addressed has a problem owner, which mostly is the
customer. For sub-problems, there may be also other problem owners, e.g. other
modelling participants.
The method provider negotiates and plans the project together with the customer.
A facilitator moderates each modelling session. In a session there can be more
than one facilitator. A larger PEM project will typically have several facilitators
forming a method provider team, which is headed by a method provider team
leader. The team leader is often an experienced facilitator.
The main responsibility of the method provider is that the chosen EM method
“works” and that the project resources are used in a way that enables the project to
be completed on time and in such a way that the project goals are achieved. The
main responsibility of the domain experts is towards solving the actual problem at
hand using their domain knowledge.

1.5 The advantages of using a participative

approach to EM
In the process of creating an Enterprise Model, knowledge about the business is
acquired from different stakeholders. The knowledge is used to populate sub-
models, which are then validated and finally used for their intended purpose.
Method developers have advocated a participative way of working in this process
(see e.g. [Bub97, F395, Nils99]). In the context of participative EM participation is
consensus-driven in the sense that it is the domain stakeholders who “own” the
model and decide its contents. In contrast, consultative participation means that
analysts create models and the stakeholders are then consulted in order to validate
the models. In the participative approach to EM, stakeholders meet in modelling
sessions, led by a facilitator, to create models collaboratively. In the modelling
sessions, models are often documented on large plastic sheets using paper cards.
The “plastic wall” is viewed as the official “minutes” of the session, for which
every participant is responsible. More on the participative approach to EM can be
found e.g. in [F395] and [Will93].
The goal of EM is often to describe the current or future state of some enterprise.
This description is then used as important input in a process concerned with
business development or systems development. Business development is focused
on defining the direction of or goals for the business as well as
structuring/aligning business processes to achieve these goals. Systems
development focuses on developing or refining information systems that will
support the business processes. For EM in general the product of modelling,
namely Enterprise Models is the main target.
Participative Enterprise Modelling has a second goal, namely to achieve some
effect on the thinking of the people participating in the modelling process. In order
to achieve consensus-driven participation, some sub-goals must also be achieved:
• To achieve active communication and lively discussion between individuals
and between groups of individuals. Functioning human communication and
lively discussion increase the chances of identifying different views on the
problem to be discussed.
• To create a group, i.e. to make people feel that they work towards the same
goal. Chances of achieving a good modelling result increases if the group
work in the same direction.
There are at least three reasons why a participative approach should be used, if
possible:
• The quality of the Enterprise Model is enhanced because models are created in
collaboration between stakeholders, rather than resulting from a consultant’s
interpretation of interviews
• Consensus is enhanced because modelling participants have to collectively
expose their thinking, meaning that they have to establish a direct conflict or
strive towards consensus.
• Achievement of acceptance and commitment is facilitated because
stakeholders are actively involved in the decision-making process.

1.6 Measuring the success of applying EKD

There are three main criteria for successful application of EKD:
1) The quality of the produced models is high.
2) The result is useful and actually used after the modelling activity is
completed.
3) The involved stakeholders are satisfied with the process and the result.
High quality in models means that they make sense as a whole and that it is
possible to implement them as a solution to some problem. However, sometimes
the sessions do not produce high quality models. Nevertheless, the sessions might
still add value to the development work as indicated below.
Successful EM is when the result of modelling, e.g. a new strategy, a new process
etc., is effectively implemented in the organisation. The EM process produces two
results that are potentially useful:
1. The produced models, which are used as input to further development or
implementation activities
2. The changed thinking and the improved knowledge of the participants
Systems development projects and process development projects are typical
situations where the models themselves are used. However, the changed thinking
and improved knowledge of the participants are often mentioned as important
positive effects of the participative approach to modelling. In fact, it is a common
view among many EM practitioners that the “real” models are in the minds of
people, not in some document [Will99].
Clearly, an EM activity has many potential stakeholders, of which the following
are closely involved in different aspects of the modelling work:
1) The method provider/facilitator
2) The customer
3) The modelling session participants
These stakeholders may have different and sometimes also conflicting success
criteria.
Method providers/facilitators have their own individual standards regard what
they consider to be successful EM, but in general they agree that the most
important thing is that the customer and the modelling participants are satisfied
with the result. One indication that the customer is satisfied is if he comes back to
embark on new modelling projects. The motivation of modelling participants to
contribute to the modelling project relies heavily on the fact that they feel that they
have accomplished something that might be useful to them. This motivation is
particularly important if modelling is an ongoing activity in a project.

1.7 EKD and competency

The competency of domain experts and the competency of the method provider
are the most crucial resources in an Enterprise Modelling project. The concept of
competency can be described using four aspects:
1) Knowledge
A person’s factual knowledge about a specific subject matter, as a result of
e.g. education.
2) Skills
A person’s ability to actually use the knowledge to achieve goals.
3) Individual properties
A wide range of personal characteristics e.g. social skills, intelligence,
flexibility, integrity, ability to co-operate, courage etc.
4) Willingness to contribute competency
A person’s attitude towards actually contributing her/his knowledge and
skills to the achievement of goals other than her/his own.
1.7.1 The competency of domain experts

On the domain expert side customer and modelling participants are the main
actors (Figure 5). In this section we focus on the modelling participants, of which
the customer can be one.
Domain
expert
Customer
can Problem
can be be owner
Modelling
participant
consists
of
Modelling
group
Figure 5: Main categories of domain experts in an EM project
In a PEM project, the project definition results in a project plan, which commonly
includes a series of modelling sessions. Each modelling session has a goal or
several goals that should be achieved. These goals contribute to fulfilling the
project definition. The goals of each modelling session define the requirements on
the competency that should be represented by the participants in the modelling

group. The willingness or opportunity of people to contribute their competency is

constrained by a number of different situational factors such as organisational
culture, authority of involved actors, management support, time resources, method
acceptance and conflicts. These relationships are shown in Figure 6.
In the following we will discuss how these relationships influence on:
• The competency of individual modelling participants
• Composition of the modelling group
includes a Modelling
Project plan
series of session
results in has Organisational

culture
Modelling
Project definition contribute to
session
(project goals) fulfilling Authority of
goal/s
involved actors
consists of
defines Management
requirements support
Interaction
Analysis Expected for
with other
object result projects
Time resources
Competencies constrains
represented in the availibility Method
of acceptance
modelling group
Conflicts
Figure 6: Competencies of a modelling group - relationships between

requirements and constraints
The competency of individual modelling participants

The modelling participants need to have knowledge that is pertinent to the
problem that the modelling session addresses. Otherwise they will have no
possibility to contribute an opinion on the subject matter. In addition to
knowledge of the problem addressed, some personal characteristics are also
desired in an “ideal” modelling participant, such as the ability to abstract and
generalise, social skills, ability to verbalise and communicate, creativity etc.
One of the most important requirements for an individual modelling participant is
the motivation to participate and to contribute to solving the problem at hand. This
can make up for lack of some personal characteristics.

Composition of the modelling group

The composition of the modelling group is crucial to the achievement of the goals
for the modelling session. One aspect to consider is that different areas of
knowledge are represented in the modelling group.
The “direction” of the analysis, i.e. if the analysis concerns the current state of
affairs or the future state, also defines requirements for the group’s composition. It
is often the case that the people that are deeply involved in the problem can
describe the current state. But when it comes to the future, a different type of
people is needed. Here we need the visionaries, perhaps those that are a bit higher
in the organisation and see more than just the little piece of the puzzle.
Another aspect of group composition is the number of participants in a group. It
seems that an ideal number is between 5 and 10. If the group is too large it is
difficult for the facilitator to manage the group process, but a really small group
can also influence negatively on the modelling result.
For further details about the dynamics of a PEM group, see e.g. [Will93, Nils99,
Astrakan01, Bergquist99, EKD98].
The view of the interviewees is that the method provider preferably should have
an influence on the composition of a modelling group. One of the most
experienced interviewees even claims that he is reluctant to take on an assignment
where he does not have this influence. The less experienced say that they need to
become better in making their requirements clear to the customer in this respect.
At present they are very seldom given the opportunity to influence the choice of
modelling participants.
1.7.2 The competency of the method provider

The competency of the method provider is a critical resource in EM application
being responsible for the effective adoption of a chosen method and for the project
reaching its goals using the assigned resources. However, the method provider is
normally not responsible for the actual knowledge content of the resulting
Enterprise Models.
As previously indicated, the method provider can be one single person playing all
the roles of a method provider or it can in fact be a team of method providers
playing different roles in different project activities. The activities carried out by a
method provider reflect the EM process:
• Define the project
• Negotiate resources
• Prepare modelling sessions
• Facilitate modelling sessions
• Document models
In addition, ordinary project management activities, such as e.g. project planning,
progress monitoring and reporting, need to be carried out.

Each type of activity in a PEM project requires certain specific competencies.

There are three main levels of general method provider competency (Figure 7).
These three levels will now be discussed.
Ability to lead
modelling projects
Ability to facilitate
modelling sessions
Ability to model
Figure 7: Three levels of method provider competency
Ability to model
The first and most basic level is that the method provider has the ability to model,
i.e. to choose a suitable formalism for the problem at hand, to use the EM
method’s meta-model in order to represent some chunk of knowledge.
Furthermore, representing the knowledge in such a way that the model actually
reflects the knowledge.
The ability does not only rely on knowledge about specific modelling formalisms.
It is very much based on knowledge about the ideas behind conceptual modelling
in general and on the ability to compare different modelling formalisms and
choose one suitable for a specific situation [Astrakan01]. These topics are
reasonably well covered in terms of literature and courses, but still it seems that
part of this ability can be learnt and part of it comes from the individual
personality:
Ability to facilitate modelling sessions
The second level of competency focuses on the ability to facilitate a modelling
process, i.e. to lead/facilitate a modelling group in the process of collaboratively
creating an Enterprise Model. This ability is very much based on knowledge about
the effects of modelling, the principles for human communication and
socialisation, especially in groups, as well as the conditions of human learning and
problem solving (cognition) [Astrakan01].
Facilitation is a general technique used in group processes for a wide variety of
purposes1, also within EM. In PEM facilitation we include the activities of
preparing modelling sessions, facilitating them and documenting the result.
1
See International Association for Facilitators (IAF) http://iaf-world.org/iaflinks.htm (as is 2001-
08-30)

An important part of the competency of a modelling facilitator is “social skills”.

These “social skills” are personal characteristics, which can be further described
as follows. [Astrakan01]:
• Listening skills
Listening is not only about listening to what is actually being said. Listening
behind the words for what is really meant is the important thing
• Group management and pedagogical skills
The leader role is facilitated by the ability to motivate and keeping the
modelling facilitators interested. The ability to detect and solving potential
conflicts is also part of this skill.
• Act as an authority
To be an authority in this context is not the same as being authoritative. To
act as an authority is to create trust for your own competency and to make
the modelling participants feel that you know what you are talking about.
• Courage and ability to improvise
It is often an advantage to have more than one facilitator in a modelling session.

Some facilitator teams share the work so that one person documents and one
facilitates. Others take turns facilitating the group. However, the team relationship
must be completely equal in order to function properly. Every member of the
facilitator team must be considered by the group to be an authority.
Ability to lead modelling projects
The third and top level emphasises the ability to co-ordinate and lead modelling
projects, involving a team of method providers, toward achieving project goals.
Leading a modelling project involves negotiating the project as well as monitoring
it and reporting the results. If facilitation of modelling sessions can be considered
to be the micro EM process then the whole project is the macro EM process. The
macro process, especially in large projects, requires a great deal of experience. Of
course they need the usual project management skills, but apart from that they
need to be able to see how the whole set of modelling sessions and their results
holds together and how they contribute to achieving the project goals.
A critical task in leading a project is negotiating the project definition and
resources and also judging which approach to modelling that is appropriate in that
situation. It is advisable that and experienced method provider negotiate the
project the less experienced focus on facilitating modelling sessions.

2. The Library Case Study

It is difficult to describe EKD without giving a large number of examples. In order
for the example fragments to hang together, we introduce a "library case". We will
give a minimal description of the problems that a particular, small library is
facing. It should be understood that the solution to the library’s problems might
include a re-orientation of its activities as well as investment in information
technology.
Disclaimer.
The situation of the library is purely imaginary and has no relation to reality.
Furthermore, the description is given only to make it easier for the reader to
understand the various examples given in the sequel. Hence, the description does
not claim to be a sufficient amount of knowledge to perform a full enterprise
modelling process.
2.1 Background
The Royal Institute of Technology (KTH) of Stockholm, main library has a small
branch library at Electrum, Kista. Electrum is a science park located in an IT-rich
suburb of Stockholm. It includes three research institutes SISU, SICS and IMT
employing altogether more than 200 qualified researchers. Electrum also hosts
five KTH departments totalling about 400 employees. In addition, Electrum has
excellent facilities for arranging conferences for up to 500 people. The conference
facility is frequently used by many kinds of companies. A restaurant, a café and a
Pizza Hut are also at Electrum. Kista is an area of Stockholm where many IT
vendors and industries are located. Examples of industries are Ericsson
Components, Ericsson Radio (Mobile telephones), IBM, Hewlett Packard, Nokia,
Lotus, Informix, and many others.
The Electrum Library specialises in literature related to information technology.
The library maintains a small set of books and a relatively complete set of the
most well known magazines and journals related to information technology. It
also provides a computerised service, accessible through remote access, to search
for books and periodicals that are maintained by Main Library as well as the
Electrum Library. The Electrum Library is serviced by two full time employees.
2.2 The Current Situation

The Main Library's funds have been cut, so that it is reconsidering the Electrum
library. There is a need to re-examine the Electrum library's goals and activities,

and to reorganise its services to departments and institutes in Electrum as well as

to business and industry in the Kista area.
The Main Library has found that the Electrum library is infrequently used. The
Main Library is not sure of the kind of user requirements regarding library
services that currently exist. The Main Library is therefore considering cutting its
annual support to the Electrum Library. The current support is 1 650 000 SEK (see
expenditure table below). There is no other income for the Electrum library.
Borrowing books, periodicals, as well as making copies of articles in journals are
currently free services.
The need is to develop (or re-design) Electrum library activities as well as services
in a way that will generate an increased annual income. It is expected this will
decrease the Main Library's annual funding of Electrum Library by 200 SEK
within a year and 500 SEK within 3 years. The Main Library has allocated 1000
SEK for this transition process. The current annual expenditures of the Electrum
library are as follows:
Personnel salaries 700 000 SEK

Office rental 450 000 SEK
Subscription to periodicals 250 000 SEK
Purchase of books 100 000 SEK
Other 150 000 SEK
Total 1 650 000 SEK
It is expected that the task of reconsidering the Electrum library's goals and
activities be carried out by developing a crude Enterprise Model of the future
Electrum library. By developing and analysing a Goals Model, a set of future
services of the Electrum library, to be offered to its customers, will be suggested.
While developing the Goals Model, crude versions of the Concepts Model, the
Business Rules Model, the Actors and Resources Model will also be developed.
The Library Case will be further developed throughout this manual as a modelling
example.

3. Overview of EKD
3.1 What is EKD?

EKD is an approach that provides a systematic and controlled way of analysing,
understanding, developing and documenting an enterprise and its components, by
using Enterprise Modelling. The purpose of applying EKD is to provide a clear,
unambiguous picture of:
• how the enterprise functions currently,
• what are the requirements and the reasons for change,
• what alternatives could be devised to meet these requirements,
• what are the criteria and arguments for evaluating these alternatives.
Basic contents of the EKD framework include: a set of description techniques,
explanation of stakeholder participation and a set of guidelines for working. EKD
application process is supported by a set of software tools (Figure 8).
A set of
description Stakeholder A set
participation of guidelines
techniques for working
A set of supporting tools
Figure 8: Contents of the EKD framework
A set of description techniques provides a set of models used for describing the
system to be analysed or constructed, and the organisation in that it will operate.
This set of description techniques is used by the “builders” of the system that is
constructed. However, it is not difficult to imagine, that the description techniques
alone do not provide much value without direct involvement of the actual
customers, end users, managers, owners, etc.
To have a common term for all involved in the project, directly or indirectly, or
otherwise having an interest in outcome of the project, we introduce a broader
term stakeholder. Stakeholders are all those who have a “stake” in the outcome of
the project, even if they do not have an explicit decision-making role in its
conduct or progress or do not hold an information essential for the project.

Customers, and end users, are obviously stakeholders; and so is the owner or the
company and the shareholders. Besides these “obvious” stakeholders directly
involded in the project, there might also be “indirect” or “hidden” stakeholders –
members of the management hierarchy who have interest (positive or negative) in
the expected outcome. Others, might be members of unions, or suppliers, or
customers, or competitors, or society.
Successful involvement of stakeholders in a project that includes application of
EKD is one of the critical success factors in building of an information system or
restructuring the organisation.
The third cornerstone of EKD – a set of guidelines for working provides a
problem solving, and experience sharing support for the EKD Process. To
successfully carry out this task some co-operative work support is necessary.
Deliverables from EKD
The deliverables of the EKD Process are a number of conceptual models that
examine an enterprise and its requirements from a number of interrelated
perspectives. These models are abstractions from the physical world. For a given
enterprise, these models will collectively constitute the Enterprise Model. Coupled
to these models may be relevant information addressing the need for evaluating
alternative operational situations; such information includes criteria for
evaluation, choices available, measurement parameters and recorded arguments
for and against choices.
At any stage of its development, the Enterprise Model can serve as the means of
understanding and communication between the participants or between
participants and other stakeholders in the EKD process. It will be a common
reference point across many different areas so that its ownership will not be
confined to specific applications or particular groups. It will be independent of any
technology so that the same model may be implemented on several technology
platforms, and the model will remain valid, irrespective of changes to technology.
The model will need to be changed, only when the situation and context in which
the enterprise exists and operates changes. It may be used as a means of evaluating
options, so that the costs of each potential option may be assessed, as well as
clearly documenting all intangible aspects.
The ”stopping rule” for developing the Enterprise Model, is a set of models,
described in sufficient detail so it can be used as a basis for continued work of
implementing the suggestions in the models, or using as a basis for continued
problem solving by other means.

How do we use EKD?
The EKD approach will typically involve strategists, tactical managers and
operational staff who together with modelling facilitators and technicians, familiar
with EKD, will engage in the process of:
1. Diagnosing – modelling the current situation and the change
requirements.
2. Understanding – interpreting, understanding, reasoning, deliberating,
and discussing the current and future states of the enterprise.
3. Designing – discussing and modelling the alternative future situations
and scenarios.
The resulting enterprise model will then be available to decision-makers for
making informed decisions about future enterprise strategies, tactics and
objectives.
Existing Situation The Need for Future
FutureSituation
Situation
“As-Is” Change “To-Be”
“To-Be”
Enterprise New Goals Enterprise
Model and Requirements Model
Modelthe
the Consider
Model Implement
Enterprise Transitions and ImplementModel
Model
Enterprise
Alternatives
Alternative
models
DISCOVERING UNDERSTANDING DESIGNING
Figure 9: Types of activities involved in the EKD Process
3.2 The Enterprise Model and its Components

The Enterprise Model contains a number of interrelated sub-models (Figure 10).
Each of them represents some aspect of the enterprise. The types of sub-models
and issues they address are:
• Goals Model (GM) focuses on describing the goals of the enterprise.
Here we describe what the enterprise and its employees want to achieve,
or to avoid, and when. Goals Models usually clarify questions, such as:
where should the organisation be moving, that are the goals of the
organisation what are the importance, criticality, and priorities of these
goals, how are goals related to each other, which problems are hindering
achievement of goals.

• Business Rule Model (BRM) is used to define and maintain explicitly

formulated business rules, consistent with the Goals Model. Business
Rules may be seen as operationalisation or limits of goals
Business Rule Model usually clarifies questions, such as: which rules
affect the organisation’s goals, are there any policies stated, how is a
business rule related a goal, how can goals be supported by rules.
• Concepts Model (CM) is used to strictly define the "things" and
"phenomena" one is talking about in the other models. We represent
enterprise concepts, attributes, and relationships. Concepts are used to
define more strictly expressions in the Goals Model as well as the content
of information sets in the Business Processes Model.
Concepts Model usually clarifies questions, such as: what concepts are
recognised in the enterprise (including their relationships to goals,
activities and processes, and actors), how are they defined, what business
rules and constraints monitor these objects and concepts.
• Business Processes Model (BPM) is used to define enterprise processes,
the way they interact and the way they handle information as well as
material. A business process is assumed to consume input in terms of
information and/or material and produce output of information and/or
material. In general, the BRM is similar to what is used in traditional
data-flow diagram models.
Business Process Model usually clarifies questions, such as: which
business activities and processes are recognised in the organisation, or
should be there, to manage the organisation in agreement with its goals?
How should the business processes, tasks, etc. be performed (workflows,
state transitions, or process models)? Which are their information needs?
• Actors and Resources Model (ARM) is used to describe how different
actors and resources are related to each other and how they are related to
components of the Goals Model, and to components of the Business
Processes Model. For instance, an actor may be the responsible for a
particular process in the BPM or, the actor may pursue a particular goal
in the GM.
Actors and Resources Model usually clarifies questions, such as: who
is/should be performing which processes and tasks, how is the reporting
and responsibility structure between actors defined?
• Technical Components and Requirements Model (TCRM) becomes
relevant when the purpose of EKD is to aid in defining requirements for
the development of an information system. Attention is focused on the
technical system that is needed to support the goals, processes, and actors
of the enterprise. Initially one needs to develop a set of high level
requirements or goals, for the information system as a whole. Based on
these, we attempt to structure the information system in a number of
subsystems, or technical components. TCRM is an initial attempt to
define the overall structure and properties of the information system to
support the business activities, as defined in the BPM.

The Technical Components and Requirements Model usually clarifies

questions, such as: what are the requirements for the information system
to be developed, which requirements are generated by the business
processes, which potential has emerging information and communication
technology for process improvement.
uses,
refers_to Goals Model
motivates,
requires motivates, defines,
requires affects, is_responsible_for
defined_by
Concepts Business Rules

Business Rules defines, Actors and
uses,
Model Model
Model is_respon- Resources Model
refers_to
sible_for
triggers
performs, defines
supports is_responsible_for
uses,
Business Process
produces Model
motivates,
requires
refers_to Technical Components and

Requirements Model
Figure 10: The sub-models comprising the Enterprise Model
Each of these sub-models includes a number of components describing different

aspects of the enterprise. For example, the Goals Model contains business goals,
business problems, divided into threats and weaknesses, causes, business
opportunities, and constraints. The modelling components of the sub-models are
related between themselves within a sub-model (intra-model relationships), as
well as with components of other sub-models (inter-model relationships).
Figure 10 shows inter-model relationships. The ability to trace decisions,
components and other aspects throughout the enterprise is dependent on the use
and understanding of these relationships. When developing a full enterprise
model, these relationships between components of the different sub-models play
an essential role. For instance, statements in the Goals Model allow different
concepts to be defined more clearly in the Concepts Model. A link is then
specified between the corresponding Goals Model component and the concepts in
the Concepts Model. In the same way, goals in the Goals Model motivate
particular processes in the Business Processes Model. The processes are needed to
achieve the goals stated. A link therefore is defined between a goal and the
process. Links between models make the model traceable. They show, for
instance, why certain processes and information system requirements have been
introduced.
There exist, however, limitations in the way sub-models and their relationships
may be populated. These are controlled by a number of static as well as dynamic
consistency rules, which control their permissible state transitions. These are

necessary because they allow for analysis and comparison. How each sub-model
focuses on a specific view of the enterprise will be described in detail in the
following chapter.
3.3 Example of an Enterprise Model

EM modelling components usually have some graphical representation e.g.
rectangular boxes, ellipses, or other shapes. The relationships between these
modelling components are represented with links.
Practically, when creating and working with the Enterprise Model, there are two
text inputs associated with each component of the model — the short name and
the long name (Figure 11). The short name is normally used for numbering and
identifying a model’s components. It should be unique to serve as a handle for
references within documents explaining the Enterprise Model. The long name is
used for expressing and storing the actual text (description) of the component.
Goal 2
Goal 1
To provide advanced To minimise
services to library hinders library's
customers operational costs
Opportunity 1 supports
solves *
Advanced supports
communication
and information supports Problem 2
Goal 3 Goal 4
technology
Deliver ietms High stock Library's budget will
electronically availability be cut by 500 KSEK
within next 3 years
Problem1
Copyright and hinders supports
ownership of
electronic material
Constraint 1
Requests for electronic
material must be
satisfied witin 3 days
Figure 11: Example of the graphical representation of a sub-model
For example, “Goal-1” in Figure 11 is a short name, and “To have a high service
level to customers” is a long name, or the goal text. Besides the short name and
the long name, there might be also some other texts associated with a particular
modelling component, such as, comments, source of information, creator, date of
creation, priority, criticality, trust level, links to other documents or files, etc. The
actual use of these texts may depend on the functionality of the tool support.
Usually such texts are not shown in the model, but appear only in the method’s
supporting software as well as textual reports.
Relationships within EM also may, or may not have textual names. If a
relationship has textual name, it should be red as indicated by arrow. E.g. Goal 2:
“To minimise library’s operational costs” hinders Goal 1: “To provide advanced

services to library customers”. Relationships usually do not possess short names,

since they exist only in conjunction with a pair of modelling components.

4. Technical Description of
Enterprise Modelling
In this chapter, we describe EKD Enterprise Modelling method in detail, including
technical aspects and their application. First, we present a brief summary about the
purpose and usage of particular sub-models of the Enterprise Model. We discuss
appropriate components for representation of the domain problem area. Then we
provide a simple modelling example based on the Library Case described before.
We also give some suggestions and hints in developing of the particular sub-
model.
4.1 Goals Modelling
4.1.1 The Purpose of Goals Modelling

The Goals Model is used for describing the goals of the enterprise along with the
issues associated with achieving these goals. The Goals Model describes
essentially the reason, or motivation, for components in the other sub-models. The
components of this model are related to the enterprise itself and its rationale.
Information system goals and requirements should not be stated here. The Goals
Model forms the framework with which the relevance of processes and technical
system requirements are measured and to which they are linked. Through links to
and from the other sub-models, the Goals Model explains why, or why not,
processes and requirements exist or do not exist. The components of the Goals
Model are related to each other through monodirectional semantic links of which
the three main types are supports, hinders, and conflicts.
4.1.2 Components of Goals Model

Component types of the Goals Model are following: goal, problem, cause,
constraint, opportunity. However, observations from a number of practical
modelling sessions show that sometimes it is necessary to add additional
components to the model, such as, comments, assumptions, scenario, tasks, etc. If
such an extension is approved by the modelling group, it may considerably
improve the expressiveness and clarity of the model.

Goal
A business Goal is a desired state of affairs that needs to be attained. It is used for
expressing goals regarding the business or state of business affairs the individual
or organisation wishes to achieve. Goals express what the enterprise and its
employees want to achieve, or to avoid, and when.
They may be expressed as a measurable set of states, or as general aims, visions or
directions. Goals can be several meanings, such as, goals, objectives, intentions,
needs, requirements, desired states, etc. Intentional sentences should begin with
the sentence "The goal is...".
Goals may also have the optional variables priority and criticality (with possible
values: low, medium, high), that allow modellers to assign different priority levels
and perceived degree of criticality.
Goals modelling requires the modelling participants to reflect over, and state their
short as well as long range goals about the enterprise. It also requires the
modelling participants to discuss and agree upon:
• The individual importance of goals,
• Criticality of goals,
• Priority of goals,
• Evaluating alternative ways of achieving goals.
Problem
A Problem is used for expressing that the environment is, or may become, in some
non-desirable state of affairs that needs to be addressed, and that hinders the
achievement of goals. By documenting perceived problems, a base is created to
detect hidden goals, that may otherwise only be implied, because problems
typically hinder the achievement of some goal. If a stated problem cannot be seen
as hindering some goal, then either the set of goals is incomplete or the problem
really is not a problem of the enterprise.
Problems may be specified into two following sub-types:
• Weaknesses – a type of problem that describes factors that may reduce the
possibility of achieving a goal. The enterprise has the resources and
knowledge to reduce the effects of the problem.
• Threats – a type of problem for which the enterprise has the resources to
reduce the effects of the problem but not the required knowledge.
Cause
A Cause is used for expressing the explanations or reasons for Problems. Causes
are usually situations or states, outside the control of the project, process, or
organisation. It may be something that is well understood and does not need to be
analysed further. Typically, a cause cannot be affected by the enterprise.

Constraint
A constraint is used for expressing business restrictions, rules, laws, or policies

from the outside world affecting components and links within the Enterprise
Model. Internal business rules and policies of the organisation are defined in the
Business Rules Model.
Opportunity
An opportunity is used for expressing resources that can make certain goals easier
to achieve, achievable states not regarded as Goals, or even to state new goals of
the enterprise. For instance, new communication technology may facilitate an
enterprise’s possibilities to achieve a goal to enlarge the international market of its
products. Opportunities are situations that we may want to take advantage of. If
so, the Opportunity should be transformed into a Goal.
Links within the Goals Model
The link types between the components of the Goals Model are:
• supports relationship, that is essentially seen as "vertical", i.e. it is used
to refine or decompose goals or other components.
hinders relationship, that is used to show negative influences between
components of the Goals Model, and can be considered as opposite to
"supports".
• conflicts relationship, that is used to define situation when an
achievement of a goal is in conflict with another. For example, a library’s
goal of attracting more clients by staying open longer, will be in conflict
with the goal of saving money on employee wage costs.
Initially the Goals Model may have a high level of abstraction. To get more clarity
and to detail goals it is often necessary to decompose or to refine them to sub-
goals. Such possibilities provide AND/OR relationships in goal graphs.
AND refinement relationship represents a set of unique sub-goals, that are
necessary to satisfy to support the original refined goal .
Figure 12 conceptually shows refinement of Goal 1 into Goal 1.1, Goal 1.2, and
Goal 1.3. Such a construction in the model means that to achieve Goal 1, it is
necessary to achieve all three sub-goals: Goal 1.1 and Goal 1.2 and Goal 1.3. We
assume that to provide a good quality lecture course in IT (Goal 1) is necessary to
have a good room and presentation equipment (Goal 1.1), and a competent and
skilful teacher (Goal 1.2), and good course material (Goal 1.2).

Goal 1
To provide a good
quality lecture course
in Information
Technology
Goal 1.1 Goal 1.2 Goal 1.3
To maintain high To find a good teacher To develop

quality rooms and in Information appropriate course
equipment Technology material
Goal 1.2.1 Goal 1.2.2

To find a teacher with
a deep knowledge of To find a teacher with
Information good teaching skills
Technology
Figure 12: Fraction of a Goals Model containing AND relationships
OR refinement relationship represents a set of alternative sub-goals. To support

the original goal, it is sufficient to satisfy only one goal from the set. This is
conceptually exemplified in Figure 13. Goals 2.1, 2.2, and 2.3 express tree
different alternatives for implementing interactive customers support, such as:
interactive WEB site on Internet, or telephone hot line, or interactive CD-ROM.
Goal 2
To achieve
interactive customer
support
Goals 2.1 Goals 2.2 Goals 2.3

To maintain 24-hour To maintain an To provide
a day telephone interactive, WWW customers with a
hot-line based bulletin board service catalogue on
on Internet CD-ROM
Goals 2.2.1 Goals 2.2.2

To purchase a WWW
To maintain an own server services from
WWW server outside Internet
provider company
Figure 13. Fraction of a Goals Model containing OR relationships

4.1.3 Notation
Component: Links:
<short_name> supports/conflicts(weak/medium/strong)
<coponent text>
hinders
Decomposition:
AND OR
<goal 1> <goal 1>
<goal 2> <goal 3> <goal 2> <goal 3>
Figure 14. Notation for Goals Models
4.1.4 Example of a Goals Model

To better understand, the main aspects of Goals modelling let us discuss the
Library Case described before. This case has been given to students as a part
practical assignment in a requirements engineering course at the Royal Institute of
Technology. In the modelling seminars, many facts of different types have been
introduced (e.g. enterprise goals, problems, opportunities, business rules, etc.).
Some of them are listed below:
• The library has its budget cut by 50% for the next 3 years.
• The library needs to find additional finance sources.
• There is a need for service improvement.
• There is a long waiting list for borrowing books.
• The library should provide a top class standard of service.
• The library needs an external finance source of 500 SEK in the next 3
years.
• The borrowing waiting list should be minimised.
• The library needs more paying clients.
• There is a regulation, that library services should be free of charge for
students and academic staff.
• There are no good registration systems for all financial transactions.

• The library is situated in ELECTRUM that is an office building for

information technology companies.
It is very often possible to determine the type of a particular fact intuitively. For
example, a sentence "The library should provide a top class standard of service",
sounds very much like an objective that the library management would like to
achieve in the future. The sentence "The library needs more paying clients" is
clearly understandable only if we assume that the library has a lack of financial
resources. We can assume that this goal is required due to the overall need for
money that is caused by 50% budget cut. Graphically part of the library’s Goals
Model is displayed in Figure 15.
Goals 10 Theat 1
To maintain and hinders The library's budget
improve the will be cut by 200
library's services KSEK within a year
and by 500 KSEK
within 3 years
supports
Goals 11
To have an external
finance source
supplying 500 KSEK
in next 3 years
supports
Goals 19 Goals 7
To attract outside To make the library

customers organisation more
cost-effective
Goals 3
Weakness 2 hinders To establish supports Opportunity 1

The library is paying services In ELECTRUM
infrequently used there are many
high-tech
hinders companies
supports hinders
Problem 4
There is a long Goals 6
Constraint 1
waiting list for To achieve a top Service should
borrowing books class standard of be free of charge
service for students and
academics
supports hinders
Goals 4 Weakness 3
To minimise Service in the library
customer's waiting in is not as good as it
the queue should be
Figure 15. Fraction of the initial Goals Model of the Library case
This is only the initial Goals Model made in the very first discussion. It can be
elaborated and detailed further in many ways to get more operational and clear
goals and other components of the model. Generally, there are two main types of
activities while working with the Goals Model — acquisition and
operationalisation.

4.1.5 Developing the Goals Model

Developing a Goals Model is initially a brainstorming activity. Views and
contributions from all participants must be considered, that normally makes the
initial product of modelling unstructured and difficult to understand. Computer
programs exist that can help structuring and organisation of this set of statements.
The following steps of goals modelling include structuring, classification, and
operationalisation of goals model components. This is normally done by model
“designers” in an iterative fashion, where participant stakeholders are
continuously consulted to validate the progress.
It is important, when developing Goals Model, to concentrate on the business
itself, and not on the supporting information system and its more technical goals.
The supporting information systems goals will be the topic for the Technical
Components and Requirements Model.
The static rules for the enterprise, as well the dynamic rules that govern the
permissible state changes of the enterprise, are also informally defined in this sub-
model. Normally "business rules" can be seen as refinements of higher level
business goals or constraints. The business rules are then further elaborated in the
Business Rules Model.
4.1.6 Driving Questions

It is useful to use, or at least to keep in mind some driving questions while doing
goals modelling, e.g.:
• What are the strategies of this part of the enterprise?
• Are there stated policies in the enterprise that may influence this model?
• Which conventions, rules, regulations and laws are relevant?
• What would you like to achieve?
• Are there any particular problems hindering this?
• Is this problem related to a particular goal?
• What is the cause of this problem?
• How can this problem be eliminated?
• Are there any particular opportunities one could use?
• What actions could be taken to improve the situation?
• How can this goal be achieved?
• Can this goal be defined in operational terms, by giving a number of
supporting sub-goals?

4.1.7 Naming the Goals Model components

While working with Enterprise Models, one should express all components of the
as clearly and precisely as possible. A good rule of thumb is that, for example,
goals in the Goals Model should be always expressed in a full sentence starting
with "The goal is...". For example, the goal "Extra money" is not a full sentence
and may be interpreted in different ways. It should be expressed as " The goal is to
have an external finance source of 500 SEK in next 3 years" if that is what is
intended (Figure 16).
Ambiguous, Clearly
uncertain goal: stated goal:
Goal-17.2 Goal-17.2
The goal is to have an
Extra money
external finance source
of 500 KSEK in next 3
years
Figure 16. The same goal expressed in two different ways
Very often, people try to write long sentences as the goal or problem statements.
There are no strict rules regarding whether the sentence is too long or not.
However, one should try to avoid writing logically different statements within one
modelling component. For example, in Figure 17 there is an initially defined
problem, that also contains a possible solution for it. To divide these to issues
separately we can introduce an opportunity that contains the solution part of the
initial problem.
Initially stated Rephrased into

problem: opportunity linked
to problem:
Problem 5 Problem 5
There are no skilled WEB There are no skilled
developers available in WEB developers
the Library (can be available in the Library
brought from outside
companies
solves
Opportunity 7
WEB developing
services can be
brought from
outside
companies
Figure 17. Initial problem contains two statements – problem and opportunity
Another aspect of the naming of the modelling components is to try to avoid

words with several meanings, as well words that may be misinterpreted in

different situations. Also try to rephrase expressions like “to have a good ABC”,
“to do this cheaper”, etc., to something more tangible and measurable. E.g. “to
have a system ABC that has low production and maintenance costs and multi-user
interface”, if that was meant.
4.1.8 Goal Refinement and Operationalisation

The purpose of the goal operationalisation, is to detail how high level goals may
be satisfied. Operationalisation of the Goals Model encourages the development
of a goal network, whereby successive refinements of goals eventually lead to the
definition of the form of the artefact that meets the originally stated goal. The key
aspects of the goal operationalisation process are:
• emphasis on creativity: goal operationalisation reflects a creative jump
from present facts to future possibilities that bring into being something
new that has not previously existed.
• emphasis on the dynamic nature of the process: the result of the
process is not static but depends on the design decisions and the visions
of the future situation during the operationalisation process. This entails
that the outcome of the process is not always the same.
The operationalisation is characterised by two principal types of activities:
During goal refinement, new goals are generated from the initial high level ones to
detail and clarify these. In this sense a high level goal is refined into one or more
sub-goals, that can in turn be refined in sub-subgoals. The result of these
successive refinements is a multi-level hierarchical structure, starting from high-
level vague enterprise objectives down to specific operational goals. In goal
refinement, it is possible to use AND/OR relationships in the structures, to refine
goals into several alternative combinations of sub-goals, or a sub-goal can be
realised by several alternative design models.
Goal conflicts management consists of a number of activities. These are:
• Conflict detection:
This focuses on identifying conflicts between goals. It may be difficult to
relate new goals to existing goals and determine the effect of former to
the latter. To do this, one should exhaustively search the goal model and
compare the new goal to each existing goal for conflicts.
A reasonable way to search for potential goal conflicts is to use the high-
level goal conflicts that have already been identified during the goal
acquisition stage. The heuristic rule is that it is more likely to find
conflicts between sub-goals of previously identified conflicting high-
level goals.
• Conflict classification:
Focuses on identifying the kind of conflict that has been detected.
⇒ Ends conflict

Goal conflicts may occur when two contradictory goals are desired.
⇒ Means conflict:
When actors hold identical goals. However, these goals are in
conflict because each actor wants to use the same resource.
Conflict classifications may be used by conflict management methods to
react accordingly.
• Conflict handling focuses on acting in the presence of conflict. This may
be one of the following:
⇒ Ignore: for example, when conflict does not prevent further
development. However, it is necessary to keep track of the conflict in
case its impact increases.
⇒ Ameliorate: the balancing of conflicting goals may not be clear until
the various design possibilities are explored in terms of alternative
design models. This way the decision is shifted to the design model
generation stage, when more concrete data about a case is available.
⇒ Resolve the conflict. Often, a goal conflict implies the unavailability
of any specific alternative to achieve both goals. In this case, the
ranking of goals may be useful for deciding an eventual dropping of
a goal. However, some goal conflicts may be overcome by:
a) redefining the goals,
b) specifying the context in which each goal is
achieved or,
c) finding alternative goal refinements that have fewer
conflicts.
The two key issues in managing conflicts are: tracking known conflicts and
recording information about these conflicts, such as the circumstances that led to
these conflicts.
Very often, the high level goals, problems, business rules, etc. acquired at the
model acquisition stage, contain a number of informal and imprecise
requirements. It is recommended that the output of the initial Goals Model be
structured at an early stage.
This task involves:
• Goal classification
To improve comprehension and understanding of a multitude of goals, it
maybe advisable to classify them in a matrix table, where they may be
categorised according to, origin, stakeholder, function, domain ,etc. This
will allow for comparison, analysis and perhaps uncover the need for
further discussion based on the analysis of the patterns of the goals.
• Goal prioritisation
A prioritisation of goals allows for conflict resolution between goals. A
higher level goal acts as a constraint on a lower level goal.

• Goal correlation.
Goal correlation is perceived as the positive or negative interaction
between goals. In general, goal collaboration is desirable, since
collaboration between two goals implies that satisfaction of one goal will
support the satisfaction of the other goal; moreover, it shows a consensus
between the goals of the stakeholders. On the other hand, existence of
antagonistic goals could prevent the satisfaction of goals. Furthermore,
failure to recognise antagonistic goals could cause confusion throughout
the design process. A systematic approach is then to reveal goal
correlations that use matrices to ensure that all possible interactions are
discovered, and diagrams that make clear the pattern of relationships.
4.2 Business Rules Modelling
4.2.1 Purpose of Business Rules Modelling

The Business Rules Model is used to define and maintain explicitly formulated
business rules, consistent with the Goals Model. Business Rules may be seen as
operationalisations or limits of goals. Business rules are the rules that control the
enterprise in a way that they define and constrain which actions may be taken in
the various situations that may arise. These may be in the form of:
• precise statements that describe the way that the business has chosen to
achieve its goals and to implement its policies or,
• the various externally imposed rules on the business, such as regulations
and laws.
Business Rules form a hierarchy where lower level rules define the way the higher
level rules or goals are implemented. Business Rule Modelling is closely related to
Goals Modelling. Rules are defined by goals while also affecting the fulfilment of
other goals. They trigger business processes and refer to concepts defined in the
Concepts Model. Actors in the Actors and Resources Model are responsible for
achieving and defining business rules. Business rules also may require certain
functionality from the information system. Components of the Technical
Components and Requirements Model may be motivated by business rules.
4.2.2 Components of Business Rules Modelling

Business rules may be categorised into:
• Derivation rules that are expressions that define the derived components
of the information structure in terms of entities that are already present in
the information base of the modelled enterprise. Derivation rules are
introduced as a means of capturing structural domain knowledge that
need not be stored and that its value can be derived dynamically using

existing or other derived information. A derivation rule is, for instance,

"A bad library client is a client that does not return a loan on time for two
consecutive times".
• event-action rules that are concerned with the invocation of activities. In
particular, action rules express the conditions under which the activities
must be taken, i.e., a set of triggering conditions and/or a set of
preconditions that must be satisfied before their execution. For instance,
"If the return of a loan is more than 4 days over-due, send a reminder".
• constraint rules that are concerned with the integrity of the information
structure components, or with the enterprise activities and their permitted
behaviour. A constraint is, for instance, “the salary of an employee must
not decrease”.
Constraints can be further specialised into:

• Static constraints apply to every state of the information base and are
time-independent. They represent conditions that must hold at every
state. A static constraint, is for example, “location of each copy of book
is unique and only one”.
• Transition constraints define valid state transitions in the information
base, thus specifying restrictions on the behaviour of the system. A
transition constraint is, for instance, “A copy of book is missing, if the
loan that includes it is overdue for more than 4 weeks”.
The relationship types between rules in the Business Rules Model are:
• Supports relationship is essentially seen as vertical, i.e. it is used to refine
or decompose rules.
• Hinders relationship is used to show negative influences between
components of the Business Rules Model, and can be considered as
opposite to supports.
As in the Goals Model, there are also possible AND/OR decomposition structures
in Business Rules Model.
• AND refinement relationships represent a set of unique sub-rules, that are
necessary to satisfy to support the original refined rule.
• OR refinement relationships represent a set of alternative sub-rules. To
support the original rule is necessary to satisfy only one rule from the set.

4.2.3 Notation
Component: Links:
<coponent text>
hinders
Decomposition:
AND OR
<Rule 1> <Rule 1>
<Rule 2> <Rule 3> <Rule 2> <Rule 3>
Figure 18. The notation used in the Business Rules Model is similar to that for the
Goals Model.
4.2.4 Example of Business Rules Model

Regarding our Library Case we can formulate several rules and represent them
graphically:
• Customers should be reported as bad customers if they have overdue
books on more than consecutive occasions, or have a book that is
overdue for more than four weeks.
• Customers should pay fines if a book is overdue, regardless of any non-
paying privileges they may have.
• Bad customers who are non-paying customers should not be allowed to
order book from other libraries.
• Paying customers should not be given priority in a waiting list.
• The library catalogue should be updated when changes occur.
In Figure 19 these rules are shown together with part of the Goals Model that they
affect. Such interpretation shows us how rules are related to goals.

Goals 3
Constraint 1 hinders
Service should To establish
be free of charge paying services
for students and
academics
supports supports
Goal 19 Goals 6
To offer additional To achieve a top
benefits for paying class standard of supports
customers service
Rule 6
Notify all customers about
supports all changes in library
supports services immediately as
hinders changes occur
Goal 5
Rule 2
There should be no To achieve high
priority in waiting precision in all Goal 20
supports
line for paying library transactions To keep the library
customers catalogue
regularly updated
supports supports
supports
Goal 4
To minimise Rule 1
A customer is a bad supports
customer's waiting
in the queue customer id he/she
does not follow Rule 5
library rules Update library
catalogue as soon
as changes occur
Rule 3 Rule 4
A customer is a bad A customer is bad
customer is he/she customer is he/she
has overdue books delays books for more
twice consecutively than 4 weeks
Figure 19. The interaction between business rules and components of the Goals
Model are displayed by the dashed-lines
4.2.5 Developing the Business Rules Model

All business rules in the Business Rules Model should be expressed in the
following way:
When {event}
If {preconditions on entities}
then {processes}
It may however, not always be possible to write a business rule using this
proposed pattern. Generally, there exist three ways business rules can be stated:
• informally such as in normal language,
• formally such as structured English or,
• formally by using specially developed rule languages, e.g. TEMPORA
ERL2, that is a notation technique for expressing business rules.
2
ERL – External Rule Language was proposed by the ESPRIT project TEMPORA

The latter two express rules in an unambiguous way that contributes to easier
implementation of them in an information system design. Such expressed rules
should contain only one atomic rule, that is a specific formal statement of a single
constraint, fact, derivation, or term and cannot be decomposed further. For
example, we can rewrite Rule-4: "Customer is reported as Bad Customer is he/she
delays book for more than 4 weeks" in following way (see Figure 20):
When Check_for_delayed_books
If Today - Loan.Return_day ≥ 28
then Report_customer_as_bad(Loan.Customer_ID)
From a rule written in this way, modelling participants and designers are able to
get information that is more precise about:
• which concepts (Loan, Customer, Bad Customer) are involved or related
in realisation of this rule
• which processes support (Check for delayed books) this rule
• are triggered (Report customer as bad) by this rule.
Process 15 Process 14
Report customer Check for
as bad delayed loans
supports
motivates
Rule 4
If Today - Loan.Return_date >= 28
refers_to
refers_to
Concept 7 Concept 18
Service Loan
has
receives
Return date
Concept 8
Concept 11
Bad Customer has ID
customer
Figure 20. Rules refer to concepts in the Concepts Model and are supported by
processes in Business Processes Model
Graphically the same facts are shown in Figure 20. However, in a formal way it is
possible to express only atomic rules. Rules that are more complex need to be
expressed in natural or semi-natural language and then decomposed or refined by
using AND/OR relationships. Although there may be also atomic rules that are
almost impossible to define in the formal way, e.g. rules that are related to Non-
functional requirements.


There are several kinds of driving questions that might be useful when modelling
business rules:
• Are there stated rules and policies within the company that may influence
this model?
• By which rules can the goals of enterprise can be achieved?
• Does a rule relate to a particular goal?
• How this rule can be decomposed?
• How can the enterprise conform to the specification of the rule?
• How do you validate that a rule is enforced?
• Which process(es) triggers this rule?
• Can this rule be defined in an operational way?
• Can a rule be decomposed into simpler rules?
4.3 Concepts Modelling
4.3.1 Purpose of Concepts Modelling

The Concepts Model is used to strictly define the "things" and "phenomena" one is
talking about in the other models, to define application concepts and data at the
conceptual level. Concepts may be tangible, such as e.g. “car”, or intangible, such
as e.g. “quality”. The Concepts Model must, at least, include components by
which we can describe the contents of the different information sets and flows of
the Business Processes Model. For instance, the goal expression "To maintain and
improve the library’s services", requires a definition in the Concepts Model of the
concept "library service". It is vital that important concepts used in other models
are defined here to avoid the possibility of misunderstandings amongst
participants and stakeholders. Inconsistencies are hence avoided.
A Concepts Model includes components such as concepts, binary relationships
and information attributes. Also, the ISA and PartOF relationships are included
in the Concepts Model to permit generalisation as well as complex component
modelling. The Concepts Model allows also the possibility of defining different
"Concepts Model Component Groups". A group of this type is simply a view of a
part of a Concepts Model, and includes a subset of the Concepts Model's concepts,
relationships and attributes. A group can be a member of another group, etc.
Groups may overlap each other in terms of their components.
The main purpose of the Concepts Model is to serve as a dictionary for reasoning
about “things” and “phenomena” included in the other models. However,
Concepts Models, or more like part of a Concepts Model, can be used for data

base design. In this case, the notation for the Concepts Model proposed here
would most likely be replaced with a more powerful data modelling notation.
Defining a language for the Concepts Model, we have based it on an easy to
understand Conceptual Modelling language. However, the Concepts Model may
also be defined using the more powerful ERT3 modelling language, e.g., where
temporal properties of concepts as well as of relationships can be described. The
choice of modelling language does not affect the modelling process itself. It is
generally possible to begin with the notation we describe in this manual and then,
later on, switch to more advanced concepts modelling language, e.g., ERT. This
might be particularly important when the Concepts Model is used as a
requirements source for a data base design.
4.3.2 Component Types

There exist the following components in the Concepts Model:
• concept is something in the domain of interest and application that we
want to reason about and to characterise and define using relationships to
other concepts.
• attribute is an component type that is only used to characterise concepts
i.e. it is a property of the concept.
Concepts can be related to each other by means of semantic relationships, such as:
binary relationships, generalisation/specialisation (ISA) relationships, and
aggregation (PartOF) relationships.
Binary relationships
A Binary relationship is a semantic relationship between two concepts or within a

concept. The semantics of the relationship is defined by the modeller by naming it.
Binary relationships are inherently bi-directional. Each direction can be given a
name, preferably in the form of a verb phrase. The direction indicated by the
arrow may be called the forward, or primary, direction and the opposite direction
the inverse direction. An example of a binary relationship is given in Figure 21.
The concepts participating in a relationship can be said to play certain roles in the
relationship. In the relationship “Publisher prints Book/Book is_printed_by
Publisher”, the Publisher is the one who prints, while the Book is what is printed
by the Publisher.
3
ERT- Entity-Relationship-Time modelling approach was proposed by the ESPRIT project
TEMPORA

Title
prints BOOK Author
PUBLISHER
ISBN
Figure 21. The concept “Publisher” is related, by binary relationship "prints", to

concept “Book” that has attributes: title, author, and ISBN.
ISA relationships
ISA relationship is a specific kind of semantic relationship between concepts. If

"A" ISA "B", then "B" is the more generic concept and A is the specific concept.
Establishing this kind of relationships is also referred to as generalisation. The
opposite or inverse of generalisation, is called specialisation.
The most significant property of an ISA relationship is that of inheritance. All that
is specified to be true about the generic concept is also true for the specific
concept. That means that all attributes, their values, and constraint (rules) are
inherited from the more generic level concept down to the more specific level
concept as are all relationships in which the more generic level concept
participates.
The sub-types that result from a particular specialisation of a concept can be non-
overlapping. Consider, for instance, the specialisation of Customer into Individual
and Organisation (Figure 22). This states that no single customer can be both an
individual and an organisation at least not at the same time. Such a specification is
called total.

BAD
CUSTOMER
CUSTOMER
INDIVIDUAL
ORGANISATION
PERSON
PRIVATE PUBLIC
COMPANY COMPANY
Figure 22. The concept “Customer” can be specialised in different ways.
There may be a difference in our model between "organisation" customer and

"individual" customer. If we want to say something specific about a bad customer
that does not relate to the general type of customers, we need to introduce a
separate concept for that. This specification is partial, because we are not
specifying other sub-types of customers, that could be good, normal, frequent, etc.
A specialisation is total when all the instances of the generic type are members of
one specific type i.e. when the specialisation is a partition of the generic type.
When the specialisation is partial there are instances of the generic concept (type)
that is not a member of any of the sub-types.
PartOF relationship
PartOF relationship, or an aggregation, is a special form of semantic relationship,

where the interrelated concepts are "strongly and tightly coupled" to each other.
The aggregate concept is an assembly of parts, and the parts are components of the
aggregate. The component concepts are often subordinate to the aggregate
concept.
The most typical example of an aggregation is a part exposition, where the part at
the top level has a number of components, and where each or some of these
components at the next level is seen as aggregates, that in turn have parts.
The PartOF relationship construct is included in the Concepts Model for reasons
of convenience, making it possible to use it whenever he or she feels that it is
natural and rewarding to see and operate on something as part of a hierarchy or a
structure of components.

Concept 47
DOCUMENT
DOCUMENT DOCUMENT
BODY HEAD
CHAPTER APPENDIX
Figure 23. An example of a PartOF relationship structure. The concept

“Document” consists of several parts.
The example in Figure 23 shows that a document is a component structure. It is

defined to have two components, a document head and a document body. The
document body, in turn, has one or more chapters and appendixes as components.
4.3.3 Notation
Cardinality relationships:
Concept:
1:M
<short_name>
0:0
<concept_name
0:1
0:M
1:1 0:0
Attribute:
1:1 0:1
<attribute_name> 0:M 1:M
0:1 1:M
0:1 0:1
1:M 1:M
0:M 0:M
Figure 24. Notation for modelling components and relationships in the Concepts
Model

Generalisation Aggregation
(total): (total):
<concept 1> <concept 1>

Generalisation Aggregation
(partial): (partial):
<concept 2> <concept 3> <concept 2> <concept 3>
Figure 25. Notation for generalisation and aggregation relationships in the

Concepts Model
4.3.4 Example of a Concepts Model

In the library case we can construct a part of Concepts Model that represents some
problems of interest. Relevant concepts to our problem may be the following:
• KTH Library, • Budget,

• ELECTRUM Library, • Library services,
• Paying services, • Customers,
• Books in several copies, • Library catalogue
• Loans, • Waiting line, etc.
These concepts and their relationships are displayed in Figure 26.

Concept 13
has Budget Electronic
State item
Concept 15
Concept 1 Concept 2 Book

in
KTH KTH library
Concept 16
has Concept 12 Concept 14-N Periodical
Copy of Item
Concept 17
o
Concept 6 Document
f
ELECTRUM owns
Library
Concept 7 Concept 18 has Return date
Concept 3 Service Loan
provides
Department or
faculty
receives Concept 19
Catalogue
works_for search
Customer Ordered loan
Concept 4
Concept 11
Bad Concept 21 Concept 23
Academic staff
customer Paying Video
service conferences
studys_in
Concept 5 Concept 9 Concept 10
Non-paying Paying
Student Copying of Purchasing
customer customer
material material
Figure 26. An example of the Library’s Concepts Model.
It is important to understand that in the real world there may be many more
relationships between concepts, but not all of them are relevant and necessary to
present in the Concepts Model. Deciding the relevant concepts and relationships
depends on the modelling scope. For example, in our case in the Concepts Model
of the Library we have not distinguished students and academic staff, or males and
females, since there will be the same service provided for both. While, for
instance, when modelling a hotel reservation system, it should be taken into
account. In real life there are also some relationships between students and
teachers, e.g. teachers give a course for students, students are examined by
teachers, etc., but from the library point of view, such relationships are not
relevant.
4.3.5 Developing the Concepts Model

In the Concepts Model we include components, among others, that represent
information, needed by or produced by processes in the Business Processes
Model. Therefore, if there is a need for some process of the Business Processes
Model, for instance "Search for availability of a book in Library’s Catalogue",
then the Book and its Copy must be included in the Concepts Model, and their
relevant attributes stated.
Note that the inclusion of the information in the Concepts Model does not imply
realisation in a computerised information system. It may be manually produced,
disseminated, and maintained as well.
The library’s catalogue can also be seen as a high-level process of the Business
Processes Model, even if we then perhaps use another name for it, for instance

"Cataloguing of books". This process of the Business Processes Model will then
contain all sub-processes that can be seen as part of the "higher-level process"
Cataloguing of books.
Whether we should include the Library’s catalogue as a component of the Actors
and Resources Model, depends on whether it is involved in any relationship as an
actor or a resource that we wish to document, with respect to components of the
Actors and Resources Model or other models and their components. One such
relationship could be, that we wish later, in the Technical Component and
Requirements Model, to state some information system requirements concerning
the Actors and Resources Model resource, the Library’s catalogue, as a whole.
Above we have exemplified a concept that, with different interpretations and
different uses, can appear in different sub-models. It is important to distinguish
sharply between these different uses and to put components in the appropriate
models at the start, before the models grow too large and confusing.
In the Concepts Model we may use "real entities". Experience has shown,
however, that when performing modelling operations, it may be very illustrative,
and supportive for human understanding, if the Concepts Model can play the role
of a "dictionary of concepts". General concepts like "Profit", "Marketing", "Sales
Effort", "Customer Value", and "Productivity", can sometimes be needed to be
documented, and their relationships discussed. It can happen that these concepts
are introduced in texts of goal statements in the Goals Model, and need further
definition and discussion.
Perhaps it is important to discuss different types of "Productivity" by using
specialisation relations, and to discuss how the components are related to "Profit"
or some specialisation of it. Note, though, that these concepts, if not further
refined as "data", will not appear as information consumed or supplied by
processes in the Business Processes Model.

While modelling concepts there several driving questions that can be used to
facilitate the modelling process:
• Which are the main concepts of this application?
• How are these concepts related?
• Why is this concept needed?
• What do we need to know about the concept in the application? When
and where do we need this (with ref. to the Business Processes Model)?
• How many instances of this concept are there?
• How does an instance of this concept come into existence?
• What makes an instance of this concept come into existence?
• What makes an instance cease to exist?
• How does an instance cease to exist?

• Are the above situations reflected in the Business Processes Model?

• Are attributes of the concept total or partial?
• Are attributes single or multi-valued?
• Is an concept type generically related to some other type?
The need for a temporal language can be ascertained by answering the following
driving questions:
• Is there a need for some historical data about concepts, relationships, or
attributes.
• Is a relationship stable or temporally varying?
• How do concepts vary over time?
• Are there temporal characteristics of the attributes?
4.4 Business Process Modelling
4.4.1 Purpose of Business Processes Modelling

The Business Processes Model is designed for analysing the processes and flows
of information and material in the enterprise. Processes can be decomposed into
sub-processes. Components of the Business Processes Model are primarily
motivated by components of the Goals Model as well as enable goals of the Goals
Model to be achieved.
The Business Processes Model describes the organisational activities, i.e. the
functions and processes of the enterprise. The core of the enterprise is the set of
processes, contributing to the value of the enterprise. For achieving a good
abstraction and overview, the Business Processes Model permits full freedom of
decomposing processes into sub-processes, etc. to any level. Depending on the
purpose of the modelling action, the processes described can be existing, or future,
planned processes. An example of a library business process can be "Management
of loan returns" that can be decomposed into " register loan return" , "check if
book reserved" and "return to bookshelf"
4.4.2 Component Types

The components of the Business Processes Model are:
• process is a collection of activities that:
⇒ consumes input and produces output in terms of
information and/or material,

⇒ is controlled by a set of rules, indicating how to process

the inputs and produce the outputs,
⇒ has a relationship to the Actors and Resources Model, in
terms of the performer of, or responsible for a process,
and
⇒ as an instance of a Business Processes Model is expected
to consume, when initiated, a finite amount of resources
and time.
• external process is a collection of activities that are:
⇒ located outside the scope of the organisational activity
area,
⇒ communicating with processes or activities of the
problem domain area and
⇒ are essential to document.
External processes sometimes can be considered as sources or
terminators for some information or material flows. A typical example of
external process may be customer who requests for certain library service
or receives the service.
• information or material set is a set of information or material sent from
one Process or External Process to another.
The contents of Material and Information flows between processes are
described by referencing them to their definitions in the Concepts Model
where they can be decomposed if necessary. Information or material flow
must have at least one sending Process or External Process and at least
one receiving Process or External Process.

4.4.3 Notation
Process: Control flows:

<short_name> Control flow
<process name>
AND join
External Process:
OR join
<short_name>
<ExtProc name>
OR split
Information or Material set:

<short_name>
<name>
Figure 27. Notation for the Actors and Resources Model
4.4.4 Example of the Business Processes Model

In the Library case we can find a number of processes, such as, receiving
customers' orders, loaning/borrowing books, accounting, etc. All of them can be
decomposed. Figure 28 shows a detailed process model for borrowing books.

Process 1
Inf.Set 1
Order Customer order
acknowledgment for a book
Inf.Set 4 Inf.Set 3 Inf.Set 2

Library accepted
Book catalogue Rejected order
order
Entity 16
Loan Process 2
Ext.process1
Search library's Customer
all copies
refers_to
Inf.Set 5
Ongoing loans Inf.Set 8 Role 2
performs Book is borrowed by
Customer
another customer
Inf.Set 6 Inf.Set 7 performs

Book is Book is not
available available Process 9
Inf.Set 14
Negotiation with
customer Queue
Role 1
Library performs
clerk
Inf.Set 12 Inf.Set 13
Process 11 Customer refuses Customer elects
Register loan wait in queue to wait in queue
transaction
Deliver books to Process 5
customer Update queue
Library response
to customer
Inf.Set 15
Inf.Set 9 Queue
Book checked Inf.Set 11
Book is not acceptance
out to customer
available
Inf.Set 10
Book
Entity 20
refers_to Book
Figure 28. An example of a Business Processes Model
In this example, the book borrowing process is displayed. Roles from the Actors
and Resources Model that perform the particular sub-process are shown. For
example, roles "Library" and "Customer", perform process Negotiation with
Customer. Links between information flows and concepts, indicate the
relationship between Business Processes Model and Concepts Model. Basically
there is no need to show all possible relationships between Business Processes
Model and other sub-models of the Enterprise Model, only the most important
links, to reduce complexity of the model.
4.4.5 Process Decomposition

The higher level processes should be separated from the lower level processes
with a decomposition mechanism. Even if there is no maximum level of
decomposition depth, restraint is urged to avoid unnecessarily complex structures.
The basic principle of decomposition is shown in Figure 29 and Figure 30.

Inf.Set2
Invalid address
Process 32
Inf.Set1
Customer's
Address
address verification
Inf.Set3
Valid address
Figure 29. The process ”Customer’s address verification” is not decomposed.
Process 32
Customer's address verification
Process 32.1
Inf.Set 1.1 Verify street
Inf.Set2
Street No. number
Invalid address
Process 32.2
Inf.Set 1.2 Verify ZIP
ZIP code code
Inf.Set1
Address
Process 32.3
Inf.Set 1.3
City Verify City Inf.Set 3
Valid address
Process 32.4
Inf.Set 1.4
Country Verify Country
Figure 30. A process ”Customer’s address verification” is decomposed into four

sub-processes, each of them performing a different part of the main process.
In this example a decomposition is made of a simple address verification process,

that has one input "Address" and two outputs "Invalid address" or "Valid address"
(Figure 29). In the next figure this process is decomposed into four sub-processes
— verify street, verify ZIP code, verify city name, and verify country (Figure 30).
Each of the sub-processes has its input data flow, since we can consider "Address"
a complex information flow and divide it into several components. All sub-
processes produce the same kind of output decision whether a particular address is
valid or not.
4.4.6 Developing the Business Processes Model

Components of the Business Processes Model must be motivated by the enterprise
goals defined in the Goals Model. Processes of the Business Processes Model are
performed on, or with, information described by components of the Concepts
Model, such as concepts, attributes, and relationships, or Concepts Model
component groups. Components of the Business Processes Model also are closely
related to all components of the Actors and Resources Model. The relationships

between Business Processes Model and Actors and Resources Model can be of
many different types, such as:
• actor A performs process P,
• actor A is_responsible_for process P,
• actor A supports process P or
• and actor A is_a_consultant_to process P.
In general, each Business Processes Model component must, at some
decomposition level, have a relationship defined to the Actors and Resources
Model.
It is important that modellers observe that the Business Processes Model describes
processes of the business area, and not systems or organisational units. In order for
a component to qualify for inclusion in the Business Processes Model, it must
describe a set of possible processes, that all can be perceived to have a start and a
stop time. At higher abstraction levels, this set of processes can be reasonably well
defined. The main distinctions between a process (type) and an Actors and
Resources Model component (actor) are:
• Temporal:
⇒ From that an Actors and Resources Model component is
created, it exists until it is disposed of or excluded from
the environment.
⇒ The Business Processes Model describes types of
processes, of which instances of these exist for a limited
time.
• Instantiation:
⇒ The Actors and Resources Model contains components at
the instance level, e.g. organisational units, individual
resources or human actors, and roles.
⇒ The Business Processes Model describes processes at the
class level.

Some driving questions in Business Process modelling:
• Which are the main processes of the enterprises?
• How are these processes related?
• Why is this process needed?
• Which information and material flows does is it need?
• What information and material flows does it produce?
• Are they represented in the Concepts Model?

• Are situations that "create" or "destroy" these information or material sets

reflected somewhere in the Business Processes Model?
• Which rules trigger this process?
• Which actors are responsible for performing and supporting this process?
4.5 Actors and Resources Modelling

The Actors and Resources Model defines the types of actors and resources, or
individual actors, involved in enterprise activities. ARM describes how different
actors and resources are related to each other and how they are related to
components of the Goals Model, e.g. goals, and to components of the Business
Processes Model, i.e. processes. It describes the existing or future business
system, containing human as well as non-human resources. It allows the inclusion,
as part of requirements engineering, a description of the socio-technical system to
be developed that cannot be done by the Business Processes Model and Concepts
Model by themselves.
By studying the Actors and Resources Model and its relationships to other models,
we can see how different actors exhibit dependencies between themselves, e.g. an
actor may be dependent on a number of other actors with respect to performing a
certain task or process.
4.5.1 Components of Actors and Resources Model

The Actors and Resources Model defines the actors and resources involved in the
enterprise activities, articulated in the Business Processes Model, or actors related
to other models or to the development of the system. Actors and resources can be:
• Individual denotes a person in the enterprise. For example: John Smith,
Anne Dewey, etc. Individuals are identified by their name. However as
names may not be unique they should be used sparingly. Essential
persons with specific skills or roles are included in the Actors and
Resources Model insofar as they clarify in some way and add meaning to
the model and its relationships. Individuals may play roles and belong to
organisational units. For instance, individual “John Smith” plays Role
“library manager” and belongs to an Organisational unit “ELECTRUM
library”. Individuals can, however, be related to other individuals, to
roles, organisational units and non-human resources, by binary semantic
relationships. The ISA and Part-Of relationships are not relevant for
individuals.
• Organisational unit can represent every organisational structure in the
enterprise such as group, department, division, section, project, team,
subsidiary, etc. For example: Planning Department, Technical Team,
Telecommunications Group, Inventory Department, Computing
Subsidiary, etc. Being actors, Organisational units can have sub-units.

They may also play roles and have other actors belonging to them. There
are no predefined inter-sub-model relationships from or to organisational
units to any other non-actor model component of the enterprise model.
Organisational units can, however, be related to other organisational
units, to individuals, roles, and non-human resources by binary semantic
relationships.
• Non-human resources can be types of machines, systems of different
kinds, equipment, etc. For example, “Volvo 850”, “FAX machine”, “MS
Word’97”, are Non-human resources. Being actors, Non-human
resources may have components and may be generalised or specialised.
Non-human resources may also play roles, e.g. Non-human resource
“Volvo 850” plays a Role “people carrier”. Of course, the same Role in a
different situation may be played by the different Non-human resource
“Airbus A300”. Non-human resources may be resources for processes.
They can also be related to other non-human resources, to individuals,
organisational units and roles by binary semantic relationships.
• Roles may be played by the Individuals and Organisational units in
different contexts. An organisational unit may for instance play the roles
of administrator and authoriser in the same context. It may be important
to identify requirements depending on the role they have. For example:
Author, Approver, Controller, Supervisor, Manager, Project Leader,
Process Owner, etc. Are roles are played by individuals, organisational
units or non-human resources. They may belong to one or more
organisational units, and be related to other roles, to individuals,
organisational units and non-human resources by user-named binary
relationships. Roles can be generalised or specialised, and be component
roles. Roles may perform processes and be responsible for performing of
processes and achieving of goals. They may also define goals.
Binary relationships are used for describing different kinds of relationships
between its components. The two main purposes for binary relationships between
Actors and Resources Model components and components of other sub-models
are the defining of:
• responsibility is a relationship between actors, between actors and
business processes, business rules, and goals. Responsibilities can be
delegated or transferred among actors. Responsibilities can be:

⇒ Organisational:- related to the freedom of an actor to make decisions

for other enterprise entities, such as, goals, rules, resources, business
processes, and other actors. Responsibility here also means
accountability for any malfunction, damage, or low performance of
enterprise entities. Organisational responsibilities can be represented
with the following relationships:
∗ actor_defines_goal
∗ actor is_responsible_for goal
∗ actor_defines_rule
∗ actor is_responsible_for rule
∗ actor is_responsible_for resource
∗ actor is_responsible_for business_process
∗ actor_owns_resource
∗ actor monitors another actor
⇒ Operational :- are related mainly to the execution of tasks and they
indicate that an actor is committed to perform a business process or
that a business process is assigned to an actor. We can represent
operational responsibilities with the relationship, "actor performs
process", that means that performer of a task has the responsibility of
properly carrying it out.
• dependency is a relation among enterprise actors. An actor depends on
another for something that can be either a resource or a business process.
Two types of dependency can be identified:
⇒ Operational:- concerns dependencies created by the flow of work.
For example, actors depend on others to get and use a resource that is
needed by the business process they perform, or an actor may wait
for an output from another actor's process, etc.
⇒ Authority:-concerns dependencies created because of organisational
rules, regulations, or relationships of authority and power. For
example, a user needs a password to work in a computer system, a
clerk needs permission to use international telephone lines, etc.
Dependency can be simultaneously of the operational and authority type.
Two specific relationships, are also part of the Actors and Resources Model:
• ISA is used to describe generalisation relationships between roles of the
Actors and Resources Model. The expression "A ISA B" states that
components playing the role B also play the role A, e.g. "Bad customer
ISA Customer". Properties and relationships owned by A are inherited by
B. This means, for instance, that if A is operating process P, then B is
also operating process P.
• PartOF, used as "B PartOF A", states that B is a component of A. We
can imagine that these types of relationships can be useful in modelling
organisational hierarchies, for instance that OrgUnit X PartOF OrgUnit
Y, or expressing component relationships of technical systems, for
instance that "ELECTRUM Library PartOF KTH Library", indicating that

the KTH Main Library includes a component like ELECTRUM library

(both seen as organisational units here).
4.5.2 Notation
Actors and Resources

Model components: Relationships:
<short_name> <relationships name>

<component
name>
Figure 31. The notation for the Actors and Resources Model components.
4.5.3 An example of the Actors and Resources Model

Referring to the library case, we can find amongst others, the following roles and
binary relationships:
• Role Library provides_services_for Role Customer,
• KTH finances ELECTRUM Library,
• Student plays Role Non-paying customer and
• Role Library Clerk works for Electrum Library.

ODiv.1
KTH Main cuts
Library
consists_of
ODiv.2 Capital 1
uses
ELECTRUM ELECTRUM
Library Library Budget
works_for
Role 1 Role 5
Role 2
provides_
Library Bad
service_for Customer
Clerk Customer
Role 3 Role 4
Individual 1 plays
Non-paying Paying
John Smith
Customer Customer
Figure 32: An example of the Library’s Actors and Resources Model
Figure 32 shows only the Actors and Resources Model. However, the components
of Actors and Resources Model also can be related to other models. For instance,
in the Business Processes Model of the Library Case (Figure 28) there are two
roles, Library Clerk and Customer that are performing certain processes.
4.5.4 Developing the Actors and Resources Model

Roles played by units or individuals can also be actors as can non-human
resources of different kinds, for instance hardware or software systems or
components. Links between the Business Processes Model components and the
Actors and Resources Model components describe the kind of relationship that
exists between a particular process and an actor or a resource.

Driving questions for facilitating the modelling process and improving of quality
of the model:
• Which are the main actors of this application?
• How are these actors related?
• Why is this actor needed?

• What is its purpose?

• Is this actor represented in the Concepts Model?
• For which process is this actor responsible?
• Which processes does this actor perform?
• Which goals are defined by this actor?
• Which business rules are defined by this actor?
• For which business rules is this actor responsible?
• Which resources does this actor own?
• For which resource is this actor responsible?
4.6 Technical Components and Requirements

Modelling
What has been elaborated by the Goals Model, Business Rules Model, Concepts
Model, Business Processes Model, and Actors and Resources Model is an initial
description of the enterprise goals, its business rules, its processes, its "system of
actors", and its information entities, such that the business processes can be shown
to contribute to the goals stated. If we wish to develop an information system to
support the processes, then there is a need to deal with technical information
system requirements, initially in a less formal way.
Therefore, the EKD approach includes a simple sub-model to describe, and to
relate to each other, initial, unclear information system requirements. This sub-
model resembles, in structure, the goals model, and, indirectly, information system
models. Initially one needs to develop a set of high level requirements or goals, for
the information system as a whole. Based on these, we attempt to structure the
information system in a number of subsystems, or technical components. For each
subsystem, we have then to define a set of goals that are more specific and
requirements. These goals and requirements have to be derived from, and be
consistent with, the earlier sub-models discussed above. The Technical
Components and Requirements Model is an initial attempt to define the overall
structure and properties of the information system to support the business
activities, as defined in the Business Processes Model. In Figure 10 (Chapter 3)
the relationships between Technical Components and Requirements Model and
other sub-models of the Enterprise Model is shown.
4.6.1 Component of the Technical Components and

Requirements Model
The Technical Component and Requirements Model includes the following types
of components:

• Information System Goal is used for expressing high level goals

regarding the information system and/or subsystems or components. They
may be expressed with measurable or non-measurable properties, aims,
visions, or directions. Information system goals are typically motivated
by activities of the Business Processes Model, and may be motivated by
goals in the Goals Model.
• Information System Problem is used for expressing undesirable states of
the business or of the environment, or problematic facts about current
situation with respect to the information system to be developed.
Information system problems typically hinder information system goals.
• Information System Requirement expresses a requirement for a
particular property of the information system to be designed. The
property can be functional or non-functional. A requirement expression
always refers to components of the Business Processes Model and may
refer to components of the Actors and Resources Model and the Concepts
Model. Information system requirements, may support or hinder
information system functional or non-functional requirements.
⇒ Information System Functional Requirements are used to express
definite requirements regarding a functional property of the
information system or some of its subsystems. Functional
requirements must be clearly defined with reference to the Concepts
Model. Preferably, a formal or at least a semi-formal way of
expressing a requirement may be needed. Every data concept,
referred to in the functional requirement, must be defined as a
component of the Concepts Model. Functional requirements can be
directly supported by information system goals, but they are more
often seen as refinements of the stated information system
requirements. Functional requirements are supported by components
of the other sub-models, in particular the Business Processes Model,
but also the Goals Model. A functional requirement must be related
to a process or a sub-process, defined in the Business Processes
Model.
⇒ Information System Non-Functional Requirements are used for
expressing any kind of requirements, constraints, or restrictions,
other then functional, regarding the information system to be built or
the process of building it. Non-functional requirements are not
always definite and can sometimes be negotiated and relaxed. It may,
for instance, happen that two non-functional requirements cannot
both be satisfied in the same full degree, due to some financial
restrictions. In this case, the level of achievement of these
requirements must be negotiated. Some non-functional requirements
may hinder other non-functional requirements, goals, and
information system problems.
They may support, or be supported by, information system goals and
information system requirements. They can be related to, and be
supported by components of the Goals Model, and processes in the
Business Processes Model. A Non-functional requirement can be

related to a component on the Actors and Resources Model with

relationships "involved_actor".
Relationships between these types of components of the types are supports and
hinders. They are defined and permitted in the same way as for the Goals Model.
4.6.2 Notation
Component: Links:
<coponent text>
hinders
Decomposition:
AND OR
<IS goal 1> <IS goal 1>
<IS goal 2> <IS goal 3> <IS goal 2> <IS goal 3>
Figure 33. The notation for the Technical Components and Requirements Model
components.

4.6.3 Example of the Technical Components and

Requirements Model
Goal 20 Goal 5
supports Register Acquire
To keep the library To achieve high
book book
catalogue regularly precision in all
updated library transactions
OM Process 43
supports Register
supports customer
Goal 23 BPM
Rule 5 BRM To setup a library
Update library information Process 40 Process 45
catalogue as soon system Provide Register
as changes occur
loan transaction
supports
supports supports
IS Goal 1
To maintain all kinds
IS FReq 5 of information within
supports the library
Library IS should use
as much existing IS Goal 5
software as possible To maintain
information about the
most popular and
newly published books
IS Goal 2 IS Goal 3 IS Goal 4

To maintain To maintain
To maintain
information about information about
information about
customer loans and requests and
book resources
transactions customer waiting list
supports
IS Req 1 IS FReq 4
To provide a 24 supports Library catalogue
hours a day library should be exportable
catalogue search on CD ROM
supports supports
IS FReq 2 IS FReq 3
Catalogue search Catalogue search
engine should be engine should
connected to have a WWW
Internet interface
Figure 34. The Technical Components and Requirements Model of the library
case shown in the context of the other sub-models.

The information system requirements can be functional as well as non-functional

(in our current model we assume that an information system requirement can
support a number of functional as well as non-functional requirements.
• A functional requirement refers to a functional property of the
information system:
⇒ to store data about book requests in library",
⇒ to respond to a query "list all publications about high
voltage transmission lines published after 1994".
• A non-functional requirement can be of many different types such as
operating constraints, political constraints, economical constraints,
constraints concerning accuracy of information, security aspects:
⇒ the Library Catalogue Search Engine must be
implemented on the existing XYZ computer system
⇒ the Library accounting Information System should be
based on existing software.
The information system requirements so stated must support the goals and
processes of the enterprise.
The Technical Components and Requirements Model is used as the basis for
modelling the information system as it models technical components of
information system and then relates to these components:
• all the information system goals,
• the information system functional requirements,
• the information system non-functional requirements and
• the information system problems,
This is a good starting point for a design of an information system.
In Figure 34, the information system technical components are related to the
information system goals and requirements. These components should match the
information system functional or non-functional requirements. They are also
related to information system goals and problems.
It allows for a discussion of:
• measurement,
• operations for creating, modifying and deleting objects and relationships,
• for displaying, querying and browsing objects and relationships and
• functionality for checking and analysing data.

IS Goal 1
To maintain all kinds
of information within
IS FReq 5 supports the library
Library IS should use
as much existing IS Goal 5
ELECTRUM Library Information System To maintain
software as possible
information about the
most popular and
Loan Transaction newly published
System books
communicates
To maintain To maintain
To maintain
information about information about
information about
Book cataloging customer loans and requests and
book resources
system transactions customer waiting list
commu-
nicates supports
Catalogue
search IS Req 1
IS FReq 4
system To provide a 24 supports
hours a day library Library catalogue
catalogue search should be exportable
Customers on CD ROM
requests system
supports
supports
IS FReq 2 IS FReq 3
communicates Catalogue search Catalogue search
engine should be engine should have a
Queue connected to Internet WWW interface
registration
system
relates_to
Technical Components Information System Requirements
Figure 35. The relationship between the information system goals and
requirements, and the information system technical components
4.6.4 Developing the Technical Components and

Requirements Model
The Information System Goals and Problems modelling components are of the
same type as Goals Model components. They have similar rules of naming and
defining as Goals Model components. IS Goals, for example, also should start
with “The goal is… “. However, modelling IS requirements, one should remember
that the focus in this sub-model must be on IS requirements and components, and
not to general organisational or business issues. The components of this sub-
model also must be measurable and verifiable, since they form the basis of the
design of the Information System. Expressions like “better than”, “bigger than”,
“the best”, etc. do not normally contribute towards the understanding of a
particular requirement. The components of this sub-model must be closely related
to the components of Business Processes Model, Goals Model, or Business Rules
Model.


The main driving questions in Technical Components and Requirements Model
modelling are:
• Which constraints and standards exist regarding communication with
existing systems or existing hardware?
• Which are the important requirements regarding non-functional
requirements type X where X, can be e.g. security, or availability, or
performance, etc. ?
• Which constraints are there regarding existing software or programming
systems that are to be used?
• Which economic, personnel, political, or other constraints are there?
• Are there legal restrictions to developing the system?
• Can this requirement (or information system Goal, or ...), be refined more
clearly (perhaps decomposed) and in a way that it can be measured or
verified?
4.7 Relationships Between the EKD Sub-models

In previous discussions about the sub-models, we have frequently run into
references, or links, between the different sub-model components. We will briefly
recapitulate the essential links (Figure 36) since the purpose of each sub-model
has already been discussed previously.
In developing a full enterprise model, links between components of the different
sub-models play an essential role. For instance, statements in the Goals Model
allow different concepts to be defined more clearly. This is done in the Concepts
Model, and a link is specified between the corresponding Goals Model component
and the concepts in the Concepts Model. In the same way, goals in the Goals
Model motivate particular processes in the Business Processes Model. The
processes are needed to achieve the goals stated. A link is therefore defined
between an objective and the process to be carried out to achieve it. Links between
models makes knowledge traceable. It is for example, possible to see why certain
processes and information system requirements have been introduced.

uses,
refers_to Goals Model
motivates,
requires motivates, defines,
requires affects, is_responsible_for
defined_by
Concepts Business Rules

Business Rules defines, Actors and
uses,
Model Model
Model is_respon- Resources Model
refers_to
sible_for
triggers
performs, defines
supports is_responsible_for
uses,
Business Process
produces Model
motivates,
requires
refers_to Technical Components and

Requirements Model
Figure 36. Relations between sub-models
According to framework displayed in Figure 36 we define following links

between sub-models of the EM.
• Links between the Goals Model and the Concepts Model are normally
used to explain a component of the Goals Model by pointing, from a
Goals Model component, to one or more components of the Concepts
Model referred to in the description of the Goals Model component. For
instance, the goal "Improve customer satisfaction" would refer to the
concept "Customer" of the Concepts Model.
• Links between the Goals Model and the Business Processes Model
typically relates goals of the Goals Model to processes of the Business
Processes Model with a "motivates" relationship. Example: "Improve
customer satisfaction" could initially motivate a particular, high-level
process in the enterprise, e.g. "Customer Relations Monitoring".
• Link types between the Goals Model and the Actors and Resources
Model can mean several things: they may motivate or require the
introduction of particular new actors, e.g. Customer Relations Agents
(motivated by the goal to improve relationships with customers), or they
may describe which Actors and Resources Model component is
responsible to achieve a particular goal or defines it, etc.
• Links between the Goals Model and the Business Rules Model typically
describe how different components of the Goals Model are implemented
in terms of business rules of the Business Rules Model. For example, the
goal "To record bad customers" stated in Goals Model requires a business

rule in Business Rules Model, that states how exactly it should be

distinguished, e.g. "Customer is reported as bad customer is he/she delays
book for more than 4 weeks".
• Links between the Business Rules Model and the Business Processes
Model typically describes, how processes of Business Processes Model
are triggered by business rules of Business Rules Model. For instance, if
there is a rule that states, "Customer is reported as bad customer is he/she
delays book for more than 4 weeks", then this rule triggers process, that
performs recording customer as Bad Customer.
• Links between the Business Processes Model and the Concepts Model
are typically between Information Sets of the Business Processes Model
and components of the Concepts Model. For instance: the Information
Set "Expected flights" would refer to concepts including attributes and
relationships like Flight, Airline, Pilot, and temporal data about arrivals.
• Links between the Actors and Resources Model and the Business Rules
Model typically describes how different components of the Actors and
Resources Model are related to business rules of the Business Processes
Model. Examples of link names are: defines, is_responsible_for.
• Links between the Business Processes Model and the Actors and
Resources Model typically describes how different components of the
Actors and Resources Model are related to or involved in processes of the
Business Processes Model. Examples of link names are: performs,
is_responsible_for, and supports. For example, actor Library Clerk
performs process Deliver book to customer.
• Links between the Technical Components and Requirements Model
components and the other model components may be more complex than
the normally binary relationships. Most typically, Business Processes
Model components motivate information system goals and information
system requirements. We may have simple binary statements, such as,
"The Library Cataloguing System must be able to handle X requests
simultaneously", but we may also have more complex statements, such
as, "The response time for user of type X, when performing process P, on
data defined as C, must be less than Z seconds".
Model components may thus be linked in a number of ways. Which links that
should be established depends on the purpose of the particular EKD project. Each
produced Enterprise Model has a purpose and focus and the links within each
Enterprise Model should therefore reflect these. Every link represents a statement,
made about the enterprise and possibly its information systems requirements. The
semantics of every such link should be analysed carefully. There is, however, a set
of minimal links that should be defined for the representation to be considered
complete. Figure 37 shows some of the links between sub-models in the Library
case.

Goal 4
Part of a Goals Model Goal 1 Goal 2
To provide advanced hinders
(GM) To minimise
services to library library's operational
customers costs
Opportunity 1 supports
supports
Advanced
communication Goal 4 Role 1
and information supports High stock Librarian
technology Goal 3 Part of an
availability
Deliver items Actors and
electronically
Resources
is_reponsible_for
Model (BPM)
Problem1
Copyright and hinders supports
ownership of Role 2
Electronic
electronic material refers_to is_respon- Service
Rule 1 sible_for assistant
Requests for electronic
material must be
satisfied within 3 days performs
Concept 1 Part of a Business

Library Rules Model (BRM) Ext.Process1
item Customers
Part of a
requests for
Concepts Model
electronic Part of a
(CM) information Business
Processes
Model (BPM)
Magazine Information Book Process1
Management responses to
of electronic requests for
information electronic info.
supports
motivates
IS Goal11
Part of a The Library Information To have a high service
Technical Components Management System rate to requests for
electronic information
and Requirements
Model (TCRM)
supports
The super
intelligent IS Requirement1
information concerns To be able to locate
locator requested information
in 99% of all requests
Figure 37. A fragment of the library case Enterprise Model. This demonstrates
some links between the sub-models.
4.8 Auxiliary modelling components

In previous chapters we have described EM sub-models and their components. In
addition to these “ordinary” modelling components, sometimes it is useful to
extend the Enterprise Model with some additional modelling components. The
reasons to do so may vary. One reason, for instance, is to improve the
expressiveness of the model, or to allow more “freedom” for the modelling team.
This is most often the case in the first modelling sessions, where the most
important task is to generate initial ideas and to get participants familiar with the
modelling process.

The types of modelling components one may add to any sub-model of EM are not
strictly prescribed or defined. The only requirements are, that everybody in the
modelling group accepts and understands the meaning of these, and that the
modelling facilitator, accepts that particular extension of the method as beneficial.
Some of the added auxiliary modelling components can later be reformulated
using the regular component types.
The most common additional modelling components modelers use are the
following:
• comments – usually clarify some of the modelling components, or the
whole model, or they contain some information that the modelling group
found important, though difficult to express in terms of the ordinary
modelling components. Comments may also contain directions for
further elaboration of the model. If comments address some particular
modelling component these are inter-linked by arrows.
• model development actions – used to express concrete actions for
development of a model, or refinement of a particular modelling
component, or a group of components.
• assumptions – used in a similar way to the ordinary modelling
components. We use assumptions to express hypothetical types of facts.
They can be lined to any other modelling component by types of links
such as, motivates, supports, hinders, conflicts, etc. Later, during the
elaboration and refinement phases of the model, assumptions can be
transformed to opportunities, problems, weaknesses, threats, goals,
processes, information system requirements, etc.
• scenarios – used to represent possible alternative series of events,
processes, or issues, etc. which may be than described or elaborated in
the model.
Examples of some auxiliary modelling components are given in Figure 38.
However, these are not the only modelling components that may be included in
the Enterprise Model. Sometimes it is even easier to replace a whole sub-model
with another. For instance, if the notation of the Business Process Model is not
suitable for a particular task, it can be replaced. However, the integrity of the
inter-model links must remain consistent as previously described.

Goal 1
To provide advanced
Goal 2
services to library Comment 1
To minimise
customers hinders This goal needs
library's
more detailed
operational costs
supports elaboration
Opportunity 1
Advanced solves *
communication
and information supports Problem 2
technology Goal 3 Goal 4 Library's budget
Deliver ietms High stock will be cut by 500
requires
electronically availability KSEK within next
3 years
Problem1 supports
Copyright and hinders
Dev.action 1
ownership of supports Constraint 1
Acquire and distribute
electronic material Requests for electronic data about operational
material must be costs of library before
satisfied witin 3 days next modelling session
Assumption 1
We assume that
majority of our
customers has
access to computers
and Internet
Figure 38: A fraction of a Goals Model containing auxiliary modelling

components
Grouping of modelling components
Another type of modelling practice is to arrange modelling components in groups.

This sort of activity is often done in an intermediary modelling session, if there is
a loose structure of modelling components, without relationships between them –
a situation, which arises when a modelling session is too short, or the model is
not complete for any reason.
There may be several categories for grouping modelling components, such as
grouping by contents (e.g. competitiveness problems, production problems),
grouping by priority (e.g. critical business processes, “housekeeping” processes),
grouping by “nature” (e.g. goals for change, goals for the future state of business),
etc. For example, after an initial restructuring of the Goals Model it can include
groups of strategic goals, HRM goals, marketing goals, production goals, etc.
Later, each of these groups can be replaced with a single goal, decomposed into a
separate graph containing sub-goals, which were members of the group, or
connected together in any way. While performing this kind of restructuring, one
should be careful in order not to loose the links between the sub-goals and other
modelling components not belonging to the group, thus to the decomposition
graph.

5. Working with the EKD

approach
5.1 Introduction
Why is this chapter important? The EKD approach is far from being constituted of
only the product, the Enterprise Model and its sub-models, described in chapter 4.
The success of applying the EKD approach depends entirely on the way it is
introduced in the enterprise and the way the development process is conducted.
This chapter attempts to present some guidelines for introducing and using the
approach in an organisation. Even if the approach and its predecessors have been
practically applied for several years, much knowledge is still observed and
developed regarding the application of the approach. The guidelines should
therefore be considered as knowledge under constant evolution and extension.
A large number of experiences in Enterprise Modelling (or Business Modelling)
have been made in Sweden. Most of them are positive: the modelling approach
gives added clarity and rigour to descriptions; the modelling approach improves
learning in an organisation; the modelling approach helps to get changes and
reengineering more easily accepted in an organisation. But it has also been
observed that the approach is difficult to explain, that there is a risk of
”overselling” the approach (leading to almost magic beliefs of what the approach
automatically may help to solve), and that there is a need for a strict engineering
discipline in moving from initial, plastic-based models on the wall, to versions of
improved models using computer aided tools.
This chapter is principally arranged to describe a possible application and
development process of EKD in an organisation. After an initial section on
discussing possible targets of EKD, a typical project outline is described in section
5.3. The following sections deal with different issues of this process.
5.2 Possible targets of EKD

The EKD approach can be applied for many different reasons. Consequently, it
may deliver different outputs and results. We call the desired output from an EKD
process a target. In describing different targets, we refer to the different EM sub-
models as described in chapter 4. Below we illustrate a number of cases.
• A company wishes to develop a strategy for its long-term development of
their human resource capital. This application will initially concentrate
on the Goals Model. What are the company’s long-term goals in general?
Which goals regarding human resources are recognised and how are these

goals related to the company’s long-range goals? Which problems are

experienced and which external threats and constraints do exist, etc. But
this type of analysis may very well also introduce the need for improved
conceptual analysis and modelling of concepts essential for the problem
at hand, e.g. what do we mean by human resource, how can we measure
it, what do we mean by ”competence” and how do we measure it, what
kind of competencies may we need in the future regarding the stated
goals (above)?. This analysis may also bring into account developing a
Business Processes Model. Should we be interested in developing a
future ”system” for developing and maintaining human resources in the
company in the future? New types of positions, roles, and skills may
require developing further the Actors and Resources Model.
• The general question to be addressed may be formulated as ”Does our
current set of information systems satisfy the need for information
support for our long range strategy of our company, and if not, what has
be changed to arrive at a satisfactory solution?”. This question involves,
more or less, all the models described in chapter 4. First, the goals of the
future situation must be analysed. Next, based on this set of goals, the set
of business rules and processes must be examined and redesigned. A new
Actors and Resources Model will most probably be developed. The
current set of information systems must be described and their general
properties given in a Technical Components and Requirements Model
(TCRM1). A model of the future set of needed technical components and
their requirements (TCRM2)must be developed based on documented
goals, rules, processes, concepts, and actors for the future business
system. A comparison between the properties of the current technical
system TCRM1 and requirements of the future set of information systems
(TCRM2) provides here the basis for analysing needs for changes and
further developments. Clearly, in many cases different alternatives of
future information systems may be analysed.
See further Section 1.3 for other EM purposes.
5.3 A typical project outline

In this section, we describe a ”scenario” of a possible EKD project giving a short
notion of various issues and problems.
Introducing the approach to the company
The EKD approach must first be ”sold” to the company. This, of course, requires
that the company management, or the ones responsible for the budget, must
become convinced of the possible positive effects of using it. Other employees of
the company, relevant to the project, must be convinced, if possible, that the EKD
process will not threaten their jobs, positions, or ”pet methods”. EKD applications
will cost time and human resources. It is only reasonable to understand that people
are in general, careful in accepting a new way of working, considering the

hundreds offered to them by consulting firms. In this initial stage, it is often

helpful to refer to other companies using EKD.
Setting the scope and focus of the project
An EKD project must have a well-defined mission and well-defined expectations

of results. The purpose of the project must be clear to all involved.
Obtaining company support and resources - getting acceptance
An EKD project cannot, similar to other projects, be successfully executed

without sufficient resources and authority. Persons involved must be explicitly
given time to participate. Computing and other resources must be allocated.
Persons and roles in a modelling project
An EKD project typically involves a number of different types of ”actors” such as

the project manager, the steering committee, the reference group, the (domain
experts) modelling participants (typically 5-8 people), the modelling facilitators,
the modelling technicians, and others. However, not all of these may be needed in
a smaller project.
Selecting members of the project team
Try to compose the group broadly to cover different aspect of the problem at hand.
See further Section 1.7.1.
Getting acquainted with project members
It is advised not to start the first modelling session without first meeting different
members of the modelling group individually. The meeting can preferably be
conducted as an ”interview”. The interviewers should (at least) be the project
manger and the modelling facilitators. The interview normally gives an improved
(mutual) understanding of what should (or could) be done in the first modelling
seminar.
Preparing for the first modelling session
Based on performed interviews, the project manger and the modelling

facilitator(s) together with other members of the technical team, must prepare a
plan of action for the first modelling seminar. This plan should include the major
questions to be posed to the group as well as an analysis of possible results and
how to structure them. Possible obstacles and conflict should be analysed.
The first modelling session
The first seminar is typically carried out using a large plastic sheet on the wall
where participants post their descriptions of different components of the models

used, such as goals, problems, and opportunities. The first session is normally
started with a short introduction to the EKD sub-models and how the modelling
process will proceed. Guidelines are given on how to formulate goals, problems,
etc. The first seminar should not take less than 3-4 hours. The result of this
seminar is normally a less well-structured graph covering some of the EKD sub-
models.
Working with the result of the first session: critique, detail and precision
The modelling technicians' role is first to transport the model on the plastic sheet
to a computerised model. Next, the model is analysed and restructured. Redundant
statements are eliminated, components strongly related are brought (physically)
close to each other. Descriptions as well as proposed relationships are critically
analysed. Components are generalised as well specialised (detailed). Questions
and critical comments are documented.
Consulting modelling participants
After refining the model, the technicians are forced to consult the modelling
participants using the questions and critical remarks from the previous step.
Possible changes and extension to the model are discussed with the participants.
Improving overview and presentation of the model
Discussion of the previous step gives information how to improve the model. This
is technically done by the modelling technicians. It is at this stage also necessary
to develop a (typically hierarchical) description of the model at this stage to make
it more easy to perceive by modelling participants and by other involved people.
The ”walk-through” modelling session: using computer support
The new version of the model, including overview information (text, bullet lists,
and aggregated graphs) does now exist in computer form. The walk-through
seminar must then take place in a laboratory equipped with sufficient means to
expose the result to a group of persons. In our case, we advocate the use of a back-
projection screen and a suitable projector. The screen size in our laboratory is 2 x
1,5 meters (a better resolution can be obtained by using 4 projectors and a
somewhat larger screen size). The task of the ”walk-through facilitator” is now to
expose the results obtained so far to the modelling group, and to invite them to
critical and constructive comments and suggestions for changes. All comments
and suggestions are documented.
Continued work on modelling and implementation in the organisation.
Work based on the two modelling seminars above normally does not result in a
sufficiently complete nor ”correct” model. Additional analyses and restructuring
work and additional ”walk-throughs” are necessary to achieve a useful result.
Continued work, therefore, typically proceeds as iterations including the work

between the first seminar and the walk-through seminar, including it. The
”stopping rule” is a set of models, described in sufficient detail so they can be
used as a basis for continued work of implementing the suggestions in the models.
5.4 Preconditions for setting up the first project

In this section, we summarise a set of preconditions for starting up an EKD
application project. The following considerations should be made:
• The modelling team is given are clearly stated mission to pursue.
• Sufficient time and resources are allocated to the activity.
• The composition of the modelling group is such, that it collectively has
knowledge spanning all the necessary fields such as, business strategies,
objectives and goals, computing, software, information systems,
management, operational issues, etc.
• The modelling group has the authority to redesign the organisation.
• Responsibilities must be assigned regarding the documentation, use and
maintenance of the Enterprise Model to be developed.
• The modelling activity is well planned, with regard to:
⇒ the issues to be discussed,
⇒ participants to be involved,
⇒ task allocation,
⇒ participants being allocated in time,
⇒ expectations to be fulfilled,
⇒ the participants having been given some training in the
use of Enterprise modelling prior to beginning the
modelling session and
⇒ that an experienced facilitator is used.
5.5 Establishing the directives for the project

The management as well as the participants in the modelling process must fully
understand and agree upon all aspects of the project. The purpose, objectives, and
scope of the project must be documented. Resource allocation (personnel,
responsibility, time, money, computing resources) must be determined. Quality
assurance in terms of results, milestones and validation must be maintained and
recorded.

5.6 Establishing the project organisation

Performing a modelling project involves and needs different kinds of skills.
Currently we envision the following types of skills and roles:
• The project manager, coming from the customer organisation will be
responsible for:
⇒ planning the project,
⇒ leading the project, and
⇒ reporting to management and to the steering committee.
• The steering committee will typically be responsible for:
⇒ supporting and ”selling” the project within the
organisation
⇒ the workplan,
⇒ resource allocation,
⇒ quality control and
⇒ evaluation.
• The reference group, typically populated with domain experts and other
stakeholders of the project, is responsible for:
⇒ supplying domain knowledge expertise and information,
and
⇒ examining and evaluating the results.
• The modelling group (modelling participants)
⇒ actively participates in the sessions,
⇒ assists the facilitators with structuring and describing the
models and,
⇒ is chosen so that:
• there are persons from various parts of the
enterprise enabling the broadest range of
knowledge and views to be available,
• the group has adequate domain knowledge,
• the group has the necessary authority to
suggest organisational change and
• the group comprises of enthusiastic, open-
minded and co-operative people.
• The facilitator(s), one or two people who,
⇒ lead and advise during modelling sessions,

⇒ support each other in acquiring knowledge and ideas

from the modelling group
The facilitators may be recruited from outside the organisation. It is also important
to note that facilitation a ”plastic-on-the-wall” session is entirely different from
facilitating a session based on back-projection screens and computer aided
representation of models.
• A Tool ”Equilibrist” is a person who masters the computer support
sufficiently well to assist the walk-through facilitator in the work of
guiding modelling participants through a computer-based model.
• The project also needs a Tool Expert, responsible for modelling tool
development and/or adaptation.
• A ”Story Teller” and presenter is needed to give modelling participants
effective introductions to the main issues presented in a model.
• Visualisers are skilled in illustrating essential results from modelling
sessions.
• Documenters and Analysts are responsible for structuring, criticising,
and documenting the results of the modelling sessions.
• Communication Specialists are responsible for developing or adapting
techniques and tools for synchronous as well as asynchronous work in
distributed environments for individuals as well as for groups.
Clearly, several of these skills may be executed by one person.
5.7 Preparing for the first modelling seminar

The first modelling seminar simply must not fail. There is no chance to come
back for a second try after a failure. Preparing the first seminar is therefore of
utmost importance.
If the project is accepted by management and the necessary preconditions are met,
a number of issues must be dealt with in the preparation stage. This is outlined
below.
5.7.1 Selecting the right domain experts to participate in

the seminar.
Domain experts should be familiar with the problem assigned to the project.
Sometimes it may be beneficial to have both the ”producer” and the ”consumer”
side represented to broaden the view. In some stages of the project, it may be
necessary to associate specialists in certain areas to the project. These specialists
may have the role to suggest organisational or IT-solutions to satisfy specific goals
stated (e.g. reengineering of some business processes, or development of some
types of IT-solutions).

Having the right people is directly affected by what type of approach is to be used
when applying EKD. When using a so-called ”top-down” approach, where
rationale is to be discussed, goals modelling is usually the starting point. This
requires that the participants are those who are directly involved in, or have
knowledge of, decision-making and goal formulation at the pertinent level of the
organisation, whether it be operational or strategic. On the other hand, a bottom-
up approach, typically used when a restructuring process is to be carried out,
begins with process modelling and may require non-managerial personnel to
describe and document organisational processes. In all situations though, it maybe
necessary to change members of a group as the discussions and models move from
one area to another and so require people with different knowledge.
5.7.2 The purpose of interviewing of domain experts

The aim of the modelling seminar is to arrive at collective consensus-oriented
decisions. This will be enhanced with adequate preparation. The facilitator should
interview the participants to:
• Prepare and become familiar with each participant
• Gain knowledge of the problem domain and essential issues to addressed
within it
• Collect information to enable the setting of driving questions
• Collect information that will improve the facilitators' ability to conduct
the modelling seminars, e.g. by giving directives what issues to
concentrate upon, by suggesting certain structure of the information
developed in a seminar, etc.
• Prepare her/himself to handle possible conflicts and/or lack of ”balance”
(created by a dominant participant) in the modelling seminar.
5.7.3 Possible interview questions

Interviews are carried out when the general objectives of the project are set. This
means also that the general subject area of concern is stated. The interview should
focus on the interviewee’s visions, goals, assumptions, experienced problems and
perceived constraints of the subject area.
Below we suggest a sample of interview questions assuming a company named
COMP, a division of the company named DIV, and a particular function of DIV
named F. It is here assumed that the purpose of the project is to analyse F and
suggest different possible improvements.
After an initial round of mutual presentations of the participants of the interview,
the following questions could be considered:
• How would you describe the function F, its role and current activities
within DIV and within COMP?

• Describe some, in your opinion, important issues within F to be

addressed in the next 3-5 years.
• Describe some problems currently experienced by DIV with the function
F.
• Give some long range as well as short range goals of the function F.
• What makes F a necessary function within DIV?
• What are, in your opinion, the current strengths and weaknesses of
function F?
• Which opportunities exist in the area of F?
• Which external constraints would you like to mention regarding F?
• Which external trends may influence the operation of F? How?
• Which management should be particularly concerned with the operation
of F?
• Which important decisions, with long-range consequences, will we have
to make within a year regarding F?
• Do you see any problems in carrying out these decisions?
• Etc.
5.7.4 How to use and take advantage of the interviews

The interviews give the project management and the facilitators an improved view
of the persons who will participate in the modelling sessions and of their visions,
problems, hopes, prejudices, and fears. This gives the facilitator a possibility to
plan how to start the modelling session, how to conduct it, and how to handle
possible upcoming situations. The interviews may give some hints on organising
the first modelling session depending on situations and opinions revealed in the
interviews.
5.8 The First Modelling Seminar

In general can we say that the first modelling seminar should be organised in such
a way as to promote concentrated work. This may be achieved by convening in a
special location not usually used by the participants or even a premise not
associated with the company. Such a choice of location may provide a more
relaxing atmosphere, making interruptions unlikely.
Apart from 5-10 participants, only a limited number of others should be present:
• One or two facilitators. The number depends on the perceived complexity
of the issues to be discussed as the number of participants.

• The EKD project leader as an observer who needs an overall knowledge

of all the EKD work
• A secretary as an observer:
⇒ To take care of the practicalities of the plastic sheet etc.
⇒ To document and evaluate the process of the modelling
session.
5.8.1 Setting up the Seminar Room

The room must contain at least one large (3m x 2m) wall clear of all decoration, to
attach a plastic sheet on. There should be precisely enough chairs and tables for
the participants. It should be large enough so that noebody could “hide” or make
himself or herself unavailable. There should not be any distractions such as
refreshments, telephones, etc.
Equipment
• At least one plastic sheet
⇒ Thick,
⇒ Two meters wide, on a roll.
• Pens
⇒ Non-permanent to enable erasure from plastic sheet.
⇒ Medium point.
⇒ At least one for each participant.
• Paper
⇒ Pre-printed with components' names
⇒ Each component type has a different colour to enable
easy identification.
⇒ An A4 page cut into four quarters gives a satisfactory
size.
• Wet rag
⇒ To wipe off pen drawings from the plastic sheet
• Adhesive putty
⇒ Two small blobs attached to the back of each piece of
paper ensures that these stay attached to the plastic sheet
when required while allowing them to be easily
transferred.
• Scissors
• An overhead projection machine

5.8.2 Making an introduction to the participants

A short introduction is to be given of each of the following:
• All those present
• EKD in principle
• The day’s agenda
• The topic(s) for discussion
• The ground rules for modelling-These are necessary since these are not
self-evident and are necessary for maximal productivity. They explain the
accepted social interactions and means of furthering creativity:
⇒ Everybody participates-no spectators
⇒ Everybody contributes constructively-differentiate
between person and subject matter
⇒ Everything of importance is written down-talk
disappears, the plastic sheet counts
⇒ Preferably over-explicit than implied
⇒ Preferably half-done hear and now than completely
brilliant next week
⇒ Write complete sentences rather than keywords
⇒ Listen to each other and think individually
⇒ Build further on each others thoughts
⇒ Strive for balance and consensus in the result
⇒ Search after missing threads of thought
5.8.3 Stimulating and Structuring the Modelling Activity

The goal of EKD is, of course, not the Enterprise Model as such. The Enterprise
Model is just a description and representation technique. To obtain an improved
understanding, to solve problems and to develop the enterprise, we should be
directed by a critical and analytical study of the Enterprise Model and its internal
relationships, based on good understanding of the principles of enterprise
modelling as they have been presented so far. This may be achieved, to some
extent, with the aid of driving questions shown in the sequel.
Driving questions
One could ask the following types of chain of questions about relationships:
• Is each goal supported by a process in the Processes Model? If not, why
not?
• Should we then introduce such a process?

• Who in the Actors and Resources Model should be responsible for this
process?
• Are they already responsible for a similar process or is there someone
else?
• Should we invest in a new resource to help us run this process?
• Does this resource need a new or improved information system?
• Can we identify in the technical and requirements model, the
requirements for the information system?
• Do there exist business rules that may put constraints on the
requirements?
• Do we have a common enterprise definition of what these constraints and
requirements mean, in the Concepts Model?
Analysis questions
By searching for relationships and inconsistencies, and discovering gaps, we can

increase our knowledge and understanding of the enterprise. The search for
knowledge must be made on an individual and group basis in the context of the
situation given the particular intentions of the participants. EKD will help you in
the right direction, by giving you the graphical, structured representation
technique in the form of the Enterprise Model, making the cognitive process of
analysis easier. Hence, the lists of driving questions mentioned in previous
sections are not complete, but only examples that should be further expanded
when applicable.
What to avoid
There are many pitfalls when one is involved in the communication of ideas
between humans, which is what we are dealing with. In the specific case of EKD
these include:
• Avoid beginning modelling with long explanations of abstract concepts.
• Begin with well-known practical or physical activities, processes or
goals.
• Avoid having unstructured models.
• Conduct restructuring and clarification activities as soon as possible after
the modelling session, otherwise a lot the information inherent in the
unstructured model will be forgotten.
• Avoid having few-worded descriptions that are not intuitively
understood.
• State descriptions carefully so that they can be easily understood later.
• Do not have goals that do not contribute to the overall objectives of the
enterprise.

• All goals must be connected so that they contribute to each other. No

loose ends should exist.
• Avoid composite statements that have many in and out relationships so
that they do not allow for easy understanding and analysis.
• Try to break down statements to the last point at which they are relevant
to the issues at hand, while structures should be compiled.
• Avoid detailing attributes before an overall context is established.
• Not all attributes are relevant.
• Do not verbalise what is apparent in the model.
• Avoid having concepts that you are unsure why you have them.
• When choosing particular words, confusion and missing concepts may be
avoided by creating new words.
• Etc.
5.8.4 Structuring and analysing results of the first seminar
Typical state of the first model.
The first session is often mainly a brainstorming activity. Hence the state of the
model is such that:
• It is lacking a structure, so that it is difficult to get an overall picture.
• There are redundant components, for example, there maybe two goals
that say the same thing.
• There may be missing components
• Relationships are lacking showing how components are connected to
each other
• The terminology written by participants maybe ambiguous.
What do we want to achieve?
As is usually the case when one is engaged in brainstorming, the majority of the
work comes in its aftermath. The overall objective of structuring and analysing the
results of the first session is to “make sense of the mess”. It is to systematically go
through all the models, components and relationships and make them presentable
as a basis for further deliberation by the participants in the following session. That
is by clarification, abstraction, structure, simplification, derivation, deduction and
induction.
The analysts’ task is not to provide answers but to ask the right questions, based
on a clear and consistent picture of the knowledge presented by the participants. In

such a way, the participants themselves are assisted in understanding,

communicating and finding solutions.
Ways of improving the first model
To achieve progress:
• Relationships are introduced
The models are given their meaning by drawing the relationships between
ALL the components. Implicit, undesirable or overlapping relationships
may be discovered and adjusted. Missing components may be discovered
due to that they may have been only implied. Since the analysts may not
have the requisite knowledge, it may be necessary to consult with
stakeholders to get a better understanding of the relationships.
• A systematic classification needs to be created
The creation of a structure depends on:
1. The criteria used for making a structure.
These may be levels of, priority, complexity, abstraction, functionality
or domains or a combination of any of these. The EKD approach does
not currently mandate a specific technique, as this is not essential due
to the wide range of uses of EKD. Presently however most research on
structure has focused on Goals Modelling.
2. The availability and use of a computer tool
An integrated computer tool for Enterprise Modelling is currently
being developed. In the mean time, ABC FlowCharter4 is being used.
While it does not support integration and consistency between sub-
models, it is adequate as an advanced drawing tool with potential for
programming advanced applications.
• The model is simplified to ease understanding
The objective of having models is that they should give insights into
issues by allowing complexity to be graphical and manageable. If a
stakeholder cannot glance at a model and get a reasonable understanding,
so has the model defeated its purpose. There are no strict guidelines here
but a few common-sense tips. Where the number of components is
relatively large, can the analyst group components and abstract the groups
to a higher level, hence producing a model with fewer components that
can be delved into where necessary.
• Terminology is clarified
Often, participants make assumptions concerning their knowledge in
their eagerness to make themselves heard. Concepts, terms and
abbreviations that may seem self-evident are not always so for others.
Clarification by participants may be required.
4
ABC FlowCharter is a registered trademark of Micrografx Corporation

The role and responsibility of the modelling group
The analysts may, due to reasons previously mentioned, need to receive

clarification of what was documented in the modelling session from the
participants. It is however, undesirable to enter a polemical discussion concerning
addition or deletion of anything that another individual has presented.
Constructing a model and a description aimed for presentation and

understanding
To present the work discussed in this section to the modelling group requires
careful planning. The group must be able to trace the results of their efforts, from
the original plastic sheet model through the analysis stage to models presented at
the next stage. They must be able to recognise what they have done. A description
must acknowledge and give credit to the first session by a verbal description of the
results. EKD is a participant-led approach so that the analyst must try not to
“overanalyse” or “overinterpret” so that the group, when confronted with new
descriptions and models restructured does not say, “we did not say that” or “we
did not mean that”.
All the participants should be sent copies of all the documentation from the first
session to enable them to study the material and reflect on its contents as an
introduction to the next session.
5.9 The ”Walk-through” Seminar

At the walkthrough seminar, the analysts present to the modelling group the work
done since the first session, rationale behind the work and continue modelling in
new directions. The seminar should aim to achieve all the following:
• Review the work from the first session
• Make corrections and/or additions to the models and descriptions
• Narrow the field of discussion and specify the domain
• Create new models
• Expand previous models
• Allocate assignments to participants
• Suggest further work and future directions
The different stages of the seminar may mean that two separate groups of
facilitators/analysts need to lead the discussions:
1. The initial review stage should be lead by the analysts who have worked
with the original models and brought about its current state.
2. The second modelling stage should be led by the facilitators who led the
first modelling session to ensure continuity

5.9.1 The Presentation

Seminar one should be presented precisely as it was. At this stage, the plastic
sheet models have been replaced by computerised tools. Since it is impractical for
6-8 people to gather around a normal sized computer screen, a large wall sized
screen with back projection is recommended. As well as the computerised
presentation equipment required, all the equipment necessary for modelling as
mentioned in section is also needed. This may entail the use of a larger room or
possibly two rooms for projection and for modelling.
A large screen allows all the participants to view computer models. In theory,
continued modelling directly on the screen together with a tool equilibrist is
possible. However, this is not advised as the focus of the group may move from
the issues to be discussed to technical finesses of the screen and program.
The presentation is a balancing act. One the one hand, the analysts must actually
do an analysis, while at the same time not discarding the group work that has
been. When interpretation, changes or deletion is done, it must be explained and
justified. This of course is to ensure that the group will continue to be motivated
to contribute. Otherwise, credibility of the analysts and eventually the models is
lost.
The results of the first walkthrough should be a refinement of the issues being
discussed. An initial inventory may have been begun. It is however unlikely that
one seminar is sufficient. For following seminars, individuals or working groups
within the modelling group should be given assignments where they could
investigate alternate solutions. This will ensure that they will not lose interest or
contact with the process. It is also a way of ensuring a participant-led
development.
5.10 The Responsibility of the Modelling Group -

Need for Domain Experts
The analysts seldom have the requisite domain knowledge to fully understand all
the intricacies of the organisation. Rather than trying to gain huge amounts of
knowledge, some of it implicit and informal, we suggest another solution. An
employee of the organisation should be co-opted into the analyst group. This
employee will provide organisational knowledge or will know where it may be
found. Simultaneously this employee will become an important resource by
gaining knowledge of Enterprise Modelling and EKD, which will be useful where
the organisation desires to continue work with modelling and analysis.

6. The Quality of The Enterprise

Model
In this chapter, we discuss further, quality aspects of an Enterprise Model. We
have mentioned some quality aspects when talking about driving questions of a
particular sub-model, or about correct or unambiguous expressing of modelling
components. Here we will summarise these guidelines and will give some criteria
that may be useful when constructing and analysing the Enterprise Model. It
should be noted that this section is only an initial attempt to capture some rules
and guidelines, found useful in field studies and experiments. It will be elaborated
in the future.
Some valuable characteristics of a good Enterprise Model are it is:
• unambiguous,
• complete,
• verifiable,
• consistent,
• modifiable,
• traceable and
• useable during the operations and maintenance phase.
For the assessment of an Enterprise Model, there must be a way to characterise its
level of quality at various stages of development. Enterprise Models can be
developed by transforming written user and customer statements into structured
but incomplete models, or by arranging group sessions where initial versions of
such models are developed. Enterprise Models can thus be very sketchy, or rather
complete, so that they can be used as a basis for further development of a formal
information system model. We can at least identify the following levels of quality
in Enterprise Models.
Initial level
The representational dimension:

• Statements made in the model components are not verified.
• Models are not "connected", there are loose components and inter-model
links are not complete.
• The level of precision in the model component statements is low, mere
precise refinement of components is not made.
• The model is not useful for further elaboration by information system
modelling.
The semantic dimension:

• The models (their components and relationships) are vague, hard to

improve without complete rework.
• The meaning of the various components is ambiguous.
• It is doubtful whether the right model component types are used for
representing domain statements.
• The focus of the models does not reflect the modelling goals.
• Concepts Model intra-model links are not validated.
• The model is not, without elaboration, adequate to be used as an
instrument for application or enterprise planning.
• The model is not semantically useful or semantically clear for further
elaboration by Concepts system modelling.
• The degree of completion is difficult to judge.
The social dimension:
• It is not clear whether the participants agree amongst themselves about
the "meaning" of the components the way they are described.
the "importance" of components the way they are described.
the "relevance" of components the way they are described.
The refined level
The representation dimension:

• The model follows all model "rules" defined in this Reference Manual.
• The statements in the model components are properly discussed and
checked.
• Models are "connected", there are no loose components and inter-model
links are complete.
• The model is useful for further elaboration by an eventual modelling of
an information system.
The semantic dimension:
• The meaning of the various components is unambiguous and clear.
• The right model component types are used for representing domain
statements.
• The focuses of the models reflect the modelling goals.
• Intra-model links are validated.
• The model is adequate as an instrument for enterprise planning.
• The model is semantically useful or semantically correct for further
elaboration by an eventual modelling of an information system.
The social dimension:
• Participants agree amongst themselves on the meaning of components the
way they are described.
• Participants agree amongst themselves about the relevance of
components the way they are described.

• Participants agree amongst themselves about the importance of

components the way they are described.
Above we have given two levels of Enterprise Model quality. Now let us discuss
some aspects that can lead to improvement of the quality. These are mainly
expressed as what should be done or avoided to achieve a better Enterprise Model.
There are a number of ways that Enterprise Models can be developed to achieve
the level stated above. We will discuss them in several categories.
Expression of modelling components
We have been already talking about the way of expressing the modelling
components. A good rule of thumb is that, for example, goals in Goals Model
should be always as a full sentence beginning with "The goal is..." or "The
objective is...". As an example, the objective "Extra money" is not a full sentence
and may be interpreted in different ways, and should be expressed as " The
objective is to have an external finance source of 500 SEK in next 3 years" if that
is what is intended. Generally, there is a rule that every modelling component
should be expressed precisely to avoid misinterpretation and hence unnecessary
changes afterwards.
If the modelling group has difficulties in clearly formulating a modelling concept,
it may be caused by the insufficient competence of the domain. In such situations,
there is a temptation to defer a resolution with, “we’ll fix it later” or “we know
what we mean with this”. For example, there may occur a need to purchase some
kind of equipment, but the team is not sure exactly what. If they leave in their
model just a remark like "Buy stuff", later it can be almost impossible to restore
what was meant with this. It may be valuable immediately to rephrase in "To buy
equipment that allows to perform process X by 50% faster than previous".
Representing sub-models graphically
The quality of the graphical representation of the Enterprise Model, is partially

dependent on the software support for the modelling method. However, whatever
the software is it is difficult to work with large and highly interconnected models.
In such a case, the chances of obtaining representational quality, ease of
understanding and a "good" model are minimal. The least we can do is not to
make the models unnecessarily complicated. We can point out few aspects that
can help:
• Crossing of arrows always makes drawing more complex and less easy to
overlook. The same can be said about long curved arrows.
• Unnecessary duplication of a modelling component within the same
model can cause difficulties in understanding.
• Large models must be decomposed in smaller pictures each of them
showing some important aspect of organisation. An overall picture
should exist somewhere that shows how these smaller pictures stick
together. The purpose of each picture also should be described clearly.

• If the Enterprise Model is getting complex, it may be useful to produce

from time to time a textual report that describes all modelling
components, their relationships with each other and attributes. In such
reports it is easier to pay attention to attributes, that are not shown in the
graphical representation, such as, trust level, criticality, priority, creator,
creation/editing date, etc.
In practice it may be almost impossible to construct a model with no crossing
arrows or no single component duplicated. There should however be a "balance"
between following such rules that lead to improvement of representational quality
and achieving the goals of the modelling itself. It is unnecessary to spend too
much precious modelling time thinking about how to connect two goals without
crossing a single arrow. If necessary, this can be done later by analysts or technical
staff. However, these people are also changing often. Otherwise, the modelling
group will have to recreate the model.
Model stability and flexibility
A model should be built in such a way that minor changes in the domain area do
not force major changes in the model. In other words, it should be possible to add
or remove some elements from model without major changes or restructuring the
rest of model. One way how to improve stability of a model is to define more
specific and detailed modelling objects. Then if later, one model has to be
expanded, chances are good that it will be necessary to only change the new things
and not the existing ones. For example, in the Concepts Model the same facts can
be represented in two ways (Figure 39 and Figure 40)
Customer borrows Book
Figure 39: An unstable Concepts Model
Customer Book
receives of

Service Loan of Copy
Figure 40: A stable Concepts Model
At a first glance, it may seem unnecessary to introduce three additional concepts:

Service, Loan, and Copy. However, in the case where it is required that one stores

the return date of the loan or price for the provided service, etc., such attributes are
helpful.
Focus of the Enterprise Model
When modelling, it is essential to keep in mind that one should include only those
aspects of the enterprise that are relevant to the issues to be discussed. For
example, there is no need to think about what colour pencils should be in each of
the company’s departments during managerial restructuring. When using the
enterprise model as a basis for obtaining requirements for an information system,
it is important, to avoid concentrating to much on actual implementation issues,
such as data representation, physical data organisation, message formats, etc.
Along with what was stated above, there are some other useful rules in enterprise
modelling:
• Graphs of each sub-model should be connected internally and between
each other. Normally there exist in enterprises, relations between goals,
processes, actors, concepts, etc., these relations should also be
represented in the Enterprise Model.
There must exist at least one goal in the goal model, one process, one
external process, one information/material set in business process model,
one concept in concepts model, and one actor in actors and resources
model. This rule may seem "academic", but it is important to emphasise
that this is the idea of EKD. In every organisation, there exists at least
one goal that defines at least why this enterprise exists, at least one
process motivated by this goal. Since it interacts with the environment
around it, there should be some influence from it and hence at least one
external process is needed. This influence should be defined in our model
somehow and we need at least one concept in concepts model and
information or material set in business process model for that.
The trust level of the entire EKD sub-model should not be higher than the
lowest trust level of the components. In the Goals Model, there should be
the least number as possible of, weak supports or hinders relationships,
low trust level, low criticality components. The existence of these often
indicates that these particular components were not agreed upon
completely by whole modelling team, and they do not give a good
guidance for information system design.
A Cause in Goals Model should always be linked to another Cause or to a
Problem. A Problem should always be linked to another Problem or to
Goals in Goals Model.
• A concept in the Concepts Model must not be a sub-type (specialisation
by using ISA relationships) or component (specialisation by PartOF
relationships) of itself. Specialisation with only one sub-type defined
must not be a total specialisation.
• Every Information or Material Set in the Business Processes Model must
be related to a concept in the Concepts Model. Every Process must be
motivated by at least one goal from Goals Model in some decomposition

level, and must be related to at least one Actors and Resources Model
role, which is responsible for that process.

7. References
[Astrakan01] “Högre kurs i modelleringsledning” (In Swedish), Course
notes Version 1.1, Astrakan Strategisk Utbildning AB,
Stockholm, Sweden, 2001.
[Bergquist99] Bergquist, S, Eide. H., “Team Games –snabbaste vägen mot
högpresterande arbetsprocesser” (in Swedish), Frontec AB,
Sweden, 1999.
[Bub92] Bubenko jr., J. A., “On the evolution of information systems
modelling - a Scandinavian perspective”, SYSLAB Report No.
92-023-DSV, SYSLAB, Department of Systems and Computer
Science, Royal Institute of Technology, Kista, Sweden, 1992.
[Dob94] Dobson, J., Blyth and Strens, R., “Organisational
Requirements Definition for Information Technology” ADB
International Conference on Requirements Engineering, ACM
(ed.), Denver, USA, 1994.
[EKD98] Bubenko jr., J., Brash, D., and Stirna, J., “EKD User User
Guide”, ESPRIT Programme 7.1 project no. 22927, Electrical
Knowledge for Transforming Applications, Royal Institute for
Technology, Stockholm, 1998.
[F394] F3 Consortium, “F3 Reference Manual”, ESPRIT III Project
6612, 1994.
[F395] F3 Consortium, “Requirements Engineering Handbook”,
ESPRIT III Project 6612, 1995.
[Fox93] Fox, M. S., Chionglo, J. F. and Fadel, F. G., “A common-sense
model of the enterprise”, Proceedings of the 2nd Industrial
Engineering Research Conference, pp. 425-429,
[Lang68] Langefors, B., “System för företagsstyrning” (in Swedish),
Studentlitteratur, Lund, Sweden, 1968.
[Louc97] Loucopoulos P., Kavakli V., Prekas N., Rolland C., Grosz G.,
Nurcan S., “Using the EKD Approach: The Modelling
Component”, UMIST, Manchester, UK, 1997.
[Nell96] Nellborn, C., “Business development - an overview of the
problem”, Lecture notes 1996-02-21.
[Nilss99] Nilsson, A. G., Tolis, C. and Nellborn, C. (Eds.), "Perspectives
on Business Modelling: Understanding and Changing
Organisations", Springer-Verlag, 1999.

Appendix A: The ELECTRUM Library

Case Study
NOTE
The situation of the library is purely imaginary and has no relation to reality.
This is not a complete Enterprise Model. It can be elaborated further in a
number of ways, e.g. by defining all information sets in the Concepts Model, or
operationalising Goals in terms of Business Rules and Processes. Information
System requirements may also be further elaborated.
The actual representation of Enterprise Models may vary depending on the
tools used for documenting models.
A.1 Top level EKD model
Goals Model
goals are may be

explained stakeholders
by referring to goals motivate with respect
concepts business rules to goals
business rules Business Rules business rules

Actors and
may be defined Model may be defined
Concepts Model by referring to by referring to Resources Model
concepts actors
business rules
control business
processes
information sets
actors may perform
in Process models Business of be responsible
are explained by Process Model of processes
referring to concepts
IS requirements
IS requirements may involve
may be further actors
defined by referring IS requirements support
to concepts business processes
IS requirements Information System Requirements Model

may support business
goals

A.2 ELECTRUM Library Goals Model

Goal 10 Theat 1
To maintain and hinders The library's budget
improve the will be cut by 200
library's services KSEK within a year
and by 500 KSEK
within 3 years
supports
Problem 6 Goal 11
To have an external
Copyright and
finance source
Opportunity 2 ownership of
supplying 500 KSEK in
Advanced electronic material
Goal 19 next 3 years
communication
and information To attract outside
technology hinders customers supports
cm3 Goal 7 Goal 21
supports supports
Goal 23 Goal 22 To make the library To minimise
To provide advanced organisation more Library's
Deliver items cost-effective operational costs
services for library
electronically
customers
supports proc.2 cm2 Goal 3
Opportunity 1
Weakness 2 hinders supports In ELECTRUM there
Constraint 2 The library is To establish
Goal 24 are many high-tech
Requests for To provide search infrequently used paying services
companies
electronic material services in hinders
cm3 hinders
must be satisfied catalogues of other
Problem 4 Constraint 1
within 3 days libraries There is a long Service should be free of
supports
proc.2 proc3 waiting list for charge for students and
borrowing books academics
Goal 6
supports To achieve a top
class standard of
service hinders
Weakness 3
supports Service in the library
supports supports is not as good as it
should be
Goal 2 Goal 4 Goal 5
To achieve To minimise To achieve high
interactive customer customer's waiting in precision in all library
support the queue transactions
supports
Goal 20
supports supports To keep the library

catalogue regularly
updated
Goal 2.1 Goal 2.2 Goal 2.3 Goal 26
proc13 Iset21
To maintain an To provide
To maintain To setup a library
interactive, WWW customers with a
24-hour a day information system
based bulletin service catalogue
telephone hot-line
board on Internet on CD-ROM
Problem 5
Development of
hinders
requires information system
is costly
Goal 2.4 Goal 2.5 IS FReq 2

Catalogue search solves
To purchase a WWW
To maintain an own server services from engine should be
IS FReq 5
WWW server outside Internet provider connected to
company Internet Library IS should use
as much existing
software as possible

CM3: Goals 3, 19, 22 relationships to Concepts Model
Concept 3
Department or
faculty Concept 18
Concept 7
Service Loan
works_for
receives
Academic staff Catalogue
Customer search
Ordered loan
studys_in
Concept 5
Student Paying Video
service conferences
Non-paying Paying Concept 24 Concept 25
customer customer Copying of Purchasing
material material
refers_to
Concept 26
Outside Goal 3
customer
refers_to To establish Goal 11
paying services To have an external
finance source
supplying 500 KSEK in
Goal 22
next 3 years
refers_to To provide advanced
services for library
Goal 19 customers supports
To attract outside
customers
CM2 : Goals 23 relationship to Concepts Model
Goal 23
Deliver items
electronically
referes_to
Concept 26
Electronic
item
Concept 15
Book
Concept 12 Concept 14-N Concept 16
Copy of Item Periodical
Concept 17
Document

Information Set 21: Electrum Library catalogue refers_to a fraction of Concepts Model
Inf.Set21: Goal 20 refers_to Information Set 21
Goal 20
To keep the library

refers_to catalogue regularly
updated
Inf.Set 21
Electrum library refers_to
catalogue
Electronic
State item
Concept 15
Book
Concept 12 Concept 14-N Concept 16
Copy of Item Periodical
Concept 17
of
Document
Concept 18
Loan

A.3 Electrum Library Concepts Model

The model shows main concepts. Attributes, except few, are not shown here.
Concept 13
has Budget Electronic
State item
Concept 15
Concept 1 Concept 2 Book
in
KTH KTH library
Concept 16
has Concept 12 Concept 14-N Periodical
Copy of Item
Concept 17
o
Concept 6 Document
f
ELECTRUM owns
Library
Concept 7 Concept 18 has Return date
Concept 3 Service Loan
provides
Department or
faculty
receives Concept 19
Concept 8
Catalogue Concept 22
works_for search
Customer Ordered loan
Concept 4
Concept 11
Bad Concept 21 Concept 23
Academic staff
customer Paying Video
service conferences
studys_in
Non-paying Paying
Student Copying of Purchasing
customer customer
material material
Concept 27: State of a copy

Information Set 31 refers_to Concept 27; Rule 20 affects fraction of Concepts Model
Inf.Set 31 Concept 27.1

State of a copy
Available
refers_to
Concept 27.2 Concept 18
Borrowed until Return date has Loan
Concept 27 Concept 27.3

State Missing
Concept 27.4
in In repair until
affects
Concept 12 Concept 27.5
Rule 20
Copy Out of stock
Book repair should
be recorded as loan
with no charge

A.4 ELECTRUM Library Business Rule Model

Business Rules Model is shown in context of the Goals Model
Goals 3
Constraint 1 hinders
Service should To establish
be free of charge paying services
for students and
academics Rule 9
Check physical
supports supports condition of each
copy when it is
Goal 19 Goals 6 supports returned to library
To offer additional To achieve a top
benefits for paying class standard of
customers service
Rule 6
supports Notify all customers about
supports
supports all changes in library
hinders
services immediately as
Rule 2 changes occur
There should be no
Goal 5
priority in waiting
line for paying To achieve high Goal 20
customers precision in all supports To keep the library
library transactions
catalogue
supports regularly updated
supports
supports supports
supports
Goal 4 Rule 1 Rule 10
A customer is a bad Rule 5
To minimise
customer's waiting customer id he/she Every day check for Update library
in the queue does not follow delayed books catalogue as soon
Rule 5.3
library rules as changes occur
Update library catalogue
when copy of item
changes its state to
"missing", or "in repair",
"out of stock"
Rule 4 Rule 3
Rule 5.1 Rule 5.2
A customer is bad A customer is a bad Update library Update library
customer is he/she customer is he/she catalogue after catalogue when
delays books for more has overdue books each loan new items and/or
than 4 weeks twice consecutively transaction copies are acquired

Rule 4: A customer is bad customer is he/she delays books for more than 4 weeks
Process 14 supports Rule 4
Rule 4 motivates Process 15
Rule 4 refers a number of Entities in Concepts Model
Here Rule 4 is expressed in semiformal language

Report customer Check for
as bad delayed loans
supports
motivates
Rule 4
If Today - Loan.Return_date >= 28
refers_to
refers_to
Service Loan
has
receives
Return date
Concept 8
Concept 11
Bad Customer has ID
customer

A.5 ELCTRUM Library Actors and Resources

Model
O.Unit. 1
KTH Main Library cuts
consists_of
O.Unit. 2 Capital 1
is_managing ELECTRUM uses ELECTRUM

Library Library Budget
works_for
Role 9 Role 1 Role 2 Role 5
Library provides_ Bad

Library manager accounts_to Customer
Clerk service_for Customer
support_work_of
Role 3 Role 4
Role 12
Library Non-paying Paying
Information Customer Customer
System
plays plays
Individual 1 O.Unit. 3
Ericsson Radio
John Smith
AB

A.6 Electrum Library Business Process Model

This graph shows only "Key" processes. Shaded components are decomposed.
Process 11
Inf.Set 42
Inf.Set. 33 Library stock Information about
New copies of maintenance new items
items and update
Ext.Process 4
Bookstore
Process 13
Library catalogue
update
Process 5
Process 3
Inf.Set 51
Inf.Set 21 Customer Customer
Electrum library Catalogue Inf.Set 20
Search item bulletin relationships
catalogue search
Inf.Set 31
State of a copy
of item Inf.Set 50
Ext.process1 Inf.Set 52 Portfolio of
Customer Electrum
Customer
Process 2 response library services
Process 14
Inf.Set 17
Item delivery
Check for Item Inf.Set 41
electronically Customer
delayed books
requests and
surveys
Process 12
Inf.Set 5 Inf.Set 10 Process 6
Ongoing loans Loan of books Book Library service
development and
management

Process 2: Item delivery electronically

Proc2: Goal 23 refers to Process 2, Constraint 2 affects Process 2.3
Process 2
Item delivery electronically
Process 2.1
Inf.Set 13
Electronic request Electronic request
acknowledgment for an electronic item
Inf.Set 12
Inf.Set 18 Inf.Set 19 Rejected
is_responsible_for Electronic item Library accepted request
catalogue request
Goal 23
Deliver items Process 2.2

Role 1 Ext.process1
electronically is_responsible_for Search library's all
Library clerk performs Customer
electronic items
Role 12
motivates Library
Information
System
supports Inf.Set 14 Inf.Set 15

is_responsible_for Item is not performs
Item is available
available
Constraint 2
Requests for
electronic material
must be satisfied
within 3 days Process 2.4
Inf.Set 16
Process 2.3 Library response Item is not
to customer available
affects Deliver item to
customer
Process 2.5
Register electronic
transaction
Inf.Set 17
Item
Entity 26
refers_to Electronic
item

Process 3: Catalogue search

Proc3: Goal 24 refers to Process 3.2
Entity 19
Catalogue
search
refers_to Role 2
performs Customer
Inf.Set 5
Process 3.1
Ongoing loans Inf.Set 20
Search in
ELECTRUM Search item
Inf.Set 21
library catalogue
Electrum library
catalogue
Inf.Set 22 Ext.process1
Item is temporary
performs Customer
not available
Role 12 Inf.Set 15
Library
Item is not available Inf.Set 23
Information
in ELECTRUM library Item is available for
System
using only at site
performs
Process 3.2 Inf.Set 24
Inf.Set 27
Search in Item is available for
Catalogue
catalogues of borrowing
information of
other libraries other libraries
Inf.Set 25
Available for
Ext.Process 2 ordering
Other Goals 24
To provide search refers_to
libraries
services in Inf.Set 26
catalogues of other
Not available
libraries

Process 5: Customers relationships
Ext.Process 4
Bookstore
Role 1
Process 11.3 Inf.Set 40
Library clerk performs Order of an item
Order new items
from bookstore
supervises Inf.Set 42
Information about
new items
Process 5:
Customers relationships
Role 9 Inf.Set 41 Inf.Set 21

Library Customer Process 5.1 Electrum library
manager requests and catalogue
surveys Disseminate
relevant information
to customers
Inf.Set 50
performs Process 5.2
Portfolio of
Electrum library
Analysis of services
customer Inf.Set 51
Communications
Customer bulletin
Inf.Set 52
Ext.process1
Customer
response Customer
Process 6
Library service
development and
management

Process 11: Library stock maintenance and update

Rules 5, 9 and Roles 9, 12 relationships to business processes
Inf.Set 21
Electrum library
catalogue
Rule 5
Update library
Role 1 catalogue as soon
as changes occur
Library clerk Process 13 Role 12
Library
Library catalogue performs
triggers Information
performs update
System
supports
Rule 9
Check physical Process 11:
condition of each Library stock maintenance and update Inf.Set 31 Inf.Set. 33
copy when it is State of a copy New items
returned to library
"in repair"
motivates Ext.Process 4
Process 11.1 Process 11.2 Bookstore
Inf.Set 37
Check condition Copy needs Send copy to
of returned copy repair repair "out of stock"
Inf.Set 30 Process 11.3 Inf.Set 40

Copy of a book Inf.Set 42
Order of an item Information
returned to Inf.Set 38 Order new items
library from bookstore about new
Copy of book
items
Ext.Process 3
Inventory
repair provider
Role 9
Inf.Set 39
Copy cannot supervises Library
be repaired manager
Process 5
Inf.Set 41
Customer Customer
requests and relationships
surveys

Process 12: Loan of books

Roles 1 and 2 perform business processes
Process 12.1
Inf.Set 1
Order Customer order
acknowledgment for a book
Inf.Set 4 Inf.Set 3 Inf.Set 2

Library accepted
Book catalogue Rejected order
order
Entity 16 Process 12.2

Loan Ext.process1
Search library's Customer
all copies
refers_to
Inf.Set 5
Ongoing loans Inf.Set 8 Role 2
Book is borrowed by
performs Customer
another customer
performs
Inf.Set 6 Inf.Set 7
Book is Book is not
available available Process 12.3
Inf.Set 14
Negotiation with
customer Queue
Role 1
Library performs
clerk
Inf.Set 12 Inf.Set 13
Inf.Set 5 Process 12.4 Customer refuses Customer elects
Ongoing loans Register loan wait in queue to wait in queue
transaction
Inf.Set 31
Process 12.6 Process 12.7
State of a copy Deliver books to Process 12.5
customer Update queue
Library response
to customer
Inf.Set 9
Book checked Inf.Set 15
out to customer Queue
Inf.Set 11
Book is not acceptance
available
Inf.Set 10
Entity 20
refers_to Book
Book

Process 13: Library catalogue update

Process 14: Check for delayed books
Process 15: Report customer as bad
Proc13: Goal 20 refers to Business Process Model (BPM), Business Rule Model relationships
to BPM, Actors and Resources Model relationships to BPM
Role 9
Library
Rule 4 manager
Rule 10 A customer is bad
is_reponsible_for
Every day check customer is he/she
Goal 20 Inf.Set. 35
for delayed delays books for
To keep the library refers_to more than 4 weeks Customer
books
catalogue regularly status "Bad"
updated
Inf.Set 21 triggers Process 15
Electrum library controls Report customer
catalogue motivates
Rule 5 as bad
Update library
catalogue as soon Process 14
as changes occur Inf.Set. 32
Check for Book is delayed for
delayed books more than 4 weeks
Process 13
triggers Library catalogue
update
performs
Inf.Set 5
Ongoing loans
Role 12
Inf.Set. 33 Process 12.4
Inf.Set 31 Library
New copies of
State of a copy Register loan Information
items
transaction System
Process 11
Library stock Inf.Set 30 Inf.Set 9
Copy of a book Copy of a book
maintenance
returned to borrowed by a
and update
library customer

Inf.Set.50: Portfolio of Electrum Library services
Inf.Set 50
Portfolio of
Electrum library refers_to
services
has Return date
Service Loan
Concept 19
Catalogue Concept 22
search Ordered loan
Paying Video
service conferences
Copying of Purchasing
material material

A.7 ELECTRUM Library IS Requirements

Model
Goal 26
To setup a library
information system
Goal 7
To make the library Process 11
organisation more Library stock
cost-effective maintenance
supports
and update
IS Goal 1
supports
To maintain all kinds supports
of information within
supports the library
IS FReq 5
IS Goal 5
Library IS should use To maintain
as much existing information about the
software as possible most popular and
newly published books

Process 13 To maintain To maintain
To maintain
Library catalogue requires information about information about
information about
update customer loans and requests and
book resources
transactions customer waiting list
supports
IS FReq 4 IS Req 1 IS FReq 4

Catalogue search supports To provide a 24 supports Library catalogue
engine should be hours a day library should be exportable
connected to other catalogue search on CD ROM
library search systems
supports supports supports

motivates Process 3
IS FReq 2 IS FReq 3 Catalogue

Goals 24 Catalogue search Catalogue search
search
To provide motivates engine should be engine should
search services connected to have a WWW
in catalogues of Internet interface
other libraries

EKD Userguide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EKD Userguide

Uploaded by

Copyright:

Available Formats

HyperKnowledge

Hypermedia and Pattern Based Knowledge

4.5 ACTORS AND RESOURCES MODELLING ............................................................................58

APPENDIX A: THE ELECTRUM LIBRARY CASE STUDY .............................................. 98

A.1 TOP LEVEL EKD MODEL........................................................................................ 98

A.2 ELECTRUM LIBRARY GOALS MODEL ............................................................... 99

A.3 ELECTRUM LIBRARY CONCEPTS MODEL ..................................................... 102

A.4 ELECTRUM LIBRARY BUSINESS RULE MODEL............................................ 103

A.5 ELCTRUM LIBRARY ACTORS AND RESOURCES MODEL .......................... 105

A.6 ELECTRUM LIBRARY BUSINESS PROCESS MODEL .................................... 106

A.7 ELECTRUM LIBRARY IS REQUIREMENTS MODEL...................................... 114

EKD User Guide page 6 of 114

1.2 Enterprise Modelling – overview

EKD User Guide page 7 of 114

2. The modelling session is then prepared. It is vital that this preparation is

Figure 1 EM as a one-off activity in a development project

EKD User Guide page 8 of 114

Figure 2 PEM as a recurring activity in a development project

1.3 The purpose of Enterprise Modelling

EKD User Guide page 9 of 114

Ensure acceptance Maintain and share

Design/ redesign Elicit business

1.3.1 Business development goals

EKD User Guide page 10 of 114

1.3.2 Quality assurance goals

1.4 Actors in Enterprise Modelling

EKD User Guide page 11 of 114

Figure 4: Some roles in an EM project

EKD User Guide page 12 of 114

1.5 The advantages of using a participative

EKD User Guide page 13 of 114

1.6 Measuring the success of applying EKD

EKD User Guide page 14 of 114

1.7 EKD and competency

1.7.1 The competency of domain experts

Figure 5: Main categories of domain experts in an EM project

EKD User Guide page 15 of 114

group. The willingness or opportunity of people to contribute their competency is

results in has Organisational

Figure 6: Competencies of a modelling group - relationships between

The competency of individual modelling participants

EKD User Guide page 16 of 114

Composition of the modelling group

1.7.2 The competency of the method provider

EKD User Guide page 17 of 114

Each type of activity in a PEM project requires certain specific competencies.

Figure 7: Three levels of method provider competency

EKD User Guide page 18 of 114

An important part of the competency of a modelling facilitator is “social skills”.

It is often an advantage to have more than one facilitator in a modelling session.

EKD User Guide page 19 of 114

2. The Library Case Study

2.2 The Current Situation

EKD User Guide page 20 of 114

and to reorganise its services to departments and institutes in Electrum as well as

Personnel salaries 700 000 SEK

EKD User Guide page 21 of 114

3.1 What is EKD?

A set of supporting tools

Figure 8: Contents of the EKD framework

EKD User Guide page 22 of 114

Deliverables from EKD

EKD User Guide page 23 of 114