Representing Business Processes: Conceptual Model and Design Methodology

Representing Business Processes Conceptual Model and Design Methodology Ph.D. Thesis of Michele Chinosi Universit` degli Studi dell’Insubria (Varese – Italy) a Dipartimento di Informatica e Comunicazione michele.chinosi@uninsubria.it 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 the most important business priorities. • Most of the currently used IT tools are inadequate to provide efficient support to final users • We have undertaken a thorough analysis of the OMG new standard for BP modeling (BPMN), along with other akin technologies like WS-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 as BPMN-related • With this work we aim to provide a concrete contribution to business process modeling, in general, and in particular to the most emerging BP-related tool: the Business Process Modeling Notation (BPMN). 3/58

Business Process Modeling Notation 4/58

Motivations The OMG published in 2007 a Request For Proposals (RFP) for a new version 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 conceptual model • 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

The Need for a New BPMN Model Main BPMN Weak Points • It does not exist a conceptual model which reﬂects the strong hierarchical structure of diagrams • Most elements are connected only through attribute values • The BPMN 1.1 UML metamodel uses only generalization relationships among classes • There are redundant deﬁnitions • 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 the details • Diﬀerences between Elements and Types are explicited • Connections-by-Types replaced with Connections-by-Semantics • Connecting Flow Objects are deﬁned inside the model • Full hierarchical model which map the strong hierarchical positioning of elements in a diagram • Complete and native XML serialization • Native referential integrity • Possibility to perform queries 15/58

BPeX XML Serialization BPeX BPMN 1.1 • Complete serialization • Strong hierarchical relationships between elements (dashed lines represent weak connections) • Only few necessary adjustements due to BPMN issues • Better and more correct attributes and elements deﬁnitions • Use of W3C XML-Schema standard • xs:assert and xs:alternative 16/58

3 Different Formats for 3 Different Purposes BPMN (OMG) is a graphical notation for structuring BP. It is a standard to represent the structure of one or more processes BPEL (OASIS) is an ‘execution language’ independent from BPMN for the definition of Web-services orchestration XPDL (WfMC) is a language for storing and exchanging workflows 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 for $ x in {// Activity [ @Id =10]} , 1 $ y in {// Pool [ @Process = ← 2 //$ x / a n c e s t o r : : W o r k f l o w P r o c e s s [1]/ @Id ]// Lane / @Name } 3 return $ y 4 5 Result: / Package [1]/ Pools [1]/ Pool [2]/ Lanes [1]/ Lane [1]/ @Name: Lane -0 6 BPeX // Lane [// Task / @Id =10]/ @Name 1 2 Result: / BPD [1]/ Pool [2]/ Lane [1]/ @Name: Lane -0 3 21/58

A Brief Summary BPEL XPDL BPeX Expressive power Less expressive More expressive Bijective correspon- dence Naming convention Names are different Some names differ- No differences ent Structure of the Completely different Some relevant differ- Few adjustments due model ences Native Referential Partially Missing Strong Integrity Execution capabili- Full support No execution allowed Not yet but planned ties Graphical informa- Not at all Full support With extensions tion Analysis Very hard if they Many queries re- Few simple queries concerns BPMN quired models Extensions to BPMN Hard to implement Very difficult to ex- Successful experi- tend the model 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 the description of the user interactions as part of the processes • Human Interactions, People Group, People Assignment • Choreographies are ‘good’, their deﬁnition are ‘bad’ • Gateways and related ‘dominator’ and ‘post-dominator’ concepts • Events deﬁnition: 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 with other (B)IOS submitters and they have been considered for the next stage 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 diﬀerent modeling approach to overcome XPDL 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 submission group 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 to discuss about our solutions for the forthcoming BPMN 2.0 • October 2008: DICOM becomes OMG Academic member • Since November 2008: our suggestions are considered to become part of the (B)IOS BPMN 2.0 proposal 24/58

Business Process Design Methodology - BPR is a (often manual) time-consuming activity - There is no mention about BP Design and Modeling methodologies inside the speciﬁcations - There are no tools supporting users in graphical modeling + Methodologies will be claimed in the next 5 years as one of the main priorities + A design methodology reduces the need for future redesign phases + To ease the task of estabilishing when (and how) a business process can 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 representation of 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 the nearest open store. The customer waits to be served. If his waiting exceeds a reasonable time (e.g., 10 minutes) he leaves the store without buying anything. On the contrary, he asks the sale assistant for an MP3 player. The sale assistant takes the order and forwards it to the store warehouse clerk who looks for the requested object. Meanwhile, the sale assistant proceeds with the payment procedure. The customer pays for the MP3 player he requested. If a problem with the payment process occurs, the sale assistant stops immediately the warehouseman who discards the order and ﬁnishes his task. Otherwise, the cashier sends a message to the warehouseman to conﬁrm the order. Finally, the customer withdraws his MP3 player from the warehouse. 29/58

The Example Process at the End of the Phase 1 30/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 the process Rules (bottom-up) • Participants dependencies • Transform the Activities (ordering, types, substitution) • Events checking • Gateways replacement • Patterns analysis 35/58

Phase 3: Physical Modeling • Input: Phase 2 output • Output: A valid and trustworthy serialization of the process Rules This phase changes with respect to the technology used to physically represent the process. This phase rules are guidance for the order to be followed 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 b p e x : P a r t i c i p a n t R e f = 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 < I n t e r m e d i a t e E v e n t bpex: EventTy pe = Intermediate bpex:Name = Payment is OK 7 bpex:Id = IE_001 > 8 < Trigger b p e x : E v e n t D e t a i l T y p e = Message bpex:Id = Tr_001 / > 9 </ I n t e r m e d i a t e E v e n t > 10 ... 11 < Task b p e x : A c t i v i t y T y p e = Task bpex:Name = Look for the requested Object 12 bpex: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 b p e x : G at e w a y T y p e = Parallel > 18 < Gates b p e x : O u t g o i n g S e q u e n c e F l o w R e f = SF_001 / > 19 < Gates b p e x : O u t g o i n g S e q u e n c e F l o w R e f = SF_002 / > 20 </ Gateway > 21 ... 22 </ Lane > 23 < SequenceFlow bpex:Name = bpex: SourceR ef = GW_001 b pex:Tar getRef = T_006 24 bpex:Id = SF_001 / > 25 ... 38/58

Business Process Normal Form Business Process Normal Form Deﬁnition The business processes modeled following the three-phases sets of rules will have some characteristics which guarantee some basic properties. We deﬁne Business Process Normal Form as the desired form a business process model should have. Correct Complete Compliant Relevant Economical Valid Trustworthy • Phase 1 • • • Phase 2 • • • • • Phase 3 39/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

Deﬁnition of BPDV A view is. . . . . . a diagram that results from a query. It is a logical window on the data and the structure of the base diagram. It stores deﬁnitions that must be interpreted 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 is created. 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 to preserve both: Syntactic correctness (or disambiguity matter) One update operation on a view is possible if and only if it produces a syntactic valid base diagram Semantic soundness (BPMN speciﬁcations compliance) One update operation on a view is possible if and only if it produces a semantic 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 business process diagram • a mechanism to express how a reader could access one diagram is not explicitely foreseen We aim to ﬁll 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 standard format that can be automatically retrieved and easily interpreted by user agents • deﬁnes the XML syntax and semantics of P3P privacy policies • users are informed of site practices without the need to read the privacy 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 to represent 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 site administration, research and development; collected data will not be shared • to collect #dynamic.[http|searchtext] to perform pseudo-analysis (to understand the interests of a visitor without keeping any personal information), sharing data with other parties not related with Google 50/58

Checking Compliance • Each BPMN POOL represents a P3P Entity • First tests are between POOL attributes and POLICY/ENTITY and POLICY/ACCESS attributes • All other tests are performed for each P3P STATEMENT • what kind of data the process works on • how the process uses collected data • with whom an entity shares collected data 51/58

Policies Enforcement ENTITY verification foreach ( Pool / Name PN ∈ BPD ) do { 1 if ( PN / P3PExtension / ENTITY == ∅) 2 then ‘‘ Error ’ ’ 3 elseif ( PN / P3PExtension / ENTITY = P3P : POLICY / ENTITY ) 4 then ‘‘ Error ’ ’; 5 else ‘‘OK ’ ’; } 6 • This check applies on every Pool (row 1) • The first condition verifies the existence of the P3PExtension/ENTITY nodes (row 2) • The core of the algorithm compares the P3PExtension/ENTITY subtree with the P3P:POLICY/ENTITY one (row 4) if (// Pool / Names / P3PExtension / ENTITY ) 1 then fn : deep - equal (// Pool / Names / P3PExtension / ENTITY , 2 p3p : POLICIES / p3p : POLICY / p3p : ENTITY ) 3 52/58

Graphical Representation Inside the Model 53/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) in the forthcoming BPMN 2.0 submission proposal by IBM, Oracle, SAP. • The comparison between BPeX and both BPEL and XPDL has been the topic of the invited talk at ‘Architecture & Processes’ Conference organized by WfMC. • The privacy policies implementation into business processes was selected by WOSIS 2008 workshop commitee to be published in an extended version in the JRPIT journal (Journal of Research and Practice in Information Technology). 56/58

Some Future Directions • Execution capabilities • Metrics applications • Modeling and validation support tools • Implementation of companies business rules and their automatic checking • XML-based query language for business processes 57/58

Thank you. Questions? 58/58

Representing Business Processes: Conceptual Model and Design Methodology

0 comments

Notes on slide 1

6 Favorites