6.6.4 The artifacts of enterprise modeling

The artifacts denoted "enterprise models" in the presentation were M3, M4 and M7 at the enterprise level and M1, M2, M5 and M6 at the project level. The models may be denoted primary artifacts in the context of this thesis, as they are prototypical enterprise models. Other artifacts that were developed and used, like terminology, metaphors and stories, are denoted subsidiary artifacts, as they played a role in enterprise modeling, but were not considered enterprise models per se. In addition, a large number of intermediate artifacts were observed, playing a role in the modeling process, but not in the final deliverables.

Analysis of primary artifacts

The drawings and diagrams developed in TEK-S are clearly enterprise models according to section 3.3: They were deliberate and explicit representations of how actors understood aspects of the enterprise or the project (i.e., their perspective). The enterprise model properties discussed here are Assessments of desirable properties of enterprise models were not observed in TEK-S, and hence, these three are discussed as they are common to most of the models.
1. Simplicity
All the models in the strategy project can be characterized as simple. The models contained only a few elements and a few language concepts, and were understood intuitively by the actors. E.g., M7 contains only two types of concepts -- activities and markets. There are a total of 13 elements -- 11 activities and 2 markets. In addition, the models make use of implicit relations, in the sense that activities are perceived to be related although there are no explicit connections between them.

Simplicity can be considered relative to a perspective. When a perspective is weakly developed, a model representing fine distinctions in the perspective may be considered as complex (as the community of knowing lack the ability to differentiate between the nuances). With a weakly developed perspective on modeling, the modeling languages had to be simple.

The preference for simple models makes sense when considering the actual use as structuring devices. With more detailed and complex models, the ease of human interpretation might have been reduced.

2. Use of professional language
Another characteristic of at least the enterprise level models is that they employ terms that are part of the professional language of the actors. Looking at the M3 model, the elements represent well known physical artifacts like reservoirs, platforms, pipelines, etc. These are part of the professional language of any actor in the project (and recall that a professional language is developed as a part of perspective making).

The use of concepts from their professional language also influences the model impression: The meaning attributed to a model depends heavily upon the preunderstanding that the interpreting actor has of the domain in question. The models can be seen as devices that are used to structure knowledge that the actors already have. The models consist of pegs for the pre-understanding of the interpreting actor.

3. Lack of formality
A third characteristic is the lack of formality. Neither syntax nor semantics of the modeling languages were formally defined and agreed upon, but that did not seem to have any significant influence on the meaning actors attributed to the models. The modeling languages may be formally defined afterwards, but that is not the point here. Discussions of modeling language were not observed at any time in the project and although they might have existed, choice of language was not a significant problem.

A reason that lack of formality was not problematic may be that the models were intended for human interpretation, and although a few of them were digitally represented (in the Web version of the strategy), they were not digital models. Computers were not intended to interpret them (with the exception of the "clickable" M7). Human actors interpret according to their perspective, and with a strong perspective, actors are likely to agree more upon interpretations than with a weakly developed perspective. Hence, formality is in a sense implicit when creating models of widely agreed upon domains.

Analysis of subsidiary artifacts

The following subsidiary artifacts are discussed in more detail:
1. Terminology
Problems pertaining to terminology, both definition of terms and finding appropriate terms for a given concept, were recurring through the whole strategy project. Terminology was the source of much disagreement.

The "definition of terms" problem can be explained by seeing the terminology as a part of the vocabulary of a community of knowing. The actors defined a vocabulary that was more precise than their own understanding. Hence, they were not able to use the language consistently. The incidence described on page , where one actor removes the qualifier terms key, core, etc. can be interpreted as a way to remove the subtle distinctions in the language. It is also a consequence of reflection 51; questioning the need for the nuances.

The associated problem of "constructing appropriate terms" could easily have been predicted if taking the meaning of a term or phrase to depend upon the actors' preunderstanding. Meaning is local to a community of knowing. To associate only one specific meaning with a term is not practically feasible.

An immediate question concerns the consequences of experiencing problems with terminology. A negative consequence was resource consumption, as a lot of time was spent on discussing alternative definitions. Another negative consequence was misunderstanding when used "incorrectly" (e.g., the dynamic document incidence on page ). A positive consequence was that the underlying concepts were discussed thoroughly, and probably more thoroughly than if there were no problems with defining the corresponding terms. The discussions contributed to the complexification of the developers' perspective, and in a sense, they were unavoidable, as the nature of the project were of a type that requires perspective making (the perspective was weakly developed, as stated on page ).

An observation was that there were always actors available to clarify and restate the message 51; the terms can be considered embedded in a communication process. Hence, when an actor had problems with understanding a term, he could ask a question and receive immediate feedback. Disseminating the final deliverable without this embedding communication process might involve a more significant risk for misunderstandings (as was observed when receiving feedback on the final deliverable from the future users, page ).

The relevance of terminology to enterprise modeling is that both concern description of some domain. Whether this description is in terms of boxes and arrows or text is of less importance. In addition, text plays a central role in most enterprise models, conveying much of the information.

In figure 6.10, there is a box labeled "Gas logistics". The form of the box indicates that it is an activity or process, just like all the other boxes. What makes it different from the other boxes is the label -- "Gas logistics" -- and location (in the sequence of activities). The real world activities that are covered by the short phrase "Gas logistics" are so complex and comprehensive that two interpretations beyond all doubt will be substantially different. To define unambiguously the meaning of gas logistics is neither feasible.
2. Explanation of models
Most of the models developed in the project (and other artifacts as well) were observed to have two parts: The model and an accompanying explanation of the model. Explanations were not formulated explicitly as a part of the model, but expressed orally in discussions or presentations. Hence, the models only contained parts of the information that was given to the audience of a presentation.

Explanations typically included a description of the model elements and a sequential account tying the model elements together. The sequential account followed relations representing cause-and-effect, time, flow, etc. An example of the use of explanations occurred at WS3, when the WG Gas leader presented the "as-is" and "to-be" model.

Explanations are integrated parts of enterprise models, as they directly influence the interpretation of the model. In the Web version of the strategy, only the models were made available to the reader. Explanations were to a large degree left out. From a theoretical point of view, this leads to a situation where even more of the meaning attributed to the model depends upon the pre-understanding that the interpreting actor has of the model elements. When the model is embedded in a communication process, the lack of an explicit explanation of the model is not as vital, as there are always explanations available from other actors. When the model is distributed without accompanying explanation, the consequences may be more serious, as interpretation is left to the model reader. Seeing the model as a boundary object, the explanation aids in the perspective taking process, ensuring a more correct interpretation of the perspective.

3. Metaphors
The use of metaphors was observed as a means to explain aspects that enterprise models were intended to describe (although not as a part of any deliberately applied technique). Belief in the effectiveness of metaphors was also stated by several actors, e.g., by the corporate staff representative at WS1 and by actors in the WGs.

Examples of metaphors that were created and used in the strategy project are (group of actors in parenthesis):

Metaphors were used as devices for attribution of meaning -- as alternative means to communicate how actors understood a given situation or phenomenon. All the "right hand sides" of the metaphors were well known to the project participants, and understanding one phenomenon in terms of another seemed to be an effective technique. From a theoretical point of view, a metaphor may be interpreted to carry the associations from the known phenomenon over to the unknown, making it more meaningful (associations give meaning, as stated in section 3.3.5). However, construction of metaphors was not used consciously as a technique for problem situations -- the use of metaphors seemed to be occasional. None of the metaphors were included in any of the final deliverables.
4. Stories
A number of stories (narratives) were collected or created to describe and exemplify concrete situations in which Statoil had been successful due to strategic development or use of technology. The purpose of the examples was to make people understand how the technology strategy could be useful in a concrete situation, as requested by the corporate staff representative at WS1.

Seven of the stories were included in the Web version of the strategy document, but none in the paper version. The stories were provided stand-alone, i.e., they were not integrated with the presentation in any way, and the readers would have to make associations by themselves. However, the examples were valuable in the strategy development phase as means to exemplify assessments and claims that were made during discussions. Hence, stories were used to validate elements of the strategy, making them sensible to the readers.

The stories are comparable to enterprise models as they both are descriptions of the enterprise. Hence, they may play a similar role.

Boland and Tenkasi (1995) explicitly include narratives as a central element in their theory of perspective making and perspective taking in communities of knowing. Narratives are considered to be central in making experiences meaningful and sensible by framing them and committing them to memory (ibid.:357).

Analysis of intermediate artifacts

The construction of intermediate artifacts was discussed on page as an activity at WS2, but was also observed in other meetings. Two of issues that spawned many intermediate artifacts were the strategy development method and the core competencies.

Concerning the strategy development method, the method foil M2 represents an early version, while the M6 model describes a final version of the method. In between, there were a number of proposals for alternative steps and sequences. At WS2, which can be considered the main event concerning the generation of intermediate artifacts, seven slightly different approaches to strategy development were presented.

Also at WS2, the discussion of future core competencies resulted in 12 different illustrations of a set of future core competencies, and most of them were developed at the workshop (a few of them had been developed in the work groups in advance).

The development and use of intermediate artifacts can be seen as a means to complexify the perspective of the community of knowing, i.e., as an element in the perspective making process. The artifacts were informal and often incomplete with respect to the issue under consideration, and can be seen as externalization of an immature understanding of the issue (a weakly developed perspective).

Artifacts as boundary objects

In order to speak of boundary objects, distinct communities of knowing must be identified. As discussed in section 6.6.1, the main distinction was between the developers on one hand (the PG/WG/SG coalition) and the users and customers on the other (the BoT/chief engineers/others coalition).

Of the primary artifacts, M1, M2, M3, M6 and M7 were observed used as boundary objects. M1 and M2 were used by the PG at WS3 to inform about the project, M3 and M7 were included in the Web version, and M6 was presented by a WG leader at WS3 to illustrate how the WGs had worked.

Of the subsidiary artifacts, the definitions (terminology) and seven of the stories were included in the Web version of the document. In addition, explanations were given orally, but they are not considered as boundary objects, as they are not suitable for studies (unless manifested using a durable medium, e.g., taped on video).

None of the intermediate artifacts were boundary objects, but that was neither the intention. Intermediate artifacts played a role mainly in the perspective making process, not in perspective taking.