This document discusses extended process modeling, languages, and notations. It covers the need for models and modeling languages to represent complex business realities and enable communication. Specific topics covered include the Zachman enterprise architecture framework, modeling languages evaluation criteria of domain appropriateness and comprehensibility, and that the process domain and business interaction network can be considered the system at the enterprise architecture level. It also discusses the transition from functional silos to a service-oriented organization.

1. Extended Process Modeling,
Languages and Notations
Nov 2010,
Sylvain Astier, sastier@gmail.com

2. Extended Process Modeling, Languages and Notations
1 The Need for Models
2 The Need for Languages
3 The Process Domain
4 Business Interactions Modeling
5 BPMN 2 Overview

3. Extended Process Modeling, Languages and Notations
1 The Need for Models
2 The Need for Languages
3 The Process Domain
4 Business Interactions Modeling
5 BPMN 2 Overview

4. 1 Why do we need models ?
• A Model is a simple representation of the
complex reality of a business.

5. 1 Why do we need models ?
• A Model is a simple representation of the
complex reality of a business.
• Models are created to simplify, abstract
reality, and focus on a specific area of
concern.

6. 1 Why do we need models ?
• A Model is a simple representation of the
complex reality of a business.
• Models are created to simplify, abstract
reality, and focus on a specific area of
concern.
➡ A Model is built for a purpose

7. 1 Why do we need models ?

8. 1 Why do we need models ?
• Models are work products of Architecture

9. 1 One question though ..
Is this Architecture ?
(Inspired from John Zachman)

10. 1 This is not Architecture !
This is NOT Architecture, it is the
result of Architecture, an instance
created from a properly defined
architecture.
(Inspired from John Zachman)

11. 1Is ThisArchitecture ? !
this is Architecture
The Product is the Model

12. 1 Architecture Definition

13. 1 Architecture Definition
• Architecture expresses the characteristics,
structures, behaviors, and relationships that
are common across a family of things.

14. 1 Architecture Definition
• Architecture expresses the characteristics,
structures, behaviors, and relationships that
are common across a family of things.
• Design expresses in detail how a specific
member of a family will be built.
- Oliver Sims

15. 1 Many Implementations can be built from a given Architecture
• An Architecture can lead to different
Implementations with different Designs.

16. 1 Many Implementations can be built from a given Architecture
• An Architecture can lead to different
Implementations with different Designs.

17. 1 Enterprise Architecture Definition
“Enterprise Architecture is the total set of
descriptive representations (models) relevant for
describing an Enterprise, that is, the descriptive
representations required to create (a coherent,
optimal) Enterprise and required to serve as a
baseline for changing the Enterprise once it is
created.”
-- John Zachman

18. 1 Enterprise Architecture reaps two major benefits :
Change Management

19. 1 Enterprise Architecture reaps two major benefits :
Change Management
• By maintaining the descriptive representations
of the object of interest, you can run ‘what-if’
analysis.

20. 1 Enterprise Architecture reaps two major benefits :
Change Management
• By maintaining the descriptive representations
of the object of interest, you can run ‘what-if’
analysis.
➡Change is manageable as soon as you can
study its impacts on models, before
modifying their instances.

21. 1 Enterprise Architecture reaps two major benefits :
Change Management
• By maintaining the descriptive representations
of the object of interest, you can run ‘what-if’
analysis.
➡Change is manageable as soon as you can
study its impacts on models, before
modifying their instances.
• You need the map of your own territory.

22. 1 Enterprise Architecture reaps two major benefits :
Integration Management

23. 1 Enterprise Architecture reaps two major benefits :
Integration Management
• Architecture is about Separation of concerns

24. 1 Enterprise Architecture reaps two major benefits :
Integration Management
• Architecture is about Separation of concerns
➡ Architecture is System thinking

25. 1 Enterprise Architecture reaps two major benefits :
Integration Management
• Architecture is about Separation of concerns
➡ Architecture is System thinking
• Enterprise Architecture is about engineering
the enterprise and how enterprises integrate,
not to build and run systems.

26. 1 Enterprise Architecture reaps two major benefits :
Integration Management
• Architecture is about Separation of concerns
➡ Architecture is System thinking
• Enterprise Architecture is about engineering
the enterprise and how enterprises integrate,
not to build and run systems.
➡ The system is the Enterprise

27. 1 The Zachman EA Framework

28. 1 The Zachman EA Framework
WHAT ?

29. 1 The Zachman EA Framework
WHAT ?
HOW ?

30. 1 The Zachman EA Framework
WHERE ?
WHAT ?
HOW ?

31. 1 The Zachman EA Framework
WHERE ?
WHAT ?
WHO ?
HOW ?

32. WHAT ?
HOW ?
WHERE ?
1 The Zachman EA Framework
WHO ?
WHEN ?

33. WHAT ?
HOW ?
WHERE ?
1 The Zachman EA Framework
WHO ?
WHEN ?
WHY ?

34. 1 The Zachman EA Framework

35. 1 The Zachman EA Framework
Identification

36. 1 The Zachman EA Framework
Identification
Definition

37. 1 The Zachman EA Framework
Identification
Definition
Representation

38. 1 The Zachman EA Framework
Identification
Definition
Representation
Specification

39. 1 The Zachman EA Framework
Identification
Definition
Representation
Specification
Configuration

40. 1 The Zachman EA Framework
Identification
Definition
Representation
Specification
Configuration
Instantiation

41. 1 The Zachman EA Framework

42. 1 The Zachman EA Framework

43. 1 One question though ..
Should everything be formalized ?

44. 1 One question though ..
Should everything be formalized ?
• Some elements are well known and predictable:
• E.g. the sequence 2; 4; 8; ?

45. 1 One question though ..
Should everything be formalized ?
• Some elements are well known and predictable:
• E.g. the sequence 2; 4; 8; ?
• N=16 with the obvious model:
➡ N = N-1 * 2

46. 1 One question though ..
Should everything be formalized ?
• Some elements are well known and predictable:
• E.g. the sequence 2; 4; 8; ?
• N=16 with the obvious model:
➡ N = N-1 * 2
• N=14 with the less obvious model:
➡ N = N -2 + N-1 + 2

47. 1 One question though ..
Should everything be formalized ?

48. 1 One question though ..
Should everything be formalized ?
No; assumptions can be made knowing that:
•They can lead to defects
•Until a phenomenon is KNOWN it is
➡Not Predictable
➡Not Repeatable

49. 1 One question though ..
Should everything be formalized ?
No; assumptions can be made knowing that:
•They can lead to defects
•Until a phenomenon is KNOWN it is
➡Not Predictable
➡Not Repeatable
ARCHITECTURE is KNOWLEDGE

50. Extended Process Modeling, Languages and Notations
1 The Need for Models
2 The Need for Languages
3 The Process Domain
4 Business Interactions Modeling
5 BPMN 2 Overview

51. 2 Why do we need modeling languages ?

52. 2 Why do we need modeling languages ?
•Modeling allows efficiency in reading and
understanding.

53. 2 Why do we need modeling languages ?
•Modeling allows efficiency in reading and
understanding.
•A standardized modeling language allows
communication improvement, much the same
way one becomes more literate through
continuous practice of French or English

54. 2 Why do we need modeling languages ?
•Modeling allows efficiency in reading and
understanding.
•A standardized modeling language allows
communication improvement, much the same
way one becomes more literate through
continuous practice of French or English
• Skillful modeling drives the simplification of
reality - and thereby abstraction.

55. 2 Why do we need modeling languages ?
•Modeling allows efficiency in reading and
understanding.
•A standardized modeling language allows
communication improvement, much the same
way one becomes more literate through
continuous practice of French or English
• Skillful modeling drives the simplification of
reality - and thereby abstraction.
•Improves efficiency, modeling allows one to
learn from the Masters and reuse patterns.

56. 2 Why do we need modeling languages ?
•Modeling allows efficiency in reading and
understanding.
•A standardized modeling language allows
communication improvement, much the same
way one becomes more literate through
continuous practice of French or English
• Skillful modeling drives the simplification of
reality - and thereby abstraction.
•Improves efficiency, modeling allows one to
learn from the Masters and reuse patterns.
•Models constitute a body of knowledge from
which one can elaborate on to create new
architectures.

57. 2 Why do we need modeling languages ?

58. 2 Why do we need modeling languages ?
• The goal of a modeling language is to enable
the description of some domain of interest.

59. 2 Why do we need modeling languages ?
• The goal of a modeling language is to enable
the description of some domain of interest.
• The semantics of a language describe the
meaning of its concepts in the domain of
interest.

60. 2 Why do we need modeling languages ?
• The goal of a modeling language is to enable
the description of some domain of interest.
• The semantics of a language describe the
meaning of its concepts in the domain of
interest.
‣ We need Modeling Languages to
express our concepts and their
interactions in a specific domain of
interest

61. 2 Why do we need modeling languages ?

62. 2 Why do we need modeling languages ?
• The set of symbols that compose a language
as well as the rules for forming valid
combinations of these symbols constitute the
language’s syntax.

63. 2 Why do we need modeling languages ?
• The set of symbols that compose a language
as well as the rules for forming valid
combinations of these symbols constitute the
language’s syntax.
• The syntax can be defined in terms of:
• Linear sequences of characters
• Pictorial signs

64. 2 One question though ..
What do they have in common ?

65. 2 One question though ..
What do they have in common ?
➡ They are SIGNS, pictograms used
to designate a concept

66. 2 Signs, Objects and Concepts

67. 2 Signs, Objects and Concepts
• A Sign is an object that is used as a
representation of something else.

68. 2 Signs, Objects and Concepts
• A Sign is an object that is used as a
representation of something else.
• An Object is an observable and identifiable
individual thing.

69. 2 Signs, Objects and Concepts
• A Sign is an object that is used as a
representation of something else.
• An Object is an observable and identifiable
individual thing.
• A Concept is always a Concept of a Type.

70. 2 Signs, Objects and Concepts
• Relationship:

71. 2 Signs, Objects and Concepts
• Relationship:
• Designation : a Sign designates a Concept

72. 2 Signs, Objects and Concepts
• Relationship:
• Designation : a Sign designates a Concept
‣ Left Curve

73. 2 Signs, Objects and Concepts
• Relationship:
• Designation : a Sign designates a Concept
‣ Left Curve
• Denotation: a Sign denotes an Object

74. 2 Signs, Objects and Concepts
• Relationship:
• Designation : a Sign designates a Concept
‣ Left Curve
• Denotation: a Sign denotes an Object
‣ This indicates that there’s going to
be a :

75. 2 Signs, Objects and Concepts
• Relationship:
• Designation : a Sign designates a Concept
‣ Left Curve
• Denotation: a Sign denotes an Object
‣ This indicates that there’s going to
be a :
• Reference: a Concept refers to an Object

76. 2 Signs, Objects and Concepts
• Relationship:
• Designation : a Sign designates a Concept
‣ Left Curve
• Denotation: a Sign denotes an Object
‣ This indicates that there’s going to
be a :
• Reference: a Concept refers to an Object
‣ There’s a Left Curve ahead

77. 2 The meaning triangle
(Ulmann’s triangle)

78. 2 The Ontological Parallelogram

79. 2 Modeling Languages

80. 2 Modeling Languages
• Lexical Layer: the set of primitive modeling
elements

81. 2 Modeling Languages
• Lexical Layer: the set of primitive modeling
elements
• Abstract Syntax: how to compose these
elements, defined in terms of a metamodel

82. 2 Modeling Languages Evaluation

83. 2 Modeling Languages Evaluation
• The Domain Appropriateness of a language
is a measure of the adequacy of a language to
express phenomenon in a given domain.

84. 2 Modeling Languages Evaluation
• The Domain Appropriateness of a language
is a measure of the adequacy of a language to
express phenomenon in a given domain.
• The Comprehensibility Appropriateness
refers to how easy it is to understand model
phenomenon from their expression in a given
language.

85. Extended Process Modeling, Languages and Notations
1 The Need for Models
2 The Need for Languages
3 The Process Domain
4 Business Interactions Modeling
5 BPMN 2 Overview

86. 3 Domain Specific Languages for Processes

87. 3 Domain Specific Languages for Processes
• The main evaluation criteria for a language
are:

88. 3 Domain Specific Languages for Processes
• The main evaluation criteria for a language
are:
• Domain Appropriateness

89. 3 Domain Specific Languages for Processes
• The main evaluation criteria for a language
are:
• Domain Appropriateness
• Comprehensibility Appropriateness

90. 3 Domain Specific Languages for Processes
• The main evaluation criteria for a language
are:
• Domain Appropriateness
• Comprehensibility Appropriateness
• A language appropriateness is determined by
its suitability to a domain, while the
comprehensibility is determined by its users

91. 3 What is the “Process Domain” : Enterprise Architecture
• Architecture is useful at many levels:

92. 3 What is the “Process Domain” : Enterprise Architecture
• Architecture is useful at many levels:
• Sub-Components

93. 3 What is the “Process Domain” : Enterprise Architecture
• Architecture is useful at many levels:
• Sub-Components
• Components

94. 3 What is the “Process Domain” : Enterprise Architecture
• Architecture is useful at many levels:
• Sub-Components
• Components
• Organization

95. 3 What is the “Process Domain” : Enterprise Architecture
• Architecture is useful at many levels:
• Sub-Components
• Components
“The Enterprise is the SYSTEM”
• Organization - Zachman

96. 3 What is the “Process Domain” : Enterprise Architecture
• Architecture is useful at many levels:
• Sub-Components
• Components
“The Enterprise is the SYSTEM”
• Organization - Zachman
• Extended Organization

97. 3 What is the “Process Domain” : Enterprise Architecture
• Architecture is useful at many levels:
• Sub-Components
• Components
“The Enterprise is the SYSTEM”
• Organization - Zachman
• Extended Organization The Business Interaction Network
is the SYSTEM

98. 3 What is the “Process Domain” : Enterprise Architecture
• Architecture is useful at many levels:
• Sub-Components
• Components
“The Enterprise is the SYSTEM”
• Organization - Zachman
• Extended Organization The Business Interaction Network
is the SYSTEM
Architecture is FRACTAL

99. 3 From Silos to Services 1/4
• Functional Silos
• Transversal Business Processes
• Service Oriented Organization

100. 3 From Silos to Services 2/4

101. 3 From Silos to Services 2/4
• A Service Unit produces value from
a set of capabilities.

102. 3 From Silos to Services 2/4
• A Service Unit produces value from
a set of capabilities.
• Some capabilities are exposed as a
service, hence made available to the
outside world.

103. 3 From Silos to Services 3/4
Transversal Business Process

104. 3 From Silos to Services 4/4

105. 3 From Silos to Services 4/4
• Capabilities can be factorized
and made available to other
Organization Units

106. 3 Different kinds of Processes

107. 3 Different kinds of Processes
Process describing a flow of
“Interactions”

108. 3 Different kinds of Processes
Process describing a flow of
“Interactions”
Process describing a flow of
“activities”

109. 3 Orchestration Processes in a Service Unit

110. 3 Different Process Aspects
(source BPMN 2.0)

111. 3 Different Process Aspects
• Orchestration: A sequence or flow of Activities in
an organization with the objective of carrying out work.
(source BPMN 2.0)

112. 3 Different Process Aspects
• Orchestration: A sequence or flow of Activities in
an organization with the objective of carrying out work.
• Collaboration: Collaboration is the act of sending
messages between any two Participants.
(source BPMN 2.0)

113. 3 Different Process Aspects
• Orchestration: A sequence or flow of Activities in
an organization with the objective of carrying out work.
• Collaboration: Collaboration is the act of sending
messages between any two Participants.
• Conversation: It represents a set of
Message Flows grouped together based
on a concept and/or a CorrelationKey.
(source BPMN 2.0)

114. 3 Different Process Aspects
• Orchestration: A sequence or flow of Activities in
an organization with the objective of carrying out work.
• Collaboration: Collaboration is the act of sending
messages between any two Participants.
• Conversation: It represents a set of
Message Flows grouped together based
on a concept and/or a CorrelationKey.
• Choreography: An ordered sequence of B2B
message exchanges between two or more Participants.
(source BPMN 2.0)

115. 3 Some of the available Process Modeling Standards
Languages are not equals when it comes
to Domain and Comprehensibility
Appropriateness

116. 3 One question though ..
In wish cases would you use BPMN ?

117. 3 One question though ..
BPMN

118. 3 One question though ..
BPMN
UML

119. 3 One question though ..
BPMN
BPEL
BPEL 4
People

120. 3 One question though ..
BPMN
BPEL
BPEL 4
People

121. 3 One question though ..
BMM
BPMN
SBVR
UML

122. Extended Process Modeling, Languages and Notations
1 The Need for Models
2 The Need for Languages
3 The Process Domain
4 Business Interactions Modeling
5 BPMN 2 Overview

123. 4 Sequence of interactions between Organization Units

124. 4 Sequence of interactions between Organization Units
• Interactions are sets of
exchanges between
participants

125. 4 Sequence of interactions between Organization Units
• Interactions are sets of
exchanges between
participants
• Interactions need to be
properly defined (Service
Level Agreements)

126. 4 Sequence of interactions between Organization Units

127. 4 Sequence of interactions between Organization Units
• Set of Interactions define
the rules of engagement
between several
participants.

128. 4 Sequence of interactions between Organization Units
• Set of Interactions define
the rules of engagement
between several
participants.
• Hence, Choreography
modeling is key to
integration of
organization units in the
context of a value
production network.

129. 4 Interactions enforced by an Orchestration Model

130. 4 Interactions defined by a Choreography Model

131. 4 Interactions defined by a Choreography Model

132. 4 Informal (not BPMN) description of a set of interactions

133. 4 Informal (not BPMN) description of a set of interactions

134. 4 One question though ..
Is the following notation adapted to its purpose ?

135. 4 One question though ..

136. 4 One question though ..
➡ A BPMN 2 Choreography expresses the
roles of participants as well as the sequences
of their interactions

137. 4 Choreography Model

138. 4 So, the Domain Specific Languages for Business Interactions
• Includes :
• Orchestrations
• Collaboration (and Conversations)
• Choreographies

139. 4 So, the Domain Specific Languages for Business Interactions
• Includes :
• Orchestrations
• Collaboration (and Conversations)
• Choreographies
They are different, intertwined, views of a
same beast

140. 4 Different domains also impact the “Process Domain”

141. 4 Assuming a Role in a global Business Interaction Network
• Formal Definition of the global set of Business Interactions :
• Sub set of interest in regard to ‘Role 2’ :

142. 4 Each participant must fulfill his role
• Interactions expected from ‘Role 2’ :
• ‘Role 2’ fulfillment :

143. Extended Process Modeling, Languages and Notations
1 The Need for Models
2 The Need for Languages
3 The Process Domain
4 Business Interactions Modeling
5 BPMN 2 Overview

144. 5 Business Process Model and Notation
• An Object Management Group specification
• Years of developments
• 70+ implementations (BPMN 1.X, 2.0)
• Created by a consortium of 47 organizations
including Analysts, Strategists, Software vendors
• Axway
• Global 360, Inc.
• Hewlett-Packard
• International Business Machines
• Oracle
• U.S. National Institute of Standards and Technology
• SAP
• ..

145. 5 Different types of Diagrams
• Orchestrations
• Collaborations (and Conversations)
• Choreographies

146. 5 Example of an Orchestration

147. 5 Example of a Collaboration

148. 5 Example of a Conversation

149. 5 Example of a Choreography

150. 5 Orchestration and Conversation

151. 5 Orchestration and Choreographies

152. 5 Event Handling

153. 5 Do not Panic !
• BPMN includes 100+ classes
• BPMN is extendable
• e.g. DoDAF added 30+ classes
• BPMN is Easy !
• Most users only need a very small
subset of BPMN
(Inspired from Column2.com)

154. 5 How much BPMN 1.1 do you need ?

155. 5 How much BPMN 1.1 do you need ?

156. 5 How much BPMN 1.1 do you need ?
The amount of BPMN used depends on the
purpose of the model

157. 5 How much BPMN 1.1 do you need ?

158. 5 How much BPMN 1.1 do you need ?
The amount of BPMN used depends on the
purpose of the model

159. 5 BPMN Models Standardization
<?xml version="1.0" encoding="UTF-8"?>
<definitions id="Definition"
targetNamespace="http://www.example.org/UserTaskExample"
typeLanguage="http://www.w3.org/2001/XMLSchema"
expressionLanguage="http://www.w3.org/1999/XPath"
xmlns=http://www.w3.org/2001/XMLSchema
xmlns=”http://www.omg.org/spec/BPMN/20100524/MODEL”
xmlns:tns="http://www.example.org/UserTaskExample">
<resource id="regionalManager" name="Regional Manager">
<resourceParameter id="buyerName" isRequired="true" name="Buyer Name"
type="xsd:string"/>
<resourceParameter id="region" isRequired="false" name="Region" type="xsd:string"/>
</resource>
<resource id="departmentalReviewer" name="Departmental Reviewer">
<resourceParameter id="buyerName" isRequired="true" name="Buyer Name"
type="xsd:string"/>
</resource>
<collaboration id="BuyerCollaboration" name="Buyer Collaboration">
<participant id="BuyerParticipant" name="Buyer" processRef="BuyerProcess"/>
</collaboration>
<!-- Process definition -->
<process id="BuyerProcess" name="Buyer Process">
<laneSet id="BuyerLaneSet">
<lane id="BuyerLane">
<flowNodeRef>StartProcess</flowNodeRef>
<flowNodeRef>QuotationHandling</flowNodeRef>
<flowNodeRef>ApproveOrder</flowNodeRef> <flowNodeRef>OrderApprovedDecision</flowNodeRef>
<flowNodeRef>TerminateProcess</flowNodeRef>
<flowNodeRef>OrderAndShipment</flowNodeRef>
<flowNodeRef>OrderHandling</flowNodeRef>
<flowNodeRef>ShipmentHandling</flowNodeRef> <flowNodeRef>OrderAndShipmentMerge</flowNodeRef>
<flowNodeRef>ReviewOrder</flowNodeRef>
<flowNodeRef>EndProcess</flowNodeRef>
</lane>
</laneSet>
<startEvent id="StartProcess"/>
<sequenceFlow sourceRef="StartProcess" targetRef="QuotationHandling"/>
<task id="QuotationHandling" name="Quotation Handling"/>
<sequenceFlow sourceRef="QuotationHandling" targetRef="ApproveOrder"/>
<userTask id="ApproveOrder" name="ApproveOrder">
<potentialOwner>
<resourceRef>tns:regionalManager</resourceRef>
<resourceParameterBinding parameterRef="tns:buyerName">
<formalExpression>
getDataInput('order')/address/name
</formalExpression>
</resourceParameterBinding>
<resourceParameterBinding parameterRef="tns:region">
<formalExpression>
getDataInput('order')/address/country
</formalExpression>
</resourceParameterBinding>
</potentialOwner>
</userTask>
<sequenceFlow sourceRef="ApproveOrder" targetRef="OrderApprovedDecision"/>
<exclusiveGateway id="OrderApprovedDecision" gatewayDirection="Diverging"/>
<sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment">
<conditionExpression>

160. 5 BPMN Models Standardization
<?xml version="1.0" encoding="UTF-8"?>
<definitions id="Definition"
targetNamespace="http://www.example.org/UserTaskExample"
typeLanguage="http://www.w3.org/2001/XMLSchema"
expressionLanguage="http://www.w3.org/1999/XPath"
xmlns=http://www.w3.org/2001/XMLSchema
xmlns=”http://www.omg.org/spec/BPMN/20100524/MODEL”
xmlns:tns="http://www.example.org/UserTaskExample">
<resource id="regionalManager" name="Regional Manager">
<resourceParameter id="buyerName" isRequired="true" name="Buyer Name"
type="xsd:string"/>
<resourceParameter id="region" isRequired="false" name="Region" type="xsd:string"/>
</resource>
<resource id="departmentalReviewer" name="Departmental Reviewer">
<resourceParameter id="buyerName" isRequired="true" name="Buyer Name"
type="xsd:string"/>
</resource>
<collaboration id="BuyerCollaboration" name="Buyer Collaboration">
<participant id="BuyerParticipant" name="Buyer" processRef="BuyerProcess"/>
</collaboration>
<!-- Process definition -->
<process id="BuyerProcess" name="Buyer Process">
<laneSet id="BuyerLaneSet">
➡ Serialization format is part of the Standard !
<lane id="BuyerLane">
<flowNodeRef>StartProcess</flowNodeRef>
<flowNodeRef>QuotationHandling</flowNodeRef>
<flowNodeRef>ApproveOrder</flowNodeRef> <flowNodeRef>OrderApprovedDecision</flowNodeRef>
<flowNodeRef>TerminateProcess</flowNodeRef>
<flowNodeRef>OrderAndShipment</flowNodeRef>
<flowNodeRef>OrderHandling</flowNodeRef>
<flowNodeRef>ShipmentHandling</flowNodeRef> <flowNodeRef>OrderAndShipmentMerge</flowNodeRef>
<flowNodeRef>ReviewOrder</flowNodeRef>
<flowNodeRef>EndProcess</flowNodeRef>
</lane>
</laneSet>
<startEvent id="StartProcess"/>
<sequenceFlow sourceRef="StartProcess" targetRef="QuotationHandling"/>
<task id="QuotationHandling" name="Quotation Handling"/>
<sequenceFlow sourceRef="QuotationHandling" targetRef="ApproveOrder"/>
<userTask id="ApproveOrder" name="ApproveOrder">
<potentialOwner>
<resourceRef>tns:regionalManager</resourceRef>
<resourceParameterBinding parameterRef="tns:buyerName">
<formalExpression>
getDataInput('order')/address/name
</formalExpression>
</resourceParameterBinding>
<resourceParameterBinding parameterRef="tns:region">
<formalExpression>
getDataInput('order')/address/country
</formalExpression>
</resourceParameterBinding>
</potentialOwner>
</userTask>
<sequenceFlow sourceRef="ApproveOrder" targetRef="OrderApprovedDecision"/>
<exclusiveGateway id="OrderApprovedDecision" gatewayDirection="Diverging"/>
<sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment">
<conditionExpression>

161. 4 One question though ..
Is it important that BPMN 2
defines its serialization format?

162. Extended Process Modeling, Languages and Notations
Conclusion