Representing Business ProcessesConceptual Model and Design Methodology
Ph.D. Thesis of
Michele Chinosi
Universita degli Studi dell’Insubria (Varese – Italy)Dipartimento di Informatica e Comunicazione
Dottorato di Ricerca in Informatica – XXI Ciclo
Advisor: Dr. Alberto Trombetta
Outline
Introduction
Conceptual Model for BPMN
Comparison with Other Standards
Business Process Design Methodology
Practical Applications
Summary & Conclusions
2/58
Introduction
• Business Process Management has been identified as one of themost important business priorities.
• Most of the currently used IT tools are inadequate to provideefficient support to final users
• We have undertaken a thorough analysis of the OMG new standardfor BP modeling (BPMN), along with other akin technologies likeWS-BPEL and XPDL, but also with other languages and formats
• Such analysis has displayed several weaknesses of other formats,mainly because no one of them was natively conceived asBPMN-related
• With this work we aim to provide a concrete contribution to businessprocess modeling, in general, and in particular to the most emergingBP-related tool: the Business Process Modeling Notation (BPMN).
3/58
Business Process Modeling Notation
4/58
Business Process Modeling Notation
5/58
Business Process Modeling Notation
6/58
Business Process Modeling Notation
7/58
Business Process Modeling Notation
8/58
Motivations
The OMG published in 2007 a Request For Proposals (RFP) for a newversion of BPMN (BPMN 2.0).
Why should we propose a new model for BPMN?
• We start analysing BPMN before the OMG RFP was published
• BPMN 1.x has some weak points
• BPMN 1.x does not have a robust metamodel nor a conceptualmodel
• There are not methodologies provided
• There is not a complete XML serialization
• There is the need of useful features to support users on modeling
• To test our assumptions and to implement the improvements
9/58
Contributions
• Conceptual model for BPMN
• Comparison with Other Standards
• Business Process Design Methodology
• Practical Applications• Business Process Diagrams Views• Business Process Security Aspects• Privacy Policies Integration
10/58
Outline
Introduction
Conceptual Model for BPMN
Comparison with Other Standards
Business Process Design Methodology
Practical Applications
Summary & Conclusions
11/58
The Need for a New BPMN Model
Main BPMN Weak Points
• It does not exist a conceptual model which reflects the stronghierarchical structure of diagrams
• Most elements are connected only through attribute values
• The BPMN 1.1 UML metamodel uses only generalizationrelationships among classes
• There are redundant definitions
• There is no referential integrity
• BPMN lacks a native and complete interchange format
12/58
BPMN 1.1 UML Model
13/58
BPMN 1.1 BPeX Model
We refer to BPeX as
• metamodel to address the description of the BPeX underlying model
• conceptual model to underline some BPeX general characteristics
• model in all the other cases
in an interchangable way depending on the context we are dealing with.
14/58
BPeX Model Main Advantages
• Top-down methodology for the structure and bottom-up for thedetails
• Differences between Elements and Types are explicited
• Connections-by-Types replaced with Connections-by-Semantics
• Connecting Flow Objects are defined inside the model
• Full hierarchical model which map the strong hierarchical positioningof elements in a diagram
• Complete and native XML serialization• Native referential integrity• Possibility to perform queries
15/58
BPeX XML Serialization
BPMN 1.1BPeX
• Complete serialization
• Strong hierarchical relationships between elements (dashed linesrepresent weak connections)
• Only few necessary adjustements due to BPMN issues
• Better and more correct attributes and elements definitions
• Use of W3C XML-Schema standard• xs:assert and xs:alternative
16/58
Outline
Introduction
Conceptual Model for BPMN
Comparison with Other Standards
Business Process Design Methodology
Practical Applications
Summary & Conclusions
17/58
3 Different Formats for 3 Different Purposes
BPMN (OMG) is a graphical notation for structuring BP. It is astandard to represent the structure of one or moreprocesses
BPEL (OASIS) is an ‘execution language’ independent fromBPMN for the definition of Web-services orchestration
XPDL (WfMC) is a language for storing and exchangingworkflows and business diagrams
18/58
BPEL Inadequacy Analysis
• BPEL is less expressive than BPMN
• BPMN is not executable
• BPEL and BPMN elements definitions are different
• The structures of BPMN and BPEL models are different
• BPEL does not save graphical information
• It is very hard to perform queries
19/58
XPDL Weaknesses Analysis
• XPDL was not originally conceived to represent BPMN diagrams
• Some elements definitions differ
• The structures of BPMN and XPDL models are different
• There is not official support for BPMN to XPDL mapping
• XPDL does not have referential integrity
• XPDL discards all the execution information
• It is very hard to perform queries
20/58
Queries Execution Comparison
Example
Which Lane does the Task with Id=10 belong to?
XPDL
1for $x in {// Activity[@Id=10]},2$y in {// Pool[@Process = ←↩3//$x/ancestor::WorkflowProcess [1]/ @Id]// Lane/@Name}4return $y5
6Result: /Package [1]/ Pools [1]/ Pool [2]/ Lanes [1]/ Lane [1]/ @Name: Lane -0
BPeX
1//Lane [// Task/@Id =10]/ @Name2
3Result: /BPD [1]/ Pool [2]/ Lane [1]/ @Name: Lane -0
21/58
A Brief Summary
BPEL XPDL BPeXExpressive power Less expressive More expressive Bijective correspon-
denceNaming convention Names are different Some names differ-
entNo differences
Structure of themodel
Completely different Some relevant differ-ences
Few adjustments due
Native ReferentialIntegrity
Partially Missing Strong
Execution capabili-ties
Full support No execution allowed Not yet but planned
Graphical informa-tion
Not at all Full support With extensions
Analysis Very hard if theyconcerns BPMNmodels
Many queries re-quired
Few simple queries
Extensions to BPMN Hard to implement Very difficult to ex-tend the model
Successful experi-ments done
22/58
A Critique of BPMN 2.0 Proposals
• The provided metamodel is too complex• multiple concentric layers, type-centric, attributes oveloading
• BPMN methodologies are still missing
• User management has been improved, but it is still framed to thedescription of the user interactions as part of the processes
• Human Interactions, People Group, People Assignment
• Choreographies are ‘good’, their definition are ‘bad’
• Gateways and related ‘dominator’ and ‘post-dominator’ concepts
• Events definition: the Escalation Event, some implicit declarations
• Other minor issues• Is the Null Task really useful?• ‘Mandatory-but-empty’ attribute is better than ’optional’?• Redundant connections• Data Management is still lean
All these issues (along with other suggestions) have been discussed withother (B)IOS submitters and they have been considered for the nextstage of the BPMN 2.0 submission.
23/58
Collaboration with the (B)IOS BPMN 2.0 Proposal
• April 2008: invited speaker @ ‘Architecture & Process 2008’Conference organized by WfMC
• To present BPeX as a different modeling approach to overcomeXPDL shortcomings
• First discussions with Nathaniel Palmer (WfMC), Keith Swenson(Fujitsu), Michael zur Muehlen (Stevens Institute of Technology)and Jim Lange (Oracle) about BPeX
• June 2008: Jim Lange proposed us to join the (B)IOS submissiongroup and put us in touch with Oracle and IBM
• June 2008: we gain access to the submissions documents
• September 2008: we meet Oracle in Milan during BPM 2008 todiscuss about our solutions for the forthcoming BPMN 2.0
• October 2008: DICOM becomes OMG Academic member
• Since November 2008: our suggestions are considered to becomepart of the (B)IOS BPMN 2.0 proposal
24/58
Outline
Introduction
Conceptual Model for BPMN
Comparison with Other Standards
Business Process Design Methodology
Practical Applications
Summary & Conclusions
25/58
Business Process Design Methodology
- BPR is a (often manual) time-consuming activity
- There is no mention about BP Design and Modeling methodologiesinside the specifications
- There are no tools supporting users in graphical modeling
+ Methodologies will be claimed in the next 5 years as one of the mainpriorities
+ A design methodology reduces the need for future redesign phases
+ To ease the task of estabilishing when (and how) a business processcan be considered ‘good’
26/58
The 3-phases Methodology Schema
27/58
Phase 1: Conceptual Modeling
• Input: Natural text specifications
• Output: A complete, correct and compliant graphical representationof the process
Rules (top-down)
• Participants identification
• Activities identification
• Events identification
• Choices identification
• Adding Relationships
• Documentation of the processes
28/58
Example Process
Everytime someone wants to buy a new MP3 player he has to go to thenearest open store. The customer waits to be served. If his waitingexceeds a reasonable time (e.g., 10 minutes) he leaves the store withoutbuying anything. On the contrary, he asks the sale assistant for an MP3player. The sale assistant takes the order and forwards it to the storewarehouse clerk who looks for the requested object. Meanwhile, the saleassistant proceeds with the payment procedure. The customer pays forthe MP3 player he requested. If a problem with the payment processoccurs, the sale assistant stops immediately the warehouseman
who discards the order and finishes his task. Otherwise, the cashiersends a message to the warehouseman to confirm the order. Finally, thecustomer withdraws his MP3 player from the warehouse.
29/58
The Example Process at the End of the Phase 1
30/58
The Example Process at the End of the Phase 1
31/58
The Example Process at the End of the Phase 1
32/58
The Example Process at the End of the Phase 1
33/58
The Example Process at the End of the Phase 1
34/58
Phase 2: Logical Modeling
• Input: Phase 1 output
• Output: A relevant (all symbols are meaningful) and economical(there are not useless elements) graphical representation of theprocess
Rules (bottom-up)
• Participants dependencies
• Transform the Activities (ordering, types, substitution)
• Events checking
• Gateways replacement
• Patterns analysis
35/58
The Example Process at the End of the Phase 2
36/58
Phase 3: Physical Modeling
• Input: Phase 2 output
• Output: A valid and trustworthy serialization of the process
RulesThis phase changes with respect to the technology used to physicallyrepresent the process. This phase rules are guidance for the order to befollowed to serialize the process.
1. BPD, Swimlanes and Processes
2. Activities
3. Events
4. Gateways
5. Flows
37/58
The Example Process at the End of the Phase 3
1<BPD bpex:Id="BPD_001" bpex:Name="Customer/Store Example">
2<Pool bpex:ParticipantRef="Part_01" bpex:Name="Store" bpex:Id="Pool_001">
3<Process bpex:Name="Store Process" bpex:Id="Proc_01"/>
4<Participant bpex:Id="Part_01"/>
5<Lane bpex:Name="Warehouseman" bpex:Id="Lane_001">
6<IntermediateEvent bpex:EventType="Intermediate" bpex:Name="Payment is OK"
7bpex:Id="IE_001">
8<Trigger bpex:EventDetailType="Message" bpex:Id="Tr_001"/>
9</IntermediateEvent >
10...
11<Task bpex:ActivityType="Task" bpex:Name="Look for the requested Object"
12bpex:Id="T_006"/>
13...
14</Lane>
15<Lane bpex:Name="Sale Assistant" bpex:Id="Lane_002">
16...
17<Gateway bpex:Name="" bpex:Id="GW_001" bpex:GatewayType="Parallel">
18<Gates bpex:OutgoingSequenceFlowRef="SF_001"/>
19<Gates bpex:OutgoingSequenceFlowRef="SF_002"/>
20</Gateway >
21...
22</Lane>
23<SequenceFlow bpex:Name="" bpex:SourceRef="GW_001" bpex:TargetRef="T_006"
24bpex:Id="SF_001"/>
25...
38/58
Business Process Normal Form
Business Process Normal Form Definition
The business processes modeled following the three-phases sets of ruleswill have some characteristics which guarantee some basic properties. Wedefine Business Process Normal Form as the desired form a businessprocess model should have.
CorrectCompleteCompliant Relevant Economical Valid Trustworthy
Phase 1 •Phase 2 • • •Phase 3 • • • • •
39/58
Outline
Introduction
Conceptual Model for BPMN
Comparison with Other Standards
Business Process Design Methodology
Practical Applications
Summary & Conclusions
40/58
Business Process Diagrams Views
• Diagrams browsing
• Graphical tool aiding users to deal with complex diagrams
• Easing the processes reorganization
• Enhanced support for different perspectives of a model
• Differentiating how processes have to appear to different users
• Users management support
• Implementing security aspects and users access permissions
41/58
Definition of BPDV
A view is. . .. . . a diagram that results from a query. It is a logical window on the dataand the structure of the base diagram. It stores definitions that must beinterpreted each time a view is generated.
A view is not. . .. . . a snapshot of the data nor of the process state at the time a view iscreated.
42/58
BPDV Classification
Specification-based Classification
• Intensional: result of ‘queries’ application
• Extensional: single elements selection
Level-based Classification
• Model Level: graphical selection
• Physical Level: queries execution
Direction-based Classification
• Interprocess: elements are taken from different processes
• Intraprocess: the elements belong to one single process
Content-based Classification
• Executable: the view contains an executable process
• Not-executable: a set of scattered elements
43/58
Not-executable View Example
44/58
Executable View Example
45/58
Updating Views
To be considered updatable, one view must guarantee the base process topreserve both:
Syntactic correctness (or disambiguity matter)
One update operation on a view is possible if and only if it produces asyntactic valid base diagram
Semantic soundness (BPMN specifications compliance)
One update operation on a view is possible if and only if it produces asemantic valid base diagram
46/58
Business Process Security Aspects
BP Access Control Policies
• it is not possible to use BPMN to describe users accessing a businessprocess diagram
• a mechanism to express how a reader could access one diagram isnot explicitely foreseen
We aim to fill this gap providing a tool which can be used to estabilish
A. the user who is accessing the diagram
B. which view the user is accessing to
C. what action the user is performing with the view he is accessing
D. whether the user can access to that view to perform that action
47/58
Customer View Example and Relative Permissions
48/58
Integrating Privacy Policies into Business Processes
The Platform for Privacy Preferences
• P3P enables Websites to express their privacy practices in a standardformat that can be automatically retrieved and easily interpreted byuser agents
• defines the XML syntax and semantics of P3P privacy policies
• users are informed of site practices without the need to read theprivacy policies
• P3P policies consist on a sequence of STATEMENT elements
PURPOSE, RECIPIENT, RETENTION, DATA-GROUP, DATATYPE,
CONSEQUENCE, NON-IDENTIFIABLE
• We successfully extended BPeX with P3P support to be able torepresent privacy practices inside business processes
49/58
Motivating Example
The excerpt of the Google Privacy Policy for a web search requires:
• to collect #dynamic.[clickstream|http|searchtext|cookies]to meet the stated purpose: performing searches, web siteadministration, research and development; collected data will not beshared
• to collect #dynamic.[http|searchtext] to performpseudo-analysis (to understand the interests of a visitor withoutkeeping any personal information), sharing data with other partiesnot related with Google
50/58
Checking Compliance
• Each BPMN POOL represents aP3P Entity
• First tests are between POOLattributes and POLICY/ENTITYand POLICY/ACCESS attributes
• All other tests are performedfor each P3P STATEMENT
• what kind of data theprocess works on
• how the process usescollected data
• with whom an entity sharescollected data
51/58
Policies Enforcement
ENTITY verification
1foreach (Pool/Name PN ∈ BPD) do {2if (PN/P3PExtension/ENTITY == ∅)3then ‘‘Error ’’4elseif (PN/P3PExtension/ENTITY 6= P3P:POLICY/ENTITY)5then ‘‘Error ’’;6else ‘‘OK ’’; }
• This check applies on every Pool (row 1)
• The first condition verifies the existence of theP3PExtension/ENTITY nodes (row 2)
• The core of the algorithm compares the P3PExtension/ENTITYsubtree with the P3P:POLICY/ENTITY one (row 4)
1if (// Pool/Names/P3PExtension/ENTITY)2then fn:deep -equal (// Pool/Names/P3PExtension/ENTITY ,3p3p:POLICIES/p3p:POLICY/p3p:ENTITY)
52/58
Graphical Representation Inside the Model
53/58
Outline
Introduction
Conceptual Model for BPMN
Comparison with Other Standards
Business Process Design Methodology
Practical Applications
Summary & Conclusions
54/58
Conclusions
• Conceptual Model for BPMN• Analysis of existing BPMN models and related weak points• BPeX as an alternative BPMN modeling approach• A complete XML serialization of such model
• Comparison with Other Standards• BPEL and XPDL analysis and comparison with BPeX• A critique of BPMN 2.0 submission proposals• Our direct contribution to (B)IOS proposal
• Business Process Design Methodology• Three-phases methodology• Business Process Normal Form
• Practical Applications• Business Process Diagram Views• Views for BP Access Control Policies• Integrating Privacy Policies into Business Processes
55/58
Main Outcomes
• Part of this work will be inserted (with the necessary adjustments) inthe forthcoming BPMN 2.0 submission proposal by IBM, Oracle,SAP.
• The comparison between BPeX and both BPEL and XPDL has beenthe topic of the invited talk at ‘Architecture & Processes’Conference organized by WfMC.
• The privacy policies implementation into business processes wasselected by WOSIS 2008 workshop commitee to be published in anextended version in the JRPIT journal (Journal of Research andPractice in Information Technology).
56/58
Some Future Directions
• Execution capabilities
• Metrics applications
• Modeling and validation support tools
• Implementation of companies business rules and their automaticchecking
• XML-based query language for business processes
57/58
Thank you.
Questions?
58/58