ENTERPRISE MODELING:MODELING BASICS

 MODELING BASICS

Creating a Model World

Enterprises are sociotechnological real-world systems. A system is a composition of elements and their relationships. Examples of elements of the system enterprise are employees, products, activities, machines, computers, and software, which interact in manifold ways. They can be described by their structures (static view) as well as their behavior (dynamic view). Because enterprises are very com- plex, in many cases analysis cannot be done directly on the real-world-system.

Enterprise modeling aims at reducing the complexity of the system to be studied. Only specific aspects of an enterprise are examined, such as data structures, input–output relationships, and logistic processes. Such subsystems of the real world are called ‘‘mini world’’ or ‘‘model domain.’’ Thus, models are descriptions of the most important characteristics of a focused domain. The creative process of building such an abstracted picture of a real-world system is called modeling (see Fig- ure 1).

In addition to the actual purpose of modeling, the modeling methods applied also determine the focus of the model. This is particularly true when a certain type of method has already been defined. Models reproduce excerpts of reality. They are created by abstracting the properties of real objects, whereas their essential structures and behavior remain intact (homomorphy). Not only the content- related purpose of the model but also the permissible illustration methods determine to what extent nonessential characteristics may be abstracted. For example, if an object-oriented modeling approach or a system-theoretic approach is selected, modeling only leads to objects applicable to the syntax or the semantics of these particular methods. In order to avoid lock-in by certain methods, architec- tures and methodologies are developed independently of any particular method, while supporting a generic business process definition.

The following sections we will discuss modeling methods and architectures in greater detail.

Levels of Abstraction

Abstraction is the basic concept of modeling. In system theory, we know many perspectives of abstraction. Thus, we can concentrate either on the structure or behavior of enterprises; on certain elements of the enterprise, such as data, employees, software, products; or on a bounded domain, such as sales, accounting, manufacturing. Typically, in enterprise modeling projects, several of these perspectives are combined. For instance, a typical modeling project might be ‘‘Describe the sales data structures.’’

However, the term level of abstraction describes the relationships between a model system and the respective real-world system. That is, it describes the steps of abstraction. From low to high abstraction we can distinguish at least three levels in modeling: instances, application classes, and meta classes.

At the instance level, each single element of the real world is represented through one single element in our model. For example, in the case of modeling an individual business process, every element involved in the business process is instantiated by the affixed name, such as customer (no.) 3842, material M 32, or completed order O 4711, etc. (see Figure 2).

Enterprise modeling at the instance level is used for controlling individual business processes. In manufacturing, this is for creating work schedules as the manufacturing process descriptions for individual parts or manufacturing orders. In office management, individual business processes are executed through workflow systems. Therefore, they must have access to information regarding the respective control structure and responsible entities or devices for every single business case.

At the application class level, we abstract from instance properties and define classes of similar entities. For example, all individual customers make up the class ‘‘customer,’’ all instances of orders constitute the class ‘‘order,’’ and so on (see Figure 2). Every class is characterized by its name and the enumeration of its attributes, by which the instance is described. For example, the class ‘‘cus-

tomer’’ is characterized by the attributes customer number, customer name, and payment period. The instances of these characteristics are the focus of the description at Level 1.

Finding classes is always a creative task. It thus depends on the subjective perspective of the modeler. Therefore, when defining, for example, order designations, we will only abstract specific properties of cases 4711 or 4723, respectively, leading to the classes ‘‘completed order’’ or ‘‘finished order.’’ At Level 2, we will abstract the ‘‘completed’’ and ‘‘finished’’ properties and create the parent class ‘‘order’’ from the subset. This operation is known as generalization and is illustrated by a triangular symbol.

When quantities are generalized, they are grouped to parent quantities. This makes order instances of Level 1 instances of the class ‘‘order’’ as well. The class ‘‘order’’ is designated as the property ‘‘order status,’’ making it possible to allocate the process state ‘‘completed’’ or ‘‘finished’’ to every instance. Materials and items are also generalized, making them ‘‘parts’’ and ‘‘resources.’’

Thus, Level 2 contains application-related classes of enterprise descriptions. On the other hand, with new classes created from similar classes of Level 2 by abstracting their application relationships, these are allocated to Level 3, the meta level, as illustrated in Figure 2. Level 2 classes then become instances of these meta classes. For example, the class ‘‘material output’’ contains the instances ‘‘material’’ and ‘‘item’’ as well as the generalized designation ‘‘part.’’ The class ‘‘information ser- vices’’ contains the class designation ‘‘order,’’ along with its two child designations, and the class designation ‘‘certificate.’’ The creation of this class is also a function of its purpose. Thus, either the generalized classes of Level 2 or their subclasses can be included as elements of the meta classes.

When classes are created, overlapping does not have to be avoided at all costs. For example, from an output flow point of view, it is possible to create the class ‘‘information services’’ from the classes ‘‘order’’ and ‘‘certificate.’’ Conversely, from the data point of view, these are also data objects, making them instances of the class ‘‘data objects’’ as well.

The classes at modeling Level 3 define every object necessary for describing the facts at Level

2. These objects make up the building blocks for describing the applications at Level 2. On the other

hand, because the classes at Level 2 comprise the terminology at Level 1, objects at Level 3 are also

the framework for describing instances.

This abstraction process can be continued by once again grouping the classes at Level 3 into classes that are then allocated to the meta2 level. Next, the content-related modeling views are abstracted. In Figure 2, the general class ‘‘object type’’ is created, containing all the meta classes as instances.

Principles of Modeling

Enterprise modeling is a creative process and can therefore not be completely directed by rules. However, if certain standards are observed, it is indeed possible to classify and understand third- party models. Furthermore, it is also a good idea to establish certain quality standards for enterprise models.

Figure 3 illustrates the relationship between principles and enterprise modeling. A principle is a fundamental rule or strategy that guides the entire process of enterprise modeling. Thus, modeling

principles concern the association between the domain and the respective model as well as the selection of appropriate modeling methods and tool support. A modeling method is a set of com- ponents and a description of how to use these components in order to build a model. A modeling tool is a piece of software that can be used to support the application of a method. We will discuss modeling methods and tools in more detail in the following chapters.

Principle of Correctness

The correctness of models depends on correct semantics and syntax, that is, whether syntax of the respective metamodel is complete and consistent. Semantic correctness of a model is measured by how closely it complies with the structure and behavior of the respective object system. In real-world applications, compliance with these requirements can be proven only after simulation studies have been carried out or other similar efforts have been made. Some modeling tools provide a simulation function that can be used for this purpose.

Principle of Relevance

Excerpts of the real-world object system should only be modeled provided they correspond with the purpose of the model. Models should not contain more information than necessary, thus keeping the cost vs. benefit ratio down to an acceptable level.

Principle of Cost vs. Benefit

One of the key factors ensuring a good cost vs. benefit ratio is the amount of effort necessary to create the model, the usefulness of modeling the scenario, and how long the model will be used.

Principle of Clarity

‘‘Clarity’’ ensures that a model is understandable and usable. It also determines how pragmatic the relationship between the model and the user is. Because models contain a large amount of information regarding technical and organizational issues, only specialists are usually able to understand them quickly. Once models are broken down into subviews, individual views are easier to comprehend.

Principle of Comparability

Models created in accordance with a consistent conceptual framework and modeling methods are comparable if the objects have been named in conformity with established conventions and if identical modeling objects as well as equivalent degrees of detailing have been used. In models created with different modeling methods, it is important to make sure that their metamodels can be compared.

Principle of Systematic Structure

This principle stipulates that it should be possible to integrate models developed in various views, such as data models, organizational models, and business process models. This requires an integrated methodology, that is, an architecture providing a holistic metamodel (see Section 4).