Convergence of Data and Processes Artifact-Centric Approach

Towards Convergence of Data and Processes
The Artifact-Centric Approach
Marco Montali
KRDB Research Centre for Knowledge and Data
Free University of Bozen-Bolzano
December 20, 2012 - Trento
Marco Montali Towards Convergence of Data and Processes December 20, 2012 1 / 45

Outline
• From activity-centric to artifact-centric BPM.
Credits to the ACSI team, in particular Marlon Dumas.
• Artifact-centric modeling.
Credits to the ACSI team.
• Foundations of artifact-centric systems and their formal veriﬁcation.
Joint work with Diego Calvanese and the KRDB “process+data”
subgroup, Giuseppe De Giacomo and colleagues, Alin Deutsch.

Traditional Process Modeling
• Structural modeling of the domain of interest:
conceptual models, domain ontologies, database schemas
UML, ORM, ER, . . .
• Behavioral modeling of the domain of interest:
activities, services, business processes
BPMN, EPC, UML, BPEL, SOA-related technologies, . . .
• A divide et impera approach, to attack the complexity of the domain.

Build-to-Order Process
1. Customer PO

1. Customer PO
2. order decomposition
Material PO
Line item
Customer PO

3. Selection and
interaction with suppliers
1. Customer PO
Material PO
Line item
Customer PO

3. Selection and
1. Customer PO
Material PO
Line item
Customer PO
4. material assembly

3. Selection and
1. Customer PO
Material PO
Line item
Customer PO
5. Shipment

3. Selection and
1. Customer PO
Material PO
Line item
Customer PO
5. Shipment
• Customer can cancel the order at any time (penalty management).

Traditional Approach
Manage
Cancelation
ShipAssemble
Manage
Material POs
Decompose
Customer PO
• Value chain construction

Traditional Approach
Manage
Cancelation
ShipAssemble
Manage
Material POs
Decompose
Customer PO
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
• Value chain construction
• Break-down of each phase into business functions.
• Further decomposition:
data component (domain description).
activities (units of work) + process component (control-ﬂow).
• Impedance mismatch: data and process divide!

BPMN ModelHigh‐Level BPMN Model 
4

Data Modeling
Customer PO Line Item
Work OrderMaterial PO
*
*
spawns
0..1
Material

Distribution of Responsibility
Supplier
ManufacturingProcurement/Supplier
Sales
*
*
spawns
0..1
Material

Cancelation Business Rule
Supplier
ManufacturingProcurement/Supplier
Sales
*
*
spawns
0..1
For each work order W
For each material PO M in W
if M has been shipped
add returnCost(M) to penalty
Determine
cancelation
penalty
Notify penalty
Material
Process Engine
Process State

Spaghetti Layer
Manage
Cancelation
ShipAssemble
Manage
Material POs
Decompose
Customer PO
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Customers Suppliers&CataloguesCustomer POs Work Orders Material POs

Conceptual Modeling vs Architectures
Architectures do not really help.
• SOA + Data Integration
Activity
Task Service
Entity Service Entity Service Entity Service Entity Service
• Enterprise Service Bus
Enterprise Service Bus
Activity
Entity Service Entity Service Entity Service Entity Service
Task Service

Conceptual Model or Conceptual Models?
• Business stakeholders have a single conceptualization of their
business.
• IT provides support for several loosely-coupled conceptual models of
the organization:
rules and policies;
analytics, dashboards, key performance indicators;
activity-centric business processes;
data.
• Lack of a coherent, holistic view:
process data redundancy;
business rules redundancy.

Rosenquist and Evolving, Living Entities (1982)
Seminar Database 75 and in the Asian Computer Year
Book.6 conceptual entity model
DATA ANALYSIS
Figure 2. The stages involved in data analysis and the information
Basic diagrammatic con
tives used
The documentation of o
systems and data structu
in a common informat
shown in Fig. 2. This co
system conforming to th
Data Dictionary Workin
The basic concept of t
paedia is the division of
and the relation between
(manual systems include
i.e. the four quadrants o
the total picture.
As illustrated in Fig.
quadrants will gradually
stages: (a) conceptual an
stage and (c) design stag
At the time of implem
documentation should b
for enquiry in order to ea
The information system
the stages mentioned ab
boundaries between the f
systems encyclopaedia
relationships covering a
process toentities and vic
which implement the fu
represented, (iv) progra
they utilize.
The information usedMarco Montali Towards Convergence of Data and Processes December 20, 2012 13 / 45

DATA ANALYSIS
B
t
T
s
i
s
s
D
p
a
(
i
t
q
s
s

•WE REAL WORLD
PROGRAM STRUCTURES
• Functional hierarchies
MA Jackson notation
PHYSICAL DATA STRUCTURES
• Extended Bachman notation
(depending on the implementation vehicle)
'THE IMPLEMENTATtON'
objecti
version
in App
'The im
of the
states
life cyc
tation
for sel
docum
functio
the me
and br
'The im
the do
tion o
benefit
implem
meta l
syntax
The
languaMarco Montali Towards Convergence of Data and Processes December 20, 2012 13 / 45

Business Artifacts on the Rescue
• Rosenquist’s vision did not become reality. . .
• . . . but the data-process divide problem became more and more
pressing.
Richardson (Forrester) at BPM 2010: “Data and process are two sides
of the same coin”.
Still the focus was on establishing connections between the MDM and
BPM silos.
• In the meanwhile, the artifact-centric approach emerged as a
foundational proposal for merging data and processes together.
Data must be modeled taking into account that they will be
manipulated by processes.
Processes must be modeled by considering that they are meant to
manipulate data.
• Initial proposals by IBM (Kamal Bhattacharya, Rick Hull, late ’90).
• ACSI Project for artifact-centric service interoperation.

What is an Artifact?
Deﬁnition
A key, business-relevant conceptual dynamic entity that is used in guiding
the operation of a business.
Consists of:
• information model - relevant data maintained by the artifact
• lifecycle model - (implicit) description of the allowed information
model evolutions through the execution of a process.
Information model Lifecycle Artifact
Goal: uniﬁed, end-to-end view of relevant entities and their possible
evolutions.

Artifacts in the Build-To-Order Process
The process now centres around interconnected business-relevant entities:
• Customer PO handles a customer order from creation to delivery.
• Work Order handles one of the work orders spawned for a line item in
a customer PO.
• Material PO handles a material PO from request to shipment (and
possible rejections).
• Assembly manages the aggregation of materials and sub-assemblies.
How to specify the lifecycle of such artifacts?
At which level of abstraction?
How and where to store data maintained by their information models?

ACSI Artifact Paradigm

A3
M: ACSI Artifact Abstract Model
An abstract (i.e., data and process
agnostic) model for representing the
key concepts of an artifact system.
Consists of:
evolutions.
evolutions.
Deﬁnition
Consists of:
evolutions.
artifact
event
environment
gateway
• Artifact type: set of artifact instances with the same information model
(database). Artifact instance = ID + database instance.
• Environment gateway: data container to exchange information with the
external world.
• Event: data container sent at some moment in time.
• Relationship: association between entities, with a stereotype. E.g.:
create-event, reference, may-destroy-artifact, . . .
• Static constraint: constraints that must hold in every state of the system.
E.g.: information model integrity constraints.
• Dynamic constraint: intra- and inter-artifact constraints about acceptable
evolutions of the system.
Lifecycle: intra-artifact constraints relating artifact phases across time.

Interoperation Hub
Extension of A3M to support multi-party service interoperation.
elevant conceptual dynamic entity that is used in guiding
a business.
model - relevant data maintained by the artifact
del - (implicit) description of the allowed information
tions through the execution of a process.
formation model Lifecycle Artifact
d-to-end view of relevant entities and their possible
Towards Convergence of Data and Processes December 20, 2012 16 / 29
information model - relevant data maintained by the artifact
lifecycle model - (implicit) description of the allowed information
: unified, end-to-end view of relevant entities and their possible
utions.
Definition
A key, business-relevant conceptual dynamic entity that is used in guid
Consists of:
evolutions.
Marco Montali Towards Convergence of Data and Processes December 20, 2012
artifact
event
environment
gateway
service
participant
organisational info
authorisation
view
What is an Artifact?
Definition
Consists of:
evolutions.
new artifact

Separation Principle and Semantic Layer
The evolution of the artifact system occurs at the artifact layer.
• Processes are defined over the database schemas of the artifacts.
The semantic layer can be added on top of the artifact layer to:
• Understand the artifact system in terms of concepts and relationships
relevant for the domain of interest.
Unified view of the whole system.
Interconnection of different artifacts that share information, though
with different representation.
Support to new artifacts in understanding how they could attach to the
information maintained by other artifacts.
Specification of queries as well as static and dynamic constraint at the
conceptual level.
• Govern the artifact system:
regulating the introduction of new artifacts and processes in the system;
ensuring that processes running over the artifact layer always
manipulate data in accordance to the semantic layer.
• Verify and monitor whether the artifact system satisfies dynamic
constraints specified over the semantic layer.

Semantically-governed A3
M
Semantic layer: I-HUB’s conceptual schema (TBox) composed of semantic
constraints that deﬁne the “data boundaries” of the artifact system.
TBox

M
Real data are concretely maintained at the artifact layer.
Snapshot: database instances of artifacts, events and gateways.
Da
Db
Dc
Artifact System Snapshot
TBox

M
Each snapshot is conceptualized in the ontology, in terms of an ABox.
Mappings deﬁne how to obtain the virtual ABox from the concrete data
sources.
Da
Db
Dc
Mappings
Semantic Layer Snapshot
TBox
ABox1

M
The system evolves thanks to actions/processes executed over the artifact
layer.
Semantic layer used to understand the evolution at the conceptual level.
Da
Db
Dc
D'a
D'b
D'c
Action
execution
Mappings Mappings
TBox
ABox1
TBox
ABox2

M
Semantic governance: semantic layer used to regulate the actions’
execution at the artifact layer. Actions leading to violate the semantic
constraints are rejected.
Da
Db
Dc
D'a
D'b
D'c
Action
execution
Mappings Mappings
TBox
ABox1
TBox
ABox2

Artifact Concrete Models
Some concrete information models:
• Relational database (with nested records).
• (Description Logic) Knowledge base.
Some concrete lifecycle models:
• Finite-state machines. State = phase; events trigger transitions.
Implemented in the Siena IBM prototype.
• Proclets (interacting Petri nets).
Emphasise many-to-many relationships between artifacts.
• Guard-Stage-Milestone lifecycles, based on declarative ECA-like rules.
Implemented in the Barcelona IBM prototype.

Guard-Stage-Milestone Artifacts
Information model: nested records.
Lifecycle: constituted by
• Events, triggering the progression of the lifecycle. External events
inject fresh data into the system, internal events mark changes of the
lifecycle state.
• Atomic tasks, used to create/destroy artifacts and to interact with
the environment. Implemented using service.
• Sentries, logical formulae combining an optional triggering event and
a query over the information model (using OCL).
• Milestones, business-relevant objectives at diﬀerent levels of
granularity. Can be achieved by making the corresponding sentry true,
invalidated otherwise.
• Stages, cluster of tasks and sub-stages that jointly concur to the
achievement of some milestones.
• Guards, sentries used to control the activation of a corresponding
stage. Whenever a guard becomes true, the stage opens and must
eventually reach a milestone to become closed.

Build-To-Order Process in GSM - Information model
• Conceptual schema. Customer purchase order:
1..1 1..1
Carrier SupplierAssembler1..1
1..1 1..1
1..1
1..1
orderID : int
status : {...}
Order
prodName : string
Product Type
Component Type
compName : string
price : int
color : string
ComponentProduct
companyName : string
Company
SSN : string
address : string {0..n}
Customer
1..1 1..n
fulﬁlls
suppliedBy1..1 assembledBy
shippedBy
Ptype Ctype
1..1
orderFor
1..1
madeOf1..1
makesOrder
• GSM status attributes: open/closed stages, achieved/invalidated
milestones.

Build-To-Order Process in GSM - Customer PO Lifecycle
Researching Ordering Assembling
all
researched
one ordered
comp.
received
submitted shipped
Submitting Shipping
human
task
human
task
automatic
task
automatic
task
automatic
task
[carry]
(Assembler)
[research]
(Assembler)
[submit]
(Customer)
[create]
(Customer)
[receiveOrder]
(Customer)
[cancel]
(Customer)
Legend: [external event ev]
... AND ev.onEvent()
[collect]
(Assembler)
Customer
Assembler
Carrier
[receiveComp]
(Assembler)
setReceived
(to Component artifact)
create
(a Component artifact)
order
(to Component artifact)
[orderComp]
(Assembler)
[orderComp]
(Assembler)
all ordered
all
assembled
[receiveComp]
(Assembler)
Fulfilling
order
assembled
Processing
order
received
order
cancelled
Diamond: guard. Rounded rectangle: stage. Circle: milestone.
Sentries are partially hidden.
Arrows denote dependencies on certain status attributes.

Reasoning about Artifacts as Dynamic Entities
We want to provide a formal foundation for artifact-centric systems, and
provide corresponding reasoning facilities for their trustworthy design.
In particular, we want to decide whether dynamic/temporal properties of
interest hold over the life of such systems.
• Veriﬁcation of temporal formulae.
• Dominance/simulation/bisimulation/containment properties.
• Automated composition of artifacts-based systems.
• Automated process synthesis from dynamic/temporal speciﬁcations.

Reasoning about Artifacts as Dynamic Entities
We want to provide a formal foundation for artifact-centric systems, and
provide corresponding reasoning facilities for their trustworthy design.
In particular, we want to decide whether dynamic/temporal properties of
interest hold over the life of such systems.
• Verification of temporal formulae.
• Dominance/simulation/bisimulation/containment properties.
• Automated composition of artifacts-based systems.
• Automated process synthesis from dynamic/temporal specifications.
Currently (2010’s) the scientific community is quite good at each of these,
but only in a finite setting!
However, artifacts pose two challenging problems:
• the presence of data makes them infinite-state systems;
• properties need to accommodate temporal operators and queries over
the artifact information models → first-oder temporal formulae.

Veriﬁcation of Artifacts is Tough
What is a non-artifact example of a ﬁnite-state control process
manipulating possibly unbounded data?

Verification of Artifacts is Tough
What is a non-artifact example of a finite-state control process
manipulating possibly unbounded data? Turing machine
Halt
curState == qf
Transition done
...
status attributes curState cellscurCell
curCell = curCell.next;
Head moved
if curCell.next == null
newCell = createCell();
newCell.value = "_";
curCell.next = newCell;
newCell.prev = curCell;
newCell.next = null;
Tape extended
if curCell.next != null
curCell = createCell();
curCell.value = "_";
curState = q0;Initialized if curCell == null
MovedR
...
curCell.value = vR1';
curState = qR1';
if curState = qR1
&& curCell.value = vR1
R1 state updated
...
curCell.value = vRk';
curState = qRk';
if curState = qRk
&& curCell.value = vRk
Rk state updated
...value prev next
Transition stage
State update stages
Init stage
Right shift stage
(left transitions) (Left shift stage)
. . .. . .
Verification of the propositional CTL ∩ LTL reachability property
“eventually milestone Halt achieved” is undecidable.

Artifact Formal Foundations
Is there hope to find interesting decidable cases?
• This requires to identify “classes of systems” that enjoy verifiability.
• First step: devise a minimal, clean mathematical framework as the
basis of investigation.
• Many approaches in the literature:
University California San Diego, University California Santa Barbara,
IBM Watson, Imperial College, Sapienza Università di Roma, Free
University of Bozen-Bolzano.
Starting from previous work, we have defined a very rich “pristine”
formal framework: Data-Centric Dynamic Systems.
Note: approaches based on multi-dimensional modal logics (one dimension
for data, one dimension for process) are not suitable.
• Undecidability holds already for rigid roles.
• No hope to isolate an interesting class.

Data-Centric Dynamic Systems (DCDS)
Data layer Process layer DCDS
Data Layer: Relational database.
• Relational schema (with constraints).
• Database instance: state of the DCDS.
Process Layer:
• Atomic actions with params: relate the current database to the next.
• Process: condition-action rules to select applicable actions+params.
• Service calls: incorporation of fresh values into the system
Deterministic services: e.g., historical exchange rate of Euro/USD
Nondeterministic services: e.g., current exchange rate of Euro/USD
Account for incoming event payloads (GSM) or user-input.
Minimal interaction between the two layers:Levesque functional approach.
• ASK queries, obtaining certain answers.
• TELL facts, asserting new information.

DCDS Example
Data Layer
Information about hotels and their price:
• Cur = Currency
• CurHotel = Hotel, Currency
• PEntry = Hotel, Price
Process Layer
Possibility of converting the price list of a hotel from USD dollars to
another currency.
• Nondet. service for price conversion: conv usd(price, currency)
• Process: Cur(c) ∧ CurHotel(h, US ) −→ Conv(h, c)
• Conv(h, c) :


PEntry(h, p) ∧ Cur(c) PEntry(h, conv usd(p, c))
CurHotel(h, cold) ∧ Cur(c) CurHotel(h, c)
Copy Rest




Execution Semantics: Inﬁnite-State Transition Systems
Cur(EUR)
Hotel(h,80)
CurHotel(h,USD)

Cur(EUR)
Hotel(h,80)
CurHotel(h,USD)
Conv(h1,EUR)
call conv_usd(80,EUR)

Cur(EUR)
Hotel(h,80)
CurHotel(h,USD)
Conv(h1,EUR)
Cur(EUR)
Hotel(h,10)
CurHotel(h,EUR)
Cur(EUR)
Hotel(h,90)
CurHotel(h,EUR)
Cur(EUR)
Hotel(h,160)
CurHotel(h,EUR)

Cur(EUR)
Hotel(h,80)
CurHotel(h,USD)
Conv(h1,EUR)
other
executable
actions
Cur(EUR)
Hotel(h,10)
CurHotel(h,EUR)
Cur(EUR)
Hotel(h,90)
CurHotel(h,EUR)
Cur(EUR)
Hotel(h,160)
CurHotel(h,EUR)
other results
Three possible sources of infinity/unboundedness:
• infinite branching;
• infinite runs;
• unbounded database.

Verification formalisms
Remember: verification is undecidable even for propositional reachability
properties and very simple DCDSs. . .
We study variants of FO µ-calculus + bisimulations.
Formulae can talk only of a fixed set of constants.
HML
PDLLTL CTL
µL
µLFO

1st variant: µLA. FO quantiﬁcation over current
active domain.
• E.g.: along every run, for each student x appearing
in the database, there exists a run leading to
graduation of x.
HML
PDLLTL CTL
µL
µLFO
µLA

1st variant: µLA. FO quantiﬁcation over current
active domain.
• E.g.: along every run, for each student x appearing
in the database, there exists a run leading to
graduation of x.
2nd variant: µLP. FO quantiﬁcation only holds over
persisting individuals.
• E.g.: it is always true that, whenever an artifact id
is present in the information model, the
corresponding artifact will be destroyed (i.e., the id
will disappear) or reach a state where all its stages
are closed.
HML
PDLLTL CTL
µL
µLFO
µLA
µLP

Conditions
Run-bounded DCDS: every run cannot accumulate more than a fixed
bound of different values.
• Still infinite-state due to infinite branching.
State-bounded DCDS: every database instance cannot contain more than
a fixed bound of different values.
• Relaxation of run-boundedness.
• Runs could be infinite, due to infinitely many values encountered in
its states.
• Such values cannot however accumulate in the same state.
These are semantic conditions, whose checking is undecidable. We have
defined sufficient, checkable syntactic conditions that guarantee them.

Results
Theorem
Veriﬁcation of µLA over run-bounded DCDSs is decidable and can be
reduced to model checking of propositional µ-calculus over a ﬁnite
transition system.
Idea: use isomorphic types instead of
actual values.
Remember: runs are bounded!
............
...

Results
Theorem
transition system.
actual values.
............
...
non a-bisimilar
a-bisimilar

Results
Theorem
transition system.
actual values.

Results
Theorem
Verification of µLA over state-bounded DCDSs is undecidable.
Idea: the logic can arbitrarily quantify over the infinitely many values
encountered during a single run, and start comparing them.
Technical proof: satisfiability of LTL with freeze quantifier can be encoded
as a model checking problem of µLA formulae over state-bounded DCDSs.

Results
Theorem
Veriﬁcation of µLP over run-bounded DCDSs is decidable and can be
transition system.
Steps:
1 Prune inﬁnite branching (isomorphic types).
...
non p-bisimilar
p-bisimilar
............
...
...
...
...

Results
Theorem
transition system.
Steps:
2 µLP looses track of previous values
that do not exist anymore. When these
values re-appear, they are interpreted as
new, fresh ones.
→ Completely new values can be
replaced with old, non-persisting ones.
This eventually leads to recycle the old
values without generating new ones.
...
...
...

Results
Theorem
transition system.
Steps:
2 µLP looses track of previous values
that do not exist anymore. When these
values re-appear, they are interpreted as
new, fresh ones.
→ Completely new values can be
replaced with old, non-persisting ones.
This eventually leads to recycle the old
values without generating new ones.

Conclusion
• Need of holistic view of data+process.
• Artifact-centric systems provide a promising answer to this
requirement.
• Veriﬁcation of artifact-centric systems is a very challenging problem.
Promising results are being produced, which also pave the way
towards implementation.
• Connection with other ongoing proposals: active XML, object-centric
BPM, collaboration hubs, (adaptive) case management.
• Foundations of artifact-centric systems combine many interesting
areas of computer science: Knowledge Representation, Logic and
Databases, AI, Formal Methods.

Ongoing/Future Work
• Application of DCDSs for the veriﬁcation of GSM-based artifacts.
• Further results both in the relational and knowledge-based setting
(semantic artifacts, Knowledge and Action Bases).
• Inconsistency-tolerant systems.
• Bidirectional mappings to propagate information from the relational
to the semantic layer and back.
• Synthesis of semantic artifacts using knowledge-based game
structures and our FO µ-calculus variants.
• Implementation of the abstraction technique and embedding into a
state-of-the-art model checker.
• Link with organizational modeling, services (broad meaning) and
commitments.

Case Management
• Seminal work by van der Aalst et al. (2005): traditional BPM, data
fragmentation and the “blind surgeon” metaphor.
• Case management philosophy: the process works over shared, visible
data structures whose lifecycle is attached to the case.
• Adaptive case management: exploits such shared data to deal with
unpredictable/unforeseen situations;
dynamic (re)planning of pathways;
ad-hoc changes.
→ underspecification of processes;
→ flexibility by design and at run-time.
• Concrete technologies:
FLOWer by Pallas Athena (first case management system).
Cordys: state machine-based process with declarative applicability rules
and dynamic planning steps.
IBM Case Manager: GSM-like approach centred on documents (case
folders).
Many similarities between the two paradigms!

CMMN: Case Management Modeling and Notation
Emerging OMG Standard for declarative case management.
• Submitters: BizAgi, Cordys, IBM, Oracle, SAP, Singularity.
• Co-authors: Agile Enterprise Design, SINTEF, TIBCO, Trisotech.
Based on GSM abstraction
Initiate
Request Order
Create Material Orders
+
-
Planning
Orders
Manage Suppliers
All Items Ordered
Order cancelled
Advanced state machines

Thanks!
Talk
End
Questions
a

iSC


Convergence of Data and Processes Artifact-Centric Approach

Recommandé

Recommandé

Contenu connexe

Similaire à Convergence of Data and Processes Artifact-Centric Approach

Similaire à Convergence of Data and Processes Artifact-Centric Approach (20)

Plus de Faculty of Computer Science - Free University of Bozen-Bolzano

Plus de Faculty of Computer Science - Free University of Bozen-Bolzano (20)

Dernier

Dernier (20)

Convergence of Data and Processes Artifact-Centric Approach