Towards Formal Analysis of ArtifactCentric Business Process Models

1
Towards Formal Analysis ofArtifact-Centric
Business Process Models
foundation
semantics
rigor
complexity
services
relevance

• Kamal Bhattacharya Cagdas Gerede Richard Hull
• Rong Liu Jianwen Su
• IBM TJ Watson U C Santa Barbara Bell Labs

2
Outline

• Motivations and project goals
• Artifact-centric business process model
• Preliminary results on reasoning/analysis
• Conclusions

3
Web Services SOA

• Web services Flexible machine-machine
  interaction
• A working definition Network-resident software
  services accessible via standardized protocols
• Interests in academic community, standards
  bodies, . . .
• Applications in e-commerce, telecom, science,
  GRID, government, education, . . .
• Service oriented architecture a design principle
  guided by service-orientation
• Flexibility
• Maintainability
• Could benefit BPM

4
Distributed Enterprise Services

• Franchise or chain operations
• Large number of geographically distributed small
  sites
• Provide support and services for sites, including
  provisioning, installation, and maintenance

IT Service Provider
?
site
site
site
site
site
newsite
5
IT Service Provider Site Install

• Illustration of high level business process

Create Order
Initiate Accounting
Plan Schedule
Approve Install
Complete Customer Accept
Cancel Order
6
Current BPM Practices Design Phase

• Modeling activity occur in multiple abstraction
  layers

process modeling
data modeling
7
Site Installation

• A view of the data elements participating in the
  services

Schedule
BR1, BR2
set_up
planning
execution
completion
completed
Delivery_ model
Customer
create_ schedule
assign_ task
set_ task_ dates
set_ schedule_ dates
. . .
Site
Task_model
set_up
on_track
delayed
completed
Task
8
Current BPM Practices Design Phase

• Modeling activity occur in multiple abstraction
  layers

process modeling
data modeling
business
IT
system modeling (databases, services,workflows,
resources)

• Translation is an art ad hoc, unreasonable, may
  lose much business sense
• Even worse system modeling is out-sourced

9
Current BPM Practices Operational Phase

• Business models change frequently for many
  reasons (requirements, environment, performance
  improvements, )

process modeling
changes
data modeling
business
IT
system modeling (databases, services,workflows,
resources)
What to change?

• Changing business processes is extremely hard.
• BPM is done by two groups of people business
  managers and IT engineers

10
Data Management In the Old Days (60s)

• Current BPM practices reminiscent of the DB
  field in the 60s
• Driving applications inventory control,
  financial data management

logical data modeling
query
desirable
have to deal with
File structures (indexes, )
COBOLprogram

• The key is to automate the s

11
The Contribution of Relational Data Model

• Physical data independence allows us to focus
  only data management issues

logical data model
SQL
conceptual
physical
query plan
physical organization (files, pages, indexes, )
12
Future of BPM?

• Automate s

process modeling
changes
data modeling
business
IT
system modeling (databases, services,workflows,
resources)
What to change?

• Reuse concepts, tools, techniques developed in CS
• First step a single conceptual model for
  business processes
• both data and processes are 1st class citizens

13
Goals of This Project

• Investigate various problems concerning
• Modeling languages
• Analysis of business process models
• Evolution techniques
• Automated design techniques
• Implementation techniques
• Expressive power
• Computational complexity
• Algorithms
• Preliminary results this paper, SOCA, ICSOC07

14
Outline

• Motivations and project goals
• Artifact-centric business process model
• Preliminary results on reasoning/analysis
• Conclusions

15
Turning Process Modeling Into Data Modeling

• Observation 1 current BPM captures a fair amount
  of processing information, in forms of states,
  business data, etc.
• Recent approaches of modeling data in BP Hull et
  al WACC99 Aalst-Weske-Grnbauer DKE05
  Wang-Kumar BPM05
• Observation 2 life cycles of data going through
  BPs are essential
• Examples Why CS freshmen without programming
  experiences do well in CS130A?What is the impact
  of Math 3A?
• This idea is not new King-McLeod
  TOIS85Mylopoulos-Bernstein-Wong
  TODS80Ginsburg-Tanaka TODS 86S. VLDB91
• Can we combine life cycles with BPs in a model?

16
Example High Tech Restaurant
Artifacts
17
Example High Tech Restaurant
Artifacts
18
Artifacts The IBM Story

• Artifacts as a methodology for modeling BPs
  Nigam-Caswell IBM SysJ03Kumaran-Nandi-Heath-Bh
  askaran-Das SAINT03
• An artifact flow captures one slice of BP
  centered around the artifact
• A BP is a collection of artifacts
• Ad hoc tools to support analysis
  Liu-Bhattacharya-Wu CAiSE07, translation
• Lacks a formal conceptual model
• Better understanding of various technical
  problems
• General purpose tools

19
Artifact-Centric BPM Illustration
Order Artifact
instantiate
Create Order
update
Invoice Artifact
Pending Order
trigger
Initiate Accounting

• invoiceId
• state
• att

Cancel Order
Planning
Plan Schedule
Canceled
Live Order

• orderId
• currentState
• dateCreated
• invoiceId
• creditCheckApproved
• planId
• installApproved
• installApprovedDate
• installCompletedDate

Approve Install
Completed
Complete Customer Accept
20
Artifact System

• An artifact system represents a business model
• W ( G, S, R )
• G a set of artifacts classes (artifact schema)
• S a set of services
• R a set of business rules

21
Artifact Classes and Schema

• An artifact class consists of
• A set of attributes, of typeeither scalar or IDs
  of otherartifacts
• A set of states,initial and final states
• State transitions not defined
• An artifact schema is a set of artifact classes
  closedunder cross-referencing

Order Artifact

• orderId
• dateCreated
• invoiceId
• creditCheckApproved
• planId
• installApproved
• installApprovedDate
• installCompletedDate

Pending Order
Planning
Canceled
Live Order
Completed
22
(Reusable) Services

• A service has a precondition and effects,
  conditions on
• Defined-ness of attribute values
• Equality of artifact IDs
• An attribute holds the ID of a newly created
  artifact

Service UpdateCredit Write x order Read y
CreditReport Pre-condition ?Defined(x,
creditApproved) Effects - Defined(x,
creditApproved) - Defined(x, creditApproved) ?
Defined(x, currentCredit)
23
Semantics of Services

• Based on circumscription
• minimum changes to satisfy an effect
• One of the effects will be true
• Note not particularly concerned with computation
  of individual values, but whether attributes are
  assigned values or not
• An attribute assigned a value may later become
  undefined
• Monotonic services a defined attribute will not
  be updated

24
Business Rules

• Rules that define business logic
• Invoke a service
• Change artifact states
• states are used to organize the processing

if PendingOrder(x) ? Defined(x,
creditApproved) invoke InitialAccounting(x) if
Defined(x, task.expectedStartDate) ? Defined(x,
task.expectedEndDate) ? Defined(x,
installApproved) change state to LiveOrder(x) ?
PendingTask(x.task)
25
Analysis Problems

• An artifact system W ( G, S, R )
• artifacts, services, business rules
• Completion Does W allow a complete run of some
  artifact?
• Dead-end Does W have a dead-end path?
• Attribute redundancy Does W have a redundant
  attribute?
• Focus on single artifact processing

26
Sampler of Results

• The problems are undecidable in general
• but in PSPACE if we allow no creation of new
  artifacts
• For monotonic services
• Complexity ranging from linear to intractable
  under various conditions

27
Completion (Monotonic Services)

• Linear time if
• Services are deterministic (single effect)
• Preconditions has no negation
• Rule conditions are positive and does not check
  state information
• NP-complete if the above conditions are slightly
  relaxed

28
Dead-End Redundancy (Monotonic Services)

• Checking if there is a dead end path is
  P2p-complete,
• even with various restrictions
• Checking redundant attributes is co-NP-complete,
  even with various restrictions

29
Conclusions and Discussions

• Artifact flows fit very well with many
  applications and used in practice
• Formal modeling could elevate the methodology to
  a general purpose model and supporting tools
• Analysis further explored in Gerede-S. ICSOC07
• Many interesting questions
• Automated design
• Planning techniques Frits-Hull-Bhattacharya-S.
  07 (in preparation)
• SBVR?
• Multi-artifact interactions modeling and
  analysis issues
• Evolution of BP models