In today’s vibrant environment of the modern society, developers of process-aware information systems need novel methods for modeling business processes. These methods should have capabilities that could address challenges such as improved reusability of the existing process designs, reduced time-to-market, or run-time business logic change. Recognizing these challenges, the topics of variability and configurability of business process have recently received significant research attention. Although there have been many promising proposals, some important challenges still remained to be address: i) there is no clear consensus on the two key notions – variability and configurability – and their implications on business process affairs such as flexibility, dynamicity, or agility; and ii) (software) development method that can consider different aspects of variability and configurability at different stages of the development lifecycle. In this talk, we will attempt to position variability and configurability of business processes in terms of the well-adopted terminology used in (software) quality engineering. We will then make a distinction between design and run-time variability, and then explain needs for managing both types of variability, so that configurability of business process can systematically be supported. During the talk, we will reflect on the experience in the work on a rule-enhanced business process modeling language (rBPMN) and families of business processes developed by borrowing from software product lines. The talk will be finished by discussing open research challenges among which cross-community and empirical research are emphasized.

1. Variability and Configurability of Business ProcessesWhy, What, When, and How? DraganGašević

3. Many (buzz)words Variable Dynamic Business processes Flexible Changeable Agile Declarative Configurable

4. What’s all this about? Perhaps “A business process is flexible if possible to change it without replacing it completely.” Rainer Schmidt, Gil Regev, Pnina Soffer, Guest Editorial: Requirements for Flexibility and the Ways to Achieve It, Int. J. Business Process Integration and Management, Vol. 3, No. 1, 2008, pp. 1-4

5. Now, please, help! What’s different and similar? Variable Dynamic Business processes Flexible Changeable Agile Declarative Configurable

6. The rest of the talk A perspective to the problem Some experience in managing variability Open challenges

7. Part IA Perspective to the Problem Why and what?

8. Let me introduce myself Also, an excuse to invite you to the 4th International Conference on Software Language Engineering http://planet-sl.org/sle2011

9. Variability in Software Locations in software where behaviour can be configured http://www.program-transformation.org/Variability/SoftwareVariabilityManagement

10. Variability Management Systematic approaches to managing the complexity of variability in software Higher configurability of software products

11. Software Product Lines A set of similar software systems (families) Share many common features Satisfy requirements of a particular domain Configuration Process … Product 1 Product 2 Product n

12. Maintainability, too?! Already known in (software) engineering … the ease with which a product can be maintained to correct defects meet new requirements make future maintenance easier, or cope with a changed environment As simple as a Wikipedia entry: http://en.wikipedia.org/wiki/Maintainability

13. Software Quality Maintainability characteristics Analyzability capability to be diagnosed for deficiency Changeability possibility and ease of change when modifications needed Understandability prospect and likelihood to be understood & comprehended ISO 9126 standard, Software engineering — Product quality

14. Community Engineering

15. Variability Management in BPs Systematic management of complexity of variability forbetter configurability

16. Changeability in BPs Possibility and ease of change when modifications needed At design, configuration, and run-time

17. Understandability in BPs Prospect and likelihood to be understood & comprehended Both variable BPs & configuration processes

18. Part IIExperience in variability & configurability of BPs How and When?

19. Families of BPs Two lifecycles Domain engineering variability is modeled Application engineering modeled variability used for configuration

20. Bird’s Eye View D1 D2 D3 D4 D5 A2 A4 D6 Domain Analysis Domain Design Domain Implementation Model Mapping Variability Modeling Business Process Model Template Implementation NFPs Aggregation and Propagation Product Family Requirements Analysis Business Process Family Design Domain Engineering Requirements Model Service Discovery/ Implementation & Binding Mapping Schema Feature Model Reference Business Process Model Feature Model enriched with NFP values Traceability Links Validation Application Implementation Application Analysis Application Design Legend Business Process Configuration & Service Selection Feature Prioritization and Selection Application Integration and Deployment Stakeholder’s Requirements Analysis Process Flow Stage Application Engineering A1 A3 Output Configured Business Process Application Requirements Specification Configured Feature Model Final Product Artifact Tractability

21. Bird’s Eye View D1 D2 D3 D4 D5 A2 A4 D6 Domain Analysis Domain Design Domain Implementation Model Mapping Variability Modeling Business Process Model Template Implementation NFPs Aggregation and Propagation Product Family Requirements Analysis Business Process Family Design Domain Engineering Requirements Model Service Discovery/ Implementation & Binding Mapping Schema Feature Model Reference Business Process Model Feature Model enriched with NFP values Traceability Links Validation Application Implementation Application Analysis Application Design Legend Business Process Configuration & Service Selection Feature Prioritization and Selection Application Integration and Deployment Stakeholder’s Requirements Analysis Process Flow Stage Application Engineering A1 A3 Output Configured Business Process Application Requirements Specification Configured Feature Model Final Product Artifact Tractability

22. Domain Analysis Product Family Requirements Analysis Requirements Model D1 + Minimize Risk Process Order Customer Satisfaction + or Build, then Ship and Bill Bill, Build, Then Ship Goal Softgoal And And Task CP Apply Process to Customer Ship & Bill Collect Payment Build & Package Order (a) + + + or Domain Engineering Or Decomposition APAC Contribution Apply Process to Trusted Customer Apply Process to Any Customer In Person Payment Electronic Payment Dependency IPP EP And And (b) DTC + + ? Determine Trustworthiness of Customer Approve Order Make Some Help Unknown Hurt Some Break Positive Negative AO And (c) Check if Return Customer Check Credit Rate CRC CCR (d)

23. Goal-goal oriented model Domain Analysis + Minimize Risk Process Order Customer Satisfaction + or Variability Modeling Build, then Ship and Bill Bill, Build, Then Ship And And CP Apply Process to Customer Ship & Bill Collect Payment Build & Package Order or Or APAC Apply Process to Trusted Customer Apply Process to Any Customer Features derived from tasks and mapped to tasks and goals In Person Payment Electronic Payment D1 D2 IPP EP And And DTC Determine Trustworthiness of Customer Approve Order AO And Check if Return Customer Check Credit Rate Feature model CRC CCR Legend Order Management And or Alternative Optional Mandatory + CV-PC = DTC Domain Engineering Payment Management Order Preparation Customer Verification P-PC = CP AO-PC = APAC Bill Check Credit Rate Payment Approve Order Build Check Return Customer CRC-PC = CRC CCR-PC = CCR Hardcopy Bill Online Transaction E-Bill Cash Credit Card Trusted Customer Approving Debit Card Any Customer Approving TCA-PC = AO ACA-PC = AO OL-PC = EP C-PC = IPP CC-PC = EP DC-PC = EP Integrity Constraints: Any Customer ApprovingincludesCustomer Verification

24. Goal-goal oriented model Domain Analysis + Minimize Risk Process Order Customer Satisfaction + or Variability Modeling Build, then Ship and Bill Bill, Build, Then Ship And And CP Apply Process to Customer Ship & Bill Collect Payment Build & Package Order or Or APAC Apply Process to Trusted Customer Apply Process to Any Customer In Person Payment Electronic Payment D1 D2 IPP EP And And DTC Determine Trustworthiness of Customer Approve Order AO And Check if Return Customer Check Credit Rate Feature model CRC CCR Legend Order Management And or Alternative Optional Mandatory + CV-PC = DTC Domain Engineering Payment Management Order Preparation Customer Verification P-PC = CP AO-PC = APAC Bill Check Credit Rate Payment Approve Order Build Check Return Customer CRC-PC = CRC CCR-PC = CCR Derived concerns from soft-goals Hardcopy Bill Online Transaction E-Bill Cash Credit Card Trusted Customer Approving Debit Card Any Customer Approving TCA-PC = AO ACA-PC = AO OL-PC = EP C-PC = IPP CC-PC = EP DC-PC = EP Integrity Constraints: Any Customer ApprovingincludesCustomer Verification Features annotated with concerns Verification with description logic

25. Goal-goal oriented model Domain Analysis + Minimize Risk Process Order Customer Satisfaction + or Variability Modeling Build, then Ship and Bill Bill, Build, Then Ship And And CP Apply Process to Customer Ship & Bill Collect Payment Build & Package Order or Or APAC Apply Process to Trusted Customer Apply Process to Any Customer In Person Payment Electronic Payment D1 D2 IPP EP And And DTC Determine Trustworthiness of Customer Approve Order AO And Check if Return Customer Check Credit Rate Feature model CRC CCR Legend Order Management And or Alternative Optional Mandatory + CV-PC = DTC Domain Engineering Payment Management Order Preparation Customer Verification P-PC = CP AO-PC = APAC Bill Check Credit Rate Payment Approve Order Build Check Return Customer CRC-PC = CRC CCR-PC = CCR Derived concerns from soft-goals Hardcopy Bill Online Transaction E-Bill Cash Credit Card Trusted Customer Approving Debit Card Any Customer Approving TCA-PC = AO ACA-PC = AO OL-PC = EP C-PC = IPP CC-PC = EP DC-PC = EP Integrity Constraints: Any Customer ApprovingincludesCustomer Verification Features annotated with concerns Verification with description logic

26. Goal-goal oriented model Domain Analysis + Minimize Risk Process Order Customer Satisfaction + or Variability Modeling Build, then Ship and Bill Bill, Build, Then Ship And And CP Apply Process to Customer Ship & Bill Collect Payment Build & Package Order or Or APAC Apply Process to Trusted Customer Apply Process to Any Customer In Person Payment Electronic Payment D1 D2 IPP EP And And DTC Determine Trustworthiness of Customer Approve Order AO And Check if Return Customer Check Credit Rate Feature model CRC CCR Legend Order Management And or Alternative Optional Mandatory + Verification with description logic CV-PC = DTC Domain Engineering Payment Management Order Preparation Customer Verification P-PC = CP AO-PC = APAC Bill Check Credit Rate Payment Approve Order Build Check Return Customer CRC-PC = CRC CCR-PC = CCR Derived concerns from soft-goals Hardcopy Bill Online Transaction E-Bill Cash Credit Card Trusted Customer Approving Debit Card Any Customer Approving TCA-PC = AO ACA-PC = AO OL-PC = EP C-PC = IPP CC-PC = EP DC-PC = EP Integrity Constraints: Any Customer ApprovingincludesCustomer Verification Features annotated with concerns

27. Domain Design Business Process Family Design D3 D4 D5 f ... Payment Identity Federation Debit Card Payment Notification Service Credit Card Validation (Pre Verification) Credit Card Payment Fraud Detection Domain Engineering Phone/Fax Notification Mobile-based Notification (MMS-SMS) Email/Voice Email Mapping Payment Reference Business Process Model (Template) Notification Services

28. Domain Design Business Process Family Design D3 D4 D5 f ... Payment Identity Federation Debit Card Payment Notification Service Credit Card Validation (Pre Verification) Credit Card Payment Fraud Detection Domain Engineering Phone/Fax Notification Mobile-based Notification (MMS-SMS) Email/Voice Email Mapping Payment Reference Business Process Model (Template) Notification Services

29. Domain Design Business Process Family Design D3 D4 D5 f ... Payment Identity Federation Debit Card Payment Notification Service Credit Card Validation (Pre Verification) Credit Card Payment Fraud Detection Verification with description logic Domain Engineering Phone/Fax Notification Mobile-based Notification (MMS-SMS) Email/Voice Email Mapping Payment Reference Business Process Model (Template) Notification Services

30. Domain Design Variability for run-time Business Process Family Design D3 D4 D5 rBPMN: rule-enhanced BPMN Domain Engineering

31. Domain Design Variability for run-time Business Process Family Design http://code.google.com/p/rbpmneditor/ D3 D4 D5 rBPMN: rule-enhanced BPMN Domain Engineering

32. Domain Implementation Business Process Model Template Implementation D6 Service Discovery/ Implementation & Binding NFRs (QoS) Price Execution Time Security Availability … S1(1) S2(2) . . . S2(20) Sn(1) Sn(2) . . . Sn(20) Sj(1) Sj(2) . . . Sj (6) Sk(1) Sk(2) . . . Sk(l) S1(1) S1(2) . . . S1(l) Business Process Family Domain Engineering Payment S3(1) S3(2) S3(3) Reference Business Process Model (Template) Notification Services Payment Services

33. Bird’s Eye View D1 D2 D3 D4 D5 A2 A4 D6 Domain Analysis Domain Design Domain Implementation Model Mapping Variability Modeling Business Process Model Template Implementation NFPs Aggregation and Propagation Product Family Requirements Analysis Business Process Family Design Domain Engineering Requirements Model Service Discovery/ Implementation & Binding Mapping Schema Feature Model Reference Business Process Model Feature Model enriched with NFP values Traceability Links Validation Application Implementation Application Analysis Application Design Legend Business Process Configuration & Service Selection Feature Prioritization and Selection Application Integration and Deployment Stakeholder’s Requirements Analysis Process Flow Stage Application Engineering A1 A3 Output Configured Business Process Application Requirements Specification Configured Feature Model Final Product Artifact Tractability

34. Bird’s Eye View D1 D2 D3 D4 D5 A2 A4 D6 Domain Analysis Domain Design Domain Implementation Model Mapping Variability Modeling Business Process Model Template Implementation NFPs Aggregation and Propagation Product Family Requirements Analysis Business Process Family Design Domain Engineering Requirements Model Service Discovery/ Implementation & Binding Mapping Schema Feature Model Reference Business Process Model Feature Model enriched with NFP values Traceability Links Validation Application Implementation Application Analysis Application Design Legend Business Process Configuration & Service Selection Feature Prioritization and Selection Application Integration and Deployment Stakeholder’s Requirements Analysis Process Flow Stage Application Engineering A1 A3 Output Configured Business Process Application Requirements Specification Configured Feature Model Final Product Artifact Tractability

35. Application Analysis + Minimize Risk Process Order Customer Satisfaction + or Build, then Ship and Bill Bill, Build, Then Ship Stakeholder’s Requirements Analysis And ü ü And + CP Minimize Risk Process Order Customer Satisfaction Apply Process to Customer Ship & Bill Collect Payment Build & Package Order + or Or A1 or APAC Apply Process to Trusted Customer Apply Process to Any Customer In Person Payment Electronic Payment ü ü IPP EP And And DTC Build, then Ship and Bill Bill, Build, Then Ship Determine Trustworthiness of Customer Approve Order AO And And Check if Return Customer Check Credit Rate And ü ü ü ü CRC CCR CP (d) Apply Process to Customer Ship & Bill Collect Payment Build & Package Order or Or Backward Reasoning ü ü APAC + Apply Process to Trusted Customer Apply Process to Any Customer In Person Payment Electronic Payment + Application Engineering Objectives Preferences Constraints IPP EP And And ü DTC Determine Trustworthiness of Customer Approve Order AO And Check if Return Customer Check Credit Rate CRC CCR ? ü ü Satisfied Weakly Unknown Weakly Denied Conflict None Satisfied Denied

36. Application Design Feature Prioritization and Selection Order Management ü ü Order Management + Minimize Risk Process Order Customer Satisfaction + or ü ü Build, then Ship and Bill Bill, Build, Then Ship Payment Management Order Preparation Customer Verification And Payment Management Order Preparation And ü ü ü ü CP Apply Process to Customer Ship & Bill Collect Payment Build & Package Order or Or APAC ü ü Bill Check Credit Rate Payment Approve Order Build Check Return Customer Apply Process to Trusted Customer Apply Process to Any Customer In Person Payment Bill Payment Approve Order Build Electronic Payment CRC-PC = CRC CCR-PC = CCR IPP EP And And ü DTC Determine Trustworthiness of Customer Approve Order + Hardcopy Bill Online Transaction E-Bill Cash Credit Card Trusted Customer Approving Debit Card Any Customer Approving AO Hardcopy Bill Online Transaction E-Bill Credit Card Trusted Customer Approving Debit Card Any Customer Approving And Check if Return Customer Check Credit Rate CRC Application Engineering CCR Pre-configuration based on intentions

37. Application Design Order Management Feature Prioritization and Selection Payment Management Order Preparation Preferences Bill Payment Approve Order Build Order Management Hardcopy Bill Online Transaction E-Bill Credit Card Trusted Customer Approving Debit Card Any Customer Approving Payment Management Order Preparation Prioritization and automatic configuration techniques Bill Payment Approve Order Build Application Engineering Trusted Customer Approving Online Transaction E-Bill Credit Card Debit Card Decision science – AHP Artificial intelligence – Fuzzy Datalog & HTN

38. Conditional Stratified Analytical Hierarchy Process Application Design Feature Prioritization and Selection Relative importance Order Management Payment Management Order Preparation Bill Payment Approve Order Build Application Engineering Trusted Customer Approving Online Transaction E-Bill Credit Card Debit Card

39. Application Design Business Process Configuration & Service Selection Preferences { Relative Importance on Concerns} A3 NFRs (QoS) A4 Price Execution Time Security Availability S1(1) S1(2) . . . S1(20) S1(1) S1(2) . . . S1(20) S1(1) S1(2) . . . S1(20) Sj(1) Sj(2) . . . Sj (6) Sj(1) Sj(2) . . . Sj (6) f Sk(1) Sk(2) . . . Sk(l) ü Application Engineering Mapping ü A1 A2 A3 A4 A5

40. Part III Open Challenges

41. Does it work!? All those models! Yeah, right!?

42. Empirical research Urgent!

43. Quality Issues Usability Natural language vs. visual Physics of notation, cognitive dimensions, … Maintainability Understandability, changeability, analyzability Internal structure metrics and experiments …

44. Does visualization help?

47. Visualization for configurability Changeability tasks (time) H1: (Easy) t (38) = 2.11, p = 0.041* H1: (Complex) t (38) = 3.47, p = 0.001* Understandability tasks (time) H3: (Easy) t (38) = 1.42, p = 0.164 H4: (Complex) t (38) = 2.71, p = 0.009 No significant effect on correctness

49. For feature models, best predictors of Analyzability: NLeaf and NVC Understandability: NLeaf and FoC Changeability: FoC, NLeaf, and CC NLeaf - Number of leaf featuresFoC - Flexibility of configuration NoV - Number of valid configurations CC - Cyclomatic complexity

50. Community call: We need a corpus!

55. Heuristic evaluation Contextual inquiry Assertion Lessons learned Design research Concept mapping Cognitive walkthrough End-user study Exploratory data analysis Which method to use? Scenario analysis Theoretical Grounded theory Case study Pilot testing Ethnography Expert review Focus group Empirical Simulation Action research Algorithmic analysis Critical analysis of literature Systemic observation

56. Evidence-based BPM As the integration of best research evidence with practitioner expertise and stakeholder values The goal made up based on

57. Evidence-based BPM

58. Evidence-based BPM

59. Evidence-based BPM Current best evidence from research to integrate withpractical experience and human valuesin the decision making process

60. Evidence-based BPM

61. Systematic reviews

62. Systematic reviews

63. Systematic reviews

64. Measures matter!

65. Measures matter! But, how much really?! ~1/3 out of the 19 studies presented empirical results Very few of them report empirical validation as critical Sanchez Gonzalez et al., 2010 BPM Journal 16 (1), pp. 114-134

66. Measures matter! But, how much really?! Not even touched research on interoperability, compliance, security, maturity, learnability, analyzability, and testability Sanchez Gonzalez et al., 2010 BPM Journal 16 (1), pp. 114-134

67. Infrastructure need!

68. Community Engineering

74. Acknowledgements Lab for Semantic Technologies at AU MarekHatala, EbrahimBagheri, AmalZouaq, Marko Boskovic, Milan Milanovic, BardiaMohabbati, Mohsen Asadi, IvanaOgnjanovic, SamanehSoltani, Luis Rocha, Vid Prezel, Tony Lenihan, EsanMurugesupillai, Glenn Brand,… Jean-Marie Favre and Ralf Lämmel Steffen Staab, Fernando Silva Parreiras, GerdGröner, Tobias Graml, Eduard Schleining Gerd Wagner and Adrian Giurca

75. Thank you!Questions?