Variability and Configurability of Business Processes Why, What, When, and How?

2,661 views

Published on

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.

Published in: Education, Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,661
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
48
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Variability and Configurability of Business Processes Why, What, When, and How?

  1. 1. Variability and Configurability of Business ProcessesWhy, What, When, and How?<br />DraganGašević<br />
  2. 2.
  3. 3. Many (buzz)words<br />Variable<br />Dynamic<br />Business processes<br />Flexible<br />Changeable <br />Agile<br />Declarative<br />Configurable<br />
  4. 4. What’s all this about?<br />Perhaps<br />“A business process is flexible if possible to change it without replacing it completely.”<br />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<br />
  5. 5. Now, please, help!<br />What’s different and similar?<br />Variable<br />Dynamic<br />Business processes<br />Flexible<br />Changeable <br />Agile<br />Declarative<br />Configurable<br />
  6. 6. The rest of the talk<br />A perspective to the problem<br />Some experience in managing variability<br />Open challenges<br />
  7. 7. Part IA Perspective to the Problem<br />Why and what?<br />
  8. 8. Let me introduce myself<br />Also, an excuse to invite you to<br />the 4th International Conference on Software Language Engineering <br />http://planet-sl.org/sle2011<br />
  9. 9. Variability in Software<br />Locations in software where behaviour can be configured<br />http://www.program-transformation.org/Variability/SoftwareVariabilityManagement<br />
  10. 10. Variability Management<br />Systematic approaches to managing the complexity of variability in software<br />Higher configurability of software products<br />
  11. 11. Software Product Lines<br />A set of similar software systems (families)<br />Share many common features<br />Satisfy requirements of a particular domain<br />Configuration Process<br />…<br />Product 1<br />Product 2<br />Product n<br />
  12. 12. Maintainability, too?!<br />Already known in (software) engineering<br />… the ease with which a product can be maintained to <br />correct defects <br />meet new requirements <br />make future maintenance easier, or <br />cope with a changed environment <br />As simple as a Wikipedia entry: http://en.wikipedia.org/wiki/Maintainability<br />
  13. 13. Software Quality<br />Maintainability characteristics<br />Analyzability <br />capability to be diagnosed for deficiency<br />Changeability<br />possibility and ease of change when modifications needed<br />Understandability <br />prospect and likelihood to be understood & comprehended<br />ISO 9126 standard, Software engineering — Product quality<br />
  14. 14. Community Engineering<br />
  15. 15. Variability Management in BPs<br />Systematic management of complexity of variability forbetter configurability<br />
  16. 16. Changeability in BPs<br />Possibility and ease of change when modifications needed<br />At design, configuration, and run-time<br />
  17. 17. Understandability in BPs<br />Prospect and likelihood to be understood & comprehended<br />Both variable BPs & configuration processes<br />
  18. 18. Part IIExperience in variability & configurability of BPs<br />How and When?<br />
  19. 19. Families of BPs<br />Two lifecycles<br />Domain engineering<br />variability is modeled<br />Application engineering<br />modeled variability used for configuration<br />
  20. 20. Bird’s Eye View<br />D1<br />D2<br />D3<br />D4<br />D5<br />A2<br />A4<br />D6<br />Domain Analysis<br />Domain Design <br />Domain Implementation<br />Model Mapping<br />Variability Modeling<br />Business Process Model Template<br />Implementation <br />NFPs Aggregation and Propagation<br />Product Family <br />Requirements<br />Analysis<br />Business Process <br />Family Design<br />Domain Engineering<br />Requirements Model<br />Service Discovery/ <br /> Implementation & Binding<br />Mapping <br />Schema<br />Feature Model<br />Reference <br />Business Process <br />Model <br />Feature Model enriched <br />with NFP values<br />Traceability Links<br />Validation<br />Application Implementation<br />Application Analysis<br />Application Design<br />Legend<br />Business Process Configuration & Service Selection<br />Feature Prioritization and Selection<br />Application Integration and <br />Deployment<br />Stakeholder’s<br />Requirements <br />Analysis<br />Process Flow<br />Stage<br />Application Engineering<br />A1<br />A3<br />Output<br />Configured<br />Business Process<br />Application <br />Requirements <br />Specification<br />Configured <br />Feature Model<br />Final Product<br />Artifact<br />Tractability<br />
  21. 21. Bird’s Eye View<br />D1<br />D2<br />D3<br />D4<br />D5<br />A2<br />A4<br />D6<br />Domain Analysis<br />Domain Design <br />Domain Implementation<br />Model Mapping<br />Variability Modeling<br />Business Process Model Template<br />Implementation <br />NFPs Aggregation and Propagation<br />Product Family <br />Requirements<br />Analysis<br />Business Process <br />Family Design<br />Domain Engineering<br />Requirements Model<br />Service Discovery/ <br /> Implementation & Binding<br />Mapping <br />Schema<br />Feature Model<br />Reference <br />Business Process <br />Model <br />Feature Model enriched <br />with NFP values<br />Traceability Links<br />Validation<br />Application Implementation<br />Application Analysis<br />Application Design<br />Legend<br />Business Process Configuration & Service Selection<br />Feature Prioritization and Selection<br />Application Integration and <br />Deployment<br />Stakeholder’s<br />Requirements <br />Analysis<br />Process Flow<br />Stage<br />Application Engineering<br />A1<br />A3<br />Output<br />Configured<br />Business Process<br />Application <br />Requirements <br />Specification<br />Configured <br />Feature Model<br />Final Product<br />Artifact<br />Tractability<br />
  22. 22. Domain Analysis<br />Product Family Requirements Analysis<br />Requirements Model<br />D1<br />+<br />Minimize Risk<br />Process Order<br />Customer Satisfaction<br />+<br />or<br />Build, then Ship and Bill<br />Bill, Build, Then Ship<br />Goal<br />Softgoal<br />And<br />And<br />Task<br />CP<br />Apply Process to Customer<br />Ship & Bill<br />Collect Payment<br />Build & Package<br />Order<br />(a)<br />+<br />+<br />+<br />or<br />Domain Engineering<br />Or<br />Decomposition<br />APAC<br />Contribution<br />Apply Process to Trusted Customer<br />Apply Process to Any<br />Customer<br />In Person <br /> Payment<br />Electronic<br /> Payment<br />Dependency<br />IPP<br />EP<br />And<br />And<br />(b)<br />DTC<br />+<br />+<br />?<br />Determine Trustworthiness of <br />Customer<br />Approve Order<br /> Make Some Help Unknown Hurt Some Break<br /> Positive Negative<br />AO<br />And<br />(c)<br />Check if Return <br />Customer<br />Check <br />Credit Rate<br />CRC<br />CCR<br />(d)<br />
  23. 23. Goal-goal oriented model<br />Domain Analysis<br />+<br />Minimize Risk<br />Process Order<br />Customer Satisfaction<br />+<br />or<br />Variability Modeling<br />Build, then Ship and Bill<br />Bill, Build, Then Ship<br />And<br />And<br />CP<br />Apply Process to Customer<br />Ship & Bill<br />Collect Payment<br />Build & Package<br />Order<br />or<br />Or<br />APAC<br />Apply Process to Trusted Customer<br />Apply Process to Any<br />Customer<br />Features derived from tasks and mapped to tasks and goals <br />In Person <br /> Payment<br />Electronic<br /> Payment<br />D1<br />D2<br />IPP<br />EP<br />And<br />And<br />DTC<br />Determine Trustworthiness of <br />Customer<br />Approve Order<br />AO<br />And<br />Check if Return <br />Customer<br />Check <br />Credit Rate<br />Feature model<br />CRC<br />CCR<br />Legend<br />Order Management<br />And<br />or <br />Alternative<br />Optional<br />Mandatory<br />+<br />CV-PC = DTC<br />Domain Engineering<br />Payment<br />Management<br />Order<br />Preparation<br />Customer <br />Verification<br />P-PC = CP<br />AO-PC = APAC<br />Bill<br />Check Credit<br />Rate<br />Payment<br />Approve <br />Order <br />Build<br />Check Return<br />Customer<br />CRC-PC = CRC CCR-PC = CCR<br />Hardcopy<br />Bill<br />Online<br />Transaction<br />E-Bill<br />Cash<br />Credit Card<br />Trusted Customer<br />Approving<br />Debit Card<br />Any Customer<br />Approving <br /> TCA-PC = AO ACA-PC = AO OL-PC = EP C-PC = IPP CC-PC = EP DC-PC = EP<br />Integrity Constraints: Any Customer ApprovingincludesCustomer Verification<br />
  24. 24. Goal-goal oriented model<br />Domain Analysis<br />+<br />Minimize Risk<br />Process Order<br />Customer Satisfaction<br />+<br />or<br />Variability Modeling<br />Build, then Ship and Bill<br />Bill, Build, Then Ship<br />And<br />And<br />CP<br />Apply Process to Customer<br />Ship & Bill<br />Collect Payment<br />Build & Package<br />Order<br />or<br />Or<br />APAC<br />Apply Process to Trusted Customer<br />Apply Process to Any<br />Customer<br />In Person <br /> Payment<br />Electronic<br /> Payment<br />D1<br />D2<br />IPP<br />EP<br />And<br />And<br />DTC<br />Determine Trustworthiness of <br />Customer<br />Approve Order<br />AO<br />And<br />Check if Return <br />Customer<br />Check <br />Credit Rate<br />Feature model<br />CRC<br />CCR<br />Legend<br />Order Management<br />And<br />or <br />Alternative<br />Optional<br />Mandatory<br />+<br />CV-PC = DTC<br />Domain Engineering<br />Payment<br />Management<br />Order<br />Preparation<br />Customer <br />Verification<br />P-PC = CP<br />AO-PC = APAC<br />Bill<br />Check Credit<br />Rate<br />Payment<br />Approve <br />Order <br />Build<br />Check Return<br />Customer<br />CRC-PC = CRC CCR-PC = CCR<br />Derived <br />concerns from <br />soft-goals<br />Hardcopy<br />Bill<br />Online<br />Transaction<br />E-Bill<br />Cash<br />Credit Card<br />Trusted Customer<br />Approving<br />Debit Card<br />Any Customer<br />Approving <br /> TCA-PC = AO ACA-PC = AO OL-PC = EP C-PC = IPP CC-PC = EP DC-PC = EP<br />Integrity Constraints: Any Customer ApprovingincludesCustomer Verification<br />Features annotated with concerns<br />Verification with description logic<br />
  25. 25. Goal-goal oriented model<br />Domain Analysis<br />+<br />Minimize Risk<br />Process Order<br />Customer Satisfaction<br />+<br />or<br />Variability Modeling<br />Build, then Ship and Bill<br />Bill, Build, Then Ship<br />And<br />And<br />CP<br />Apply Process to Customer<br />Ship & Bill<br />Collect Payment<br />Build & Package<br />Order<br />or<br />Or<br />APAC<br />Apply Process to Trusted Customer<br />Apply Process to Any<br />Customer<br />In Person <br /> Payment<br />Electronic<br /> Payment<br />D1<br />D2<br />IPP<br />EP<br />And<br />And<br />DTC<br />Determine Trustworthiness of <br />Customer<br />Approve Order<br />AO<br />And<br />Check if Return <br />Customer<br />Check <br />Credit Rate<br />Feature model<br />CRC<br />CCR<br />Legend<br />Order Management<br />And<br />or <br />Alternative<br />Optional<br />Mandatory<br />+<br />CV-PC = DTC<br />Domain Engineering<br />Payment<br />Management<br />Order<br />Preparation<br />Customer <br />Verification<br />P-PC = CP<br />AO-PC = APAC<br />Bill<br />Check Credit<br />Rate<br />Payment<br />Approve <br />Order <br />Build<br />Check Return<br />Customer<br />CRC-PC = CRC CCR-PC = CCR<br />Derived <br />concerns from <br />soft-goals<br />Hardcopy<br />Bill<br />Online<br />Transaction<br />E-Bill<br />Cash<br />Credit Card<br />Trusted Customer<br />Approving<br />Debit Card<br />Any Customer<br />Approving <br /> TCA-PC = AO ACA-PC = AO OL-PC = EP C-PC = IPP CC-PC = EP DC-PC = EP<br />Integrity Constraints: Any Customer ApprovingincludesCustomer Verification<br />Features annotated with concerns<br />Verification with description logic<br />
  26. 26. Goal-goal oriented model<br />Domain Analysis<br />+<br />Minimize Risk<br />Process Order<br />Customer Satisfaction<br />+<br />or<br />Variability Modeling<br />Build, then Ship and Bill<br />Bill, Build, Then Ship<br />And<br />And<br />CP<br />Apply Process to Customer<br />Ship & Bill<br />Collect Payment<br />Build & Package<br />Order<br />or<br />Or<br />APAC<br />Apply Process to Trusted Customer<br />Apply Process to Any<br />Customer<br />In Person <br /> Payment<br />Electronic<br /> Payment<br />D1<br />D2<br />IPP<br />EP<br />And<br />And<br />DTC<br />Determine Trustworthiness of <br />Customer<br />Approve Order<br />AO<br />And<br />Check if Return <br />Customer<br />Check <br />Credit Rate<br />Feature model<br />CRC<br />CCR<br />Legend<br />Order Management<br />And<br />or <br />Alternative<br />Optional<br />Mandatory<br />+<br />Verification with description logic<br />CV-PC = DTC<br />Domain Engineering<br />Payment<br />Management<br />Order<br />Preparation<br />Customer <br />Verification<br />P-PC = CP<br />AO-PC = APAC<br />Bill<br />Check Credit<br />Rate<br />Payment<br />Approve <br />Order <br />Build<br />Check Return<br />Customer<br />CRC-PC = CRC CCR-PC = CCR<br />Derived <br />concerns from <br />soft-goals<br />Hardcopy<br />Bill<br />Online<br />Transaction<br />E-Bill<br />Cash<br />Credit Card<br />Trusted Customer<br />Approving<br />Debit Card<br />Any Customer<br />Approving <br /> TCA-PC = AO ACA-PC = AO OL-PC = EP C-PC = IPP CC-PC = EP DC-PC = EP<br />Integrity Constraints: Any Customer ApprovingincludesCustomer Verification<br />Features annotated with concerns<br />
  27. 27. Domain Design<br />Business Process Family Design<br />D3<br />D4<br />D5<br />f<br />...<br />Payment<br />Identity Federation<br />Debit Card<br />Payment<br />Notification Service<br />Credit Card Validation<br />(Pre Verification)<br />Credit Card<br />Payment<br />Fraud<br />Detection<br />Domain Engineering<br />Phone/Fax Notification<br />Mobile-based Notification<br />(MMS-SMS)<br />Email/Voice<br />Email<br />Mapping<br />Payment <br />Reference Business Process Model (Template)<br />Notification Services<br />
  28. 28. Domain Design<br />Business Process Family Design<br />D3<br />D4<br />D5<br />f<br />...<br />Payment<br />Identity Federation<br />Debit Card<br />Payment<br />Notification Service<br />Credit Card Validation<br />(Pre Verification)<br />Credit Card<br />Payment<br />Fraud<br />Detection<br />Domain Engineering<br />Phone/Fax Notification<br />Mobile-based Notification<br />(MMS-SMS)<br />Email/Voice<br />Email<br />Mapping<br />Payment <br />Reference Business Process Model (Template)<br />Notification Services<br />
  29. 29. Domain Design<br />Business Process Family Design<br />D3<br />D4<br />D5<br />f<br />...<br />Payment<br />Identity Federation<br />Debit Card<br />Payment<br />Notification Service<br />Credit Card Validation<br />(Pre Verification)<br />Credit Card<br />Payment<br />Fraud<br />Detection<br />Verification with description logic<br />Domain Engineering<br />Phone/Fax Notification<br />Mobile-based Notification<br />(MMS-SMS)<br />Email/Voice<br />Email<br />Mapping<br />Payment <br />Reference Business Process Model (Template)<br />Notification Services<br />
  30. 30. Domain Design<br />Variability for run-time<br />Business Process Family Design<br />D3<br />D4<br />D5<br />rBPMN: rule-enhanced BPMN<br />Domain Engineering<br />
  31. 31. Domain Design<br />Variability for run-time<br />Business Process Family Design<br />http://code.google.com/p/rbpmneditor/<br />D3<br />D4<br />D5<br />rBPMN: rule-enhanced BPMN<br />Domain Engineering<br />
  32. 32. Domain Implementation<br />Business Process Model Template<br />Implementation <br />D6<br />Service Discovery/ Implementation & Binding<br />NFRs (QoS)<br />Price<br />Execution Time<br />Security<br />Availability<br />…<br />S1(1)<br />S2(2)<br /> .<br /> .<br /> .<br />S2(20)<br />Sn(1)<br />Sn(2)<br /> .<br /> .<br /> .<br />Sn(20)<br />Sj(1)<br />Sj(2)<br /> .<br /> .<br /> .<br />Sj (6)<br />Sk(1)<br />Sk(2)<br /> .<br /> .<br /> .<br />Sk(l)<br />S1(1)<br />S1(2)<br /> .<br /> .<br /> .<br />S1(l)<br />Business Process Family<br />Domain Engineering<br />Payment <br />S3(1)<br />S3(2)<br />S3(3)<br />Reference Business Process Model (Template)<br />Notification Services<br />Payment Services<br />
  33. 33. Bird’s Eye View<br />D1<br />D2<br />D3<br />D4<br />D5<br />A2<br />A4<br />D6<br />Domain Analysis<br />Domain Design <br />Domain Implementation<br />Model Mapping<br />Variability Modeling<br />Business Process Model Template<br />Implementation <br />NFPs Aggregation and Propagation<br />Product Family <br />Requirements<br />Analysis<br />Business Process <br />Family Design<br />Domain Engineering<br />Requirements Model<br />Service Discovery/ <br /> Implementation & Binding<br />Mapping <br />Schema<br />Feature Model<br />Reference <br />Business Process <br />Model <br />Feature Model enriched <br />with NFP values<br />Traceability Links<br />Validation<br />Application Implementation<br />Application Analysis<br />Application Design<br />Legend<br />Business Process Configuration & Service Selection<br />Feature Prioritization and Selection<br />Application Integration and <br />Deployment<br />Stakeholder’s<br />Requirements <br />Analysis<br />Process Flow<br />Stage<br />Application Engineering<br />A1<br />A3<br />Output<br />Configured<br />Business Process<br />Application <br />Requirements <br />Specification<br />Configured <br />Feature Model<br />Final Product<br />Artifact<br />Tractability<br />
  34. 34. Bird’s Eye View<br />D1<br />D2<br />D3<br />D4<br />D5<br />A2<br />A4<br />D6<br />Domain Analysis<br />Domain Design <br />Domain Implementation<br />Model Mapping<br />Variability Modeling<br />Business Process Model Template<br />Implementation <br />NFPs Aggregation and Propagation<br />Product Family <br />Requirements<br />Analysis<br />Business Process <br />Family Design<br />Domain Engineering<br />Requirements Model<br />Service Discovery/ <br /> Implementation & Binding<br />Mapping <br />Schema<br />Feature Model<br />Reference <br />Business Process <br />Model <br />Feature Model enriched <br />with NFP values<br />Traceability Links<br />Validation<br />Application Implementation<br />Application Analysis<br />Application Design<br />Legend<br />Business Process Configuration & Service Selection<br />Feature Prioritization and Selection<br />Application Integration and <br />Deployment<br />Stakeholder’s<br />Requirements <br />Analysis<br />Process Flow<br />Stage<br />Application Engineering<br />A1<br />A3<br />Output<br />Configured<br />Business Process<br />Application <br />Requirements <br />Specification<br />Configured <br />Feature Model<br />Final Product<br />Artifact<br />Tractability<br />
  35. 35. Application Analysis<br />+<br />Minimize Risk<br />Process Order<br />Customer Satisfaction<br />+<br />or<br />Build, then Ship and Bill<br />Bill, Build, Then Ship<br />Stakeholder’s Requirements <br />Analysis<br />And<br />ü<br />ü<br />And<br />+<br />CP<br />Minimize Risk<br />Process Order<br />Customer Satisfaction<br />Apply Process to Customer<br />Ship & Bill<br />Collect Payment<br />Build & Package<br />Order<br />+<br />or<br />Or<br />A1<br />or<br />APAC<br />Apply Process to Trusted Customer<br />Apply Process to Any<br />Customer<br />In Person <br /> Payment<br />Electronic<br /> Payment<br />ü<br />ü<br />IPP<br />EP<br />And<br />And<br />DTC<br />Build, then Ship and Bill<br />Bill, Build, Then Ship<br />Determine Trustworthiness of <br />Customer<br />Approve Order<br />AO<br />And<br />And<br />Check if Return <br />Customer<br />Check <br />Credit Rate<br />And<br />ü<br />ü<br />ü<br />ü<br />CRC<br />CCR<br />CP<br />(d)<br />Apply Process to Customer<br />Ship & Bill<br />Collect Payment<br />Build & Package<br />Order<br />or<br />Or<br />Backward <br />Reasoning<br />ü<br />ü<br />APAC<br />+<br />Apply Process to Trusted Customer<br />Apply Process to Any<br />Customer<br />In Person <br /> Payment<br />Electronic<br /> Payment<br />+<br />Application Engineering<br />Objectives<br />Preferences<br />Constraints<br />IPP<br />EP<br />And<br />And<br />ü<br />DTC<br />Determine Trustworthiness of <br />Customer<br />Approve Order<br />AO<br />And<br />Check if Return <br />Customer<br />Check <br />Credit Rate<br />CRC<br />CCR<br />?<br />ü<br />ü<br />Satisfied Weakly Unknown Weakly Denied Conflict None<br /> Satisfied Denied<br />
  36. 36. Application Design<br />Feature Prioritization and Selection<br />Order Management<br />ü<br />ü<br />Order Management<br />+<br />Minimize Risk<br />Process Order<br />Customer Satisfaction<br />+<br />or<br />ü<br />ü<br />Build, then Ship and Bill<br />Bill, Build, Then Ship<br />Payment<br />Management<br />Order<br />Preparation<br />Customer <br />Verification<br />And<br />Payment<br />Management<br />Order<br />Preparation<br />And<br />ü<br />ü<br />ü<br />ü<br />CP<br />Apply Process to Customer<br />Ship & Bill<br />Collect Payment<br />Build & Package<br />Order<br />or<br />Or<br />APAC<br />ü<br />ü<br />Bill<br />Check Credit<br />Rate<br />Payment<br />Approve <br />Order <br />Build<br />Check Return<br />Customer<br />Apply Process to Trusted Customer<br />Apply Process to Any<br />Customer<br />In Person <br /> Payment<br />Bill<br />Payment<br />Approve <br />Order <br />Build<br />Electronic<br /> Payment<br />CRC-PC = CRC CCR-PC = CCR<br />IPP<br />EP<br />And<br />And<br />ü<br />DTC<br />Determine Trustworthiness of <br />Customer<br />Approve Order<br />+<br />Hardcopy<br />Bill<br />Online<br />Transaction<br />E-Bill<br />Cash<br />Credit Card<br />Trusted Customer<br />Approving<br />Debit Card<br />Any Customer<br />Approving <br />AO<br />Hardcopy<br />Bill<br />Online<br />Transaction<br />E-Bill<br />Credit Card<br />Trusted Customer<br />Approving<br />Debit Card<br />Any Customer<br />Approving <br />And<br />Check if Return <br />Customer<br />Check <br />Credit Rate<br />CRC<br />Application Engineering<br />CCR<br />Pre-configuration<br />based on intentions<br />
  37. 37. Application Design<br />Order Management<br />Feature Prioritization and Selection<br />Payment<br />Management<br />Order<br />Preparation<br />Preferences<br />Bill<br />Payment<br />Approve <br />Order <br />Build<br />Order Management<br />Hardcopy<br />Bill<br />Online<br />Transaction<br />E-Bill<br />Credit Card<br />Trusted Customer<br />Approving<br />Debit Card<br />Any Customer<br />Approving <br />Payment<br />Management<br />Order<br />Preparation<br />Prioritization and <br />automatic configuration <br />techniques<br />Bill<br />Payment<br />Approve <br />Order <br />Build<br />Application Engineering<br />Trusted Customer<br />Approving<br />Online<br />Transaction<br />E-Bill<br />Credit Card<br />Debit Card<br />Decision science – AHP<br />Artificial intelligence – Fuzzy Datalog & HTN<br />
  38. 38. Conditional Stratified Analytical Hierarchy Process <br />Application Design<br />Feature Prioritization and Selection<br />Relative importance<br />Order Management<br />Payment<br />Management<br />Order<br />Preparation<br />Bill<br />Payment<br />Approve <br />Order <br />Build<br />Application Engineering<br />Trusted Customer<br />Approving<br />Online<br />Transaction<br />E-Bill<br />Credit Card<br />Debit Card<br />
  39. 39. Application Design<br />Business Process Configuration & Service Selection<br />Preferences<br />{ Relative Importance on Concerns}<br />A3<br />NFRs (QoS)<br />A4<br />Price<br />Execution Time<br />Security<br />Availability<br />S1(1)<br />S1(2)<br /> .<br /> .<br /> .<br />S1(20)<br />S1(1)<br />S1(2)<br /> .<br /> .<br /> .<br />S1(20)<br />S1(1)<br />S1(2)<br /> .<br /> .<br /> .<br />S1(20)<br />Sj(1)<br />Sj(2)<br /> .<br /> .<br /> .<br />Sj (6)<br />Sj(1)<br />Sj(2)<br /> .<br /> .<br /> .<br />Sj (6)<br />f<br />Sk(1)<br />Sk(2)<br /> .<br /> .<br /> .<br />Sk(l)<br />ü<br />Application Engineering<br />Mapping<br />ü<br />A1<br />A2<br />A3<br />A4<br />A5<br />
  40. 40. Part III Open Challenges<br />
  41. 41. Does it work!?<br />All those models! Yeah, right!?<br />
  42. 42. Empirical research<br />Urgent!<br />
  43. 43. Quality Issues<br />Usability <br />Natural language vs. visual <br />Physics of notation, cognitive dimensions, …<br />Maintainability<br />Understandability, changeability, analyzability<br />Internal structure metrics and experiments<br />…<br />
  44. 44. Does visualization help? <br />
  45. 45.
  46. 46.
  47. 47. Visualization for configurability <br />Changeability tasks (time)<br />H1: (Easy) t (38) = 2.11, p = 0.041*<br />H1: (Complex) t (38) = 3.47, p = 0.001*<br />Understandability tasks (time)<br />H3: (Easy) t (38) = 1.42, p = 0.164<br />H4: (Complex) t (38) = 2.71, p = 0.009<br />No significant effect on correctness<br />
  48. 48.
  49. 49. For feature models, best predictors of<br />Analyzability: NLeaf and NVC<br />Understandability: NLeaf and FoC<br />Changeability: FoC, NLeaf, and CC<br />NLeaf - Number of leaf featuresFoC - Flexibility of configuration<br />NoV - Number of valid configurations CC - Cyclomatic complexity<br />
  50. 50. Community call: We need a corpus!<br />
  51. 51.
  52. 52.
  53. 53.
  54. 54.
  55. 55. Heuristic evaluation<br />Contextual inquiry<br />Assertion<br />Lessons learned<br />Design research<br />Concept mapping<br />Cognitive walkthrough<br />End-user study<br />Exploratory data analysis<br />Which method to use?<br />Scenario analysis<br />Theoretical<br />Grounded theory<br />Case study<br />Pilot testing<br />Ethnography <br />Expert review<br />Focus group<br />Empirical<br />Simulation <br />Action research<br />Algorithmic analysis<br />Critical analysis of literature<br />Systemic observation<br />
  56. 56. Evidence-based BPM<br /> As the integration of best research evidence with practitioner expertise and stakeholder values<br />The goal made up based on <br />
  57. 57. Evidence-based BPM<br />
  58. 58. Evidence-based BPM<br />
  59. 59. Evidence-based BPM<br />Current best evidence from research<br />to integrate withpractical experience and human valuesin the decision making process<br />
  60. 60. Evidence-based BPM<br />
  61. 61. Systematic reviews<br />
  62. 62. Systematic reviews<br />
  63. 63. Systematic reviews<br />
  64. 64. Measures matter!<br />
  65. 65. Measures matter!<br />But, how much really?!<br />~1/3 out of the 19 studies presented empirical results<br />Very few of them report empirical validation as critical <br />Sanchez Gonzalez et al., 2010 <br />BPM Journal 16 (1), <br />pp. 114-134<br />
  66. 66. Measures matter!<br />But, how much really?!<br />Not even touched research on interoperability, compliance, security, maturity, learnability, analyzability, and testability<br />Sanchez Gonzalez et al., 2010 <br />BPM Journal 16 (1), <br />pp. 114-134<br />
  67. 67. Infrastructure need! <br />
  68. 68. Community Engineering<br />
  69. 69.
  70. 70.
  71. 71.
  72. 72.
  73. 73.
  74. 74. Acknowledgements<br />Lab for Semantic Technologies at AU<br />MarekHatala, EbrahimBagheri, AmalZouaq, Marko Boskovic, Milan Milanovic, BardiaMohabbati, Mohsen Asadi, IvanaOgnjanovic, SamanehSoltani, Luis Rocha, Vid Prezel, Tony Lenihan, EsanMurugesupillai, Glenn Brand,…<br />Jean-Marie Favre and Ralf Lämmel<br />Steffen Staab, Fernando Silva Parreiras, GerdGröner, Tobias Graml, Eduard Schleining<br />Gerd Wagner and Adrian Giurca<br />
  75. 75. Thank you!Questions? <br />

×