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
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)
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
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.
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
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
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.
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
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
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.
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
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
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
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
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
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 ?
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.
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
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
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)
