Dynamic Consistency between Value and Coordination Models

Dynamic Consistency Between Value and

Coordination Models – Research Issues

Lianne Bodenstaﬀ, Andreas Wombacher, and Manfred Reichert

Information Systems Group, Department of Computer Science,

University of Twente, The Netherlands

{l.bodenstaff, a.wombacher, m.u.reichert}@utwente.nl

Abstract. Inter-organizational business cooperations can be described

from diﬀerent viewpoints each fulﬁlling a speciﬁc purpose. Since all view-

points describe the same system they must not contradict each other,

thus, must be consistent. Consistency can be checked based on common

semantic concepts of the diﬀerent viewpoints. This is suﬃcient for equal

concepts, while weakly related concepts, e.g. related to runtime behavior

of viewpoints, have to be considered explicitly. In this paper we identify

dynamic consistency issues correlated to the runtime behavior between

value and coordination viewpoints on behalf of an example. In partic-

ular, an issue class on occurrence estimations of execution options and

an issue class on granularity diﬀerences in modelling are identiﬁed and

illustrated.

1 Introduction

Modelling inter-organizational business cooperations constitutes a crucial task

that can be done from diﬀerent viewpoints. Each viewpoint emphasizes an im-

portant aspect of the cooperation. In this paper two viewpoints are dealt with.

The value viewpoint gives an indication on the proﬁtability of the cooper-

ation. The value model describing this viewpoint models which objects of eco-

nomic value are exchanged between parties. Furthermore, estimations, e.g. on the

number of occurrences of an object of value, are modelled. The value model en-

ables talking about the commercial interests of the diﬀerent business actors and

abstracts from processes and object ﬂow, i.e., it models what objects of value are

exchanged but not how this exchange is realized. The coordination viewpoint,in

turn, represents the interactions and interdependencies between the cooperating

parties in terms of exchanged messages. The model describing the coordination

viewpoint represents how the actors in the model cooperate, i.e., it represents

the coordination of the exchanges. Together, the two viewpoints describe what is

exchanged of value between the parties and how these exchanges can be realized.

Multi-viewpoint descriptions of complex systems must maintain consistency

across viewpoints. To ensure both models indeed describe the same cooperation,

Supported by the Netherlands Organisation for Scientiﬁc Research (NWO) under

contract number 612.063.409 (Value-Based IT Alignment).

R. Meersman, Z. Tari, P. Herrero et al. (Eds.): OTM Workshops 2006, LNCS 4277, pp. 802–812, 2006.

Springer-Verlag Berlin Heidelberg 2006

Dynamic Consistency Between Value and Coordination Models 803

they have to be checked for consistency, i.e., we have to validate that the over-

lapping system speciﬁcation contained in both viewpoints is not contradicting.

Our work will build on the approach presented in [1]. So far, this approach

has solely considered consistency checking of static aspects, i.e., during design

time, and does not consider the runtime behavior of a model. Therefore, certain

aspects of a model, e.g. estimations made in the value model, are not considered.

However, these estimations should still be consistent with the dynamic aspects of

the coordination model. In this paper we refer to consistency of the static aspects

as static consistency and consistency of the dynamic aspects will be referred to

as dynamic consistency.

To illustrate relevant issues, we use a running example in which we abstract

from details for the sake of simplicity. This example consists of a health insurance

company which provides one-year insurance to its customers based on monthly

paid premiums. Insured customers can claim refunds for treatments they paid

themselves. Furthermore, the insurance company gets money from CVZ for every

paid refund to the customer. CVZ is a Dutch organization distributing tax money

from the government to the insurance companies. CVZ gets funding on an annual

basis in exchange for a proof of proper distribution of tax money.

The paper is structured as follows: Section 2 and Section 3 explain in detail

value and coordination modelling. After that consistency aspects are discussed

in Section 4. Section 5 identiﬁes research issues in dynamic consistency checking

between the value and coordination models. In Section 6 we discuss related work.

We end this paper with a summary and outlook in Section 7.

2 Value Model

For inter-organizational design the value viewpoint is especially important be-

cause all actors involved are proﬁt-and-loss responsible. The expected revenue

for every actor is calculated through a method of cost-beneﬁt analysis (like e.g.

Net Present Value (NPV) [2], Return on Investment [3] and Real Options Analy-

sis [4]). In this paper we use e3-value [5] because of its graphical representation.

However, the issues raised in this paper apply to value models in general. e3-value

uses NPV for cost-beneﬁt analysis.

We informally describe the semantics of basic e3-value concepts [5], based on

Figure 1. It depicts our sample business case as explained in the introduction as

an e3-value model. The example depicts four actors and eight value transfers.

For example, one value object, premium, is transferred from the customer to

the insurance company. Another value object, the insurance itself, is transferred

from the insurance company to the customer. These two transfers are in Figure 1

annotated with an ‘F’. A combination of value transfers in one transaction is

referred to as a value exchange.Ine

3-value a distinction is made between diﬀerent

kinds of value objects. A value object is either a product, service, money or

consumer experience.Inthisexamplethepremium is a value object of the money

type and the insurance provided by the insurance company can be considered

as a service.

804 L. Bodenstaﬀ, A. Wombacher, and M. Reichert

The consumer need is “having a health insurance for one year”. This is rep-

resented by placing the start stimulus at the customer. Now, the set of value

objects that needs to be transferred to fulﬁll the consumer need, consists of

all value transfers connected through the dependency path in the model. Every

month there are two possible sets of value transfers that can fulﬁll the consumer

need. Either the customer claims restitution for treatments he paid for himself

and he pays the monthly premium, or he only pays the monthly premium.When

the customer claims a restitution, the insurance company claims compensation

from CVZ. CVZ, in turn, gets its funding from the government. The health in-

surance company has multiple customers, represented as a market segment in

the ﬁgure.

Fig. 1. e3-value model, business case

In Figure 1, the twelve monthly payments for fulﬁlling one consumer need

are realized by adding an explosion element, annotated with ‘A’ in the ﬁgure,

associated with ratio 1 : 12. The choice between the two options for fulﬁlling

the consumer need is represented as an OR-split in the ﬁgure. After an OR-

split only one of the dependency paths is chosen. When the customer has not

received treatments that month, the path annotated with ‘C’ is chosen. The

two resulting value transfers constitute the ﬁrst set of transfers that can fulﬁll

the consumer need. If the customer did receive treatment that month, the path

annotated with ‘D’ is chosen. This path splits through an AND-split, represent-

ing a parallel occurrence of two or more dependency paths. In an AND-join

all entering dependency paths share the continuation of the dependency path.

Now, both value exchanges in the model between the insurance company and the

customer occur. To enable more than one restitution claim per month another

explosion element, annotated with ‘B’, is added. The insurance company claims

restitution from CVZ. These value transfers together, are the second set of value

transfers. The dependency path starting within CVZ represents the third set of

value transfers. In Section 5.4 the reason for intermitting the dependency path

is explained.

In the proﬁtability sheets, associated with the graphical representation of the

value model, the estimations are denoted. The market segment is quantiﬁed by

estimating the number of customers and the ratio on the explosion elements and

OR-split is set. For every monetary value transfer the quantiﬁcation is denoted in

the proﬁtability sheets. Now, the expected revenue for every actor in the model

can be calculated.

Dynamic Consistency Between Value and Coordination Models 805

3 Coordination Model

In a cooperation the messages between actors are exchanged in a particular

order which is not represented in the value model. The set of ordered tasks and

message exchanges is referred to as the execution sequence. The coordination

model is important to determine conceptual problems of the cooperation at an

early stage. Coordination model examples are e.g. Finite State Automata (FSA),

Petri Nets [6], Workﬂow Nets and ﬂowcharts.

In this paper we use Petri Nets [7] to represent coordination models because of

its graphical representation, formal semantics and the variety of available tools.

Although we use Petri Nets in this paper, the issues illustrated are modelling

technique independent. In Figure 2 the sample business case as described in the

introduction is represented as a coordination model in terms of a Petri Net.

First, the basic concepts of a Petri Net are introduced after which the business

case is explained in more detail.

The static part of the Petri Net consists of places (indicated as circles) and

transitions (indicated as rectangles) which are connected with each other through

arcs. Places represent message exchanges and transitions represent tasks. Fur-

thermore, the dynamic part of the Petri Net enables simulation of executions

in the model. A place can hold zero or more tokens. A distribution of tokens

over places represents the state of a Petri Net. A transition is called enabled,

i.e., it may ﬁre, if each place connected to the transition with an incoming arc,

holds at least one token. When a transition ﬁres a token is removed from each

of these places and a token is put in every place connected with the transition

CVZ GovernmentCustomer

Initiator

Insurance

Company

Premium

Initiator

Start

Payment

Funding

Payment

Complete

End

Restitution

12 Complete 12

Distribution_Proof

Fig. 2. Coordination model in terms of a Petri Net

806 L. Bodenstaﬀ, A. Wombacher, and M. Reichert

through an outgoing arc. A Petri Net and a distribution of tokens over places is

also referred to as an instance of a coordination model.

The message exchanges are modelled as places on the border between two

actors. After a token is put at the start place the ﬁrst initiator transition is

enabled. If the transition ﬁres, it enables initiator transitions for every actor.

The customer has two parallel execution sequences. The ﬁrst ensures the mes-

sage exchange of the payment of the premium to the insurance company. The

second sequence depicts the message exchanges of asking for a restitution to

the insurance company and of receiving the restitution payment from the in-

surance company. A recursive process, annotated with ‘1’ in Figure 2, is used

to allow claiming more than one restitution per month. After the customer has

paid all monthly premiums and received all restitution payments from the in-

surance company, he sends a complete message to the insurance company. For

every request of restitution by the customer, the insurance company sends a

payment to the customer as well as a request for restitution to CVZ. After the

insurance company received all payments from CVZ and has performed all pay-

ments to the customer, it sends a complete message to CVZ. CVZ receives, after

sending a message with proof of proper distribution, funding for a year by the

government. In parallel, CVZ receives messages from the insurance company for

restitutions and pays the restitutions to the insurance company. After the insur-

ance company exchanges the complete message and CVZ has received funding

from the government, a token is available in every place needed for enabling the

end transition to terminate the process.

4 Consistency Between Value and Coordination Models

The value model and coordination model sketched in the previous sections de-

scribe the same system from diﬀerent viewpoints. To ensure that both models

indeed are related to the same system, we have to check whether these two view-

points are consistent with each other. In [1] an intuitive deﬁnition of consistency

between a value and a coordination model has been deﬁned.

A value and coordination model are considered to be consistent if:

1. for every set of value transfers in the value model (dependency path in e3-

value), there exists an execution sequence in the coordination model such

that exactly the product/money value transfers contained in the set are

exchanged in the execution sequence, and

2. for every execution sequence in the coordination model, there exists a set

of value transfers in the value model (dependency path in e3-value) such

that the message exchanges contained in the execution sequence represent

product/money value transfers exchanged in the set of value transfers.

Note that the deﬁnition focusses on product and money value transfers, since

experience and service value transfers are not instantiating an explicit message

exchange. A message exchange represents a product value transfer, if the sender

and receiver of the message exchange equals the provider and the recipient of

Dynamic Consistency Between Value and Coordination Models 807

a value. With regard to the example in Section 2 the insurance value transfer

is a service, thus, can not be correlated with a message exchange. The money

value transfer premium in the value model is provided by the customer and

received by the insurance company. A corresponding message exchange sent by

the customer and received by the insurance company is also contained in the

coordination model.

The consistency deﬁnition mentioned so far ignores the dynamics of the mod-

elled system, resulting in estimations in the value model and observed behavior

in the coordination model.

5 Research Issues

In this section we demonstrate the need for dynamic consistency checking by

identifying major consistency issues that occur during runtime and could not

be identiﬁed during design time. We identify two classes of issues that concern

mismatches between value and coordination model.

The ﬁrst class concerns a mismatch between the estimations made in the

proﬁtability analysis and the execution semantics of the coordination model.

This class represents the mismatch between the estimated number of occurrences

and choices between sets of transfers in the value model and actual occurrences

and choices of message exchanges in the coordination model. The second class

deals with the mismatch of diﬀerent levels of granularity. Model boundaries

can vary among models with diﬀerent purposes although describing the same

system. Furthermore, within a model diﬀerent levels of granularity can occur.

This class covers mismatches of granularity diﬀerences between actors and value

transfers in the value model itself as well as between the value and coordination

model. Next, the issues are illustrated by the use of our example.

5.1 Issue 1: Number of Occurrences of a Value Transfer

For the fulﬁllment of one consumer need, a speciﬁc value transfer might occur

several times. This number of occurrences may be ﬁxed or it can be an estimated

average of occurrences of value transfers over periods of time and actors. When

estimating the proﬁtability of the cooperation in the value model, the number of

expected occurrences of each value transfer compared to a single consumer need

as well as the value of each transfer is estimated.

As an example, in e3-value the ratio between the consumer need and a value

transfer as well as the ratio between two value transfers is represented by an

explosion or implosion element. Regarding our example, the consumer need will

be fulﬁlled if the premium is paid twelve consecutive months. In the value model,

Figure 3(a), this is modelled by adding an explosion element with ratio 1 : 12.

We denote this ratio as a fixed ratio because it is the same with every customer

and every case. Furthermore, a customer uses its insurance by asking one or

more restitutions. This is again modelled as an explosion element with, in this

example, an associated ratio of 1 : 1,5. We denote this type of ratio as an average

ratio.

808 L. Bodenstaﬀ, A. Wombacher, and M. Reichert

The coordination model must contain a correspondence to the number of oc-

currences of value transfers as expressed in the value model. In the coordination

model a value transfer with a ﬁxed ratio is represented by forcing a ﬁxed number

of message exchanges to occur. In the case of an average ratio, a construction

for enabling repetitions of tasks is used.

Using a Petri Net-based coordination model, the ﬁxed ratio of monthly pay-

ments can be realized by adding an initiator transition for the customer. The

initiator transition inserts twelve tokens for further processing of premiums and

restitutions, represented in the upper part of Figure 3(b). Furthermore, to allow

claiming more than one restitution per month a recursive process, annotated

with ‘1’ in Figure 2, is used. In the coordination model there is no ratio repre-

sented between the monthly paid premium and the amount of restitutions as it

is done in the proﬁtability analysis of the value model, highlighted in the lower

part of Figure 3(b).

In case of having ﬁxed ratios consistency can be assured when designing the

models while having average ratios is an example of the ﬁrst class of issues.

(a) Value part

Initiator

End

......

(b) Coordination part

Fig. 3. Illustration of Issue 1

5.2 Issue 2: Choices in Sets of Value Transfers

If a consumer need can be fulﬁlled in multiple ways by carrying out diﬀerent

sets of value transfers, each of these sets is represented in the value model.

Further, every set is associated with an expected percentage of consumer needs

that will be fulﬁlled by using that speciﬁc set. In the example (see Figure 1),

the consumer need can be fulﬁlled by either using the possibility of restitution

during a monthly period or by not using this possibility. The ratio between these

options is estimated by the insurance company based on all its customers and

their restitution requests in previous years. This is again modelled in Figure 4(a)

where the estimated ratio is modelled as 1 : 3.

In the coordination model the diﬀerent ways of fulﬁlling a consumer need are

represented as decisions between tasks. InourPetriNet(seeFigure2),forex-

ample, the decision point of requesting a restitution is place p1 (see mark ‘1’). In

Figure 4(b), this part of the Petri Net is again depicted where the ratio between

arc a1 and a2 is not represented. Now the mismatch is that the proﬁtability

analysis of the value model is based on an average over a speciﬁc period of time

while during runtime of the coordination model either restitutions occur or not.

Dynamic Consistency Between Value and Coordination Models 809

(a) Value part

End

......

(b) Coordination part

Fig. 4. Illustration of Issue 2

(a) Value part

Customer Insurance

Company

(b) Coordination part

Fig. 5. Illustration of Issue 3

The average value can only be determined after the coordination process has

been executed several times.

Checking estimated ratios on choices in sets of value transfers with runtime

instances of the coordination model, belongs to the ﬁrst class of issues.

5.3 Issue 3: Granularity Diﬀerence Between Actors

As another issue, calculation methods in value modelling use estimations on the

number of occurrences of value transfers based on groups of actors. However, in

the coordination model every actor is modelled separately. Thus, the estimated

number of occurrences of value transfers based on an actor group in the value

model cannot be directly related to the real time number of occurrences of

message exchanges per actor in the coordination model.

In the value model, for example, the insurance company interacts with several

customers rather than a single actor. However, the coordination model represents

the interaction between the insurance company and a single customer. Thus,

the two models have diﬀerent levels of granularity of actors. This is an issue for

dynamic consistency checking because the average of restitutions in the value

model can only be compared with the average value calculated over several

instances associated to diﬀerent actors of a coordination model.

A schematic example of this issue is given in Figure 5. The coordination model

captures only a fraction of the market segment represented in the value model,

i.e., one customer.

5.4 Issue 4: Granularity Diﬀerence Between Value Transfers

Recall that the purpose of a model determines which information is represented

in a model. If, due to the boundaries of the model, one value transfer represents

810 L. Bodenstaﬀ, A. Wombacher, and M. Reichert

(a) Real life situation

(b) Modelled situation

Fig. 6. Valuemodel,Issue4

Government

Start

Initiator

Insurance

Company

CVZ

Fig. 7. Coordination model, Issue 4

the transfer of a value object concerning a market segment while another transfer

represents the transfer of a value object concerning one speciﬁc actor of that

market segment, a granularity diﬀerence between these value transfers occurs.

Since a value transfer is atomic and therefore can not be partly executed, the

relation between both value transfers cannot be straightforwardly calculated.

For example, for paying restitutions to all insurance companies, CVZ gets a

ﬁxed amount of funding from the government. This is a value transfer concerning

the market segment of insurance companies. The purpose of the value model is

to estimate the revenue of one speciﬁc actor of the market segment insurance

companies. Therefore, only a fraction of the value transfer between the govern-

ment and CVZ is relevant for our modelling purpose. This results in a diﬀerent

level of granularity between the value transfers between CVZ and the govern-

ment, concerning the market segment, and the value transfers between CVZ and

the particular insurance company. Therefore, the two interfaces of CVZ cannot

be related through a dependency path and thus the dependency path is broken

within actor CVZ as depicted in Figures 6 and 7.

In the coordination model this granularity diﬀerence is not present because

every actor is modelled separately. Thus, there is a mismatch between the gran-

ularity in the value model aﬀecting consistency with the coordination model.

Recall that the deﬁnition of static consistency is based upon matching the

execution paths in the coordination model and the dependency paths in the

value model (cf. Section 4). The separation of the dependency paths creates

two independent paths which must be related to a single execution path in the

coordination model. In the proﬁtability analysis, however, there is a relation

between both dependency paths. Thus, the estimations made in the proﬁtability

analysis on the relation of the dependency paths have to be checked after runtime

of the coordination model.

6 Related Work

Consistency between diﬀerent viewpoints is an important issue addressed often in

literature. In particular, there exist diﬀerent ways of deﬁning consistency within

a single viewpoint as well as between diﬀerent viewpoints. For instance in the

Dynamic Consistency Between Value and Coordination Models 811

workﬂow community diﬀerent notions of consistency mainly based on deadlock-

freeness have been deﬁned on all kinds of workﬂow models, like e.g. Workﬂow

Nets, guarded Finite State Automata, Coloured Place/Transition Nets, or stat-

echarts. Further there exist proposals to extend consistency between diﬀerent

models of the same viewpoint again focusing on deadlock-freeness like e.g. [8,9,10]

for the diﬀerent models.

Consistency between diﬀerent viewpoints has been addressed on diﬀerent lev-

els of abstraction. An analysis on the conceptual level has been provided in [11]

where the value and coordination viewpoints are compared based on the se-

mantic concepts used in the diﬀerent viewpoints. A human intuitive consistency

deﬁnition has been proposed in [12] which gives an understanding on what con-

sistency means without explaining how to check it. This intuitive deﬁnition has

been operationalized in [1]. However, this consistency deﬁnition does not consider

dynamic consistency.

Besides the above mentioned approaches on checking consistency between

viewpoints, there exist constructive approaches guaranteeing consistency of the

model derived from another model. For example in [13] an approach is proposed

to use an intermediate model as a bridge between a business model and a process

model. [14] propose a chaining method to derive from a business model a cor-

responding process model. The approach is based on associating diﬀerent value

transfer to oﬀ-the-shelf process patterns and combining these patterns. All these

constructive approaches focus on static consistency and do not address the issues

raised in this paper.

7 Summary and Outlook

In this paper we illustrate issues related to dynamic consistency checking be-

tween value and coordination models by the use of concrete examples. More

speciﬁcally, we identify two classes of major consistency issues. Furthermore, we

illustrated the need for a dynamic consistency deﬁnition, since current consis-

tency deﬁnitions, e.g. as deﬁned in [1], cannot check consistency between two

models for all aspects, i.e., dynamic as well as static aspects. The contribution of

this paper is the identiﬁcation and structuring of these issues. We continue this

research by investigating a dynamic consistency deﬁnition to resolve the issues

raised in this paper.

The authors thank Roel Wieringa and Jaap Gordijn for participating in dis-

cussions and giving their comments on earlier versions of this paper.

References

1. Zlatev, Z., Wombacher, A.: Consistency between e3-value models and activity

diagrams in a multi-perspective development method. In: OTM Conferences (1).

(2005) 520–538

2. Laudon, K., Laudon, J.: Essentials of Management Information Systems. 5 edn.

Prentice Hall (2003)

812 L. Bodenstaﬀ, A. Wombacher, and M. Reichert

3. Friedlob, G.T., Plewa Jr., F.J.: Understanding Return on Investment. John Wiley

& Sons, Inc. (1996)

4. Benaroch, M.: Managing information technology investment risk: A real options

perspective. Journal of Management Information Systems 19(2) (2002) 43–84

5. Gordijn, J., Akkermans, J.M.: Value-based requirements engineering: Exploring

innovative e-commerce ideas. Requirements Engineering 8(2) (2003) 114–134

6. Peterson, J.L.: Petri Net Theory and the Modeling of Systems. Prentice-Hall

(1981)

7. Jensen, K.: Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical

Use. Springer (1997) Three Volumes.

8. Aalst, W., Weske, M.: The P2P approach to interorganizational workﬂows. In:

Proceedings of 13. International Conference on Advanced Information Systems

Engeneering (CAISE), Interlaken, Switzerland (2001)

9. Wombacher, A., Fankhauser, P., Aberer, K.: Overview on decentralized establish-

ment of consistent multi-lateral collaborations based on asynchronous communi-

cation. In: Proc. IEEE Int’l. Conf. on e-Technology, e-Commerce and e-Service

(EEE). (2005) 164–170

10. Kindler, E., Martens, A., Reisig, W.: Interoperability of workﬂow applications:

Local criteria for global soundness. In: Business Process Management, Models,

Techniques, and Empirical Studies. (2000) 235–253

11. Gordijn, J., Akkermans, J., van Vliet, J.: Business modelling is not process mod-

elling. In: Conceptual Modeling for E-Business and the Web. Volume 1921.,

Springer LNCS (2000) 40–51

12. Wieringa, R.J., Gordijn, J.: Value-oriented design of service coordination processes:

correctness and trust. In: Proceedings of the ACM Symposium on Applied Com-

puting (SAC, New York, NY, USA, ACM Press (2005) 1320–1327

13. Andersson, B., Bergholtz, M., Edirisuriya, A., Ilayperuma, T., Johannesson, P.:

A declarative foundation of process models. In: Proc. of the 17th International

Conference on Advanced Information Systems Engineering. (2005) 233–247

14. Andersson, B., Bergholtz, M., Gr´egoire, B., Johannesson, P., Schmitt, M.,

Zdravkovic, J.: From business to process models - a chaining methodology. In:

CAiSE2006: Proceedings of the 18th International Conference on Advanced Infor-

mation Systems Engineering, Luxembourg (2006) 211–218