Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Developer-Friendly BPM

7.839 visualizaciones

Publicado el

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

Publicado en: Tecnología

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