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 Tema

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.

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 Tema.

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 the sequel.

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 components.

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 activity.

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.

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). Preparation involves 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 account.

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 (assertion 9).

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 of discussions.

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.