Enterprise Dynamic Systems Control enforcement

of runtime business transactions

EEWC 2012, Delft

Sérgio Guerreiro1,2, André Vasconcelos2,3, José Tribolet2,3

1 Universidade Lusófona de Humanidades e Tecnologias, Escola de Comunicação, Artes, Arquitectura e Tecnologias da Informação,

Campo Grande 376, 1749-024 Lisbon, Portugal 2 CODE - Center for Organizational Design & Engineering, INOV, Rua Alves Redol 9, Lisbon, Portugal

3 Department of Information Systems and Computer Science, Instituto Superior Técnico, Technical University of Lisbon, Portugal

This work was partially supported by the Fundação para a Ciência e a Tecnologia (SFRH / BD/43252 / 2008). And also supported by PTDC/CCI-COM/115897/2009, MOBSERV.

UNIVERSIDADE LUSÓFONAde Hum anidades e Tecnologias

Humani nihil alienum

Presentation contents

1. Problem

2. Research setting

3. Design & implementation

4. Conclusion

2

The problem

Prescriptions to be followed

Clarifying inqueries

Po

pu

lati

on

Res

cue

Tea

m

Sound out situation

Assess Situation Injured

people?

Evacuation necessary ?

Assess location

Hea

lth

Car

eP

oli

ceC

entr

al c

om

man

d

Assess location

X

Secure injured

yes

Determine evacuation

area

Determine & allocate

evacuation target

yes

Warn population

no

no

Define & allocate

transportation

Evacuation procedure

+

Measure for objects in the

evacutation area+

Send suppliers to rescued population

+

X

Secure injured

Bac

ku

p H

ealt

h

Car

eF

ireF

igh

ters

Deallocate evacuation

target

Deallocate transportation

eSafe

Service

Provider (MSa)

eDeliveryPortal

Point of Single

contact (MSb)

Competent

Authority (MSb)

T01

rq

T01

ac

T01

T01

pm

T01

st

T12

rq

T12

ac

T12T12

pm

T12

st

T2

rq

T2

ac

T2\\

T2

pm

T2

st

T11

rq

T11

ac

T11

T11

pm

T11

st

T10

rq

T10

ac

T10

T10

pm

T10

st

T08

rq

T08

ac

T08T08

pmT08

st

T07

rq

T07

ac

T07

T07

pm

T07

st

T13

rq

T13

ac

T13 T13

pm

T13

st

T3

rq

T3

ac

T3

T3

pm

T3

st

T9

rqT9

ac

T9T9

pm

T9

st

T6

rq

T6

ac

T6

T6

pm

T6

st

0...1

0...1

0...1

A business transaction model prescription do not operate in reality. They are mainly used to share an understanding about the organization. However, Organizational actors do operate in reality, and organizational actors might or might not execute as prescribed.

3

Problem exemplification with Pizzeria case study prescribed Process Structure Diagram:

4

Customer

T01

rq

T01

pm

Order Taker

T01

acT01

T01

st

T02

rq

T02

ac

T02\\

T02

pm

T02

st

Baker

T04

rq

T04

ac

T04\\

T04

pm

T04

st

Deliverer

T03

rq

T03

ac

T03\\

T03

pm

T03

st

Customer

Problem exemplification with Pizzeria case study prescribed Information Use Table:

5

Object class, fact type, or result type

Action rule

PURCHASE T01/rq T02/rq T03/rq T04/rq

CUSTOMER T01/rq

C is the customer in P T01/rq T04/rq

PIZZA_KIND T01/rq T02/pm

total_price T02/rq

delivery address T04/pm

Joining PSD & IUT prescriptions

6

Business transaction representation

7

Business transaction representation

8 Available @ http://www.youtube.com/watch?v=MtrZxgIeJuQ

Observed business transaction (transition space misalignment)

Example:

Baker stating (T02/st) the pizza directly to the customer (T03/rq)

9

Customer

T01

rq

T01

pm

Order Taker

T01

acT01

T01

st

T02

rq

T02

ac

T02\\

T02

pm

T02

st

Baker

T04

rq

T04

ac

T04\\

T04

pm

T04

st

Deliverer

T03

rq

T03

ac

T03\\

T03

pm

T03

st

Customer

Customer

T01

rq

T01

pm

Order Taker

T01

acT01

T01

st

T02

rq

T02

ac

T02\\

T02

pm

T02

st

Baker

T04

rq

T04

ac

T04\\

T04

pm

T04

st

Deliverer

T03

rq

T03

ac

T03\\

T03

pm

T03

st

Customer

Deviation between the prescribed business

transaction model and observed execution.

Observed business transaction (transition space misalignment)

Available @ http://www.youtube.com/watch?v=dzaWhrQft1g

11

Example: The PURCHASE fact type is not shown to the Customer in T03/rq (Pizza for free?)

Observed business transaction (state space misalignment)

Object class, fact type, or result type

Process steps

PURCHASE T01/rq T02/rq T03/rq T04/rq

CUSTOMER T01/rq

C is the customer in P T01/rq T04/rq

PIZZA_KIND T01/rq T02/pm

total_price T02/rq

delivery address T04/pm

Deviation between the prescribed business

transaction model and observed execution.

12

Observed business transaction (state space misalignment)

Available @ http://www.youtube.com/watch?v=gWDMCdTlqDc

Other examples of applications where this problem is still not completely solved

1. Business processes run-time compliance

verification, e.g.: financial audit control

2. Organizational access control modes to govern the

user’s access to the artifacts of an organization, e.g.: Fine-grained

task-based security enforcement for complex WfMS

3. Governance of business processes in small and

medium-sized enterprises – requires too much

investment for a SME

13

Problem statement:

’How to design and implement dynamic systems control in business transactions operating in a run-time organizational environment, taking into account the misalignments between operational conditions and prescribed references as defined by the organizational models?’

14

Enterprise Dynamic Systems Control (EDSC)

Presentation contents

1. Problem

2. Research setting

3. Design & implementation

4. Conclusion

15

Separation of problems

① Observation: What are the principles that should be enforced to confer observation to the run-time business transactions?

② Decision: How to integrate the business rules concepts with the observed business transactions in order to decide upon the control action to take?

③ Controllability: What are the principles that should be enforced in the business transactions in order to enable its run-time control?

16

Hypothesis ① Actor’s qualification for executing business transactions

requires the knowledge of the prescribed DEMO business transaction models and the continuous observation of the run-time business transactions

② Business rules enforce higher-order control in the operation of the organization enabling the continuous organizational change

③ Actor’s qualification integrated with DEMO business transaction models allows the enforcement of control actions in the operation of the organization

17

Enterprise Dynamic System Control

Enterprise Governance

Observation Actuation

Qualification

18

Foundations

• Dynamic Systems Control (DSC)

• Enterprise Engineering (EE)

– Design & Engineering Methodology for Organizations (DEMO)

– Enterprise Governance

• Access control models (ACM), for exemplification purposes

19

Presentation contents

1. Problem

2. Research setting

3. Design & implementation

4. Conclusion

20

Main concepts Business transaction model (BTM), restrict the design freedom (Hoogervorst & Dietz, 2008) and are relevant to share a common understanding between the different stakeholders of an organisation (Land et al., 2009). (Dietz, 2006; 2007) defines BTM as: Run-time, BTM instances exist and are executed while the actors perform their activities.

Observation, “...a system is completely observable if every state variable of the system affects some of the outputs...” (Ribeiro, 2002)

Controllability, “...a process is said to be completely controllable if every state variable of the process can be controlled to reach a certain objective in finite time by some unconstrained control u(t)...” (Ribeiro, 2002)

Control cycle: Observe Business rules Control, “...is the organizational competence for continuously exercising guiding authority over enterprise strategy and architecture development, and the subsequent design, implementation and operation of the enterprise...” (Hoogervorst, 2009) 21

actor roles, specifying who is responsible for each part of the transaction, who initiates and executes it,

a transition space definition,

a state space definition,

aims at achieving a specific result.

EDSC – 2 types of actuation:

1. Change business transactions models prescriptions,

2. Change business rules because deviation is innovative.

22

Design of EDSC concepts in DEMO (Transition space)

A Transaction pattern with rollback between 3 parties:

For simplification one transaction is represented by:

Using DEMO theory and methodology to design the solution

Design of EDSC concepts in DEMO (Which transactions?)

For a time period P T01 Business rule definition T11 Business rule management T02 Model definition T12 Model management T03 Access definition T13 Access management T04 Observation of run-time session T05 Run-time control T06 Run-time access control T07 Run-time business rule control

Design of EDSC concepts in DEMO (Transition space)

A13

Access

provisioner

A12

Model

provisioner

A11

Business

rules

provisioner

A04

Interceptor

A01

Business

rule

manager

A02

Model

manager

A03

Access

controller

CA04

User

T13

T04

Observation of run-time

session

T11

Business rulemanagement

T12

Modelmanagement

Accessmanagement

Enterprise Governance

T01

Business rule definition

T02

Modeldefinition

T03

Accessdefinition

T05

run-time control

A05

Run-time

controller

A06

Run-time

access

controller

A07

Business

rules engine

T07

T06

run-timeaccess control

run-timebusiness

rule control

Design of EDSC concepts in DEMO (Which State space ?)

R05

R02

R12

R03

R06

R13

Access

ModelSession

Business

Rule

R01

R07

R11

Period

Period

Period

User

Role

U is mapped in R

and constrained by C

Constraint

R is mapped in P

and constrained by C

Permission

Static

Constraint

Dynamic

Constraint

URC

P RC

R is enforced in AR

P is enforced in FT

P is enforced in AR

Behavior

R is composed

of C and A

Rule Condition Rule Action

R C A

Operand

Operator

AR R

P FT

P AR

R is composed by

O1, OR, O2R O1 OR

R changes the RLR

The behavior B of R

with priority P

B P R

Priority

DEMO:

Elementary

Actor

Role

DEMO: Fact type

DEMO:

Transaction

Kind

DEMO:

Action

Rule

O2

RL

A

A

A

P

P

P

The run-time permission

of access is Permission

A P

The run-time role

of access is Role

A R

The run-time RPC

of access is RPC

A RPC

The run-time constraint

of access is Constraint

A C

The run-time URC

of access is URC

A URC

Access A have been

managed for period P

Access A has been

controlled for period P

Access A has been

defined for period P

P

P

P

BR

BR

BR

Business rules BR have

been managed for period P

Business rule BR has been

defined for period P

Business rule BR has been

controlled for period P

Model M has been

defined for period P

Model M has been

managed for period P

P

P M

M

S P

T is the transaction in M

M T

Session S has been

controlled for period P

Period

R04

Session S has been

observed for period P

P S

S in

RL

ID

S in

DC

ID

S in

UID

S in

AID

S in

FT

ID

S in

T

MODEL

DEFINITION

Design of EDSC concepts in DEMO (How is EDSC organized?)

Time Prescribed models

A13

Access

provisioner

A12

Model

provisioner

A11

Business

rules

provisioner

A04

Interceptor

A07

Business rules

engine

A02

Model

manager

A03

Access

controller

CA04

User

T04

Observation of run-time

session

Business rulemanagement

T12

Modelmanagement

Accessmanagement

Enterprise Governance

T01

Business rule definition

Modeldefinition

T03

Accessdefinition

T05

run-time control

A05

Run-time

controller

A06

Run-time

access

controller

T07

T06

run-timeaccess control

run-timebusiness

rule control

CPB14

CPB15

CPB16CPB17

CPB18

1

CPB15

CPB17

T13

A01

Business

rule

manager

T11

T02

CPB16

Observed vs prescribed models check

Management

Actors

Prescribed models

Observation

Presentation contents

1. Problem

2. Research setting

3. Design & implementation

4. Conclusion

29

Contributions

① The awareness to embed control between the business transaction models and its operation. Control is presented as a continuous orchestration of combined low-level and high-level control actions taken by the organizational actors while performing business transactions.

② A full white-box ontological solution to control the

operation of the run-time business transactions, using DEMO ontology

③ The identification and representation of the control

concepts that might be used in any DEMO business transaction model.

30

Conclusions Control and models are most of the times decoupled from the enterprise design. The practical consequences :

(i) the duplication of effort & (ii) designed models not aligned with control

As a summary, the control of the run-time business transactions is defined as the delegation capability of assuring that the responsibilities, competencies and authorities are being followed by the actors by the mean of the accountability and actuating in the predefined models. Accountability capability must be explicit considered in the design of the control of the organization.

31

Identified limitations

• EDSC theory development demands the usage of more case studies from the industry

• Lack of software tools to support the modeling and control of EDSC

• The high volume of data that is observed from the business transactions instances. This issue is not addressed yet.

32

Future research

• Experiment the solution in more case studies

• Facilitating the business rules definition and management

• Improving the interaction effect that exists between the business rules.

• Visual representation for better understanding of the operation

• Develop a full integrated control environment to be used by small and medium-sized enterprises.

33

Enterprise Dynamic Systems Control enforcement

of runtime business transactions

EEWC 2012, Delft

Sérgio Guerreiro1,2, André Vasconcelos2,3, José Tribolet2,3

1 Universidade Lusófona de Humanidades e Tecnologias, Escola de Comunicação, Artes, Arquitectura e Tecnologias da Informação,

Campo Grande 376, 1749-024 Lisbon, Portugal 2 CODE - Center for Organizational Design & Engineering, INOV, Rua Alves Redol 9, Lisbon, Portugal

3 Department of Information Systems and Computer Science, Instituto Superior Técnico, Technical University of Lisbon, Portugal

This work was partially supported by the Fundação para a Ciência e a Tecnologia (SFRH / BD/43252 / 2008). And also supported by PTDC/CCI-COM/115897/2009, MOBSERV.

UNIVERSIDADE LUSÓFONAde Hum anidades e Tecnologias

Humani nihil alienum