8.3 The Model Development Phase
The Tema development phase is illustrated in , being an elaborate
and enlarged version of the "inner loop" of Figure 8.1.
Figure 8.2: Enterprise model development phase according to
8.3.1 Objectives of the development phase
The main objective of enterprise modeling in the development phase is assumed
to be sense-making: To develop an overall understanding of either
the enterprise or some part of it, and to use this understanding to argue
for other artifacts that may be developed.
|The strategy development process presented in chapter 6 is a prime
example of a how enterprise modeling is envisioned used. Enterprise modeling
was a means to describe aspects of the enterprise and make sense of elements
of the strategy.
No assumptions are made regarding the further purpose of a more sophisticated
understanding of some domain. Examples may be holistic thinking, arguing
for certain decisions that have been made, changing the way-of-working,
etc. Even if the primary objective is to understand, any other objectives
must be kept in mind by those developing enterprise models to make sure
they develop models that meet their ultimate purposes (assertion 3). In
case of shared understanding or holistic thinking being an objective, assertions
4 or 5 may apply, respectively.
8.3.2 The development process
Tema's primary stance on the development process is as deliberate
selection of techniques for sense-making from a pool. The "pool of techniques"
concept implies that activities can be interchanged at the modelers' discretion.
There are however some dependencies that make certain activities precede
others. This is illustrated in Figure 8.3.
Figure 8.3: Major stages in the Tema development phase
The overall "method" illustrated in has the following stages:
As pointed out in section 8.2.1, enterprise modeling is assumed to be an
integrated part of a project with some other purpose, and all decisions
related to normal project execution are therefore assumed taken care of.
It is the particularities of enterprise modeling that are of interest here.
Preparations to modeling, including team training to understand the principles
and gain competence in use of the approach.
Development of enterprise models and intermediate artifacts using a pool
Preparation of exposed artifacts for dissemination.
Stage 1: Team training
The first stage in Tema is to ensure that the project group is properly
prepared for the modeling part of the project (assertion 15). Singh and
Lewis (1995:3), in their discussion of accomplishment of concurrent engineering
projects, advocate a preparatory project stage referred to as team training
to ensure that project teams are capable of meeting the challenges
of project work (and particularly the challenges of working as a team).
The concept of team training can be adopted as a natural first stage of
The main objective of the first stage is to learn the concepts of Tema
and ensure that the preconditions for employing Tema are fulfilled.
Themes that may require attention at the initial stage are discussed in
Fitness between Tema and the project objectives
A first issue is to decide whether Tema is appropriate for use in
the project at all. If project participants experience confusion and are
unsure of how to proceed, this may be an indication of need for a modeling
approach that focuses on sense-making and not directly on representation.
The type of work that is to be modeled may also be an indicator (assertions
1 and 2). Anyway, if the actors are reluctant to Tema as an approach
to enterprise modeling, chances for success may be slim (as it may be interpreted
as an attempt at premature closure of the question of use of modeling approach
– and actors enact their local realities, leading to self-fulfilling prophecies).
Concepts and techniques being a part of Tema
A prerequisite for employing Tema is to be familiar with at least
some of the techniques in the proposed pool. There are two reasons: Effective
sense-making depends upon familiarity with the techniques (without competence
in use of the techniques attention may be directed at the techniques themselves
instead of at the domain that is to be investigated, assertion 15). Another
reason for requiring a certain familiarity with the techniques is that
the project actors otherwise may be unable to judge when a technique can
be applied appropriately.
The actors also need an overview of the Tema architecture: What
are the main elements, and how are they arranged (e.g., the separation
into a development phase and a dissemination phase, and the distinction
between intermediate and exposed artifacts).
The principles underlying Tema
Learning the framework without learning the principles outlined in chapter
7 may lead to questioning of the validity of Tema, i.e., Tema
may not make sense. Hence, the principles are seen as an integrated part
of the framework, and may provide guidelines for enterprise modeling that
are not discussed in the current chapter.
|Assertion 3 encourages the project actors to be aware of the problem
of drifting objectives. To keep an eye on objectives is not stated
as an explicit activity in any part of the current chapter, but is still
intended as a part of Tema. The project actors may agree to revisit
the objectives frequently, e.g., as a part of concluding each project meeting.
Observations from the strategy project presented in chapter 6 may also
be used as examples, hopefully convincing actors of the necessity of Tema
Theory underlying Tema
If considered appropriate in a given project, the project actors may even
discuss selected parts of the underlying theory used for analysis and support
of the methodological principles. A candidate for at least a superficial
treatment is the view on enterprise modeling as a process of perspective
making and perspective taking, focusing on human sense-making as a communication-intensive
The focus on theoretical discussions does not have priority, but elements
of the theories may be used to argue for certain parts of the framework.
Hence, if there is one or a few persons that are well educated in the theories
supporting Tema, this may be sufficient (but to require education
of all project participants in all the subtleties of the theories is a
violation of the practical applicability criterion for design).
Communities involved in modeling
As Tema poses requirements to knowledge and competence in the project
team, an assessment of required training of project actors have to be made.
The actors also have to identify the enterprise audience – who
are the customers and the future users of the artifacts being developed
as a part of the project and thereby the ones having interest in taking
part in the modeling process. The importance of identifying the audience
is due to the view of audience as taking part in the perspective making
(at an enterprise level). The issue of audience ought to be revisited frequently
during the project in order to ensure that feedback is received (assertions
19 and 25).
The above issues may also be approached using some of the techniques
from the pool, so the project group have the opportunity to attain the
required skills simultaneously.
|Discussing audience and their requirements to the project can be done
using the Quality Function Deployment (QFD) technique, breaking down requirements
into required actions to meet the requirements. QFD is proposed as a member
of the pool of techniques.
Stage 2: Development of enterprise models
Deciding which techniques to include in the pool has been done based on
observations from the empirical studies in addition to both personal and
other's experience with the techniques. The most prominent common trait
is their focus on sense-making: The techniques are not primarily
devices for representation, manifestation or distribution (recall the model
of modeling in Figure 3.3). Selecting a pool of both creative and analytical
techniques is a direct consequence of seeing enterprise modeling as dominated
by sense-making activities (assertion 7).
As observed in the strategy project, the project groups used different
approaches albeit not always aware of their resemblance to established
techniques. The pool includes techniques that resemble the observed approaches.
|The strategy project represents a rich source of observations related
to use of creative and analytical techniques: Brainstorming was used deliberately
to create ideas. A variant of the QFD technique was employed without being
recognized as such until after its application. Problem situations involving
obvious concept interdependencies led to complexity that could have been
reduced with dependency analysis.
The following techniques are generally recommended as a part of Tema
(assertions or activities from chapter 7 are used as rationales):
The techniques will be discussed in more detail in chapter 9 along with
prerequisites for applying them, expected outcomes, and additional rationales
for inclusion in the framework.
Brainstorming is a technique for creative construction of a number
of concepts or ideas from a general theme (assertion 7).
The technique implies describing the intended meaning of a term through
characterization as opposed to definition (assertion 11). Characterization
means to describe different aspects of a concept or the use of a term in
context, more in line with a dictionary entry.
Concept clustering is to structure concepts into appropriate categories
(e.g., as output from brainstorming). The outcome of concept clustering
is a set of categories, each with a number of elements. Categorization
was an activity in TEK-S (A12).
Dependency analysis involves assessment of cause-and-effect relations
between a number of concepts. Dependency analysis introduces a certain
structure upon the domain (assertion 16).
Quality Function Deployment
QFD is a simple, yet powerful technique for breakdown of an overall
objective into means-and-ends. QFD is easy to learn, although not necessarily
easy to use. Concepts are also analyzed for internal dependencies (leaving
QFD as a structuring device, assertion 16).
Deployment Flow Charting
Deployment flow charting is a technique that is appropriate for modeling
of activities, products, roles and their dependencies in a process over
time. As a flow-charting technique, it illustrates a simple modeling language,
and exemplifies a prototypical enterprise modeling approach (A21
An OPPO assessment is a description of the Objective, Product, Process
and Organization of a task. The OPPO technique is orthogonal to the other
techniques, in the sense that all techniques can be analyzed in terms of
objectives, products, processes and organization. OPPO works as a structuring
device (assertion 16).
Construction of metaphors
Metaphors are subsidiary artifacts in enterprise modeling (assertion
22). Construction of metaphors provides the project group with different
perspectives on an issue (metaphors play both an explanatory and a generative
Construction of narratives
Construction of narratives is the development of concrete stories or
scenarios describing phenomena in the enterprise, being effective devices
for sense-making (assertion 23).
Group reflection is not a technique, but rather an activity. The essential
idea is to reflect upon the selection and application of techniques in
various problem situations. As Tema does not prescribe a strict
method for how to go ahead with enterprise modeling, the project group
must apply techniques as they consider appropriate in each setting. Reflection
was observed in TEK-S (A14).
The number of existing creative and analytical techniques is large,
and the ones listed above are just few that are fit for purpose in Tema.
A proposition is that any organization or project group may extend or delimit
the pool as a way to tailor the framework to a specific organization, project
or domain. This is a flexibility inherent to the architecture of Tema.
An observation concerning flexibility: Relying on a pool of techniques
restricts (and thereby supports) how activities being a part of
modeling is done, but not what is modeled (the domain) or in what
sequence (maintaining flexibility).
Another observation is that the techniques are intended to be used in
groups and in meetings. The reason is their reliance and
focus on communication, being appropriate for the type of forums referred
to in assertion 9. The techniques are not intended as tools for individuals,
although they to some extent can be applied as such, too.
In addition to the above techniques, Tema recommends use of fast
iteration cycles through construction of intermediate artifacts, presentation,
interpretation and finally feedback. Based on the observations from empirical
studies, this is an effective way of working when the outcome of work is
unknown (assertion 6). Frequent summarizing is also recommended as a means
to make sense of a domain (assertion 8).
Stage 3: Preparation of artifacts for dissemination
When the model development process has reached a stadium where sufficient
understanding is perceived to have been attained (the perspective is considered
to be sufficiently complexified), exposed artifacts must be prepared for
dissemination (corresponding to the manifestation step in Figure 3.3).
The development phase is not finished even if the models and subsidiary
artifacts are made available to the enterprise audience. The enterprise
models are still under construction, and feedback has to be taken into
implementation in a medium suitable for dissemination (as the medium
used for development may not be the most appropriate for dissemination),
polishing of contents and layout of the artifacts (e.g., formulation
of text, and layout of diagrams) in order to avoid the problems concerned
by assertion 20, and
integration of the artifacts (linking the main product of the project
with model elements, narratives, term characterizations, other models,
Reflections on the development process
The development process is concerned with perspective making – to develop
a perspective that is complexified enough to make the actors make sense
of the subtleties of the domain that is modeled. From this point of view,
the composition of the pool of techniques may seem more reasonable: The
techniques are not means to represent the perspective in terms of
boundary objects, but rather means to construct the perspective.
Without this essential insight, the relationship between the pool of techniques
and enterprise modeling may be unclear.
8.3.3 Intermediate artifacts
The intermediate artifacts that are developed in the course of enterprise
modeling are output from the various techniques discussed above. Their
characteristics are outlined when the techniques are discussed in more
detail in chapter 9.
Examples of intermediate artifacts are term characterizations, partial
enterprise models, textual explanations of model elements, narratives,
metaphors, sets of concepts, concept categories, flow charts, matrices,
dependency maps and OPPO assessments.
The distinct property of all intermediate artifacts is that they are
not necessarily finished. They may only partially describe a problem situation
(assertion 10). Intermediate artifacts may also have short life cycles
and never become exposed to the enterprise audience. Their primary role
is as constructions in the perspective making process.
8.3.4 The group of enterprise modelers
Tema poses requirements to actor knowledge and competence.
The project group must be comprised of actors who in sum are knowledgeable
within all relevant areas of the modeling domain. The reason is that lack
of knowledge will slow the communication process down or leave some aspects
unnoticed (assertion 14). To require competence within the modeling domain
is neither necessary nor always feasible.
To pose domain knowledge as a requirement may seem unattainable, as
a main characteristic of the domain is that actors do not know in advance
what to produce. Hence, domain knowledge is not a strict requirement, but
more of an desirable property. The actors must at least have the ability
to understand the domain with some effort or involve other actors on demand.
The project group must be competent in applying the basic techniques
comprising the pool. They also need basic communication skills and computer
literacy to exploit and understand consequences of the digital medium (assertions
15 and 24).
8.3.5 Forums and media for development
The forums proposed for enterprise model development are face-to-face meetings,
a project database and a bulletin board system for many-to-many communication,
and face-to-face conversations, email and phone for individual communication.
Still, the primary forum for model development is face-to-face meetings
In meetings, the use of simple media like overhead foils, flip-overs,
Post-It notes on the wall, etc. is advocated (assertion 12). A reason is
that the medium must allow both communication and interaction by several
actors simultaneously. The construction of an intermediate artifact must
be almost instantaneous to reflect an idea that an actor gets as a part
Between meetings, intermediate artifacts can be made available to the
project group (and possibly the enterprise audience, but beware assertion
20) both through a shared project database and as a part of a preliminary
version of the final document on the Intranet. With appropriate technology,
the bulletin board system can be integrated with the project database.