Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Developer-Friendly BPM


Published on

A webinar that I gave on June 11, 2014, sponsored by camunda.

Published in: Technology

Developer-Friendly BPM

  1. 1. Sandy Kemsley l l @skemsley Developer-Friendly BPM The Myth of Zero-Code BPM
  2. 2. Agenda  Limitations of model-driven BPM  Drivers for developer-friendly BPM  Comparing BPM paradigms 2Copyright Kemsley Design Ltd., 2014
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Sandy Kemsley l l @skemsley