Sub-models of 4EM

Sandkuhl, Kurt; Stirna, Janis; Persson, Anne; Wißotzki, Matthias

doi:10.1007/978-3-662-43725-4_8

Kurt Sandkuhl⁸,
Janis Stirna⁹,
Anne Persson¹⁰ &
…
Matthias Wißotzki⁸

Part of the book series: The Enterprise Engineering Series ((TEES))

5217 Accesses

Abstract

This chapter presents the sub-models of the 4EM language as well as the basic principles of using them. The sub-models are the Goals Model, the Business Rules Model, the Concepts Model, the Business Process Model, the Actors and Resources Model, the Technical Components and Requirements Model, as well as the use of inter-model links that connect the sub-models. All sub-models will be presented with their components (notation), a guide for developing them (driving questions) and an example. As a running example we will use A4Y case described in Chap. 6.

Access provided by Autonomous University of Puebla. Download chapter PDF

Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

This chapter presents the sub-models of the 4EM language as well as the basic principles of using them. The details of setting up a modeling project and carrying out the modeling process are discussed in Chap. 9. Furthermore, in Chap. 12 the main quality criteria for models are described. The sub-models presented in this chapter are the Goals Model, the Business Rules Model, the Concepts Model, the Business Process Model, the Actors and Resources Model, the Technical Components and Requirements Model, as well as the use of inter-model links that connect the sub-models. As a running example we will use A4Y case described in Chap. 6.

The main focus of this chapter is on the modeling language—meaning and purpose of the modeling components and the sub-models . The graphical look of the modeling components is usually influenced by the modeling tools used and can in principle be changed without affecting the outcome of modeling. There are however some general principles that should be followed—every modeling component should have a unique identifier including the type of modeling component and the graphical symbol should be well readable both on the screen and when printed. Recommended template of 4EM is shown in Fig. 8.1. Sometimes the combination of identifier and number is referred to as short name of the component.

8.1 Goals Model

The Goals Model is used for describing the goals of the enterprise along with the issues associated with achieving these goals. The Goals Model describes essentially the reason, or motivation, for components in the other sub-models. The components of this model are related to the enterprise itself and its rationale. Information system goals and requirements should not be stated here. The Goals Model forms the framework with which the relevance of processes and technical system requirements are measured and to which they are linked. Through links to and from the other sub-models, the Goals Model explains why, or why not, processes and requirements exist or do not exist. The components of the Goals Model are related to each other through unidirectional semantic links of which the three main types are supports, hinders, and conflicts.

8.1.1 Components of the Goals Model

Component types of the Goals Model are the following: goal, problem, cause, constraint, opportunity. However, observations from a number of practical modeling sessions show that sometimes it is necessary to add additional components to the model, such as comments, assumptions, scenarios, tasks, etc. The purpose of such extensions is usually to improve the expressiveness and clarity of the model.

8.1.1.1 Goal

A business Goal is a desired state of the enterprise that is to be attained. It is used for expressing goals regarding the business or state of business affairs, i.e., what the enterprise and its employees want to achieve, or to avoid, and when.

Goals may be expressed as a measurable set of states, or as general aims, visions, or directions. Goals can be several meanings, such as business goals, objectives, intentions, needs, business requirements, desired states, etc. Intentional sentences should begin with the phrase “The goal is…”. This phrase can be omitted but the expression should be such that if added it would still remain grammatically and logically correct. Figure 8.2 shows an ambiguously formulated goal on the left while the goal on the right is more precisely formulated.

It is recommended to follow the principle of SMART goals, meaning that every goal should be specific (S), measurable (M), accepted (A), realistic (R), and time framed (T). This guideline contributes to increasing the understandability and usability of the model. In Fig. 8.2 the goal on the right follows this principle.

Goals may also have the optional variables priority and criticality (with possible values: low, medium, high), which allow modelers to assign different priority levels and perceived degree of criticality.

Goals modeling requires the participants to reflect over, and state their short as well as long-range goals about the enterprise. It also requires the modeling participants to discuss and agree upon issues such as the individual importance of goals, the criticality of goals, and the priority of goals, as well as evaluating alternative ways of achieving goals. These issues should not necessarily be discussed at once. It is more useful that the modeling group returns to them during the course of the modeling workshop.

8.1.1.2 Problem

A Problem is used for expressing that the environment is in, or may reach, some non-desirable state of affairs that needs to be addressed, which hinders the achievement of goals. By documenting perceived problems, a basis is created for detecting hidden goals that may otherwise only be implied, because problems typically hinder the achievement of some goal. If a stated problem cannot be seen as hindering some goal, then either the set of goals is incomplete or the problem really is not a problem of the enterprise.

Problems may be specified into two subtypes:

Weaknesses—a type of problem describing factors that may reduce the possibility of achieving a goal. Weaknesses typically are factors that can be considered as internal with respect to the problem domain.
Threats—a type of problem describing influencing forces that may reduce the possibility of achieving a goal. Threats typically are external factors coming from outside of the problem domain.

Figure 8.3 shows examples of problems.

8.1.1.3 Cause

A Cause is used for expressing the explanations or reasons for Problems. Causes are usually situations or states, outside the control of the project, process, and organization. It may be something that is well understood and does not need to be analyzed further. Typically, a cause cannot be affected by the enterprise. An example is given in Fig. 8.4.

8.1.1.4 Constraint

A constraint is used for expressing business restrictions, rules, laws, or policies from the outside world affecting components and links within the enterprise model. Internal business rules and policies of the organization are defined in the Business Rules Model. Figure 8.5 provides an example.

8.1.1.5 Opportunity

An opportunity is used for expressing resources that can make certain goals easier to achieve, achievable states not regarded as Goals, or even to state new goals of the enterprise. For instance, new communication technology may facilitate an enterprise’s possibilities to achieve a goal to enlarge the international market of its products. Opportunities are situations that we may want to take advantage of and consider for development (see Fig. 8.6 for an example). If so, the Opportunity should be transformed into a Goal at a later modeling stage.

8.1.1.6 Links Within the Goals Model

The link types between the components of the Goals Model are (Fig. 8.7):

Supports relationship, that is used to show that fulfilling one goal supports fulfilling another. Supports is essentially seen as “vertical” relationship, i.e., it is used to refine or decompose goals into other often more operational goals.
Hinders relationship, that is used to show negative influences between components of the Goals Model, and can be considered as opposite to “supports.”
Conflicts relationship, that is used in a situation when an achievement of a goal is in conflict with another.

Initially the Goals Model may have a high level of abstraction. To obtain more clarity and to specify goals in more detail it is often necessary to decompose or to refine them to sub-goals. Such possibilities are provided by AND, OR, as well as AND/OR relationships.

The AND refinement relationship is used to specify a set of unique sub-goals that are necessary to satisfy a goal (Fig. 8.8).

The OR refinement relationship is used to specify a set of alternative sub-goals that support a goal. It is sufficient to satisfy only one goal from the set (Fig. 8.9).

The AND/OR relationship is used to specify a set of alternative sub-goals—to support a goal. A combination of sub-goals from the set will satisfy a goal (Fig. 8.10).

8.1.2 Notation

The notation of the Goals model is depicted in Fig. 8.11.

8.1.3 Example Goals Model

8.1.3.1 Modeling the Current Situation (the AS-IS Model)

A4Y’s primary objective for the current year is to reach a profit increase of 15 % (Goal 1). There are two sub-goals that support the achievement of this primary objective. The company can increase its profits by increasing its sales through promotional measures (Goal 2), by lowering its operating costs by 10 % (Goal 3), or by implementing a combination of Goal 2 and 3 (Fig. 8.12).

In order to increase sales, the company A4Y can acquire new customers (Goal 5) or expand its marketing activities (Goal 6). Both goals support Goal 2. Further refinement of Goal 2 can be done by introducing more sub-goals: development of new product versions/variants (Goal 2.1), reducing the time to market (Goal 2.2) or extension of services (Goal 2.3). As these goals belong to Goal 2 they can be seen as refinement of this goal. Therefore, Goal 2 is marked in the top-level model with a (+) to indicate the existence of a decomposition (see Fig. 8.12). This decomposition with the sub-goals included is illustrated in Fig. 8.13. In order to reach these goals, the company already investigated potential measures, such as the introduction of a new payment system (Opportunity 9).

However, the achievement of Goal 2.1 is also associated with the problem that development of new products is time-consuming and is associated with substantial costs (Problem 9). This problem has an indirect effect on Goal 3, as it is in conflict with the reduction of operational costs (see Fig. 8.13). To resolve this conflict, the company has to decide how to deal with this issue in the future. The decision should be documented in the final version of the model. After further analysis of the sub-goals of Goal 2, Goal 10 is introduced, which defines the need to investigate the possibility to acquire more efficient machinery, as well as Goal 11 that identifies the need to implement third-party payment services. Opportunity 9 documents one such option—to use PayPal services. At this stage this is modeled as an opportunity because the company has not yet decided which supplier to use for these services.

In order to increase the profit of the company according to defined goals, operational costs should be reduced in addition to increasing sales. This objective is modeled with Goal 3, which in turn consists of several sub-goals. On the one hand, Goal 3 consists of the sub-goal of optimizing production processes (Goal 4 in Fig. 8.12) and on the other hand it consists of several supporting sub-goals (see Fig. 8.14). Thus, Goal 3 is also marked with a (+). There are also weaknesses, threats, and restrictions influencing the goals (see Fig. 8.14). For Goal 3.2, the company has documented a weakness that the shipping guidelines so far have not been applied in a satisfactory way. Therefore, this weakness hinders Goal 3.2. Another problem that hinders Goal 3.1 is the risk that the blacksmith does not have the necessary knowledge for maintenance of the machinery. Both problems (Weakness 5 and Threat 6) can be solved by simple measures. Nevertheless, there is a restriction, which cannot be influenced by the company and which hinders the achievement of Goal 3.3—in periods with high workload, the company either hires additional workers for a limited period of time or the regular employees work overtime. In both cases the length of temporary employment and the maximum overtime of regular employees is strictly regulated by law (Constraint 1).

8.1.3.2 Modeling the Company’s Vision (the TO-BE Model)

A4Y decided not to invest in new machinery for developing new products and product variants in the near future. Based on this decision, an agreement is reached on how to solve the conflict between Goals 2 and 3. The agreement is to increase sales through promotional activities to a certain degree, and to put the main focus on reduction of operating costs.

Accordingly, Goal 2.1 and the associated Problem 9 were removed, because it was assumed that the high costs associated to this goal could hinder Goal 3 (see Fig. 8.15) which is not acceptable.

So far the model of the future state (TO-BE model) has been developed by simplifying and removing modeling components. This, of course, is not the only way—there also is a need to develop the model by introducing new components that support the main objective of the company. For example, Goal 6 and Goal 4 are extended with new sub-goals (Goal 6.2, Goal 4.1, Goal 4.2, Goal 4.3) as shown in Figs. 8.16 and 8.17.

8.1.4 Developing and Refining the Goals Model

In the previous section we showed a small example of goal modeling for the AS-IS and TO-BE states of an organization. There are some common principles of developing a goals model in a modeling workshop, which are discussed here.

Developing a Goals Model is initially a brainstorming activity. Views and contributions from all participants must be considered, which normally makes the initial product of modeling unstructured and difficult to understand. Initial versions of Goals Models often look like islands of goals and problems where the grouping of modeling components implies certain categorization with respect to the modeling problem. Once this is done the following steps include structuring, classification, and operationalization of Goals Model components. This is normally done collaboratively in an iterative fashion, where participating stakeholders are continuously consulted to validate the progress. Naturally, this also leads to discovering new goals and/or problems, which are in turn analyzed and added to the Goals Model that emerges as a result of the modeling effort.

It is important, when developing a Goals Model, to concentrate on the business itself, and not on supporting information system and more technical goals related to the systems. Information systems goals will be modeled in the Technical Components and Requirements Model (Sect. 8.6).

The static rules of the enterprise, as well the dynamic rules that govern the permissible state changes of the enterprise, are also informally defined in this sub-model. Normally “business rules” can be seen as refinements of higher level business goals or constraints. The business rules are then further elaborated in the Business Rules Model (Sect. 8.2).

At any stage of goal modeling, it is useful to use, or at least to keep in mind, some driving questions. These will keep the modeling effort focused and moving forward.

Table 8.1 suggests a number of driving questions for goal operationalization and refinement of goals. These two actions deserve a closer look.

Table 8.1 Driving Questions for goal modeling

Full size table

The purpose of the goal operationalization is to elaborate detailed measures for fulfilling high-level goals. Operationalization of the Goals Model encourages the development of a goal network, usually a hierarchy, where top-level strategic goals are decomposed into a number of more operational sub-goals. However, it needs to be pointed out that in practice categorizing goals into strategic or operational goals is not easy or even needed, because in the goal hierarchy there are also goals “in the middle” which are not as specific as operational goals and not high enough in the hierarchy to be called strategic. The key aspects of the goal operationalization process are:

Emphasis on creativity: goal operationalization reflects a creative jump from present facts to future possibilities that bring into being something new that has not previously existed.
Emphasis on the dynamic nature of the modeling process: the result of the process is not static but depends on the design decisions and the visions of the future situation during the operationalization process. This means that the outcome of the process is not always the same.

The operationalization is characterized by two principal types of activities—goal refinement and conflict management.

During goal refinement, new goals are generated from the initial high-level goals into detailed and clarified goals. In this sense a high-level goal is refined into one or more sub-goals that can, in turn, be refined in sub-sub-goals. The result of these successive refinements is a multilevel hierarchical structure, starting from high-level vague enterprise objectives down to specific operational goals. In goal refinement, it is possible to use AND/OR relationships in the structures, to refine goals into several alternative combinations of sub-goals, or a sub-goal can be realized by several alternative models.

Goal conflicts management consists of a number of activities such as the following:

Conflict detection: This focuses on identifying conflicts between goals. It may be difficult to relate new goals to existing goals and to determine the effect of the former on the latter. To do this, one should exhaustively search the goal model and compare the new goal to each existing goal for conflicts. A reasonable way to search for potential goal conflicts is to use the high-level goal conflicts that have already been identified during the goal acquisition stage. The heuristic rule is that it is more likely to find conflicts between sub-goals of previously identified conflicting high-level goals.
Conflict classification: This focuses on identifying the kind of conflict that has been detected. Ends conflict—Goal conflicts may occur when two contradictory goals are desired. Means conflict—When actors hold identical goals. However, these goals are in conflict because each actor wants to use the same resource. Conflict classifications may be used by conflict management methods to react accordingly.
Conflict handling focuses on acting in case of conflict. Alternatives are the following:
- Ignore: for example, when conflict does not prevent further development. However, it is necessary to keep track of the conflict in case its impact increases.
- Ameliorate: the balancing of conflicting goals may not be clear until the various design possibilities are explored in terms of alternatives. This way the decision is shifted to the model generation stage, when more concrete data about a situation is available.
- Resolve the conflict. Often, a goal conflict implies the unavailability of any specific alternative to achieve both goals. In this case, the ranking of goals may be useful for deciding a potential dropping of a goal. However, some goal conflicts may be overcome by: redefining the goals, specifying the context in which each goal is achieved or finding alternative goal refinements that have fewer conflicts.

The two key issues in managing conflicts are: tracking known conflicts and recording information about these conflicts, such as the circumstances that led to these conflicts.

Very often, the high-level goals, problems, business rules, etc., acquired at the elicitation contain a number of informal and imprecise requirements. Initial versions of a model might also contain certain redundancy, which is allowed in order to support the discussion and to accommodate stakeholder wishes. It is recommended that the output of the initial Goals Model be structured at an early stage. This task involves:

Goal classification: To improve comprehension and understanding of a multitude of goals, it maybe advisable to classify them in a matrix table, where they may be categorized according to origin, stakeholder, function, domain, etc. This will allow for comparison and analysis and will potentially uncover the need for further discussion based on the analysis of the patterns of the goals.
Goal prioritization: A prioritization of goals allows for conflict resolution between goals. A higher level goal acts as a constraint on a lower level goal.
Goal correlation: Goal correlation is perceived as the positive or negative interaction between goals. In general, positive correlation among goals by supports relationships is desirable, which implies that satisfaction of one goal will support the satisfaction of the other goal. On the contrary, the existence of antagonistic goals could prevent the satisfaction of goals. Furthermore, failure to recognize antagonistic goals could cause confusion throughout the modeling process. In addition to analyzing the goals model, goal correlations can also be analyzed by creating a connectivity matrix—where all goals are listed as rows and columns and each cell represents a relationship. In larger models this sometimes allows discovering new relationships.

8.2 Business Rules Model

The Business Rules Model is used to define and maintain explicitly formulated business rules, consistent with the Goals Model. Business rules may be seen as operationalizations or limitations of goals. Business rules are the rules that control the enterprise in such a way that they define and constrain which actions may be taken in the various situations that may arise. These may be in the form of:

Precise statements that describe the way that the business has chosen to achieve its goals and to implement its policies or
The various externally imposed rules on the business, such as regulations and laws.

Business Rules often form a hierarchy where lower level rules define the way the higher level rules or goals are implemented. Business Rule modeling is closely related to Goals modeling. Rules are defined by goals while also affecting the fulfillment of other goals. They trigger business processes and refer to concepts defined in the Concepts Model. Actors in the Actors and Resources Model are responsible for achieving and defining business rules. Business rules may also require certain functionality from information systems. Components of the Technical Components and Requirements Model may, therefore, be motivated by business rules.

8.2.1 Components of the Business Rules Model

Business rules may be categorized into Derivation Rules, Event-action Rules, and Constraint Rules that are further classified into Static and Transition Constraints.

Derivation rules are expressions that define the derived components of the information structure in terms of entities that are already present in the information base of the modeled enterprise. Derivation rules are introduced as a means of capturing structural domain knowledge that needs not to be stored. Its value can be derived dynamically using existing or other derived information. A derivation rule is, for instance, “A bad library client is a client that does not return a loan on time for two consecutive times.”

Event-action rules are concerned with the invocation of activities. In particular, action rules express the conditions under which the activities must be taken, i.e., a set of triggering conditions and/or a set of preconditions that must be satisfied before their execution. For instance, “If the return of a loan is more than 4 days overdue, send a reminder.”

Constraint rules are concerned with the integrity of the enterprise information, or with the enterprise activities and their permitted behavior. A constraint is, for instance, “the salary of an employee must not decrease.” Constraints can be further specialized into:

Static constraints apply to every state of the information base and are time-independent. They represent conditions that must hold at every state. A static constraint is, for example, “location of each copy of book is unique and only one.”
Transition constraints define valid state transitions in the information base, thus specifying restrictions on the behavior of the system. A transition constraint is, for instance, “A copy of book is missing, if the loan that includes it is overdue for more than 4 weeks.”

The relationship types between rules in the Business Rules Model are:

Supports relationship is essentially seen as vertical, i.e., it is used to refine or decompose rules.
Hinders relationship is used to show negative influences between components of the Business Rules Model, and can be considered as opposite to supports.

As in the Goals Model, there are also possible AND/OR decomposition structures in Business Rules Model (Figs. 8.18 and 8.19).

AND refinement relationships represent a set of unique sub-rules that are necessary to satisfy to support the original refined rule.
OR refinement relationships represent a set of alternative sub-rules. To support the original rule it is necessary to satisfy only one rule from the set.

8.2.2 Notation

The notation of the Business Rules Model is depicted in Fig. 8.20.

8.2.3 Example Business Rules Model

8.2.3.1 Modeling the Current Situation (AS-IS Model)

As shown in the Goals Model, the primary goal defined by the company is the profit increase by 15 %. Other goals were defined to support Goal 1. Many of the goals are connected to business rules, which further specify conditions for achieving the goals and create possibilities for the company to monitor goal achievement. In this context, A4Y developed several rules to be followed by the staff in the different business processes. For example, the two Rules 9 and 5 are intended to support the objective “Reduce time to market” (Goal 2.2); see Fig. 8.21. Rule 9 supports Goal 2.2 with the directive that the manufactured products have to be shipped daily. The second important rule (Rule 5) states that the manufacturing process must not take longer than 2 weeks. Thus, both rules support the objective of selling the products as soon as possible.

A4Y has identified a number of rules that are derived from other rules, i.e., they are rules that build on each other. First, the rules on the refinement level must be met before the “higher level” rule can be applied. For example, Rule 27 aims at selecting the logistics service provider according to the packet size and the recipient country. In order to follow this rule, Rule 7 must be considered which requires that the shipping guidelines should be observed at all times.

For the manufacturing part of the business, the company has a rule (Rule 16, Fig. 8.21) that states that an order should be triggered when the number of items in stock falls below a minimum inventory of 500 items. In this context, also Rule 5 is affected, as an empty warehouse can significantly prolong the production process or even halt it. By formalizing this relationship, dependencies can be detected quickly and support is given, regarding how this rule has to be applied in order to guarantee an appropriate amount of parts in stock. The rules are illustrated in Fig. 8.21.

Furthermore, it may happen that the same rule can apply to multiple objectives. For example, the Goals 4.1 and 4.2 both are supported by Rule 6, since that directive specifies the maximum number of characters in the engraving and helps to avoid unnecessary costs and delays in production (see Fig. 8.22).

To comply with the shipping policies and avoid legal consequences for the company, two additional rules are defined by management—Rule 7 is refined by defining Rule 8 and 10. Firstly, the product must be packed in accordance with international standards and, secondly, other guidelines were created to ensure proper billing. These two rules are visualized in Fig. 8.23 and define preconditions for a smooth and accurate shipping process.

Furthermore, the management defined rules to be applied in the business processes as complement to the goal-related rules. Rule 26 “Report poor quality to the CEO” at the same time supports Rule 11 in control of the delivered goods and is part of Process 12.5. In this process, the quality control for incoming goods is carried out. If any defect should occur, this must be reported to the CEO (see Fig. 8.24).

When examining dependencies between all rules defined for AA4Y, one rule is discovered which prevents reaching certain goals: Rule 3 defines that the CEO and all involved parties have to explicitly agree, if a manufacturing order or procurement order has to be changed. This means for Goal 4.1—to just mention one example—that any customer order requires the explicit agreement of the CEO. If the CEO is not available, the production process for this order cannot be started. This in turn contradicts Goal 4.1 that aims to reduce the production time, since the required flow of information and tasks resulting from Rule 3 rather extend the production time than shorten it (see Fig. 8.25).

8.2.3.2 Modeling the Future State (TO-BE Model)

A4Y decided not to invest in new machines for developing new products and product variants in the near future. The reason for this is the intention to increase sales by promotional activities, and to focus on the reduction of operational costs. Accordingly, Goal 2.1 was removed in order to avoid an increase in operational costs. When removing Goal 2.1, the corresponding rules also had to be eliminated, as they have no further use (see Fig. 8.26).

A4Y also decides to establish contracts with shipping service providers, which include pickup service for the goods to be shipped. Due to this proposed measure, Rule 9 has to be removed and replaced by Rule 28 (see Fig. 8.27). Rule 9 defines that products should be shipped on the day of their completion, i.e., the foreman has to deliver the products to the shipping service providers as soon as they are completed. This is considered inefficient and shall now be replaced by Rule 28 “Products should be ready for shipping.” According to the new rule, the foreman has to prepare the products for shipping, but no longer has to deliver them to the shipping service provider. All products ready for shipping are picked up by the shipping service two to three times a week.

As the company also decides to outsource part of the IT system, a new rule needs to be added to Goal 3.4 (see Fig. 8.28), defining that privacy has to be observed at all times (Rule 18). It should be noted that not every goal requires a rule.

As a result of a thorough analysis of the rules defined in the AS-IS model, the management of A4Y decides to remove or replace certain rules. As already discussed when describing the AS-IS model, Rule 3 stating that any changes require the consent of each stakeholder involved and the manager him/herself hinders Goal 4.1, reduction of production time. As a consequence, it is decided to remove this rule, i.e., Goal 4.1 “Reduce production time” can be performed more efficiently.

8.2.4 Introducing More Formality in the Business Rules Model

Business rules are seen as a formal part of organizational design. In many cases they are expressed in natural language. But in view of the inherent informality of natural language, formal expression of rules is needed in some cases. In 4EM this can be achieved by expressing business rules in the following way:

It may, however, not always be possible to formulate a business rule using this proposed pattern. Generally, there are several ways by which business rules can be stated:

Informally such as in normal language,
Formally such as structured English, or
Formally by using specially developed rule languages, e.g., Object Constraint Language (OMG 2000), SBVR (OMG 2008)

The latter two express rules in an unambiguous way that contributes to easier implementation of them in an information system design. Such rules should contain only one atomic rule, that is, a specific formal statement of a single constraint, fact, derivation, or term and cannot be decomposed further. For example, we can rewrite Rule 16: “When the stock below 500 order new” as shown in Fig. 8.29.

From a rule written in this way, modeling participants and designers are able to get more precise information about the event, condition, and the process to be triggered; see Fig. 8.30.

However, in a formal way it is possible to express only atomic rules. Rules that are more complex need to be expressed in natural or seminatural language and then decomposed or refined by using AND/OR relationships. Also, there may be also atomic rules that are almost impossible to define in a formal way, e.g., rules that are related to nonfunctional requirements.

8.2.5 Developing and Refining the Business Rules Model

Business rule modeling is often linked together with modeling other types of sub-models. For example when developing goals there may be a need to define certain rules, when modeling business processes specifying exceptions may be needed, and when modeling concepts a need to define integrity constraints may arise. There are several kinds of driving questions that could be useful when eliciting and analyzing business rules; see Table 8.2.

Table 8.2 Driving questions for business rule modeling

Full size table

8.3 Concepts Model

The Concepts Model is used to define the “things” and “phenomena” which are used in the other models. Concepts may be tangible, such as e.g. “car,” or intangible, such as e.g. “quality.” The Concepts Model must, at least, include components by which we can describe the contents of the different information sets and flows of the Business Processes Model. For example, the goal expression “To maintain and improve the library’s services” requires a definition in the Concepts Model of the concept “library service.” It is vital that important concepts used in other models are defined here to avoid the possibility of misunderstandings amongst participants and stakeholders. Inconsistencies are hence avoided.

A Concepts Model includes components such as concepts, binary relationships, and information attributes. Also, the ISA and PartOF relationships are included in the Concepts Model to permit generalization as well as complex component modeling. The Concepts Model also allows the possibility of defining different “Concepts Model Component Groups.” A group of this type is simply a view of a part of a Concepts Model, and includes a subset of the Concepts Model’s concepts, relationships, and attributes. A group can be a member of another group, etc. Groups may overlap each other in terms of their components.

The main purpose of the Concepts Model is to serve as a dictionary for reasoning about “things” and “phenomena” included in the other models. Hence the 4EM language for Concepts Modeling is relatively simple. A Concepts Model, or most often parts of it, can also be used for database design. In this case, the notation for the Concepts Model proposed here would most likely have to be replaced with a more formal data modeling notation e.g., Object-Role Modeling (ORM) (Halpin and Morgan 2008). The choice of modeling language does not affect the modeling process itself. It is generally possible to begin with the notation we describe in this book and then, later on, switch to more advanced concepts modeling language, e.g., ORM or UML Class Diagrams (OMG 2005). This may be particularly important when the Concepts Model is used as a requirements source for a database design.

8.3.1 Components of Concepts Model

The Concepts Model follows the same principles as most other modeling languages for data models—it consists of concepts, attributes, and a set of associations.

Concept is something in the domain of interest and application that we want to reason about and to characterize and define using relationships to other concepts.

Attribute is a component type that is only used to characterize concepts, i.e., it is a property of the concept (see Fig. 8.31).

Concepts can be related to each other by means of semantic relationships, such as binary relationships, generalization/specialization (ISA) relationships, and aggregation (PartOF) relationships.

A Binary relationship is a semantic relationship between two concepts or within a concept. The semantics of the relationship is defined by the modeler by naming it. Binary relationships are inherently bi-directional. Each direction can be given a name, preferably in the form of a verb phrase. The direction indicated by the arrow may be called the forward, or primary, direction and the opposite direction the inverse direction. An example of permitted multiplicities for binary relationships is given in Fig. 8.32. The concepts participating in a relationship can be said to play certain roles in the relationship. In the relationship “An E-shop customer places several Customer Orders; Each Customer Order is placed by exactly one E-Shop customer” (see Fig. 8.32), the customer is the one who places the order, while the order is what “is placed” by the Customer.

8.3.1.1 ISA Relationships

An ISA relationship is a specific kind of semantic relationship between concepts. If “A” ISA “B,” then “B” is the more generic concept and A is the specific concept. Establishing this kind of relationships is also referred to as generalization. The opposite or inverse of generalization is called specialization.

The most significant property of an ISA relationship is that of inheritance. All that is specified to be true about the generic concept is also true for the specific concept. That means that all attributes, their values, and constraint (rules) are inherited from the more generic level concept down to the more specific level concept as are all relationships in which the more generic level concept participates.

The subtypes that result from a particular specialization of a concept can be non-overlapping. Consider, for instance, the specialization of Product into Engraved Product and Standard Product (see Fig. 8.33). This states that no single product can be both engraved product and standard product, at least not at the same time. Such a specification is called total.

A specialization is total when all the instances of the generic type are members of one specific type, i.e., when the specialization is a partition of the generic type. When the specialization is partial there are instances of the generic concept (type) that is not a member of any of the subtypes. For example customer has two subtypes e-shop customer and anonymous customer, but more subtypes are possible as well.

8.3.1.2 PartOF Relationship

A PartOF relationship or an aggregation is a special form of semantic relationship, where the interrelated concepts are “strongly and tightly coupled” to each other. The aggregate concept is an assembly of parts, and the parts are components of the aggregate. The component concepts are often subordinate to the aggregate concept.

The most typical example of an aggregation is a part dependency, where the part at the top level consists of a number of components, and where each or some of these components at the next level are seen as aggregates, which in turn have parts.

The PartOF relationship construct is included in the Concepts Model for reasons of convenience, making it possible to use it whenever it is considered natural and rewarding to see and operate on something as part of a hierarchy or a structure of components.

The example in Fig. 8.34 shows that an off-line marketing campaign consists of a component structure. It is defined to have three components: a printed advert, a brochure, and a poster. A brochure in turn consists of own content and third-party content.

8.3.2 Notation

Notation of the Concepts Model is shown in Fig. 8.35.

8.3.3 Example of a Concepts Model

8.3.3.1 Modeling the Current Situation (AS-IS Model)

A4Y sells accessories in the form of physical products. A product (Concept 6) is based on sample blanks (Concept 14) and can be engraved (Concept 8) or be resold as a standard product (Concept 7). Sample blank, also called pattern blank, is a basic component that can be manufactured into a product if it is faultless. If a production order for the production of standard products exists, in the first step a sample is minted or produced using a laser. Subsequently, the sample is passed on to production, if it shows no flaws (Concept 15). The example is shown in Fig. 8.36.

All information and properties that have been defined for the concept “Product” also apply to the refinement of this concept, i.e., “Product with engraving” and “Standard product.” Since there are no further refinements, a total ISA relation has to be used here. Once the requested product is produced, it can be sold.

A pattern blank consists of different components (Concept 11), which are delivered by suppliers (Concept 50). The selection of suppliers is conducted by an Internet search (Concept 51). Among other reasons, this search will be initiated if the number of parts in stock (Concept 49) drops below the threshold of 500 items—this is expressed with Rule 16 (see Fig. 8.37). In the future, the company wants to introduce a supplier relationship management (SRM) in order to establish long-term relationships to suppliers and ease the task of supplier selection. For assessing and selecting suppliers a number of criteria were defined; see Concept 52 and its specializations.

The company has a certain budget available to conduct marketing measures. These measures are divided into online (Concept 26) and off-line marketing (Concept 27). In connection with both concepts, a number of measures are carried out, which are linked using partial PART_OF relations to the concepts. For example, the off-line marketing consists of sales pitches (Concept 28), the creation and distribution of brochures (Concept 29), and posters (Concept 30). The online marketing is divided in a similar manner into the concepts search engine optimization (SEO) (Concept 31), search engine marketing (SEM) (Concept 32), and newsletter (Concept 33). The division of marketing activities in the concept model is shown in Fig. 8.38.

8.3.3.2 Modeling the Future State (the TO-BE Model)

With respect to the future development of A4Y it showed that the concept model does not require substantial modification, as the planned changes in processes and objectives do not have serious impact on the concepts.

However, the company wants to establish a defined number of regular suppliers when introducing a supplier relationship management system (SRM). The intended effect is to avoid the time-consuming Internet search by establishing a network of regular suppliers. Due to this measure, Concept 51 is replaced by the new concept “Selection of regular suppliers” (Concept 67); see Fig. 8.39.

8.3.4 Developing and Refining the Concepts Model

It is important to understand that in the real world there may be many more relationships between concepts, but not all of them are relevant and necessary to present in the Concepts Model. Deciding on the relevant concepts and relationships depends on the modeling scope. The Concepts Model includes components, among others, that represent information, needed by or produced by processes in the Business Processes Model. Therefore, if there is a need for some process of the Business Processes Model, for instance, “Search for availability of a book in Library’s Catalogue,” then the Book and its Copy must be included in the Concepts Model, and their relevant attributes stated.

Note that the inclusion of the information in the Concepts Model does not imply realization in a computerized information system. It may be manually produced, disseminated, and maintained as well.

Whether concepts such as supplier and stock should be included as a component of the Actors and Resources Model depends on whether the concept is involved in any relationship as an actor or a resource which has to be documented with respect to components of the Actors and Resources Model or other models and their components. One such relationship could be that we later wish, in the Technical Component and Requirements Model, to state some information system requirements concerning the Actors and Resources Model resource “stock.”

Above we have exemplified a concept that, with different interpretations and different uses, can appear in different sub-models. It is important to distinguish sharply between these different uses and to put components in the appropriate models at the start, before the models grow too large and confusing.

In the Concepts Model we may use “real entities.” Experience has shown, however, that when performing modeling operations, it may be very illustrative, and supportive for human understanding, if the Concepts Model can play the role of a “dictionary of concepts.” General concepts like “Profit,” “Marketing,” “Sales Effort,” “Customer Value,” and “Productivity” can sometimes be needed to be documented, and their relationships discussed. It can happen that these concepts are introduced in texts of goal statements in the Goals Model, and need further definition and discussion.

Perhaps it is important to discuss different types of “Productivity” by using specialization relations, and to discuss how the components are related to “Profit” or some specialization of it. Note, however, that these concepts, if not further refined as “data,” will not appear as information consumed or supplied by processes in the Business Processes Model.

While modeling concepts there several driving questions that can be used to facilitate the modeling process; see Table 8.3.

Table 8.3 Driving questions for concept modeling

Full size table

8.4 Business Process Model

The Business Process Model is designed for analyzing the processes and flows of information and material in the enterprise. Process can be decomposed into subprocesses. Components of the Business Process Model are primarily motivated by components of the Goals Model as well as enable goals of the Goals Model to be achieved.

The Business Process Model describes the organizational activities, i.e., the functions and processes of the enterprise. The core of the enterprise is the set of processes, contributing to the value of the enterprise. For achieving a good abstraction and overview, the Business Process Model permits full freedom of decomposing processes into subprocesses, etc., to any level. Depending on the purpose of the modeling, the processes described can be existing, or future, planned processes.

8.4.1 Components of the Business Process Model

The components of the Business Process Model are similar to most process modeling approaches. Its main components are process, external process, information set, and material set.

Process is a collection of activities that:

Consumes input and produces output in terms of information and/or material,
Is controlled by a set of rules, indicating how to process the inputs and produce the outputs,
Has a relationship to the Actors and Resources Model, in terms of the performer of, or responsible for a process, and
As an instance of a Business Process Model is expected to consume, when initiated, a finite amount of resources and time.

External process is a collection of activities that are:

Located outside the scope of the organizational activity area in focus,
Communicating with processes or activities of the problem domain area, and are
Essential to document.

External processes sometimes can be considered as sources or terminators for some information or material flows. A typical example of external process may be a customer process that requests for certain library service or receives the service.

Information or material set is a set of information or material sent from one Process or External Process to another process.

The contents of Material and Information flows between processes are described by referencing them to their definitions in the Concepts Model where they can be decomposed if necessary. Information or material flows must have at least one sending Process or External Process and at least one receiving Process or External Process.

8.4.2 Notation

The Notation of the Business Process model is depicted in Fig. 8.40.

8.4.3 Process Decomposition

The higher level processes should be separated from the lower level processes with a decomposition mechanism. This means that a process is broken down into several subprocesses, each of them performing a part of the process. Each subprocess can in turn be decomposed into subprocesses. In theory this can be done until a level of atomic actions is reached. In most cases such level of detail is impractical and even if there is no maximum level of decomposition depth it is suggested to avoid unnecessarily complex structures. In most cases three or four levels of decomposition are sufficient. The basic principle of decomposition is shown in Figs. 8.41 and 8.42.

In Fig. 8.42 Process 1 is decomposed into three subprocesses, each of them performing a different part of the main process. Note that the incoming and outgoing information sets are the same on both decomposition levels.

8.4.4 Example of Business Process Model

8.4.4.1 Modeling the Current Situation (AS-IS Model)

Using off-line and online marketing (terms in the Concepts Model), the customer (Role 2) is made aware of the company’s products. The customer has two options to choose a product. The first is during a sales pitch with an employee in A4Y’s shop, and the other one is using the product catalogue search in the e-shop (Process 2). The catalogue is maintained (Process 1) by the IT staff (Role 1), which includes updating the information (Information Set 1). If the customer has chosen a product (Information Set 8) and a customer profile exists (Process 24 and Information Set 11), the customer can place an online order (Process 3). However, if the customer profile is missing, it must be created before ordering (Process 23). This relationship is shown in Fig. 8.43.

Process 23 consists of several subprocesses. In order to create a customer profile, the customer must provide certain personal information (Information Set 33), including the name (Information Set 33.1), the address (Information Set 33.2), and the desired payment methods (Information Set 33.3). This information is verified subsequently (Process 23.2, 23.3, 23.4) and stored (Information Set 11) (Fig. 8.44).

As soon as manufacturing of the product ordered by the customer is finished, a shipping order (Information Set 3) is commissioned. The foreman delivers the ordered goods to the shipping service providers. In order to make this process more efficient, the company plans to establish long-term contracts with shipping service providers, which lead to a different way of shipping the goods: instead of separate shipping orders for each product and varying schedules for collecting the goods, the shipping service provider will collect the goods according to a predefined schedule (see Fig. 8.45).

8.4.4.2 Modeling the Changes (TO-BE Model)

The development of the “TO-BE” business process model shows that no significant changes of the AS-IS situation are required for the future development of the company. Only two modifications of the AS-IS model have to be made: The management of A4Y decides to extend and elaborate its online presence with a particular emphasis on online marketing; hence an additional process, the social media marketing (Process 15.4; see Fig. 8.46), is added to the online marketing. This step is motivated by the intention to establish an online presence in social networks, as they are enjoying a growing popularity.

The second change concerns the shipping of products. As described in the AS-IS model, the foreman currently has to deliver the products to the different shipping service providers. Instead, the management intends to establish contracts with the shipping service providers, which includes a pickup service of the products by the service providers from the branches of A4Y two to three times a week. Thus, Process 20 is removed from the target model and an External Process 1 “Shipping of products” is introduced. This external process is to be carried out by the shipping service providers (External Process 1 in Fig. 8.47).

8.4.5 Developing and Refining the Business Process Model

Components of the Business Process Model must be motivated by the enterprise goals defined in the Goals Model. Processes of the Business Process Model are performed on, or with, information described by components of the Concepts Model, such as concepts, attributes, and relationships, or Concepts Model component groups. Components of the Business Process Model also are closely related to all components of the Actors and Resources Model. The relationships between Business Process Model and Actors and Resources Model can be of many different types, such as:

actor A performs process P,
actor A is_responsible_for process P,
actor A supports process P or
and actor A is_a_consultant_to process P.

In general, each Business Process Model component must, at some decomposition level, have a relationship defined to the Actors and Resources Model.

It is important that modelers observe that the Business Process Model describes processes of the business area, and not systems or organizational units. In order for a component to qualify for inclusion in the Business Process Model, it must describe a set of possible processes, that all can be perceived to have a start and a stop time. At higher abstraction levels, this set of processes can be reasonably well defined. The main distinctions between a process (type) and an Actors and Resources Model component (actor) are:

Temporal:

When an Actors and Resources Model component is created, it exists until it is disposed of or excluded from the environment.
The Business Processes Model describes types of processes, for which instances exist for a limited time.

Instantiation:

The Actors and Resources Model contains components at the instance level, e.g., organizational units, individual resources or human actors, and roles.
The Business Processes Model describes processes at the class level.

Some driving questions in Business Process modeling are given in Table 8.4.

Table 8.4 Driving questions for business process modeling

Full size table

8.5 Actors and Resources Modeling

The Actors and Resources Model defines the types of actors and resources, or individual actors, involved in enterprise activities. The Actors and Resources Model describes how different actors and resources are related to each other and how they are related to components of the Goals Model, e.g., goals, and to components of the Business Process Model, i.e., processes. It describes the existing or future business system in terms of human as well as nonhuman resources. It allows the inclusion of a description of a socio-technical system to be developed that cannot be depicted in the Business Processes Model and Concepts Model alone.

By studying the Actors and Resources Model and its relationships to other models, we can see how different actors exhibit dependencies between themselves, e.g., an actor may be dependent on a number of other actors with respect to performing a certain task or process.

8.5.1 Components of Actors and Resources Model

The Actors and Resources Model defines the actors and resources involved in the enterprise activities, articulated in the Business Process Model, or actors related to other models or to the development of an information system. Actors and resources can be individuals, organizational units, nonhuman resources, and roles.

Individual denotes a person in the enterprise. For example: John Smith, Anne Dewey, etc. Individuals are identified by their name. However as names may not be unique they should be used sparingly. Essential persons with specific skills or roles are included in the Actors and Resources Model insofar as they clarify in some way and add meaning to the model and its relationships. Individuals may play roles and belong to organizational units. Individuals can, however, be related to other individuals, to roles, organizational units, and nonhuman resources, by binary semantic relationships. The ISA and PartOF relationships are not relevant for individuals.

Organizational unit can represent every organizational structure in the enterprise such as group, department, division, section, project, team, subsidiary, etc. For example: Planning Department, Technical Team, Telecommunications Group, Inventory Department, Computing Subsidiary, etc. Being actors, Organizational units can have subunits. They may also play roles and have other actors belonging to them. There are no predefined inter-model relationships from or to organizational units to any other non-actor model component of the enterprise model. Organizational units can, however, be related to other organizational units, to individuals, roles, and nonhuman resources by binary semantic relationships.

Nonhuman resources can be types of machines, systems of different kinds, equipment, etc. For example, “Volvo S80,” “FAX machine,” “MS Word 2011” are Nonhuman resources. Being actors, Nonhuman resources may have components and may be generalized or specialized. Nonhuman resources may also play roles, e.g., Nonhuman resource “Volvo S80” plays a Role “people carrier.” Of course, the same Role in a different situation may be played by the different Nonhuman resource “Train X2000.” Nonhuman resources may be resources for processes. They can also be related to other nonhuman resources, to individuals, organizational units, and roles by binary semantic relationships.

Roles may be played by the Individuals and Organizational units in different contexts. An organizational unit may for instance play the roles of administrator and authorizer in the same context. It may be important to identify requirements depending on the role they have. For example: Author, Approver, Controller, Supervisor, Manager, Project Leader, Process Owner, etc., are roles played by individuals, organizational units, or nonhuman resources. They may belong to one or more organizational units, and be related to other roles, to individuals, organizational units, and nonhuman resources by user-named binary relationships. Roles can be generalized or specialized, and be component roles. Roles may perform processes and be responsible for performing of processes and achieving of goals. They may also define goals.

Binary relationships are used for describing different kinds of relationships between its components. The two main purposes of binary relationships between Actors and Resources Model components and components of other sub-models are the definition of:

Responsibility: a relationship between actors, between actors and business processes, business rules, and goals. Responsibilities can be delegated or transferred among actors. Responsibilities can be:

Organizational: related to the freedom of an actor to make decisions for other enterprise entities, such as goals, rules, resources, business processes, and other actors. Responsibility here also means accountability for any malfunction, damage, or low performance of enterprise entities. Organizational responsibilities can be represented with the following relationships:
- actor_defines_goal
- actor is_responsible_for goal
- actor defines_rule
- actor is_responsible_for rule
- actor is_responsible_for resource
- actor is_responsible_for business_process
- actor owns_resource
- actor monitors_another actor
Operational: are related mainly to the execution of tasks and they indicate that an actor is committed to perform a business process or that a business process is assigned to an actor. We can represent operational responsibilities with the relationship, “actor performs process,” that means that performer of a task has the responsibility of properly carrying it out.
Dependency: is a relation among enterprise actors. An actor depends on another actor for something that can be either a resource or a business process. Two types of dependency can be identified:
- Operational: concerns dependencies created by the flow of work. For example, actors depend on others to get and use a resource that is needed by the business process they perform, or an actor may wait for an output from another actor’s process, etc.
- Authority: concerns dependencies created because of organizational rules, regulations, or relationships of authority and power. For example, a user needs a password to work in a computer system, a clerk needs permission to use international telephone lines, etc.

Dependency can be simultaneously of the operational and authority type.

Two specific relationships are also part of the Actors and Resources Model:

ISA is used to describe generalization relationships between roles of the Actors and Resources Model. The expression “A ISA B” states that components playing the role B also play the role A. Properties and relationships owned by A are inherited by B. This means, for instance, that if A is operating process P, then B is also operating process P.
PartOF, used as “B PartOF A,” states that B is a component of A. We can imagine that these types of relationships can be useful in modeling organizational hierarchies, for instance that OrgUnit X PartOF OrgUnit Y, or expressing component relationships of technical systems.

8.5.2 Notation

The notation of the Actors and Resources Model is depicted in Fig. 8.48.

8.5.3 Example of the Actors and Resources Model

8.5.3.1 Modeling the Current Situation (AS-IS Model)

In the actors and resource model, the case company A4Y is represented as the top organizational unit (OU 1), which is headed by a CEO (Role 4). All other organizational units (OU 2, OU 3, OU 4, OU 5) are part of OU 1. The role of the CEO in the company is taken by the individual “Alexander Mueller” (Individual 1). Furthermore, the role of the CEO may also act as sales agent in relation to customers (Role 2) or communicate with external suppliers (Role 8) regarding orders for his company. Figure 8.49 shows an example of the actors and resources model.

Dependencies between the IT department and the “e-shop” (Resource 1) interact with the information system (Resource 2), which is controlled by the IT department (OU 3). The IT staff (Role 1) in the IT department maintains the e-shop, i.e., the provided information is always kept up to date and potential problems are promptly solved (see Fig. 8.50).

If the customer orders a product with an engraving, this order is sent to the production organization (OU 5) and received by the employees of the production organization. Subsequently, the blacksmith (Role 5) is involved in the production process. If goods ordered from an external supplier (Role 8) arrive, the delivery is received and checked by the foreman (Role 7). Both roles, the foreman and the blacksmith, belong to the production organization (OU 5). Once the production process is finished by the blacksmith, the foreman can handle the shipping. He delivers the goods to selected shipping service providers (Role 9). These dependencies are illustrated in Fig. 8.51.

8.5.3.2 Modeling the Changes (TO-BE Model)

Based on the model of the current situation it is decided that no major change is needed for the future development of A4Y. The management, however, opts for two minor changes. The delivery of products to the shipping service providers shall no longer be performed by the foreman. Instead, a contract with the shipping service providers (Role 9) shall be established including a pickup service two to three times each week, i.e., the foreman is contact point for the pickup of the products to be delivered (role 7) (see Fig. 8.52).

Furthermore, it is decided by the management to outsource the e-shop and other information systems of the company to cloud providers (OU 6). Consequently, an external information system (Resource 3) has to be established in the future, located at the cloud provider. This information system includes the aforementioned e-shop as well as other systems to be used in the company, such as a logistics system, SRM or CRM. These systems are intended to interact with the company’s internal information system (Resource 2), which is controlled by the IT department (OU 3) (see Fig. 8.53). However, critical IT systems, such as the cash register and inventory system, remain included in the company’s internal information system (Resource 2).

Although the e-shop will be outsourced, the maintenance of the shop information will still be performed by the company’s internal IT staff (Role 1). This also includes the possibility to perform extensions and further development of e-shop functionality.

8.5.4 Developing and Refining the Actors and Resources Model

Roles played by units or individuals can also be actors as can nonhuman resources of different kinds, for instance, hardware or software systems or components. Links between the Business Process Model components and the Actors and Resources Model components describe the kind of relationship that exists between a particular process and an actor or a resource.

Driving questions for facilitating the modeling process and improving the quality of the model are given in Table 8.5.

Table 8.5 Driving questions for actors and resources modeling

Full size table

8.6 Technical Components and Requirements Modeling

What has been elaborated by the Goals Model, Business Rules Model, Concepts Model, Business Processes Model, and Actors and Resources Model is an initial description of the enterprise’s design in terms of its goals, its business rules, its processes, its “system of actors,” and its information entities. If we wish to develop an information system to support the processes, then there is a need to deal with technical information system requirements, initially in a less formal way.

Therefore, the 4EM approach includes a simple sub-model to describe, and to relate to each other, initial, unclear information system requirements. This sub-model resembles, in structure, the goals model, and, indirectly, information system models. Initially one needs to develop a set of high-level requirements or goals, for the information system as a whole. Based on these, the information system is structured in a number of subsystems, or technical components. For each subsystem, a set of goals is then defined that are more specific as well as requirements. These goals and requirements have to be derived from, and be consistent with, the earlier sub-models discussed above. The Technical Components and Requirements Model can also be used to capture the existing information systems and IT-components in an enterprise. To capture the as_is situation is of particular importance, if future developments of the IT-landscape in an organization will be based on the existing components. The Technical Components and Requirements Model is an initial attempt to define the overall structure and properties of the information system to support the business activities, as defined in the Business Process Model. In Fig. 8.60 the relationships between the Technical Components and Requirements Model and other sub-models of the enterprise model are shown.

8.6.1 Component of the Technical Components and Requirements Model

The Technical Components and Requirements Model includes the following types of components—IS goal, IS problem, IS Requirement (that is further specialized into IS Functional and IS Nonfunctional Requirement) and IS Technical Components.

Information System Goal is used for expressing high-level goals regarding the information system and/or subsystems or components. They may be expressed with measurable or nonmeasurable properties, aims, visions, or directions. Information system goals are typically motivated by activities of the Business Processes Model, and may be motivated by goals in the Goals Model.

Information System Problem is used for expressing undesirable states of the business or of the environment, or problematic facts about current situation with respect to the information system to be developed. Information system problems typically hinder information system goals.

Information System Requirement expresses a requirement for a particular property of the information system to be designed. The property can be functional or nonfunctional. A requirement expression always refers to components of the Business Processes Model and may refer to components of the Actors and Resources Model and the Concepts Model. Information system requirements may support or hinder information system functional or nonfunctional requirements.

Information System Functional Requirements are used to express definite requirements regarding a functional property of the information system or some of its subsystems. Functional requirements must be clearly defined with reference to the Concepts Model. Preferably, a formal or at least a semiformal way of expressing a requirement may be needed. Every data concept, referred to in the functional requirement, must be defined as a component of the Concepts Model. Functional requirements can be directly supported by information system goals, but they are more often seen as refinements of the stated information system requirements. Functional requirements are supported by components of the other sub-models, in particular the Business Processes Model, but also the Goals Model. A functional requirement must be related to a process or a subprocess, defined in the Business Processes Model.

Information System Nonfunctional Requirements are used for expressing any kind of requirements, constraints, or restrictions, other than functional, regarding the information system to be built or the process of building it. Nonfunctional requirements are not always definite and can sometimes be negotiated and relaxed. It may, for instance, happen that two nonfunctional requirements cannot both be satisfied in the same full degree, due to some financial restrictions. In this case, the level of achievement of these requirements must be negotiated. Some nonfunctional requirements may hinder other nonfunctional requirements, goals, and information system problems. They may support, or be supported by, information system goals and information system requirements. They can be related to, and be supported by, components of the Goals Model, and processes in the Business Processes Model. A Nonfunctional requirement can be related to a component on the Actors and Resources Model with relationships “involved_actor.”

Information System Technical Components are used for expressing any kind of part of the existing or envisioned architecture of the information system needed for supporting the enterprise design specified in other sub-models. There can be components, packages, services, or even entire systems. The purpose of this component is to specify the required IS components on a crude level from a point of view of a business actor.

Relationships between these types of components of the types are supports, hinders, and operationalization relationships AND, OR, AND/OR. They are defined and permitted in the same way as for the Goals Model. Between IS technical components a PART_OF aggregation relationship similar to the one in Concepts Model is also permitted. Between IS technical components and IS goals binary relationships of type has_goal and has_requirement are also possible.

8.6.2 Notation

The notation of the Technical Components and Requirements Model is depicted in Fig. 8.54.

8.6.3 Example of Technical Components and Requirements Model

8.6.3.1 Modeling the Current Situation (AS-IS Model)

In order to guarantee a smooth manufacturing process of the products, certain technical components (TC) are required. The main component is an information system (TC 1), which consists of the components “Database system” (TC 2), “e-shop system” (TC 3), “Cash system” (TC 4), “Ordering system” (TC 5), and the “Inventory system” (TC 6). There is also the requirement of the company that the “Production system” (TC 5) and the “Cash system” (TC 4) must support the “Inventory system” (TC 6). This is to ensure that the inventory information always is up to date, i.e., whenever the production process is completed or sales of products are registered the inventory information has to be updated in order to avoid availability problems of goods. The overall structure of the information system is illustrated in Fig. 8.55.

Management also defined functionality of the “e-shop system” (TC 3) as required for the future. It is expected that this functionality will be provided by separate components, which can be used by the customers (see Fig. 8.56). A “Product catalogue search system” (TC 3.1) shall enable the customer to find the desired products faster in the variety of offered products. In addition, the “Ordering system” (TC 3.2) has the task to provide the customer the opportunity of online ordering. The third functionality shall offer supportive services (TC 3.3) to customers, which e.g. include supplementary product information or maintenance recommendations. Thus, these three components are a necessary support for the e-shop system (TC 3).

Furthermore, the analysis of the current situation reveals that one of the existing technical components has shortcomings and causes delays in the business processes. The mobile data collection (MDE) device (TC 7), which the employees have to use to capture register changes in the inventory, is outdated and no longer supports the daily work in a satisfactory manner. This technical component (TC 7) has a negative impact on the inventory system (TC 6), which is captured by using a “hinders” relationship. In addition to requirements regarding the technical components, management also defined functional requirements for future IT support. For example, the cash system (TC 4) should be able to create a customer profile (Functional Requirement 3), if a customer wants to place an order online. One of the nonfunctional requirements (Nonfunctional Requirement 1) specifies that authentication of a client must have been performed before this client can buy something online. These requirements and the technical components are illustrated in Fig. 8.57.

8.6.3.2 Modeling the Future State (TO-BE Model)

For the future, management decided to outsource the e-shop (TC 3) in order to save costs. Nevertheless, the e-shop (TC 3) should still remain integrated into the company’s internal information system (T 1) in order to allow for the IT staff of A4Y to maintain the entire system. When outsourcing the e-shop, a new technical component “external information system” has been added (see Fig. 8.58). The external information system (TC 8), which includes the e-shop, also has to support the cash system (TC 4), for example, for processing online orders.

Moreover, management plans the introduction of a logistics system (TC 7 in Fig. 8.59), such as an ERP system. This logistics system (TC 7) should capture all inventory changes in A4Y warehouse. If the number of items in stock drops below a defined minimum value, the system shall automatically send a message to the manager. This is also a functional requirement for the logistics system. Furthermore, the obsolete MDE devices (TC 7) shall be removed from the company and replaced by new equipment (TC 9).

8.6.4 Developing and Refining the Technical Components and Requirements Model

The Information System Goals and Problems modeling components are of the same type as Goals Model components. They have similar rules of naming and defining as Goals Model components. IS Goals, for example, should also start with “The goal is… ”. However, modeling IS requirements, one should remember that the focus in this sub-model must be on IS requirements and components, and not on general organizational or business issues. The components of this sub-model must also be measurable and verifiable, since they form the basis of the design of the Information System. Expressions like “better than,” “bigger than,” “the best,” etc., do not normally contribute to the understanding of a particular requirement. The components of this sub-model must be closely related to the components of the Business Process Model, Goals Model, or Business Rules Model.

The main driving questions in Technical Components and Requirements Model modeling are (Table 8.6):

Table 8.6 Driving questions for technical components and IS requirements modeling

Full size table

8.7 Relationships Between the 4EM Sub-models

The previous sections explained the purpose of each 4EM sub-model including components and relationships. The references, or links, between the 4EM sub-models were also mentioned but will be recapitulated in this section. The essential links between the sub-models are shown in Fig. 8.60.

In developing a full enterprise model, links between components of the different sub-models play an essential role. For instance, statements in the Goals Model might require that different concepts used in the statements have to be defined more clearly. This is done in the Concepts Model, and a link is specified between the corresponding Goals Model component and the concepts in the Concepts Model. In the same way, goals in the Goals Model motivate particular processes in the Business Processes Model. The processes are needed to achieve the goals stated. A link is therefore defined between a goal and the process to be carried out to achieve it. Links between models make knowledge traceable. It is, for example, possible to see why certain processes and information system requirements have been introduced. Figure 8.60 provides an overview of links between the sub-models.

Inter-model links are shown with dashed arrows. The example displayed in Fig. 8.61 illustrates different links between sub-models of the enterprise model.

Links between the Goals Model and the Concepts Model are normally used to explain a component of the Goals Model by pointing, from a Goals Model component, to one or more components of the Concepts Model referred to in the description of the Goals Model component. For example the Goal 2.1 “to develop both new products variants and versions” refers to concept 6 “Product.” In CM concept 6 is further explained.

Links between the Goals Model and the Business Processes Model typically relate to goals of the Goals Model to processes of the Business Process Model with a “motivates” relationship. For example: goal 2.2 “decreasing the time to market” could initially motivate a particular, high-level process in the enterprise, e.g., process 13 “Create a standardized product.”

Link types between the Goals Model and the Actors and Resources Model can mean several things: they may motivate or require the introduction of particular new actors, e.g., Customer Relations Agents (motivated by the goal to improve relationships with customers), or they may describe which Actors and Resources Model component are responsible to achieve a particular goal or defines it, etc. e.g. in Fig. 8.61 role 5 Blacksmith is responsible for Goal 2.2.

Links between the Goals Model and the Business Rules Model typically describe how different components of the Goals Model are implemented in terms of business rules of the Business Rules Model. For example, the goal 2.2 “to decrease time to market” is supported by a business rule 5 in Business Rules Model which states that the manufacturing process has to be completed within 2 weeks. There are more examples about Goals Model and Business Rules Model interconnection in Sect. 8.2 about business rule modeling.

Links between the Business Rules Model and the Business Process Model typically describe how processes of the Business Process Model are triggered by business rules of Business Rules Model. Business processes can also support business rules. For example process 13 “Create a standardized product” supports Rule 5. In Fig. 8.62 Rule 1 requires that customers should be signed in to place an order.

Links between the Business Processes Model and the Concepts Model are typically between Information Sets of the Business Process Model and components of the Concepts Model. See for example Fig. 8.62.

Links between the Business Process Model and the Actors and Resources Model typically describe how different components of the Actors and Resources Model are related to or involved in processes of the Business Process Model. Examples of link names are performs, is_responsible_for, and supports. For example, the role IT employee performs the process “Maintain online presence”.

Links between the Actors and Resources Model and the Business Rules Model typically describe how different components of the Actors and Resources Model are related to business rules in the Business Process Model. Common link names are: defines, is_responsible_for. For examples, see Fig. 8.63.

Links between the Technical Components and Requirements Model components and the other model components show why certain components exist and how they contribute to the business, i.e., they help the business and IT alignment. Most typically, business process and goals motivate information system goals, information system requirements, and components; see Fig. 8.64.

Model components may thus be linked in a number of ways. Which links should be established depends on the purpose of the particular 4EM project. Each produced Enterprise Model has a purpose and focus and the links within each Enterprise Model should therefore reflect these. Every link represents a statement, about the enterprise and possibly its information systems requirements. The semantics of every such link should be analyzed carefully. There is, however, a set of minimal links that should be defined for the representation to be considered complete. Figures in this section show some of the links between sub-models in the A4Y case. More about inter-models links from the perspective of model quality is given in Sect. 12.3.5.

8.8 Auxiliary Modeling Components

In previous sections we have described the 4EM sub-models and their components. In addition to these “ordinary” modeling components, it is sometimes useful to extend the enterprise model with some additional modeling components. The reasons for doing so may vary. One reason, for instance, is to improve the expressiveness of the model, or to allow more “freedom” for the modeling team. This is most often the case in the first modeling sessions, where the most important task is to generate initial ideas and to familiarize participants with the modeling process.

The types of modeling components one may add to any sub-model of EM are not strictly prescribed or defined. The only requirements are that everybody in the modeling group accepts and understands the meaning of these and that the modeling facilitator accepts that particular extension of the method as beneficial. Some of the added auxiliary modeling components can later be reformulated using the regular component types.

The most common additional modeling components modelers use are the following:

Comments—usually clarify some of the modeling components, or the whole model, or they contain some information that the modeling group found important, though difficult to express in terms of the ordinary modeling components. Comments may also contain directions for further elaboration of the model. If comments address some particular modeling component these are interlinked by arrows.
Development actions—used to express concrete actions for development of a model, refinement of a particular modeling component, or a group of components, or an action needed in the project, for example, in order to gain more knowledge about a certain design alternative.
Assumptions—used in a similar way to the ordinary modeling components. We use assumptions to express hypothetical types of facts. They can be lined to any other modeling component by types of links such as motivates, supports, hinders, conflicts, etc. Later, during the elaboration and refinement phases of the model, assumptions can be transformed to opportunities, problems, weaknesses, threats, goals, processes, information system requirements, etc.

Examples of some auxiliary modeling components are given in Fig. 8.65. However, these are not the only modeling components that may be included in the Enterprise Model. Sometimes it is even easier to replace a whole sub-model with another. For instance, if the notation of the Business Process Model is not suitable for a particular task, it can be replaced. However, the integrity of the inter-model links must remain consistent as previously described.

References

Halpin T, Morgan T (2008) Information modeling and relational databases, 2nd edn. Morgan Kaufmann, San Francisco, CA. ISBN 978-0-12-373568-3
Google Scholar
Object Management Group (OMG) (2000) Object constraint language specification, Chapter 7 of OMG unified modeling language specification, Version 1.3, March 2000
Google Scholar
Object Management Group (OMG) (2005) Unified modeling language (UML) 2.0
Google Scholar
Object Management Group OMG (2008) Semantics of business vocabulary and business rules (SBVR), version 1.0
Google Scholar

Download references

Author information

Authors and Affiliations

University of Rostock, Rostock, Germany
Kurt Sandkuhl & Matthias Wißotzki
Stockholm University, Stockholm, Sweden
Janis Stirna
University of Skövde, Skövde, Sweden
Anne Persson

Authors

Kurt Sandkuhl
View author publications
You can also search for this author in PubMed Google Scholar
Janis Stirna
View author publications
You can also search for this author in PubMed Google Scholar
Anne Persson
View author publications
You can also search for this author in PubMed Google Scholar
Matthias Wißotzki
View author publications
You can also search for this author in PubMed Google Scholar

Rights and permissions

Reprints and permissions

Copyright information

About this chapter

Cite this chapter

Sandkuhl, K., Stirna, J., Persson, A., Wißotzki, M. (2014). Sub-models of 4EM. In: Enterprise Modeling. The Enterprise Engineering Series. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-662-43725-4_8

Download citation

DOI: https://doi.org/10.1007/978-3-662-43725-4_8
Published: 07 July 2014
Publisher Name: Springer, Berlin, Heidelberg
Print ISBN: 978-3-662-43724-7
Online ISBN: 978-3-662-43725-4
eBook Packages: Computer ScienceComputer Science (R0)

Publish with us

Policies and ethics

Sub-models of 4EM

Abstract

Keywords

8.1 Goals Model

8.1.1 Components of the Goals Model

8.1.1.1 Goal

8.1.1.2 Problem

8.1.1.3 Cause

8.1.1.4 Constraint

8.1.1.5 Opportunity

8.1.1.6 Links Within the Goals Model

8.1.2 Notation

8.1.3 Example Goals Model

8.1.3.1 Modeling the Current Situation (the AS-IS Model)

8.1.3.2 Modeling the Company’s Vision (the TO-BE Model)

8.1.4 Developing and Refining the Goals Model

8.2 Business Rules Model

8.2.1 Components of the Business Rules Model

8.2.2 Notation

8.2.3 Example Business Rules Model

8.2.3.1 Modeling the Current Situation (AS-IS Model)

8.2.3.2 Modeling the Future State (TO-BE Model)

8.2.4 Introducing More Formality in the Business Rules Model

8.2.5 Developing and Refining the Business Rules Model

8.3 Concepts Model

8.3.1 Components of Concepts Model

8.3.1.1 ISA Relationships

8.3.1.2 PartOF Relationship

8.3.2 Notation

8.3.3 Example of a Concepts Model

8.3.3.1 Modeling the Current Situation (AS-IS Model)

8.3.3.2 Modeling the Future State (the TO-BE Model)

8.3.4 Developing and Refining the Concepts Model

8.4 Business Process Model

8.4.1 Components of the Business Process Model

8.4.2 Notation

8.4.3 Process Decomposition

8.4.4 Example of Business Process Model

8.4.4.1 Modeling the Current Situation (AS-IS Model)

8.4.4.2 Modeling the Changes (TO-BE Model)

8.4.5 Developing and Refining the Business Process Model

Temporal:

Instantiation:

8.5 Actors and Resources Modeling

8.5.1 Components of Actors and Resources Model

8.5.2 Notation

8.5.3 Example of the Actors and Resources Model

8.5.3.1 Modeling the Current Situation (AS-IS Model)

8.5.3.2 Modeling the Changes (TO-BE Model)

8.5.4 Developing and Refining the Actors and Resources Model

8.6 Technical Components and Requirements Modeling

8.6.1 Component of the Technical Components and Requirements Model

8.6.2 Notation

8.6.3 Example of Technical Components and Requirements Model

8.6.3.1 Modeling the Current Situation (AS-IS Model)

8.6.3.2 Modeling the Future State (TO-BE Model)

8.6.4 Developing and Refining the Technical Components and Requirements Model

8.7 Relationships Between the 4EM Sub-models

8.8 Auxiliary Modeling Components

References

Author information

Authors and Affiliations

Rights and permissions

Copyright information

About this chapter

Cite this chapter

Download citation

Share this chapter

Publish with us

Search

Navigation