Most developers in the Eclipse community are aware of the latest innovations and the coolest technologies they can use out of the box to improve their development processes. But what about business analysts and solution architects looking to improve the way they do business process design and management? The typical business process analyst will collect requirements and design processes using a generic language, typically BPMN, deploy it on a process engine, run it and eventually measure it. There is a plethora of Business Process Management Suites from many big vendors, most of them based on Eclipse technologies, that follow this approach. This talk gives a fresh look at this topic drawing from experience and feedback received at previous BPM events at EclipseCON. The talk will propose a domain-specific approach to business process modelling and will show how this can be combined with the various Eclipse technologies used in BPM. Using Sirius, Xtext, BPMN2 Modeler, Stardust, Mangrove and EMF-based transformations, the talk will give the audience a new perspective of what can be achieved in business process modelling when domain knowledge is used at the core of modelling activities. After an introduction to the problem, the talk will illustrate the approach with a scenario in which the technologies mentioned above will be leveraged to create domain-specific graphical and textual process editors, connect them to BPM editors and runtimes, and enrich them with runtime monitoring information from various sources. Anybody who is interested in building enterprise applications with Eclipse or is already doing so, should leave the talk with an understanding of the advantages that a domain-specific approach can bring to business process modelling and with useful knowledge of how to put it in practice.

1. Model Your Business
Processes Like You're in
2015!
Adrian Mos, Xerox Research

2. Business Domain
Business Process
SOA
N x
Typical BP Modelling

3. Domain-Specific Process Modelling
Generic Processes
• BPMN language
• Process semantics is diluted
• Natively understood by the
BPMS (not necessarily fully
portable though)
• Hard to enforce concept-level
SLAs and constraints
• Hard to reuse at all
granularities
Domain-Specific Processes
• Specific language (graphical or
textual)
• Process semantics is strong
• Require conversion to BPMN to
be used in BPMS
• Easy to operate at business
concept-level (SLAs etc)
• Facilitate reuse of business
concepts

4. Generic Processes (BPMN)

5. Domain-Specific Processes
Textual
• Xtext-based for instance
• Appropriate for certain fields
such as legal processes
• Can be used for editing
details in graphical processes
(policies, rules)
Graphical
• Sirius-based for instance
• Appropriate where control
flow is important and layered-
views are useful

6. From Modelling to Execution and Back
Domain-Specific Process Environment
BPMN 2 Editor
BPMS or SOA Specific Editor
BPMS Execution Engine
SOA Environment

7. Landscape
Mangrove BPMN2
Modeler

8. Monitoring Approach

9. From Design to Execution and Back

10. Monitoring at Work
BPMS Execution Engine SOA Environment
Cx
Domain Specific Monitoring
Cy Cz
Ay,
86
S1,
30
S2,
10
S3,
75
Ax,
30
S1,
7
S2,
10
Az
1,
43
Az
2,
28

11. Business Processes using Domain Concepts
a cb d
b g
a
p
d b
f ab t
c fb e
d ca
o
f
a
c
o
t
CPa
setSLA(…)
getMetric(α)
BP1
BP2
BP3
BP4
BP5
BP6
SOA Runtime
S5S3
S6
S4
S2
S1
SLA and Monitoring
at the concept level
across the process
collection

12. DEMO

13. Thank You
adrian.mos@xerox.com