8.2    TEMA Architecture

The most prominent design criterion of Tema is fit with the principles stated in chapter 7. Figure 8.1 illustrates how each concept from Figure 7.1 is associated with or supported by a particular service or technological solution.

8.2.1    Decisions underlying the framework

The current section discusses the fundamental decisions that characterize Tema, and applies to both the development and dissemination phase.
Figure 8.1: Outline of Tema architecture a team-based enterprise modeling approach

Context of enterprise modeling

The context of enterprise modeling in Tema is the enterprise, consisting of a project group and the embedding enterprise, as illustrated in . The two groups of actors play two different roles in a modeling process: The role of a developer and the role of an audience. Both the project group and the organization may be seen as developer or audience at different stages in the process.

The project is the natural setting for enterprise modeling in Tema. Enterprise modeling is not envisioned as a continuous effort going on for a long period of time. It is more likely to be used as a means to develop some other artifact. This view is a natural consequence of a leaning towards a constructivistic worldview: Enterprise models do not represent an objective, invariable organizational reality, and the perspective taken in this thesis is not the "enterprise models as corporate memory" view held by some proponents (e.g., Prytz, 1995). Seeing enterprise modeling as dominantly a sense-making process also encourages modeling as an activity (i.e., to use the metaphor of corporate memory, "enterprise modeling as corporate memorizer" is more appropriate, in the sense that enterprise modeling is a means to construct the "memory" of organizational reality).

The technology strategy project represents a typical setting of enterprise modeling according to Tema: In order to develop and disseminate the technology strategy, they also developed and disseminated enterprise models. Hence, enterprise models were not seen as ends by themselves, rather they were means to meet other objectives. 

Set of rules for enterprise modeling

The set of rules or methodological aspect refers to required activities in the development and dissemination phases of . "When to do what why" in the various phases is the essence of this framework component.

A fundamental decision made in Tema is to stress flexibility at the expense of efficiency and predefined support, i.e., to adhere to a non-presumptionistic stance as stated above.

The immediate consequences of a non-presumptionistic stance on the set of rules for Tema depend on the phase. In the development phase, Tema advocates a pool of techniques instead of a predefined, all-encompassing method for enterprise modeling. By a pool of techniques is meant a pre-selected set of relatively simple approaches to investigation of problems of limited extent and complexity. That a technique is simple implies that it consumes little resources and time to master (although it may require some effort to apply in a specific situation). Each technique contributes to solving a particular problem or illuminating a certain aspect, and careful selection of techniques may provide a powerful "tool box" for approaching seemingly complex problem situations. Applying the taxonomy of work from section 3.6 on techniques in general, one may say that with a technique, the form of the product is known but not the contents.

Brainstorming is proposed as a technique in the pool. The outcome of a brainstorming might be a set of ideas on a whiteboard (the form of the outcome), even though one can not tell in advance what the ideas are about (the contents).

An all-encompassing method for enterprise modeling would be stated in terms of a series of steps leading from a perceived problem situation to meeting the objective. Although a method might be iterated, the steps are usually not considered as self-contained and interchangeable.

A set of rules will then provide guidelines for why applying what technique when, in addition to guidelines for other activities that have to be carried out both in the development and dissemination phase.

Turning to the dissemination phase, the immediate consequence of a non-presump-tionistic stance is that even if a few constraints on the dissemination process (in terms of required dissemination activities) are posed, there are no fixed sequence of steps that are assumed to be adequate in all situations.

Concepts for enterprise modeling

Modeling concepts refer to impressions and expressions of enterprise models and subsidiary artifacts. In particular, a modeling language to use for representation of enterprise models must be decided upon.

The empirical studies indicated that project groups may be able to create informal modeling languages on their own as a part of the modeling process, tailored to the specific needs in their project (assertion 13). Consequently, Tema makes as few presumptions as possible about features of the languages. This is also consistent with a claim made by Singh and Lewis (1995:6):

"In any case, the best choice of modeling technique for any organization is the practice most familiar to its teams."
If the project group are acquainted with a language in advance, it would be appropriate to use concepts from this language as long as it has expressive power to represent the required phenomena.
In the strategy project, the work groups decided to describe Statoil's strengths, weaknesses, opportunities and threats as a part of the enterprise models. The language concepts were tailored to their needs. 

In the PA30 project, bombs and clouds were used to denote perceived problems and opportunities at the process plant. This was considered highly successful by the project group, and represents the most important information in their enterprise model (as it was used to propose changes at the plant). The process and product aspects played the role of structural background against which the problems and opportunities could be discussed. 

A non-presumptionistic approach is feasible when the purpose of enterprise modeling is human sense-making (category I) and not what may be referred to as computer sense-making (category II and III). Hence, proposing to create modeling languages as part of the modeling effort is a direct consequence of the decision made in section 1.2.2 concerning what support: The focus of Tema is human sense-making. Frameworks with a wider variety of purposes may not go for the solution outlined here.

However, in order to develop a modeling language, the modeling group must be aware of the possibilities. They must have an idea what to "choose" from. Choice of language elements is also influenced by the techniques proposed to be a part of the pool of techniques discussed above.

An aspect of any modeling language is the medium used for representation of the artifacts. In Tema, a fundamental decision is to separate between what is the primary medium in the development phase and in the dissemination phase. In the development phase, paper (or equivalents like whiteboard or blackboard) is the primary medium (assertion 12). In the dissemination phase, the primary medium is digital. Hence, paper variants of models may have reduced quality as compared to the original variant. Choosing a digital medium enables a more effective communication process for dissemination of models (depending on the audience's competence in using the medium, assertion 25). Paper is considered to encourage one-way communication with little feedback.

User requirements to enterprise modeling

The user requirements are influenced by the objectives associated with enterprise modeling. In Tema, the primary objective is assumed to be human sense-making and communication, i.e., to understand and discuss aspects of the enterprise through construction or interpretation of models and subsidiary artifacts. Hence, the user requirements that are intended met by Tema pertain to the modeling process and less to the artifacts (as sense-making and communication are social processes).

Seeing enterprise models as structuring devices (assertion 16) that may assist the actors as they attempt to make sense of the overall enterprise, guide them to information or to other actors (assertion 18) imposes other requirements on models than seeing them as knowledge bases for querying about all kinds of information regarding the enterprise (as some other frameworks for enterprise modeling do, e.g., TOVE and Enterprise, see chapter 5).

8.2.2    Delimiting the discussion of Tema

To develop and describe a framework like Tema requires more resources than available in this research project. Consequently, Tema is described in detail for only a few aspects and more superficially for the rest: What is left is the process aspect of the development phase and to some degree the dissemination phase. Some consequences of neglecting certain aspects are considered in more detail in section 10.2.1 when evaluating the framework.