Representing Business Processes: Conceptual Model and Design Methodology

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

[email protected]

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


5/58


6/58


7/58


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






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






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






25/58


- 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


31/58


32/58


33/58


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


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


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






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






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

Representing Business Processes: Conceptual Model and Design Methodology

Business

Transcript of Representing Business Processes: Conceptual Model and Design Methodology