1. Copyright 2007, Workflow Management Coalition Workflow, BPM, & New Enterprise Architecture Keith Swenson Technical Committee Chairman WfMC Vice President of R&D Fujitsu Computer Systems http://kswenson.wordpress.com/

2. is defined in a is managed by a composed of which may be Process Definition Representation of what is intended to happen Business Process What is intended to happen Workflow Management System ( BPMS ) Workflow Management System ( BPMS ) Activities Manual Activities Manual Activities Automated Activities Automated Activities Work Items Invoked Applications Invoked Applications Process Instance used to create & manage composed of Representation of what is actually happening Controls the automated Aspects of the process. includes one or more Not managed by BPMS during execution are represented by Tasks allocated to a Workflow Participant. Services called as part of process Activity Instances subprocess Terms

3. 3 Motivation Drivers for Business Process Management (BPM) Drivers for Business Process Management (BPM) Performance Business Process Improvement Engineering of Process-aware IS Performance Business Process Improvement Engineering of Process-aware IS Compliance Mandated compliance (e.g. SOX) Desired compliance (e.g. ISO, ITIL) Compliance Mandated compliance (e.g. SOX) Desired compliance (e.g. ISO, ITIL)

4. Copyright 2007, Workflow Management Coalition The Evolution of Workflow and BPM How we got where we are, and why.

5. 1990  Workflow in the Brain Application Logic in Monolithic Program UI “Screens” Enterprise Application “Account Management” Background CheckConformance Rules List AcctsNew Acct Mod AcctDel Acct

6. 1993  Workflow Assist in Sequence Application Logic in Monolithic Program UI “Screens” background check create account check guidelines Launches UI User accesses original UI directly Human BPM/Workflow: Enterprise Application “Account Management” Background CheckConformance Rules List AcctsNew Acct Mod Acct Del Acct

7. 1996  Distribute Work Application Logic in Monolithic Program UI “Screens” background check create account check guidelines Launches Enterprise Application “Account Management” Background CheckConformance Rules List AcctsNew Acct Mod Acct Del Acct

8. 2002  Service Oriented Architecture Application Logic Service Oriented Architecture Exposed Web Services enter info create account bg check rulesReview UI connects user to process engine, not the back-end applications Enterprise Application “Account Management” Background CheckConformance Rules List AcctsNew Acct Mod AcctDel Acct

9. 2005  Composite Services = IT Agility enter info create account call 1Review ESB / BPEL Application Logic Exposed Web Services Composite Services BackgroundOld Rules List AcctsNew Acct Mod AcctDel Acct New Rules

10. Representing Human Activities Review Automated phase before to prepare for the task Wait phase for Human to do the work, includes timers and escalation logic Automated phase after to take care of results of the task User Interface (while waiting) Note: this notation is not standard! Modeling Human Activities helps to accommodate the kinds of changes that human organizations go through.

11. 2008  Simplify as “Human Steps” call 1 enter info Review ESB / BPEL Application Logic Exposed Web Services Composite Services Background Rules List AcctsNew Acct Mod AcctDel Acct

12. Separation of Responsibility Business Retains Control of Assignment of Responsibility Groups, Roles, Skills Deadlines Alerts, Reminders, Escalations Order of Tasks Addition of Manual Tasks User Interface IT Retains Control of Computational Logic Data Representations Scalability / Performance Interoperability Master Data Management ESB / BPEL BackgroundRules List AcctsNew Acct Mod AcctDel Acct call 1 enter info Review

13. Who? When? What? How? Separate Development Business Retains Control of Assignment of Responsibility Groups, Roles, Skills Deadlines Alerts, Reminders, Escalations Order of Tasks Addition of Manual Tasks User Interface IT Retains Control of Computational Logic Data Representations Scalability / Performance Interoperability Master Data Management Depends strongly on who is in each organization. Changes on daily basis Organizational Culture Optimize for each team Respond to market or legislation Related to Training, Experience Requires expensive technical capabilities Very low or no dependence upon the organizational culture Knowledge of infrastructure

14. 2010  Cloud Based BPM call 1 enter info Review ESB / BPEL Public Cloud Hosted Workflow Background Rules List AcctsNew Acct Mod AcctDel Acct “Cloudlet” Corporate Private Cloud

15. Copyright 2007, Workflow Management Coalition Business Level Agility Calmly Confronting Change

16. Agility = Business Driven Change w/o Programming News Flash! Some other bank sued! Need to respond quickly to avoid risk! News Flash! Some other bank sued! Need to respond quickly to avoid risk! ESB / BPEL BackgroundRules List AcctsNew Acct Mod Acct Del Acct call 1 enter info Review

17. Agility = Business Driven Change w/o Programming Immediate Response: Handle the problem manually with a specialist team -- the next day. Immediate Response: Handle the problem manually with a specialist team -- the next day. ESB / BPEL BackgroundRules List AcctsNew Acct Mod Acct Del Acct call 1 enter info Review legal check

18. Agility = Business Driven Change w/o Programming Eventually: Automate the step with a service, and eliminate the manual review team a few weeks or months later. Eventually: Automate the step with a service, and eliminate the manual review team a few weeks or months later. ESB / BPEL Background Rules List AcctsNew Acct Mod Acct Del Acct call 1 enter info Review Legal Compliance

19. Copyright 2007, Workflow Management Coalition Model Preserving Strategy Keith Swenson Technical Committee Chairman WfMC Vice President of R&D Fujitsu Computer Systems http://kswenson.wordpress.com/

20. Three Kinds of Change Business Process Enactment: –the business process as it moves from the beginning to the end of handling a single case. The process definition does not normally change here, only the process instance or context that records the state of a particular case changes. Business Process Lifecycle: –these are the changes that a business process goes through from initial concept, to modeling, to integration, and finally to deployment into an enactment environment. Business Process Improvement: –the change to a business process that occurs over time through repeated use of the business process lifecycle followed by analysis of how well that version of the business process worked.

21. Lifecycle Example – 3 Key Roles A Business Process Analyst has insight into the business itself, and also has skills being able to model that process. A Systems Engineer performs the work of integrating the process with the other systems in the organization. In the enactment environment are Administrators and Users who interact with the running processes. MODEL

22. Model Transforming Strategy Transformed between domains optimized for that domain can take advantages of specific capabilities Often is dramatic change without any apparent correlation between the parts of the different models.

23. Model Preserving Strategy Preserving means that the model remains substantially the same in all domains.

24. Analytics Analytics provides information about how long each activity takes, how often branches are taken in the execution environment ? Analytic results on a transformed model may not be meaningful to the business user.

25. Simulation & Optimization Simulation attempts to estimate how well a process will run in real environment. Optimization attempts to find the best configuration. Simulation results on the business model may not be valid or meaningful if the execution model is different.

26. Round-Trip Difficulties ? Ability to return to original model with all the extensions of the system engineer is not always possible. Transformed model does not always contain all the information from the previous domain. With Model Preserving Strategy round-trip is a given.

27. Agile Development Get 100% of business domain work done… Business and System work can be done at any time without any time gap. System engineer can suggest changes to business model. They work together on the same model because it is preserved. Get 100% of system domain work done. Forces a “fast waterfall” approach.

28. Error Resolution If a process hits a business problem that was not anticipated by the process, then a person must get involved to determine the correct resolution to the problem. ? If may be difficult for a business person to recognize the error situation, or to determine the correct rule modification, if the executing model is different from what they originally drew.

29. Optimization & Performance – Within Domain Model leverages business person skills. Model leverages engineering and programming skills. Model can use special execution optimizations

30. Tradeoffs Model Transforming Strategy –Preferred by systems engineers and useful for high performance execution. Model Preserving Strategy –Best if you want the business person to be in control of the processes. –Enables better simulation, optimization, analytics, error correction, round trip, and agile development of business processes. –Brings business and process together.

31. Process Design Ecosystem Vendor F Vendor E SOA Design Workflow Design Vendor C Vendor D Vendor B Vendor A Process DiscoveryProcess Simulation Process Execution Process Modeling Process Model Repository Process Optimization Process Execution Executable Model Repository (e.g. XPDL) Executable Model Repository (e.g. BPEL) Discovery Ownership/Issue Resources/Time Goals/Strategies BPMN

32. Process Design Ecosystem Vendor F Vendor E SOA Design Workflow Design Vendor C Vendor D Vendor B Vendor A Process DiscoveryProcess Simulation Process Execution Process Modeling Process Model Repository Process Optimization Process Execution Executable Model Repository (e.g. XPDL) Executable Model Repository (e.g. BPEL) Discovery Ownership/Issue Resources/Time Goals/Strategies BPMN Lifecycle (To Execution)

33. BPM Suite Trends Structured Flexible Unstructured Enterprise Integration Workflow Email BPM Orchestration Human Oriented BPM Social Networks 1990’s Today ? Dynamic BPM Case Mgmt

34. Dynamic BPM Use Case: Fighting Fires Challenge for Responders –Speed –Information –Coordination of Teams Unpredictable … –Fixed plan can not anticipate changing needs –Plan elaborated as you work –Composed from fragments –Respond to situation

35. Modeling for a Change For change to be easy –Representation must be “natural” –Conceptually matching what people do –Mimicking organizational structure, job functions, and roles Transforming the diagram into a “reduced” list makes it hard to change –Can actually reduce Agility E.g.: a “map” vs. “directions”

36. Social Network & Dynamic BPM No strong distinction between “designers” and “users”. Blending of domains. Design at the same time as running. Unified, continuously updated, process Model Preserving Strategy is a Requirement

37. Review Definition of Model Strategy –Model Preserving Strategy –Model Transforming Strategy Tradeoffs –Analytics –Simulation –Error Correction –Performance Designing for Change Process Ecosystem Dynamic BPM

38. Summary New structure for enterprise applications –Separate “who” & “when” controlled by business users –From “what” & “how” controlled by IT developers –Purposefully segregate these aspects so that the right group has the right flexibility from the start Key Benefits: –Business Level Control & Agility Modeling for a Change –How the process is represented is important in affording the right kinds of change. –Model of human behavior vs. server behavior

39. BPM In Practice: A Primer for BPM & Workflow Standards All of this and more is covered in this new book from Keith Swenson and Robert Shapiro available at: http://www.lulu.com/content/2244958 See the related blog at: http://kswenson.wordpress.com/books

40. Process Thought Leadership