The document discusses limitations of fully model-driven business process management (BPM) and advantages of a developer-friendly approach that combines process modeling with existing application development. A fully model-driven BPMS can be limited by business analysts' inability to model complex event-driven processes and technical integration details. It also does not support existing corporate development standards. A combined model-driven and code-based approach allows modeling of business-visible steps while technical processes and integration are handled through standard coding. This achieves better business-IT alignment on process models while limiting need to refactor applications or retrain developers.

1. Sandy Kemsley l www.column2.com l @skemsley
Developer-Friendly
BPM
The Myth of Zero-Code BPM

2. Agenda
 Limitations of model-driven BPM
 Drivers for developer-friendly BPM
 Comparing BPM paradigms
2Copyright Kemsley Design Ltd., 2014

3. Before Model-Driven BPM
Business Analyst
 Write requirements
 Draw process diagrams
as an illustration of
requirements
 Pass off to developer
Developer
 Interpret requirements,
sometimes “creatively”
 Write technical
specifications
 Write code
Copyright Kemsley Design Ltd., 2014 3

4. Problems With Pre-MDD
 No alignment of requirements,
process diagrams, technical specs
and code
 Lengthy requirements and
development cycles
Copyright Kemsley Design Ltd., 2014 4

5. Model-Driven BPMS:
Business Analyst
 Create executable BPMN process
models
 Generate simple UIs for human tasks
 Deploy process directly (prototype or
production)
 Pass off to developer if more complex
Copyright Kemsley Design Ltd., 2014 5

6. Model-Driven BPMS:
Developer
 Augment business process models
with BPMN technical activities
(events, message flows)
 Write integration code for existing
systems
 Integrate BPM into existing portal
Copyright Kemsley Design Ltd., 2014 6

7. Limitations of Full
Model-Driven BPMS
 Business analyst capabilities:
l Event-driven processes
l Technical integration
l Executable process model becomes
“corrupted” with technical details
 Developer environment:
l BPMS becomes proprietary app dev
l BPMN becomes visual code
l No support for corporate dev standards
Copyright Kemsley Design Ltd., 2014 7

8. Developer-Friendly BPM
 Executable process models
l Shared models for business-visible
steps
l Technical models for orchestration
 Add process to existing applications
l No rewriting of applications
l Open platforms
Copyright Kemsley Design Ltd., 2014 8

9. BPM Within Existing
Application Development
 Work with corporate development
standards:
l Development environment,
frameworks, languages
l Code repository and version control
l Automated testing tools
l Lightweight process engine
l Less vendor lock-in
Copyright Kemsley Design Ltd., 2014 9

10. Selecting A Paradigm
Full Model-Driven BPM
 Entire executable flow is
understood by business
 Standalone forms-based
UI
 No complex event logic
 No complex integration
OR
 Use BPMS as corporate
application development
environment
Model+Code BPM
 Complex application
beyond process flow
 Event-driven processes
 Integration with existing
systems and UI
 Combine model-driven
with existing enterprise
app dev standards
Copyright Kemsley Design Ltd., 2014 10

11. Summary
 Understand the advantages and
limitations of fully model-driven BPM
 Combine model-driven BPM with
existing enterprise app dev:
l Best of breed approach
l Supports complex core processes and
applications
l Business-IT alignment on process
models
l Limit application refactoring and
developer retraining
Copyright Kemsley Design Ltd., 2014 11

12. Sandy Kemsley l www.column2.com l @skemsley