Capability as a Service in digital enterprises

CaaS

EC FP7 Project 611351

Capability as a Service in digital enterprises Collaborative Project Number 611351

Deliverable 5.3: The Final Version of Capability Driven Development Methodology

Start date of the project: September 1, 2013 Duration: 36 months Lead contractor for this deliverable: UR Authors: Jānis Grabis, Martin Henkel, Jānis Kampars, Hasan Koç, Kurt Sandkuhl, Dirk Stamer, Janis Stirna, Francisco Valverde, Jelena Zdravkovic Revision: 1.0, final, May 31, 2016

Project funded by the European Commission within the Seventh Framework Programme (2007-2013) Dissemination Level PU

Public

PP

Restricted to other programme participants (including the Commission Services)

RE

Restricted to a group specified by the consortium (including the Commission Services)

CO

Confidential, only for members of the consortium (including the Commission Services)

X

1

CaaS


Versioning and Contribution History Version Description

Authors

0.10

Outline

Kurt Sandkuhl

0.20

Initial Content for sections 1, 2, parts of 3 and 4

Kurt Sandkuhl

0.30

Initial version of section 3.1

Kurt Sandkuhl

0.31

Contributions to section 3.1

Janis Stirna

0.36

Initial content for sections 3.4, 4.1.1 and 7

Hasan Koç

0.37

Revised extensions, section 4.4, 4.3

Janis Stirna, Martin Henkel

0.38

Review of sections 2.1, 2.4, 2.5, 2.6

Paco Valverde

0.39

Revised section 3.7 and section 4.1.3 are added

Jānis Grabis

0.40

Changes in 1, 3,4 and the annex

Kurt Sandkuhl

0.41

Revised section 3.6, added Appendix F

Jānis Kampars

0.42

Review of design process

Martin Henkel

0.46

Section 4.4 added

Jānis Grabis

0.48

Appendix C updated; minor revisions in Sections 3 and 4

Jānis Grabis

0.49

Minor changes in Executive Summary, Section 2, Section 3.1, and Kurt Sandkuhl Section 4

0.5

Added content to section 5

0.51

Version 0.50 without change tracks and minor formatting changes Kurt Sandkuhl

0.6

Document review

Martin Henkel

0.61

Appendix E removed

Janis Grabis

0.62

Section 7 extended

Hasan Koç

0.7

Format checking, minor changes in section 3.6

Hasan Koç

1.0

Final version

Hasan Koç

Kurt Sandkuhl

2

CaaS


Executive Summary The overall objective of the CaaS project is to create an integrated approach consisting of methods, tools and reusable best practices that allow digital enterprises to take advantage of changes in business context and technologies. This deliverable primarily contributes to CaaS Objective 1, namely, “to elaborate a methodology and supporting methods for Capability Driven Development (CDD) which is adopted by the industrial partners involved in the project and their customers”. To this end the deliverable presents the final version of the CDD methodology, which consists of a number of method components supporting different aspects of the CDD process. More specifically, methodology components addressing capability design, enterprise and business process modelling, context modelling, supporting reuse, as well as adjusting capability delivery at run-time have been developed. Furthermore, there is a method component supporting the decision making about whether or not CDD is suitable and how to get started. The methodology also includes method extensions for specific application domains, namely business process outsourcing, collaborative software development and project management office. The deliverable reflects the modular and incremental approach to methodology engineering and documentation in CaaS, which is manifested in the methodology components and extensions. The modularity allows for the users to focus only on those parts of the methodology that are needed for their work. The CDD methodology is described from three conceptual aspects – (1) The modelling languages in terms of concepts and notations used to represent the modelling product, i.e. the models and capability designs created. (2) The way of working, the procedures and tools used, in order to arrive at a capability design that fits organization’s needs, i.e. the modelling process. (3) The technical foundation and formal definition of algorithms for run-time adjustments of capabilities. The deliverable also includes extensive examples of capability design, context modelling and run-time adjustments. These examples are meant to support understanding and selection of the method components.

3

CaaS


Table of Contents EXECUTIVE SUMMARY ........................................................................................................... 3 LIST OF FIGURES .................................................................................................................... 8 LIST OF TABLES .................................................................................................................... 11 LIST OF ACRONYMS ............................................................................................................. 13 1. INTRODUCTION ............................................................................................................ 15 1.1 ADHERENCE TO REVIEWER RECOMMENDATIONS FROM RP2 ..................................................... 16 1.2 OUTLINE OF THE DOCUMENT ............................................................................................... 16 2. OVERVIEW OF THE CAPABILITY DRIVEN METHODOLOGY .............................................. 17 2.1 THE ROLE OF CAPABILITY IN THE CDD METHODOLOGY ............................................................. 18 2.2 ELEMENTS OF A CDD METHOD ENGINEERING FRAMEWORK ..................................................... 18 2.3 METHODOLOGY DEVELOPMENT PRINCIPLES ........................................................................... 20 2.4 OVERVIEW OF THE CDD LIFE-CYCLE ...................................................................................... 20 2.5 STAKEHOLDER TYPES INVOLVED IN THE USE OF THE CDD METHODOLOGY ................................... 21 2.6 USE OF TOOLS TO SUPPORT THE CDD METHODOLOGY ............................................................ 22 3. METHOD COMPONENTS OF THE CDD ........................................................................... 24 3.1 GETTING STARTED WITH CAPABILITY DESIGN .......................................................................... 24 3.1.1 Method Component: Getting Started with Capability Design ................................ 25 3.1.1.1 Important Concepts ...................................................................................................................... 25 3.1.1.2 Procedure for Getting Started with Capability Design .................................................................. 25 CAPABILITY DESIGN PROCESS ............................................................................................... 32

3.2 3.2.1 Method Component: Capability Design ................................................................. 32 3.2.1.1 Important Concepts ...................................................................................................................... 33 3.2.1.2 Procedure for Capability Design ................................................................................................... 34 3.2.1.3 Notation for Capability Design ...................................................................................................... 39 ENTERPRISE MODELLING ..................................................................................................... 40

3.3 3.3.1 Method Component: Enterprise Modelling ............................................................ 40

3.4

3.3.1.1 Important Concepts ...................................................................................................................... 40 3.3.1.2 Procedure for Enterprise Modelling ............................................................................................. 42 3.3.1.3 Notation for EM ............................................................................................................................ 46 CONTEXT MODELLING ........................................................................................................ 48 3.4.1.1 Overview of the Procedures of the Context Modelling Method Component ............................... 49 3.4.1.2 Cooperation Principles for Context Modelling .............................................................................. 49

3.4.2 Method Component: Capture Context Element ..................................................... 51 3.4.2.1 3.4.2.2 3.4.2.3

Important Concepts ...................................................................................................................... 52 Procedure ...................................................................................................................................... 53 Notation ........................................................................................................................................ 59

3.4.3.1 3.4.3.2 3.4.3.3

Important Concepts ...................................................................................................................... 61 Procedure ...................................................................................................................................... 62 Notation ........................................................................................................................................ 63

3.4.3 Method Component: Design Context Set ............................................................... 60

3.4.4 Method Component: Prepare for Operational Use ................................................ 63 3.4.4.1 Important Concepts ...................................................................................................................... 64 3.4.4.2 Notation ........................................................................................................................................ 66 REUSE OF CAPABILITY DESIGN .............................................................................................. 66

3.5 3.5.1 Overview of Method Component for Reuse of Capability Design .......................... 66 3.5.1.1 3.5.1.2

Procedures .................................................................................................................................... 67 Concepts ....................................................................................................................................... 68

3.5.2.1 3.5.2.2

Important Concepts ...................................................................................................................... 70 Procedure ...................................................................................................................................... 70

3.5.2 Method Component: Pattern Elicitation and Elaboration ...................................... 69 3.5.3 Method component: Pattern application and performance evaluation ................ 78 4

CaaS

EC FP7 Project 611351 3.5.3.1 Important Concepts ...................................................................................................................... 78 3.5.3.2 Procedure ...................................................................................................................................... 79 RUN-TIME DELIVERY ADJUSTMENTS ...................................................................................... 88

3.6 3.6.1 Purpose and Preconditions ..................................................................................... 90 3.6.2 Overview of Method Components for Capability Adjustment ................................ 91 3.6.2.1

Procedures .................................................................................................................................... 91

3.6.3.1 3.6.3.2

Important Concepts ...................................................................................................................... 93 Procedure ...................................................................................................................................... 94

3.6.4.1 3.6.4.2

Important Concepts .................................................................................................................... 101 Procedure .................................................................................................................................... 101

3.6.5.1 3.6.5.2


3.6.6.1 3.6.6.2 3.6.6.3 3.6.6.4

Purpose and Preconditions ......................................................................................................... 108 Overview of Method Component ............................................................................................... 109 Cooperation Principles ................................................................................................................ 110 Procedure .................................................................................................................................... 111

3.6.7.1 3.6.7.2


3.6.3 Method component: Adjustment modelling and design ........................................ 92 3.6.4 Method Component: Adjustment Implementation and Delivery ......................... 101 3.6.5 Method Component: Adjustment Assessment and Improvement ....................... 104 3.6.6 Method Component: Performance Based Context Evaluation Adjustment ......... 108

3.6.7 Method Component: Predictive analysis .............................................................. 116 4. METHOD EXTENSIONS ................................................................................................ 124 4.1 BUSINESS PROCESS OUTSOURCING ..................................................................................... 124 4.1.1 Method Extension: Capability Ready Business Services ....................................... 124 4.1.1.1 4.1.1.2 4.1.1.3

Purpose and Preconditions ......................................................................................................... 125 Cooperation Principles ................................................................................................................ 126 Method Component: Capability Ready Business Services .......................................................... 126

4.1.2.1 4.1.2.2 4.1.2.3

Purpose and Preconditions ......................................................................................................... 133 Cooperation Principles ................................................................................................................ 135 Method Component: Prepare Local and Global Optimization .................................................... 136

4.1.2 Method Extension: Prepare Local and Global Optimization ................................ 132

4.1.3 Method Extension: Evolutionary Development of Capabilities Delivered as Software Service Bundles ................................................................................................. 148 4.1.3.1 Purpose and Preconditions ......................................................................................................... 149 4.1.3.2 Cooperation Principles ................................................................................................................ 149 4.1.3.3 Method Component: Evolutionary Development ...................................................................... 149 4.1.3.4 Summary ..................................................................................................................................... 157 CAPABILITY RELATIONSHIP ANALYSIS AND MODELLING FROM A STRATEGIC PERSPECTIVE ............. 157

4.2 4.2.1 Analysis of Capability Relationships and Mapping to Delivered Services ............. 158 4.2.2 Strategic Capability Modelling ............................................................................. 165 4.3 INTEGRATION OF CDD AND MDD ...................................................................................... 171 4.3.1 Purpose and Preconditions ................................................................................... 172 4.3.2 Cooperation Principles ......................................................................................... 173 4.3.3 Method Component: Selection of Integration Approach for CDD and MDD ........ 173 4.3.3.1 4.3.3.2


4.3.4 Method Component: Conceptual Gap Analysis of CDD and MDD tools ............... 183 4.3.4.1 Important Concepts .................................................................................................................... 184 4.3.4.2 Procedure .................................................................................................................................... 184 PROJECT MANAGEMENT OFFICE METHOD EXTENSION: CAPACITY EVALUATION IN COLLABORATIVE

4.4 CAPABILITY DELIVERY ................................................................................................................. 191 4.4.1 Purpose and Preconditions ................................................................................... 192 4.4.2 Method Component: Capacity Evaluation ........................................................... 193 4.4.2.1 4.4.2.2


5

CaaS


5. SUMMARY AND CONCLUSIONS .................................................................................. 202 REFERENCES ...................................................................................................................... 205 6. APPENDIX A: META-MODEL OF CAPABILITY DESIGN ................................................... 209 Capability ............................................................................................................................................... 210 Goal ........................................................................................................................................................ 210 Indicator ................................................................................................................................................. 211 Context Indicator ................................................................................................................................... 211 KPI .......................................................................................................................................................... 211 Resource ................................................................................................................................................ 212 Process (alias Business Process) ............................................................................................................. 212 Process Variant ...................................................................................................................................... 213 Capability Delivery Pattern (alias Pattern) ............................................................................................. 213 Context Set ............................................................................................................................................. 214 Context Situation ................................................................................................................................... 214 Context Element Range .......................................................................................................................... 215 Context Element .................................................................................................................................... 215 Context Element Value .......................................................................................................................... 216 Context Element Type (alias Context Type) ........................................................................................... 216 Measurable Property ............................................................................................................................. 216 KPI Calculation ....................................................................................................................................... 217 KPI Value ................................................................................................................................................ 217 Context Calculation ................................................................................................................................ 218 Calculation ............................................................................................................................................. 218 Context Indicator Calculation ................................................................................................................. 218 Scheduled Adjustment ........................................................................................................................... 219 Event Based Adjustment ........................................................................................................................ 219 Adjustment ............................................................................................................................................ 220 Capability Delivery Variation Point ........................................................................................................ 220 Process Variant Variation Point ............................................................................................................. 221 Variation Point ....................................................................................................................................... 221 Variation Aspect ..................................................................................................................................... 221 Adjustment Constant ............................................................................................................................. 222

7. APPENDIX B: APPLICATION OF CONTEXT MODELLING METHOD COMPONENT ............ 223 7.1 AN EXAMPLE FROM THE AIRLINE INDUSTRY .......................................................................... 223 7.1.1 Enterprise objectives ............................................................................................ 223 7.1.2 High-level Processes ............................................................................................. 224 7.1.3 Practical Application of Context Modelling Method Component ......................... 229 Step 1. Process Model Analysis ......................................................................................... 229 Step 2: Context Element Design ........................................................................................ 230 Step 3: Context Set Design ................................................................................................ 233 Step 4: Design Binding ...................................................................................................... 233 7.2 AN EXAMPLE FROM THE PHARMACEUTICAL INDUSTRY ............................................................ 235 7.2.1 Enterprise objectives ............................................................................................ 236 7.2.2 High-level Processes ............................................................................................. 237 7.2.3 Practical Application of Context Modelling Method Component ......................... 242 Step 1: Process Model Analysis ......................................................................................... 242 Step 2: Context Element Design ........................................................................................ 243 Step 3: Context Set Design ................................................................................................ 245 Step 4: Design Binding ...................................................................................................... 245 7.3 APPLICATION IN SIV CASE ................................................................................................. 247 7.3.1 Enterprise objectives ............................................................................................ 247 7.3.2 High-level Processes ............................................................................................. 248 7.3.3 Practical Application of Context Modelling Method Component ......................... 249 Step 1: Process Model Analysis ......................................................................................... 249 Step 2: Context Element Design ........................................................................................ 250 Step 3: Context Set Design ................................................................................................ 252 6

CaaS

EC FP7 Project 611351 Step 4: Design Binding ...................................................................................................... 253

8. APPENDIX C: EXAMPLE OF USING SCHEDULED ADJUSTMENT FOR CAPABILITY DELIVERY 255 8.1 ADJUSTMENT MODELLING AND DESIGN ................................................................................ 256 8.2 ADJUSTMENT IMPLEMENTATION AND DELIVERY ..................................................................... 258 9. APPENDIX D: EXAMPLE OF PERFORMANCE BASED CONTEXT EVALUATION ADJUSTMENT 262 Step 1 Define goals and KPI .............................................................................................. 262 Step 2 Define context calculation ..................................................................................... 263 Step 3 Define performance adjustment ............................................................................ 264 Step 4 Monitor capability delivery .................................................................................... 265 Step 5 Adjust context range evaluation ............................................................................ 266

7

CaaS


List of Figures Figure 2-1. Method components according to Goldkuhl et al. (1998). .......................... 19 Figure 2-2. CDD methodology overview ....................................................................... 21 Figure 2-3. CDD phases and tools .................................................................................. 23 Figure 3-1. Process first capability modelling ................................................................ 37 Figure 3-2. Sub-Models of the 4EM approach and their relationships .......................... 42 Figure 3-3. The EM process model showing processes and information sets (adapted from Persson & Stirna, 2010) ......................................................................................... 43 Figure 3-4. Example use of the 4EM Goal Modelling notation (from Sandkuhl, 2014).47 Figure 3-5. Example use of the BPMN for process modelling . .................................... 48 Figure 3-6. Method component Capture Context Element............................................. 52 Figure 3-7. An example of dependency analysis ............................................................ 59 Figure 3-8. CDT Notation for Context Modelling ......................................................... 60 Figure 3-9. Method component Design context set ........................................................ 61 Figure 3-10. Method component Prepare for operational use ...................................... 64 Figure 3-11. Capability pattern lifecycle ........................................................................ 67 Figure 3-12. Reuse of Capability Design method component relation to CDD phases 68 Figure 3-13. Method Component Pattern Elicitation and Documentation ..................... 70 Figure 3-14. Editing a pattern in CPR ............................................................................ 75 Figure 3-15. Example screen of a pattern in CPR .......................................................... 77 Figure 3-16. Pattern application and performance evaluation method component ........ 78 Figure 3-17. Search patterns by context elements .......................................................... 80 Figure 3-18. Projects referencing context element ......................................................... 80 Figure 3-19. CPR faceted search .................................................................................... 81 Figure 3-20. Pattern Performance Indicator ................................................................... 82 Figure 3-21. Capability viewed in CPR.......................................................................... 85 Figure 3-22. CNA indicators .......................................................................................... 86 Figure 3-23. Adjustment groups ..................................................................................... 89 Figure 3-24. Method component relation to CDD phases .............................................. 92 Figure 3-25. Method component Adjustment modelling ............................................... 92 Figure 3-26. Linking a Context Element to a Context Calculation ................................ 95 Figure 3-27. Linking a KPI to a KPICalculation .................................................. 95 Figure 3-28. Event based adjustment and it relationships with other elements. ............ 96 Figure 3-29. Linking a Capability Delivery Variation Point to a Scheduled Adjustment ........................................................................................................................................ 96 Figure 3-30. Adjustment Constant element .................................................................... 97 Figure 3-31. IDA for a Context Calculation ................................................................... 98 Figure 3-32. IDA for a KPICalculation ................................................................. 99 Figure 3-33. IDA for an Event Based Adjustment ....................................................... 100 Figure 3-34. IDA for a Scheduled Adjustment............................................................. 100 8

CaaS


Figure 3-35. Method component Adjustment design and delivery .............................. 101 Figure 3-36. JavaAdjustment class template ........................................................ 102 Figure 3-37. Method component Adjustment assessment and improvement ............... 105 Figure 3-38. Charts visualizing KPI and context values. ............................................. 106 Figure 3-39. The context evaluation adjustment algorithm .......................................... 110 Figure 3-40. Search based adaptation adjustment as a part of capability model. ......... 113 Figure 3-41. Reactive vs proactive capability delivery adjustment.............................. 117 Figure 3-42. Overview of the predictive analysis method component ......................... 118 Figure 3-43. Concepts of prediction, historic data and prediction horizon .................. 118 Figure 3-44. A fragment of capability design using actual data ................................... 120 Figure 3-45. Application of the prediction pattern ...................................................... 121 Figure 4-1. Method Extension 1: Capability Ready Business Services ....................... 127 Figure 4-2. Method Extension 2: Prepare Local and Global Optimization .................. 136 Figure 4-3. The overview of evolutionary development method component .............. 150 Figure 4-4. The evolutionary capability development process..................................... 151 Figure 4-5. Capability delivery monitoring results in the first stage ............................ 156 Figure 4-6. Overview of the Analysis of capability relationships and Mapping to Delivered Services method component ........................................................................ 160 Figure 4-7. Example of capability ownership, (see D3.2 for details) ........................... 161 Figure 4-8. Example of collaboration of capabilities, (see D3.2 for details) ............... 163 Figure 4-9. Example of composition of capabilities..................................................... 164 Figure 4-10. Overview of the Strategic Capability Modeling method component ...... 167 Figure 4-11. Overview of the selection of integration approach for CDD and MDD method component ....................................................................................................... 174 Figure 4-12. Result of the CDD modelling of step 1.................................................... 176 Figure 4-13. Excerpt from the CDD model depicting a context set ............................. 182 Figure 4-14. Overview of the Conceptual Gap Analysis of CDD and MDD tools method component .................................................................................................................... 184 Figure 4-15. The collaborative incident resolution process. ........................................ 192 Figure 4-16. Overview of the capacity evaluation method component ........................ 193 Figure 4-17. The PMO capability design: incident resolution resource evaluation view ...................................................................................................................................... 196 Figure 7-1. A screenshot from the app ......................................................................... 223 Figure 7-2. A simplified fragment of ComfortFly´s goal model .................................. 224 Figure 7-3. The workflow of the application ................................................................ 224 Figure 7-4. Flight situation assessment ........................................................................ 225 Figure 7-5. Airport situation assessment ...................................................................... 225 Figure 7-6. Actions recommended by the application based on user context, detailed view .............................................................................................................................. 227 Figure 7-7. Actions recommended by the application based on user context, consolidated view ......................................................................................................... 228 Figure 7-8. Two process variants of the task “assess airport situation” ....................... 230 9

CaaS


Figure 7-9. Dependency analysis between gateways ................................................... 231 Figure 7-10. Initial context model ................................................................................ 232 Figure 7-11. Context model including capability, as a connector of all three views ... 233 Figure 7-12. Simplified goal model of AutoPhar ......................................................... 237 Figure 7-13: High-level process (organizational processes) ........................................ 237 Figure 7-14. Variations in "Planning" Process ............................................................. 238 Figure 7-15. Variations in "Procurement" Process ....................................................... 239 Figure 7-16: Variations in "Development" Process ..................................................... 239 Figure 7-17. Activities in highly regulated environments ............................................ 239 Figure 7-18. Single activity in the high-level process “Quality Assurance” ................ 240 Figure 7-19. Variations in "Storage and Delivery" Process ......................................... 240 Figure 7-20. Variations in "Sales and Marketing" Process .......................................... 241 Figure 7-21: Process execution in an attractive market with low economic infrastructure and low amount of emerging players ........................................................................... 241 Figure 7-22. The adaptation of process execution depicted in Figure 7-21 to the application context ........................................................................................................ 242 Figure 7-23. Dependency analysis................................................................................ 244 Figure 7-24. Context model including capability, as a connector of all three views ... 245 Figure 7-25: Simplified Goal Model of SIV Group ..................................................... 248 Figure 7-26: High-level clearing process ..................................................................... 248 Figure 7-27: 1st level sub-process to implement the appropriate handling instructions 249 Figure 7-28: Process model for clearing exception type „NZM-1122“. ...................... 250 Figure 7-29: Dependency analysis in SIV case ............................................................ 251 Figure 7-30: Initial context model ................................................................................ 252 Figure 7-31: Extended context model, including capabilities, processes and goals..... 253 Figure 8-1. Cloud service scaling capability. ............................................................... 256 Figure 8-2. Selected calculations and adjustments added to a fragment of the capability design ............................................................................................................................ 257 Figure 8-3. Data bindings and adjustment constant added to the model (a fragment). 258 Figure 8-4. A sample context calculation ..................................................................... 259 Figure 8-5. Java code implementing ScaleCloudResourcesSchAdj scheduled adjustment ..................................................................................................................... 260 Figure 8-6. CNA of the Cloud service scaling capability: a) indicators; b) adjustment constants; c) context situation monitoring; and d) log of adjustments. ........................ 261

10

CaaS


List of Tables Table 3-1. Main concepts for getting started with Capability Design ............................ 25 Table 3-2. Overview of the three alternative design approaches ................................... 33 Table 3-3. Concepts for the Capability Design Component ........................................... 33 Table 3-4. Main notational symbols for Capability Design ........................................... 39 Table 3-5. Actor involvement in the EM process steps (R- responsible, P- participates) ........................................................................................................................................ 46 Table 3-6. Assignment of Stakeholders to Method Components ................................... 49 Table 3-7. RACI chart .................................................................................................... 50 Table 3-8. Concepts in Capture Context Element Component ...................................... 52 Table 3-9. An example of gateway identification .......................................................... 54 Table 3-10. An example of process variant identification.............................................. 54 Table 3-11. An example of factor and goal fulfilment analysis based on identified gateways ......................................................................................................................... 58 Table 3-12. An example of factor and goal fulfilment analysis based on identified process variants............................................................................................................... 58 Table 3-13. Renaming the gateways as variation points ................................................ 59 Table 3-14. Concepts in Design Context Set Component .............................................. 61 Table 3-15. Concepts in Prepare for Operational Use Method Component ................. 64 Table 3-16. Patterns, key concepts ................................................................................. 68 Table 3-17. Pattern template used for CDD ................................................................... 72 Table 3-18. The most important concepts for Adjustment modelling ............................ 93 Table 3-19. Functionality provided by Measurable Property IDA ................................. 98 Table 3-20. Assignment of Stakeholders to Method Components ............................... 111 Table 3-21. Important concepts of predictive analysis ................................................. 118 Table 4-1. Important Concepts of the Method Capability Ready Business Services ... 128 Table 4-2. Stakeholders required for different steps of the method extension ............. 135 Table 4-3. Concepts used in the method extension from D5.2..................................... 137 Table 4-4. Additional concepts defined by the method extension ............................... 137 Table 4-5. Context elements extracted from the context model ................................... 141 Table 4-6. Support for identifying decision variables .................................................. 143 Table 4-7. Decision variables in the local system for V1 ............................................ 144 Table 4-8. Final list of decision variables for V1 on global level ................................ 144 Table 4-9. Final list of decision variables in the local systems for V2......................... 145 Table 4-10. Final list of decision variables for V2 on global level .............................. 145 Table 4-11. Concepts used in the method extension .................................................... 150 Table 4-12. Context values and their context ranges.................................................... 152 Table 4-13. Capability support matrix .......................................................................... 153 Table 4-14. Stakeholders required for the method component .................................... 159 Table 4-15. Example - mapping capabilities to services .............................................. 165 Table 4-16. Stakeholders required for the method component .................................... 166 11

CaaS


Table 4-17. Stakeholders required for the method extension ....................................... 173 Table 4-18. Stakeholders required for the method extension ....................................... 178 Table 4-19. Summary of run time monitoring options ................................................. 180 Table 4-20. Summary of run time adaptation options .................................................. 181 Table 4-21. Summary of generic integration needs ...................................................... 182 Table 4-22. The zAppDev MDD concepts with examples given ................................. 185 Table 4-23. Template of overlapping concepts table ................................................... 188 Table 4-24. Example of overlapping concepts’ table ................................................... 188 Table 4-25. Actions to be taken for overlapping concepts ........................................... 190 Table 4-26. Key concepts of capacity evaluation method component ......................... 194 Table 4-27. Layout of the capacity evaluation matrix .................................................. 199 Table 5-1. Summary of method component vision of D1.4 and the Final Version of the CDD methodology ........................................................................................................ 202 Table 7-1. Capturing the gateways ............................................................................... 229 Table 7-2. Identifying and analyzing factors causing variability ................................. 230 Table 7-3. Renaming the gateways as variation points ................................................ 232 Table 7-4. Adding context calculations to the context model ...................................... 234 Table 7-5. Adding adjustments to the context model ................................................... 235 Table 7-6. Capturing variations .................................................................................... 242 Table 7-7. Numbering process variants ........................................................................ 242 Table 7-8. Identifying and analyzing factors causing variability (gateway view) ....... 243 Table 7-9. Identifying and analyzing factors causing variability (process variant view) ...................................................................................................................................... 243 Table 7-10: Renaming the gateways ............................................................................ 244 Table 7-11. Expressing the context calculations .......................................................... 246 Table 7-12. Expressing the adjustments ....................................................................... 246 Table 7-13: Capturing the gateways ............................................................................. 249 Table 7-14: Identifying and analysing factors causing variability ............................... 250 Table 7-15: Renaming the gateways as variation points .............................................. 251 Table 7-16: Adding context calculations to the context model .................................... 253 Table 7-17: Expressing the adjustments ....................................................................... 254

12

CaaS


List of Acronyms 4EM

For Enterprise Modeling

API

Application Programming Interface

ARM

Actors and Resource Model

BPM

Business Process Model

BPMN

Business Process Model and Notation

BPO

Business Process Outsourcing

BRM

Business Rules Model

BSP

Business Service Provider

CaaS

Capability as a Service

CCP

Capability Context Platform

CDA

Capability Delivery Application

CDA

Capability Delivery Application

CDD

Capability Driven Development

CDT

Capability Design Tool

CM

Concepts Model

CNA

Capability Navigation Application, Capability Delivery Navigation Application

CPR

Capability Pattern Repository

EKD

Enterprise Knowledge Development

EM

Enterprise Modelling

ERP

Enterprise Resource Planning

GM

Goals Model

GW

Gateway

IDA

Input Data Association

KPI

Key performance indicator

MDD

Model Driven Development

13

CaaS


MSCONS

Metered Services Consumption Report

PPI

Pattern Performance Indicator

PMO

Project Management Office

RACI

Responsible-Accountable-Consulted-Informed

SOA

Service Oriented Architecture

SSB

Software-service bundle

TCRM

Technical Components and Resources Model

VP

Variation Point

XML

Extensible Markup Language

14

CaaS


1. Introduction The overall objective of the CaaS project is to create an integrated approach consisting of methods, tools and reusable best practices that allow digital enterprises to take advantage of changes in business context and technologies. The CaaS project follows an evolutionary development approach and the innovation process is industry driven. The following objectives of the project have been formulated in the DoW: •

•

• • •

•

Objective 1: To elaborate a methodology and supporting methods for capability driven development which is adopted by the industrial partners involved in the project and their customers. Objective 2: To formulate best practices for delivery of digital businesses as capability delivery patterns and to populate the repository of capability delivery patterns with at least 50 patterns. Objective 3: To develop methods for capability delivery adjustment according to the changes in context. Objective 4: To establish the capability design and delivery environment and to introduce it in business environments by industrial partners. Objective 5: To validate the capability design and delivery methodology in at least three industrial use cases, to implement capability delivery applications for these industrial cases and to test ability to adjust capability delivery to changing context in real life situations. Objective 6: To prepare the methodology for successful industrial and academic dissemination, exploitation and uptake by software development companies, ICT consulting companies, and industrial user groups in order to make the wider impact of the project results to the European community

This deliverable supports the achievement of Objective 1 and Objective 6. Objective 1 is supported by providing the following contributions: •

•

•

The final version of the CDD methodology, which consists of a number of method components supporting different aspects of the CDD process. More specifically, methodology components addressing getting started with CDD, capability design, enterprise and business process modelling, context modelling, supporting reuse, as well as adjusting capability delivery at run-time have been developed. Method extensions for the application domains represented by the use cases are included. These domains are business process outsourcing, collaborative software development and project management office. The deliverable presents the three conceptual aspects of the CDD methodology – (1) the modelling languages in terms of concepts and notations used to represent the modelling product, i.e. the models and capability designs created. (2) The way of working, the procedures and tools used, in order to arrive at a capability

15

CaaS


design of good quality i.e. the modelling process. (3) The technical foundation and formal definition of algorithms for run-time adjustments of capabilities. The final methodology version has been developed iteratively and incrementally based on feedback from all use cases. The initial version of the methodology was published in D5.2. Initial versions of the method extensions were subject of deliverables from the use case work packages WP2, WP3 and WP4, i.e. deliverables D2.2, D3.2 and D4.3. Objective 6 is supported as this deliverable forms part of the documentation that supports future industrial users from software development, ICT consulting or industry in using CDD, i.e. it is subject to exploitation. The work reported in this deliverable has been jointly performed by academic partners (SU, RTU, UR, UPVLC) of the CaaS consortium within work package WP5. It has also be done in close cooperation with Croz within WP6, primarily on the work pertinent to development of the CDT and CNA, as well as in close collaboration with use case partners SIV, CMLS, and Everis.

1.1 Adherence to Reviewer Recommendations from RP2 There are no recommendations of the reviewers in the second review period which are deemed relevant to this deliverable.

1.2 Outline of the Document The rest of the document is structured as follows. Chapter 2 provides an overview of the CDD methodology including elements of the method engineering framework used to define the methodology components, methodology development principles, overview of the CDD methodology, stakeholder types to be involved in its use, as well as the tool support. Chapter 3 defines the method components of the CDD, addressing the following areas – Getting Started with CDD, Capability Design, Enterprise Modelling, Context Modelling, Reuse of Capability Design, as well as Run-time Adjustment. The concept of method component is seen as composite. Hence, several of the components consist of a few smaller method components. Chapter 4 provides method extensions which are structured into different sections according to the application domains they are targeting. Chapter 5 presents concluding remarks. The document also contains several appendices. Appendix A presents an updated CDD meta-model that now includes additional components for context indicator calculation. Appendix B presents two detailed examples of applying the context modelling method components from airline and pharmaceutical industries. Appendix C elaborates an example of scheduled adjustments for capability delivery. Finally, Appendix D presents an example of performance based context evaluation adjustment.

16

CaaS


2. Overview of the Capability Driven Methodology The main goal of the CaaS project is to facilitate a shift from the service-oriented paradigm to a capability delivery paradigm. This paradigm shift requires development a new methodical framework supporting capability-driven design and development in general and it also requires changes in the development processes and engineering methods used in the three industrial cases in CaaS. The CDD methodology for capability-driven design and development consist of the following method components; Getting Started with CDD, Capability Design, Enterprise Modelling, Context Modelling, support for Reuse of Capability Design, and Run-time Delivery Adjustments. The Getting Started with CDD method component provides checklists supporting decision making whether or not CDD is suitable for an organisation. Furthermore, steps for getting started with using CDD are described. The capability design method component contains three approaches to start with capability design (goal, process and concepts). The Enterprise modelling component is required for identifying business goals related to the capability under consideration. Enterprise modelling includes for example business process modelling and goal modelling. The Context modelling component is used to specify the potential context situations of the capability. The component for supporting reuse of capability design specifies how the concept of patterns can be used to elicit, elaborate and store enterprise models. The component for Run-time Capability Adjustment, concerns the specification of adjustments needed in order to cater to changes in capability context. The CDD methodology has been developed in an iterative and incremental process including several methodology versions in the CaaS project: •

•

•

•

Base methodology: the main purpose of the base methodology was to support the industrial use cases in developing initial capability models, i.e. the business services to be considered in the use cases including their context. For this purpose, the base methodology covered selected ways of capability modelling and provide method components supporting these selected ways. CaaS base methodology has been described in an internal project report and used for elaboration of deliverables D2.1, D3.1, D4.1 and D4.2. CDD methodology: the initial CaaS methodology supports a wider selection of capability development processes and extended the base methodology towards capability delivery and runtime adaptation. This version of the methodology is available in deliverable D5.2. CDD method extensions: each of the industrial cases in CaaS (WP2, WP3, WP4) developed extensions of the initial CaaS methodology. The extensions are documented in deliverables D2.2, D3.2 and D4.3. Final CDD methodology: one of the final results of the CaaS project is the final version of the CDD methodology including the latest versions of all method components and method extensions packaged for use outside the CaaS project. This deliverable presents this final version of the methodology.

17

CaaS


2.1 The Role of Capability in the CDD Methodology The main objective of CaaS is to establish a capability driven development for congruent digital business and information system development methodology. The methodology for capability-driven design (CDD) and development consists of various components addressing different modelling aspects, such as context modelling, business process modelling, pattern modelling or capability modelling. An initial overview of all CDD method components is given in Deliverable 1.4, section 7.4 (Bērziša et al, 2014). This section will briefly describe the concept of capability in relation to the main modelling aspects used. According to the definition developed in the context of this project and included in Deliverable 1.4 (Bērziša et al, 2014b), a capability is the ability and capacity that enables an enterprise to achieve a business goal in a certain context. Thus, a capability always is defined by something (e.g. an intention) that the business can achieve, a defined operational context and goals of the enterprise to be reached. Conceptually, the model of a capability consists of the following parts: •

•

strategic objectives or business goals related to the capability or motivating the creation of the capability. These objectives should be specified in a precise, measurable and accepted way, for example by using Enterprise Modelling techniques such as elaborating a goal model. the business service(s) offered to customers within the capability. In CDD, the business service(s) have to be specified using a model-based approach. For the base methodology, we limit the support to process-oriented approaches and we assume that exactly one business service is defined for each capability.

•

the specification of the potential application context where the business service is supposed to be deployed. The specification of the capability’s potential deployment contexts is captured in a context model.

•

an IT-based solution for delivering the capability in the defined context, i.e. executing the business service. For the initial methodology, we assume that all variations of the solution for different context instances are defined, e.g. as delivery patterns. patterns specifying reusable elements for reaching business goals under specific situational contexts. The CDD methodology is providing a method component for identification, elicitation and representation of patterns.

•

This methodology is supported by a CDD environment that provides a set of tools for modelling, deploying and monitoring at runtime the defined capabilities. Details about the CDD environment are presented in D6.3.

2.2 Elements of a CDD Method Engineering Framework When developing the CDD methodology, the consortium had to engage in method engineering, i.e. a task of developing and integrating new and existing components of methodologies. The way methods and method components are described within CDD is an extension of the method conceptualization proposed by Goldkuhl et al. (1998). Goldkuhl et al. state that a comprehensive method description should describe the perspective, framework, cooperation principles and all method components. Figure 2-1 18

CaaS


illustrates how the elements of the method conceptualization are related.

Figure 2-1. Method components according to Goldkuhl et al. (1998).

The following elements are elaborated for each component of the CDD methodology: •

•

•

Method component – this is core defining in operational terms what are the concepts used, a procedure, and a notation. More specifically, o the concepts specify what aspects of reality are regarded as relevant in the modelling process, i.e. what is important and what should be captured a model. These relevant concepts and their relationships should be named in the method component and explained if necessary. o the procedure describes in concrete terms how to identify the relevant concepts in a method component. It may also cover prerequisites and resources. The procedure should be described in terms of work steps to be performed with input, output and tool support. In some cases the procedure also includes guidelines of modelling. o The notation specifies how the result of the procedure should be documented. As a rule, this must provide appropriate expressions for each concept and for the potential relationships between them. In graphic notations, these are the symbols to be used. Overview to method components: the method overview describes the relationships between the individual method components, i.e. which components are to be used and under what conditions, as well as the sequence of the method components (if any). This overview often is referred to as method “framework”. Forms of cooperation: many modelling tasks require a range of specialist skills or cooperation between different roles. These necessary skills and roles must be described, along with the division of responsibilities between the roles and the form of cooperation. The cooperation form also includes who will take 19

CaaS

•


responsibility for each task or method component, and how the collaboration will be organized. Purpose: every method (or method component) has to clearly state, what the purpose of the method is, e.g. what modelling or problem solving task is supported by the method. Furthermore, a method usually describes the procedure for the modelling task or problem solving at hand from a particular perspective, which influences what is considered important when following the procedure defined by the method. This perspective should also be stated explicitly.

A method component often includes a number of work steps and sometimes it even contains other method components. Thus, we assume that a method component can in turn include one or several other method components (sub-components) that are described in the same structure as a complete method.

2.3 Methodology Development Principles The development of the CDD methodology follows the following principles, which were defined during analysis of use case requirements and are document in Deliverable 1.4 (Bērziša et al, 2014b): •

• •

•

CDD should not be a single methodology mandatory for all business cases but a reference methodology ready-to-use and pathways from this reference methodology to proprietary methodologies All types of models, i.e. patterns, context, process and enterprise models, should be based on the same meta-model The (reference) methodology should not be a monolithic block but componentoriented in order to allow flexible use of selected method components depending on the intentions an organization has and a particular development situation. Integration of existing methods or method components should be given preference before substituting them with new.

2.4 Overview of the CDD Life-cycle The CDD methodology life-cycle and its activities are defined in D1.3 “Vision of the CDD Methodology”. This life-cycle is made up of three phases: enterprise modelling, design, delivery. There are also two simultaneous activities for management and feedback (Figure 2-2). The phases of the CDD methodology correspond to the stages in the ISO/IEC 2007 specification.

20

CaaS


MANAGEMENT Start

Planning

ENTERPRISE MODELLING

Concepts models

Rules model

Technical components and its model

DESIGN

DELIVERY

Capability solution part

Context suitability assessment

Capability intention part

Capability evaluated

Capability ready for deployment

Metrics

Actor models

Ending

Repository

Goal models KPI

Repository

Process models

Control

Consistency check

Indicator status report

FEEDBACK Figure 2-2. CDD methodology overview

The Enterprise Modelling phase represents the traditional approach to business design and development of information systems. The CDD methodology will apply existing Enterprise Modelling techniques to provide starting information for the capability design. In particular, EKD (Loucopoulos et al., 1997; Bubenko, Persson & Stirna, 2001) and 4EM (Sandkuhl et al., 2014), are used. However, definition and updating of these methods is beyond the scope of the CDD methodology.

2.5 Stakeholder Types Involved in the Use of the CDD Methodology The CDD methodology involves several stakeholders. As initially specified in D1.4 the following stakeholders are involved in the CDD: •

• •

Capability analyst: analyses information about capabilities and their expected operating context. From this analysis, they predict the evolution of the context and take advantage of these predictions by providing new services or improving existing services. Method engineer: person who has knowledge about the CDD methodology and can tailor it for requirements specific to an organization. CDD provider: Provides and maintains the CDD methodology and the tools to support it.

Additionally, there are stakeholders involved in the business and directly associated with capabilities under study: • •

Business service manager: Responsible for management strategies, for changes in business and to identify opportunities for capitalizing on these changes. Business analyst: a person who analyses the business models and proposes changes to these models.

21

CaaS


•

Solution engineer: configures and carries out business solution implementations, such as the implementation and configuration of an IT system support. Business service operator: aims to follow best practices for achieving the delivery of services to the customers. Solution architect: works closely with solution engineers to ensure proper implementations. Solution architect is the link between the needs of the business and the solution engineer.

• •

Other stakeholders involved are: • • • •

Capability provider: responsible of providing capabilities to the customer. Customer (client): The end user who benefits from the services provided by capabilities. Capability worker: responsible of assuring the proper delivery of a capability in technical terms. Capability feedback provider: analyses the feedback received from customers, capability workers and from other stakeholders in order to improve the capability delivery.

2.6 Use of Tools to Support the CDD Methodology The CDD methodology is supported by the CDD environment. The CDD environment should supports the goals defined in the CDD methodology, implements the capability meta-model (see Appendix A) and provides a set of tools and modelling editor in order to support the method components. The CDD environment consists of the following key components: •

•

•

•

•

Capability Design Tool (CDT): a graphical modelling tool for supporting the creation of models (goal models, process models, concept models, context models, business processes and capability models) according to the capability meta-model. The CDT will provide to capability analysts a suitable set of tools for defining capabilities according to the best practices from the Enterprise Modelling domain. Capability Navigation Application (CNA): a web application that imports the capability models defined in the CDT in order to monitor the described context. CNA connects to the context platform to monitor the capability context, informs the capability analyst and business services manager about current KPIs and handles run-time capability adjustments. Capability Context Platform (CCP): The context platform is a platform for gathering the context information defined in a context model and distributing it to the CNA. Capability Pattern Repository (CPR). The pattern repository allows the storage and retrieval of patterns. Each patterns describes a solution to a problem and can be in the form of textual descriptions and/or models. Capability Delivery Application (CDA): A CDA represents the business application or service used to support the capability delivery. This can be a custom-made system, or a configured standard system such as a SAP ERP. The 22

CaaS


CNA provides adjustment to CDA according to current context in order to guarantee capability delivery. These components of the CDD environment support different phases of the CDD methodology as Figure 2-3 shows. CDT is used for EM and capability design phases. CCP is used during both the capability design and delivery phases. In the design phase, it provides information about available context elements whereas in the delivery phase, it provides actual context data. CNA and CDA are used during the capability delivery phase for monitoring and delivery. CDT also supports a pattern repository (CPR) used for the design and delivery phases in order to gather and improve best practices from the enterprise.

Figure 2-3. CDD phases and tools

23

CaaS


3. Method Components of the CDD The CDD methodology consists of method components, each described using the framework described in Section 2.2. The purpose with dividing the methodology into several method components is to make it easy to apply selected parts of the methodology only. Furthermore, the use of method components makes the methodology extensible. To structure the methodology the method components have been divided into upperlevel method components. Each upper-level component is describing a certain applications area, and contains method components relevant for that area. The upperlevel method components are the following: •

•

• • • •

Getting Started with CDD. Supports decision making whether or not CDD is suitable for an organization. Furthermore, the required steps to get started with CDD are described. Capability Design Process. Contains an overview on how to design, evaluate and develop capabilities by using process models, goal models and other types of models. Enterprise Modelling. The component contains method components that guide the creation of enterprise models that are used as input for capability design. Context modelling. Describes the method components needed for analysing the capability context, and the variations needed to deal with variations. Reuse of Capability Design. This component contains guidelines for the elicitation and documentation of patterns for capability design. Run-time Delivery Adjustment. Describes the components needed to adjust a capability at runtime.

Each upper level method component and its constituent method components are described in the following sections. For the description of each method component a template based on the framework by Goldkuhl et al. (1998) is used: • • • • •

Name of the method component theme (in the section heading) Purpose and a brief introduction, if necessary Important concepts Notation Procedure

The template used is further described in Section 2.2.

3.1 Getting Started with Capability Design Whether or not capability design is a suitable way of working for an organization and how to get started with it should be assessed prior to embarking on the journey of transforming an organization’s way of working to capability driven. In practical terms this means assessing the organization’s current ways of working for the suitability before committing extensive amount of resources on capability design. The method component provided in this section addresses these two questions by describing a systematic procedure and supporting questions.

24

CaaS


3.1.1 Method Component: Getting Started with Capability Design The purpose of this method component is to support decision making whether or not to use capability design and to help the organization to prepare for capability design. Details about the actual capability modelling and design are described in subsequent method components. This method component is primarily directed to managers of business services in enterprises or persons responsible for enterprise-internal method use. 3.1.1.1 Important Concepts Table 3-1. Main concepts for getting started with Capability Design

Concept / Term

Explanation

Capability

Capability is the ability and capacity that enable an enterprise to achieve a business goal in a certain context.

Business Service

Business Services offered to business customers by business units of the organization under consideration. Business services represent a value offer to the customer and usually are a source of income for the organisation. Business services often are described as a Process to be performed which sometimes has different Process Variants.

Deployment Context

Deployment context describes is describing the characteristics of the environment in which a business service is provided.

Process

Process is series of actions that are performed in order to achieve particular result. A Process supports Goals and has input and produces output in terms of information and/or material. When initiated a process is perceived to consume resources.

Process Variant

Process Variant is a part of the Process, which uses the same input and delivers the same outcome as the process in a different way.

Note: Terms highlighted in Courier refer to concepts in the CDD meta-model, see Appendix A.

3.1.1.2 Procedure for Getting Started with Capability Design The procedure for getting started with capability design consists of several steps that will be elaborated in this section: • • • • • •

Check suitability Scoping Establish project organisation Train capability thinking Plan CDD process Get CDD environment

25

CaaS


Step 1: Check suitability of the CDD approach

Input • • •

Information about established business services offered by the enterprise under consideration regarding purpose, existing and future target groups Information about the existing enterprise architecture, enterprise modelling approaches, and other relevant development approaches used in the organization Information about the existing modelling tools and development environments used in the organization

Objective •

To decide about suitability of the capability design approach for the problem at hand

Activities The first step when looking into capability design should be to assess the suitability of the capability-driven design approach for the organization under consideration. For this purpose, this section provides two lists of questions: one list aims at identifying situations in which the use of capability design is advisable and the second list helps indicating organizational properties for which capability design would fit poorly. Before starting this step, information about established business services offered by the organization under consideration regarding purpose, existing and future target groups has to be available. Based on this information the questions should be answered as support to make a decision. a) Reasons against the use of capability-based design If one of the following questions leads to a negative answer, the use of capability design will probably not fit very well to the organisation or the organization should proceed with caution. • • • • • • • •

•

Is your organization offering business services which are based on IT-solutions? Can the business services be described in a process-oriented way? Does the situation in which the business services are delivered influence how they are delivered? Is your organization planning to offer existing business services in new markets or for new customer groups? Is your organization planning to implement new business services? Will the business services planned for a new market or customer group largely have the same process than the existing ones? Do you expect changes in the business service when offering them in a new market or business context? Do you use a proprietary development methodology that supports your system development life-cycle thoroughly? If yes, does this methodology allow integration possibilities? Do you use development environment that does not allow integration with other tools and platform?

If your answer to any of the above questions is “NO”, the use of capability-driven design is probably not advisable, either because your business services are not IT-based or process oriented, because no clearly identifiable variations of the business processes 26

CaaS


exist or elaboration of such cannot realistically be expected, or your development methodology and technology is not suitable for integration with CDD. b) Reasons for the use of capability-based design If only a few of the questions listed under a) have resulted in a negative answer and one of the following questions leads to a positive answer, the use of capability design is recommended. In this case step 2 of this method component should be started. • • • • • •

Does your organization plan to offer the same business services for different target groups and markets? Does your organization plan to offer new or additional variations of established business services? Are there variations in the execution of business services and do the variations depend on certain situations in which they are executed? Does your organization need to monitor the delivery of business services according to predefined indicators? Does your organization plan to re-design the overall offering of business services? Does your organization plan to migrate established services to more digitized versions?

If none of the questions listed under a) resulted in a “NO” and none of the questions listed under b) resulted in a “YES” more information is needed to give a clear recommendation for or against use of CDD. In this case we recommend to either visit a capability thinking seminar or to take contact to an expert in capability-driven design for individual consultancy. Output • •

Decision for or against use of capability-design Initial assessment of the organizational setting in which CDD will be introduced

Tools Checklist as displayed above Contributors Business service manager, business analyst

Step 2: Scoping

Input The suitability of the CDD approach for the task at hand has been investigated and decided positively Objective To decide what business service should be in focus of the first capability design activity. The purpose of the first implementation is to serve as a “pilot” project on the basis of which more business services can be chosen for capability support. Activities 27

CaaS


When getting started with CDD it is strongly recommended to focus capability design on only one single business service. This recommendation is based on the experience that setting up project organization and method/tool environment for CDD may sometimes lead to unexpected challenges which can be more easily dealt with if only one “pilot” business service is being developed. Lessons learned from the pilot case will be valuable for setting up later cases. The core activity of this step is to decide on the scope of capability design, i.e. to select one pilot business service to consider first. In case there are several candidate business services, the process should be as follows: •

•

•

•

Prepare a list of all business services and IT-based customer offers which have variations in the way they are performed depending on certain conditions and which are supposed to be offered to new target groups or in new markets For each of the identified business services and customer offers, collect the following information: o What situations influence delivery of the services or the customer offers? For instance, what are the plans for deploying them in new markets or to new customer groups? Which market in what time frame? o What is the workload of managing people, business analyst, and solution engineers required for preparing the business service for the new market? Any available resources? o How critical is the launch of the business service or customer offers in new markets for the organization in terms of customer group, turnover or image? o How is the business service monitored and adjusted? The ideal candidate for capability design among these business services or customer offers would have a clear goal in which new markets it shall be offered, no short-term but a mid-term time frame when this is supposed to happen, personnel resources available for working in capability design and (for the “pilot” case) no high criticality for the overall business. This case has to be selected. If the selection of a candidate is not possible based on the above criteria, it could be useful to perform a goal modelling workshop with decision makers in the organisation. Goal modelling is part of the method component “Enterprise Modelling”.

Output Pilot business service is selected; information about future market, available personnel, criticality for the enterprise and existing business process variations is available Tools Office tools for documenting the selection process and output information Contributors Business service manager, business analyst

28

CaaS


Step 3: Establish Project Organization

Input Pilot business service is selected; information about future market, available personnel, criticality for the enterprise and existing business process variations is available Objective To establish a project organisation for carrying our CDD pilot project. The project organization can later be transformed into a more permanent CDD team within the organization. Activities A project team performing capability design usually consists of several persons that have to be available for the planned time frame and carry out certain roles in the team. Team staffing, allocation of resources, and assigning authority to perform the necessary organizational change is the central concern of this step that organization’s management must support. In a capability design team, the following roles need to be assigned and the required competences represented: •

• • •

•

Project manager: is responsible for planning and controlling the project; has to make sure that the required persons from the organisation get the time budget they need for participating in the project Business service manager: Responsible for management strategies for changes in business and to identify opportunities for capitalizing on these changes. Method engineer: person who has knowledge about CDD methodology and can tailor it for certain needs Capability analyst: analyses information about capabilities and operating context, to predict evolution of the context and to take advantage of these predictions by providing new services or improving existing services. CDD provider: Provides and maintains the CDD methodology, should support the organization with knowledge about how to introduce CDD in the organization, how to tailor the CDD approach, as well as what integration and customization tasks should be performed in order to establish the CDD Environment.

In simpler cases or smaller organizations some of the above roles can be fulfilled by the same person, e.g. the project manager can at the same time be the business service manager. Output Project team and role distribution in the team is defined; the resources and authority are assigned by the management Tools Office tools for documenting project organisation Contributors Management of the organization, capability analyst, project manager, business service manager, method engineering 29

CaaS


Step 4: Train Capability Thinking

Input Project team and role distribution in the team is defined; the resources are assigned by the management Objective To introduce the project team to capability thinking including the basic concepts, general procedure, best practices and available method and tool support Activities The project team should obtain solid knowledge about capabilities; the way capabilities are used and can be used. This is summarized with the term “capability thinking” and includes terminology, basic concepts, general procedure, best practices and available method and tool support. I.e., reasonably good understanding of the CDD methodology is to be created amongst the people participating in the pilot. The actual training is offered by CDD provider as a seminar or in training sessions and not subject of this document. A discussion on how to adapt the CDD methodology and CDD Environment to the existing methods and tools used according to the emerging needs of the organization should be a part of the seminar. Output • •

Project team is trained in capability thinking Assessment of what customizations of the CDD methodology and Environment are likely to be needed.

Tools CDD Environment for demonstration purposes Contributors Project team, CDD Provider

Step 5: Plan the CDD process

Input Pilot business service selected for capability implementation; information about future market, available personnel, criticality for the enterprise and existing business process variations is available; project team and role distribution in the team is established Objective To plan the different steps of capability design including the use of the CDD method components. To assess the suitability of CDD for organization-wide use. Activities The goals of the pilot project should be discussed with respect the goals of the business service and the need to assess the suitability of CDD for future adoption in the organization. 30

CaaS


The CDD process steps such as details of the capability design and delivery should also be discussed and possible needs for customizations identified, however this can also be done while performing the actually methodology steps (described in other method components). At this stage however the overall project planning should be established, e.g. deadlines, stakeholders to be involved, information system development of maintenance work, etc. Output Planned CDD process Tools Office tools or project management tool to document the CDD planned process Contributors Project team, CDD provider during the pilot project may not be necessary in later projects, e.g. in other parts of the organization. Step 6: Install CDD environment

Input Pilot business service is selected; project team and role distribution in the team is established; CDD process is planned; CDD software is provided Objective To install the CDD environment. To ensure that the CDD environment is ready to use. Activities The project team should be ready to work productively after this step. For this, the needed tools of the CDD environment have to be installed properly on every desired computer. The CDD environment consists mainly of four independent tools or systems. These are namely: capability design tool (CDT), capability delivery navigation application (CNA), capability context platform (CCP) and capability delivery application (CDA). The required steps to install the CDD-environment are: checking individual prerequisites for each tool, meeting hard- and software requirements, getting the needed software, installation of the individual tools, integration of each tool to a functioning overall CDD environment and testing the configuration. The system requirements must be tested before an installation and must be fulfilled to enable a productive work. The tools indicated must be provided by the tool provider before the installation process. The sources to receive the software are indicated in the below mentioned documents. There are three documents describing the installation and setup process in detail. The document ‘Deliverable 6.4: The final (third) release of the CDD environment’ gives an overview about the system requirements and the tool installation of CDT and CNA. Furthermore, the integration of CCP is explained. Pre-requisites are described as well as a step-by-step installation guide for each 31

CaaS


system. Also, there are given instructions to test the configuration. The document ‘Deliverable 6.6: CDD environment documentation’ extends the above mentioned documents by a more detailed user guide and a detailed architectural overview, which might be helpful to understand the context and the interaction between the tools of the CDD environment. The document ‘CDD Technical User Guide’ gives some helpful background information on the technical background, which might be useful, if there occur problems during the setup process. Output CDD is installed and ready to use Tools CDD environment Contributors Project team, CDD tool provider

3.2 Capability Design Process In CDD, capability design is considered as the process of developing organizational designs that can be configured according to the context in which they will be used, i.e. this captures a set of solutions applicable in different business situations. Capability design is followed by capability delivery and supported by the feedback process (see Figure 2-2).

3.2.1 Method Component: Capability Design The purpose of this method component is to give an overview of alternative ways to design a capability. Specific details of how the design is performed are described in subsequence method components. Thus, this method component guides a capability designer on how to combine other method components in order to create a capability design. We here differentiate between three alternative capability design approaches: starting with goals, starting with business service processes, or starting with business concepts. Table 3-2 gives an overview of the three approached based on four criteria: • Primary view on capabilities. What are the bases for capability identification? • Preconditions with respect to models. What kind of preconditions with respect to existing models or specification is needed for using the strategy? • Characteristics of enterprise. What are the characteristics of an enterprise (regarding size, domain or type) the strategy is expected to be useful for? • Degree of flexibility of the strategy. To what extent does the strategy allow for adapting the flow of activities to project contingencies? (e.g. changes in the order of activities, dealing with missing or unreliable input, etc.)

32

CaaS


Table 3-2. Overview of the three alternative design approaches

Goal-first

Process-first

Concept-first

Primary view on capabilities

A capability fulfils A capability is key organisational operationalised as a goals. set of processes.

A capability encompass the management of key concepts.

Preconditions with respect to models

Ideally, top-level Pre-existing business organisational goals process specifications should be defined. or process-oriented culture.

Pre-defined management structures, product structures or other conceptual models.

Characteristics of enterprise

Organisations with Mature organisations a high degree of with well-established adaptable/nonprocesses. routine work.

Organisations with a well-defined and stable organisational or product structure.

Degree of Can also start with flexibility of the visions or existing strategy issues. Highly iterative and incremental modelling process.

The strategy can cope with ill specified goal or concept models. Process reengineering requires thorough revision of capability designs.

Can cope with different levels of concept granularity. The drivers for capability definition are slightly more complex. Is flexible with regard to the degree of specification of business processes.

Essential step on how to apply the three approaches are described in the following sections. 3.2.1.1 Important Concepts Table 3-3. Concepts for the Capability Design Component

Concept / Term

Explanation

Capability

Capability is the ability and capacity that enable an enterprise to achieve a business goal in a certain context.

KPI

Key Performance Indicators (KPIs) are measurable properties that can be seen as targets for achievement of Goals.

Context Set

Context Set describes the set of Context Elements that are relevant for design and delivery of a specific Capability.

Context Element Context Element Range is used to specify boundaries of Range permitted values for a specific Context Element and for a specific Context Set. Context Element

A Context Element is representing any information that can be used to characterise the situation of an entity.

Goal

Goal is a desired state of affairs that needs to be attained. Goals 33

CaaS


can be refined into sub-goals forming a goal model. Goals should typically be expressed in measurable terms such as KPIs. Process

Process is series of actions that are performed in order to achieve particular result. A Process supports Goals and has input and produces output in terms of information and/or material. When initiated a process is perceived to consume resources.

Pattern

Patterns are reusable solutions for reaching business Goals under specific situational contexts. The context defined for the Capability (Context Set) should match the context in which the Pattern is applicable.

Process Variant

Process variant is a part of the Process, which uses the same input and delivers the same outcome as the process in a different way.

Note: Terms highlighted in Courier refer to concepts in the CDD meta-model, see Appendix A.

3.2.1.2 Procedure for Capability Design Input • •

Existing enterprise models, e.g. goals models, business process models, concepts models Existing patterns

Objective •

To design a capability that allows reaching a business goal in a particular context.

Activities Step 1: Design

There are three alternative pathways of proceeding with capability design – starting with goals, starting with business services, processes, or starting with business concepts. Each of the alternatives will be described separately.

Alternative step 1a: Goals first capability design

Goals are used to model the intentional perspective of organizational design. Hence, capability design can start with analysing the existing goal hierarchy and/or setting new goals and then shifting to analysing how they should be reached in terms of capabilities, business processes and which context properties should be considered. The modelling process may include steps as outlined below. It is also worth mentioning that the modelling process is not entirely sequential – it is iterative and incremental, i.e. the modeller has to develop all parts of the capability design - the goals, capability, context, process in balance and consistent with each other. Activity 1a.1: Analyse the overall business vision and goals. The existing goals models need to be analysed with respect to identifying which goals are required to be supported by capabilities. Goals are typically organized in a goal hierarchy with more strategic goals on the top and more operational goals below. The goals that require capability 34

CaaS


support typically are on a more operational level because capabilities are concerned with explicit business designs and concrete actions. But in principle, some top-level goals could also be supported by capabilities. The goals that are the likely candidates for capability design should have elaborated KPIs for their monitoring. It might happen that the existing design does not have an explicit design that connects the corporate KPIs and goals, in which case this needs to be established or refined. This activity can be supported by the use of the enterprise modelling method component, see Section 3.3.1. In particular, a goals model is central be used for this activity. Activity 1a.2: Identify specific capabilities required by goals. In this activity the goals are analysed and relevant capabilities are defined and relationship between the capabilities and the goals established in order to indicate how the capabilities support the goals. At this stage the contribution of a capability to a goal should also be analysed with respect to the whole goal hierarchy, e.g. if a capability is deemed to support several sub-goals in the same goal hierarchy, then it might be more appropriate to associate it with their top-goal. Activity 1a.3: Analyse the existing business processes. Once the capability and goal relationship is established, the relationship to existing business processes needs to be established as well. In an existing business design the business processes are documented. If they are linked to goals then the capability should be associated with the same business processes that its goals are. Establishing such a general relationship is sufficient at this stage because the process variants will be designed later, once the application context is modelled. Activity 1a.4: Identify and model the context affecting the identified capabilities. For each capability the context set in which it is applicable should be defined. This entails defining the relevant context element and their ranges within which the capability is applicable. This activity can be performed by using the context modelling method component (see section 3.4). Activity 1a.5: Analyse and define process variants. A capability is realized by a set of business processes. In many cases there are also some adjustments to capability delivery that are needed depending on the changes in the context. In order to arrive at a more complete capability design the overall business process is analysed and potential context changes assessed in order to identify variations in capability delivery. This leads to defining process variants and variation points the context modelling method component (see section 3.4). Activity 1a.6: Model delivery adjustments. This step specifies the needed capability delivery adjustments and links them to the overall capability design. More about this can be found in section 3.6. Activity 1a.7: Review and/or incorporate relevant patterns. Capability design is based on the existing best practices. Hence we foresee that at any stage of this process the capability designer should be able to review the existing patterns that present relevant best practices in the form of process variants, concept models, algorithms and include them in the capability design. Alternative step 1b: Process first capability design

The process first capability modelling pathway proposes that the starting point of the capability design is a process underlying a business service under consideration. The business service is further refined and extended by adding context awareness and 35

CaaS


adaptability feature to establish a capability of delivering this service in varying circumstances. Many organisations at this level have already defined and modelled business processes which are implemented to offer business services. Hence, the process first capability design assumes that the digital enterprise that aim to offer capabilities have services modelled and implemented as business process models. The modelling process includes the following activities: Activity 1b.1: Define Scope. The organisation offers services based on business processes that are already modelled. In order to design the capabilities by means of business processes the capability designer first selects the service and sets the scope of the capability design. The selection can depend on various factors, such as optimizing the services with high process costs or managing services that frequently change and require the adjustment of business processes. Activity 1b.2: Define level of granularity. This step defines the abstraction level, at which the processes supporting the business service to be improved are identified and analysed. An option to describe different levels of granularity could be applying the decomposition method proposed by Milani et al. (2013). This method differentiates between a main process, which does not belong to a larger process and is decomposed into sub-processes. The sub-processes can be refined into atomic activities (called tasks). Regarding the business goals and offered capabilities needed to reach them, the method user most probably models at main process level. Nevertheless, the main processes might be refined by sub-processes in Activity 1.b.3. Furthermore, in Variability Identification step this granularity level can be changed by identified process variants, which refine processes from the base process model. Activity 1b.3: Identify processes/ activities/ tasks. After setting an abstraction level on the prior step, this activity identifies the processes modelled and used by the enterprise that are relevant for capability delivery. For this purpose 5-policies approach proposed by (Hallerbach et al., 2010) can be applied, which describes a general strategy for identifying processes. The approach can be adjusted for the chosen granularity level in the activity before. It should be emphasized that capturing possible variations of the processes are not included in these activities. This should be carried out in Find Variations method component of context modelling. Activity 1b.4: Analyse existing BPM and refine if necessary. The activity assures that selected business process models are up-to-date and applies changes if required. Activity 1b.5: Identify or name the capability to be delivered. The capability designer has a view on selected business service and supported processes. The information that the capability designer acquired during the execution of prior steps can be used as an input to establish a capability definition. The level of granularity is an important issue when identifying capabilities since overly refined capabilities could lead to complex models. In Design Context method component an activity requires either refining a defined capability or establishing the capability. As a result, if the capabilities are unclearly defined or cannot be established at this level yet, then the modeller should execute the upcoming activities to identify the context elements via observing the variations. Activity 1b.6: Update goals model and KPIs. The capability designed should be aligned 36

CaaS


with the goals that an enterprise aims to achieve. To check if business goals are satisfied during the capability delivery, KPIs are used to measure the achievement of goals. This steps analyses and updates the goal models as well as KPIs, if any exist. If no goals model is available, than the designer goes to activity 1b.7. Activity 1b.7: Develop goals model and KPIs. Goals define the requirements to be fulfilled during the delivery of a capability. If the enterprise has no goals model, then the capability designer formulates and models the goals in alignment with scope of the business service in this step. It means that the designer should rather focus on the capability related goals and should not model the enterprise objectives on a general basis. Detailed information about developing goals model can be found in (Sandkuhl et al., 2014). In order to check if business goals are satisfied during the capability delivery, KPIs are used to measure the achievement of goals. In this activity modeller develops KPIs required by the goals developed in this activity or updated in the aforementioned activity. Activity 1.b.8: Relate goals, capabilities and processes. This activity establishes the connection between the developed/ identified/ analysed components. The behaviour of the components under varying situations should be studied in the following step. Activity 1.b.9: Identify and model context. A capability is defined by specific business services, a defined application context for these business services and goals of the enterprise to be reached. In this activity the capability designer models the context of the capability delivery, i.e. the potential application context where the offering is supposed to be deployed. For this purpose the designer uses four method components subsequently, namely find variations, capture context element, design context and prepare for operational use. The method components are described in detail in context modelling method component part (see section 3.6). Activity 1.b.10: Model delivery adjustments. This activity outlines the components needed to adjust capability adjustment at runtime and refers to the capability adjustment method component (see section 3.6). Activity 1.b.11: Link components. This activity finalises the capability model with interlinking the outputs that have been previously developed. The process first capability design is depicted in Figure 3-1.

Figure 3-1. Process first capability modelling Alternative step 1c: Concepts first capability design

In organizational design concepts are used for modelling the static aspects of the business, such as, product structures, customer profiles, material as well as information used and produced by the business processes. In CDD, concepts is also used for modelling context. All in all, these concept models can be seen as knowledge models of 37

CaaS


the organization. Capabilities may be designed by starting with analysing the existing knowledge structures and their relationships with the application context. The following activities illustrate such a way of working: Activity 1c.1: Analyse the existing concepts. This step aims to identify concepts describing relevant products and/or services that are realized in the company. They may be modelled as a whole or as aggregate concepts; in some cases the concepts associated with the supporting information structure is also modelled. Activity 1c.2: Analyse dependencies between the concepts and existing business processes and business goals. This activity aims to identify which business goals are relevant and what are the KPIs that monitor their achievement, as well as what business processes are using to realize the concepts. For example, products have development, production, sales and support processes. In some cases these processes might not be fully defined and/or modelled and if so, the necessary models may need to be defined later if they are found to be influenced by the context and to be subjects to variability. New or additional business goals and KPIs might also be defined at this step. Activity 1c.3: Elicit candidate capabilities. The purpose of this step is to identify products or services (modelled as concepts) that need to be realized by capabilities taking into account the findings from analysing the dependencies in the previous step. Activity 1c.4: Identify the context affecting the identified capabilities. For each capability the context set in which it is applicable should be defined. This entails defining the relevant context element and their ranges within which the capability is applicable. Activity 1a.5: Analyse and define process variants. A capability is realized by a set of business processes. In many cases there also some adjustments to capability delivery are needed depending on the changes in the context. For example, there might be different capabilities needed for different product versions, or some variations of the manufacturing process need to be introduced because of different material or customer requirements. Activity 1a.6: Model delivery adjustments. This step specifies the needed capability delivery adjustments and links them to the overall capability design. More about this can be found in section 3.6 Activity 1a.7: Review and/or incorporate relevant patterns. Capability design is based on the existing best practices. Hence we foresee that at any stage of this process the capability designer should be able to review the existing patterns that present relevant beast practices in the form of process variants, concept models, algorithms and include them in the capability design. Step 2: Capability evaluation

The evaluate capability activity checks capability development feasibility from the business and technical perspective before committing to capability implementation. The capability feasibility can be assessed using simulation and cost/benefit analysis before actually committing to capability implementation. A failed evaluation may trigger a new cycle of the capability design phase. Step 3: Development of capability delivery application

The capability development activity readies the capability for the deployment. The indicators for monitoring and the adjustment algorithms are packaged as a CNA. The 38

CaaS


design specifications serve as a basis for modifying/implementing capability delivery applications, which are created using methods and technology of preference by the capability stakeholders. Output A capability ready for deployment and utilization Tools CDT Contributors Business service manager, business analyst, solution engineer. 3.2.1.3 Notation for Capability Design

Table 3-4. Main notational symbols for Capability Design

Concept / Term

Notation

Capability

KPI

Goal

Context Set

Context Element

Context Element Range

39

CaaS


Process

Process Variant

Variation Point

The above notation is supported by the CDT.

3.3 Enterprise Modelling Enterprise Modelling (EM) is an activity where an integrated and negotiated model describing different aspects of an enterprise is created. An Enterprise Model consists of a number of related “sub-models”, each describing the enterprise from a particular perspective, e.g. processes, business rules, goals, actors and concepts/information/data (Persson & Stirna, 2001). For CDD, EM approaches using visual modelling languages are considered relevant, since they reflect the industrial state of practice and ease participation of business stakeholders.

3.3.1 Method Component: Enterprise Modelling The purpose of this method component is to capture and document the existing organizational design in terms of business goals, problems, KPIs, business processes, concepts, etc. The overall vision of the CDD approach is to use (and update if necessary) the models that the organization already has for capability design. However, if the organization does not have existing models or their use is deemed impractical (e.g. they are severely out of date, the modelling language used is incompatible with the CDD approach or the quality of models is below acceptable), new models need to be created. In the latter case we recommend the 4EM method (Sandkuhl et al., 2014) for carrying out enterprise modelling. The rest of this section will briefly outline EM as a method component of CDD. 3.3.1.1 Important Concepts Concepts of 4EM are defined in (Sandkuhl et al., 2014). 4EM uses six interrelated submodels which complement each other and capture different views of the enterprise, i.e. each of the sub-models represents some aspect of the enterprise (see Figure 3-2). These sub-models and issues they address are: •

Goals Model (GM) focuses on describing the goals of the enterprise. Here we describe what the enterprise and its employees want to achieve, or to avoid, and when. Goals Models usually clarify questions, such as: where should the organisation be moving, that are the goals of the organisation what are the 40

CaaS


importance, criticality, and priorities of these goals, how are goals related to each other, which problems are hindering achievement of goals. •

Business Rule Model (BRM) is used to define and maintain explicitly formulated business rules, consistent with the Goals Model. Business Rules may be seen as operationalization or limits of goals Business Rule Model (BRM) usually clarifies questions, such as: which rules affect the organisation’s goals, are there any policies stated, how is a business rule related a goal, how can goals be supported by rules.

•

Concepts Model (CM) is used to strictly define the "things" and "phenomena" one is talking about in the other models. We represent enterprise concepts, attributes, and relationships. Concepts are used to define more strictly expressions in the Goals Model as well as the content of information sets in the Business Processes Model. CM usually clarifies questions, such as: what concepts are recognised in the enterprise (including their relationships to goals, activities and processes, and actors), how are they defined, what business rules and constraints monitor these objects and concepts.

•

Business Processes Model (BPM) is used to define enterprise processes, the way they interact and the way they handle information as well as material. A business process is assumed to consume input in terms of information and/or material and produce output of information and/or material. Business Process Model usually clarifies questions, such as: which business activities and processes are recognised in the organisation, or should be there, to manage the organisation in agreement with its goals? How should the business processes, tasks, etc. be performed (workflows, state transitions, or process models)? Which are their information needs?

•

Actors and Resources Model (ARM) is used to describe how different actors and resources are related to each other and how they are related to components of the Goals Model, and to components of the Business Processes Model. For instance, an actor may be the responsible for a particular process in the BPM or, the actor may pursue a particular goal in the GM. Actors and Resources Model usually clarifies questions, such as: who is/should be performing which processes and tasks, how is the reporting and responsibility structure between actors defined?

•

Technical Components and Requirements Model (TCRM) becomes relevant when the purpose of EKD is to aid in defining requirements for the development of an information system. Attention is focused on the technical system that is needed to support the goals, processes, and actors of the enterprise. Initially one needs to develop a set of high level requirements or goals, for the information system as a whole. Based on these, we attempt to structure the information system in a number of subsystems, or technical components. TCRM is an initial attempt to define the overall structure and properties of the information system to support the business activities, as defined in the BPM. The Technical Components and Requirements Model usually clarifies questions, such as: what are the requirements for the information system to be developed, which requirements are generated by the business processes, which potential has emerging information and communication technology for process improvement. 41

CaaS


Figure 3-2. Sub-Models of the 4EM approach and their relationships

The initial CDD methodology focuses on the use of goal models and process models in order to design capabilities. However the other models of the 4EM approach can be used to complement these models. 3.3.1.2 Procedure for Enterprise Modelling Input Organization’s vision and strategy Existing enterprise models, context models, IT architecture Stakeholder wishes and requirements, existing policies and standards. Objective To capture, refine and document the existing and envisioned organizational designs.

42

CaaS

EC FP7 Project 611351 Inf. 1 Init ial probl em statement

Inf. 2 Other supporting information

Proc.1 External.Proc. 1

Inf. 4 Problem not suitable for EM. Do not continue with modeli ng.

Define scope and objectives of the project

Project acquisition and initiation process

Inf. 3 Project definition

Proc.2

Plan for project activities and resources

Inf. 5 Project plan (including risk assessment)

Inf. 6 List of relevant domain expert s

Proc.3

Inf. 7 Model s from other relevant projects or earl ier iterati ons

Plan for modeling session

Inf. 9 List of candidate model ing participants

Inf. 8 Objectives of the session

Proc.4

Proc.5

Gather and analyze background information

Interview modeling participants Inf. 11 Candidates’ views on the problem at hand

Inf. 10 Additi onal information about t he problem

Inf. 12 Facilitator’s percept ion of participants’ personali ties and potential contribution to the sessi on

Proc 6 Prepare modeling session Inf. 13 List of pract icalit ies (bookings, agenda, etc.)

Inf. 14 Objectives and plan for the modeling session

External.Proc. 2

Proc.7

Support project in practical matters

Conduct modeling session

Inf. 15 List of actions

Inf. 16 Ent erprise Models

Proc.8

Proc.9

Write meeting minutes

Analyze and refine models

Inf. 17 Meeti ng mi nutes

Inf. 19 Issues requiring further modeling sessions

Inf. 18 Ent erprise Models and/or project results ready for presentati on

Proc.10 Present the results to stakeholders

Inf. 20 Project result completed

External.Proc. 3

Implement project result

Figure 3-3. The EM process model showing processes and information sets (adapted from Persson & Stirna, 2010) 43

CaaS


Activities The process of carrying out EM is shown in Figure 3-3 and Table 3-5. It shows involvement of different actors (Persson & Stirna, 2010). The CDD approach has the possibility to integrate the EM process with the CDD process for supporting cases when an organization does not have enterprise models that can be used as input for capability design. If the envisioned EM activity is about to cover a larger problem area, a dedicated EM project might need to be established and related to the CDD project. Process 1: Define scope and objectives of the EM project. We assume that the EM project is commissioned either as a result of selling consulting services or another inhouse development project has decided to address a specific problem area by a modelling approach. In either case there usually exists an initial problem statement (inf. set 1) and an organizational actor that will benefit from solving the problem– problem owner. At this stage the problem owner and the EM project leader should discuss the problem to find its boundaries, what the likely ways of solving it might be, and what the expected outcomes are. This would form a project definition (inf. set 3). In this process model we assume that the organization has already assessed its suitability for using the participative approach to EM, but if has not been done, or some doubts arise (e.g. a strong sense of hidden agendas) then the EM project leader should assess the situation in the organization. The problem should also be assessed for being suitable for EM. If the organization or the problem is found to be unsuited for EM, then the problem owner and the project leader should choose other ways of solving the problem, e.g. by the consultative approach or by brainstorming. When dealing with complex and/or wicked problems it might be difficult to formulate a clear problem definition. In such cases the project might organize a modelling session with an objective to find out what the real problem is and how to tackle it. Process 2. Plan for project activities and resources. At this stage the EM project leader, problem owner and facilitator plan specific activities to be carried out. This includes the overall number and schedule of modelling sessions, the issues addressed in them (inf. set 5), as well as indicating relevant domain experts to be involved in the modelling sessions later (inf. set 6). Additional issues to pay attention at this stage are risk assessment, resource allocation, both for the method provider team and for the domain experts, and establishing project groups’ overall authority, i.e. mandate to solve the problem. Process 3. Plan for modelling session. The objective is to plan a specific modelling session, i.e. to set its overall objective and questions to be addressed (inf. set 8). Existing models produced in previous modelling session of the project or earlier projects in the organization and/or other supporting information might also be analysed. The initial list of relevant domain experts (inf. set 6) should be analysed and candidates for involving in the modelling session should be selected (inf. set 9). Process 4 Gather and analyse background information. The modelling facilitator usually needs to obtain additional information to learn more about the organization and the background of the problem at hand. Process 5. Interview modelling participants. The candidates for involving in the modelling session (inf. set 9) are interviewed individually in order to learn more about their views on the problem at hand (inf. set 11) and to assess the participant’s potential contribution at the modelling session (inf. set 12). A benefit for the candidate is that he/she is able to learn about the project and the upcoming modelling session in advance. In some projects it is beneficial to interview more participants that are going to be used 44

CaaS


in the modelling sessions, because this allows the project team to learn more about the organization and, indirectly, to spread the word about the project and the coming change in the organization. Process 6. Prepare modelling session. At this stage a detailed plan for the modelling session (inf. set 14) is elaborated by analysing the background material and findings from the interviews. This plan should include specific objectives the modelling session, specific questions to be addressed, preliminary set of enterprise models to be developed (e.g. goal models, concepts models, actor models), a set of driving questions for starting the discussion, the expected level of model quality. The modelling facilitator should also assess various risks and scenarios of how the modelling session might develop. E.g. what are the topics that the participants will not talk willingly, what are the topics that might lead the discussion astray, what can cause conflicts, how to act in case of a conflict. This should be done in collaboration with the problem owner and project leader. The practicalities of the meeting (inf. set 13) should also be organized, which includes location, agenda, travel plans, etc. Process 7. Conduct modelling session. The objective of this paper is not to describe details of how a modelling session is conducted. Recommendations of what to do and what not to are available, for example, in the EKD and 4EM method descriptions. The tangible outcome of the modelling session is the models produced (inf. set 16) and an additional list of actions for implementing the decisions made during the modelling session (inf. set 15). Additional intangible outcomes of modelling are participants’ improved understanding of the problem area and a firmer commitment to the decisions made. Process 8. Write meeting minutes. After the modelling session it is recommended to write minutes of the meeting (inf. set 17) which includes the models as in the state were produced at the modelling seminar and action list. At this stage the models should not be more refined because the main purpose of this activity is to send notes to the participants which might also serve as a reminder of the actions that they have agreed to be responsible for. Process 9. Analyse and refine models. Enterprise Models created at a modelling session usually need further refinement in terms of presentation and layout, as well as content. The result of the modelling session should also be analysed with respect to the objectives of the session and the project. This either leads the project team to a conclusion that the expected result is achieved and can be presented to the organization (inf. set 18). Otherwise the team identifies a set of issues for further development and modelling (inf. set 19) and proceeds with planning subsequent project activities (process 2). In many cases information sets 18 and 19 are reports of the project activities. Process 10. Present the results to stakeholders. The modelling project ends with presenting the results to the problem owner and relevant stakeholders. A part of this presentation is decision making on how the results should be implemented or taken-up by the organization. It might also be that the stakeholders identify issues that are not resolved and require further development (inf. set 19). The EM process we have outlined ends when the problem owner and the involved stakeholders feel that they have a result that can be implemented. In the case of CDD, the EM project results will serve as input for Capability Design. Output Enterprise Models and decisions for capability design 45

CaaS


Tools CDT or Visio, depending on what the format in which the existing models are stored. Contributors The involved are represented Table 3-5. Table 3-5. Actor involvement in the EM process steps (R- responsible, P- participates)

EM Process Step

Customer Customer Domain expert

Business Service Manager

Business Solution Analyst architect

P1 Define scope and objectives of the project

R

P

P2 Plan for project activities and resources

R

P

P

P3 Plan for modelling session

P

R

P

P

R

P4 Gather and analyse background information P5 Interview modelling participants P6 Prepare modelling session

P P

P7 Conduct modelling session

R P

P

P8 Write meeting minutes P9 Analyse and refine models

P

P10 Present the results to stakeholders

R

P

R R

P

P

R

P

P

R

P

P

P

3.3.1.3 Notation for EM As stated earlier, the 4EM modelling method contains several different types of models for goals, processes, actors and roles, concepts, technical components and requirements, and rules. A full description of the graphical representation for these models can be found in (Sandkuhl et al., 2014). Even though a specific notation can help the modeller express certain concepts, or provide a certain level of detail, the CDD approach is not bound to a specific notation for EM. Thus a business analyst can choose a notation that are used at the customer site, or are otherwise fitting for the task at hand. The application of the initial CDD methodology in the three CaaS project cases is a good 46

CaaS


example of the use of EM models, and their respective notation. Two types of enterprise models have been particularly extensively used in the initial work on cases – goal models and process models. For goal modelling the 4EM goal modelling notation has been used, while for process modelling the BPMN (Business Process Model and Notation) has been applied. The reason for using BPMN is that it is currently a well-known and well documented process modelling notation, and that the initial case organisations that participated in the CDD development had prior experience with it. The 4EM and BPMN notation are both fully documented in (Sandkuhl et al., 2014) and (OMG, 2014), respectively. However, to illustrate the notations we provide two small examples in the following sub-sections. Goal model – example notation (from 4EM)

The goals model is used for describing the goals of the enterprise along with the issues associated with achieving these goals. Besides goal, a goal model may also contain symbols for problems, opportunities and constraints. Furthermore, the concepts/symbols may be related by links. Link types include supports, hinders and conflict relationships (Sandkuhl et al., 2014). Figure 3-4 shows an example goal model, including a goal (“Expand marketing activities”) that are supported by two sub-goals.

Figure 3-4. Example use of the 4EM Goal Modelling notation (from Sandkuhl, 2014).

The goal model can be further extended by introducing more supporting and conflicting goals and problems hindering goal fulfilment. For a full description of the 4EM goal modelling notations, please refer to (Sandkuhl, 2014), chapter 8.1. Process model – example notation (from BPMN)

A process model is used to describe a set of activities to perform to achieve a certain goal. The Business Process Modelling and Notation standard (OMG, 2014), is a comprehensive notation for describing a process model. While it contain the basic symbols for activities, events and control flow, it also contains extensive support for representing roles and organisations, messages (synchronous and asynchronous), error handling and information flows. Figure 3-5 shows a small process model with the main symbols; a start message event, activities, control flow branching and merging, and end event.

47

CaaS


Figure 3-5. Example use of the BPMN for process modelling .

The process model can be extended by introducing symbols for organisations, information flow and so on. For a full description of BPMN, please refer to (OMG, 2014). BPMN 2.0 notation is available in (OMG, 2014)

3.4 Context Modelling A capability always is defined by specific business services, a defined application context for these business services and goals of the enterprise to be reached. The general purpose of Context Modelling Method Component is to specify the potential application context where the business service is supposed to be deployed. This specification also has to capture at what points in the process what variation will have to happen. A context model captures the specification of the deployment contexts in which a capability can be used. The use of the context modelling method component starts from a number of preconditions: • • •

•

The method component benefits from the initial definitions of the capabilities. If there are none, then these should be defined parallel with context model. The business goals to be achieved with the capability are specified and modelled. These goals help to identify required context elements. The business service related to the capability is defined, i.e. business process models exist specifying the service. The business process models are needed for identifying variation points and dependences to context elements. Relevant patterns defining best practices and/or variations of the business process at design-time or run-time may help identifying relevant context elements The context model allows defining rules for pattern to use under certain conditions.

The way of working is considered iterative and incremental, i.e. for example, the modeller is able to switch from goal and capability specification to identification of relevant context elements and back. The purpose of this method component is to provide a systematic help for the following problems: • •

How can one identify and design the business context in an environment, in which the digital enterprises deliver capability? How is business context related the enterprise objectives and business processes that are motivated by such goals? 48

CaaS


3.4.1.1 Overview of the Procedures of the Context Modelling Method Component Procedures inform the method users about the actions to be performed as well as its orders. We differentiate between three method components each of which is connected with different phases of context modelling. In this respective we propose the following method components that are later elaborated in respective sections: •

•

•

Capture Context Element: Analyses the business process models and investigates the entities and aspects of the context by eliciting the factors, drivers, influences that cause variations in the business processes. By defining the attributes and measurable properties, the method user defines a context element. Design Context Set: Identifies the relevant context elements and models their allowed ranges for the selected capability. The context element ranges are then put in a container (context set), which is required by the capability. Prepare for Operational Use: The context model will serve as input for configuring CNA and for defining deployments of capabilities. This method component describes the way of adding part of the specifications to the context model, which are a precondition for using the context model during operations. Other parts of the specifications are added in the Run-time Delivery Adjustments method component.

3.4.1.2 Cooperation Principles for Context Modelling This section briefly describes the organisational preconditions to be established before using the context modelling method component. This includes both, the structures and roles within the team using the method, and the enterprise or organization where the method is applied for modelling. Following competences should be possessed in order to use this method component: •

• •

Skills in elicitation techniques (inquiring, abstracting, structuring etc.) to identify and analyse relevant information in the respective business environment and to gather information from secondary data. Knowledgeable on the CDD methodology concepts introduced in Deliverable 1.4: Requirements Specification for CDD (D1.4) and the CDD meta-model. Experience with CDT, CNA and CCP.

Considering the cooperation principles and skills we relate the stakeholders to the context modelling method components. The different stakeholders used are taken from Deliverable 1.3: Vision of the CDD methodology (D 1.3). This is illustrated in Table 3-6 (see D 1.3 for other stakeholders and relationship between them). Table 3-6. Assignment of Stakeholders to Method Components

Roles Capability analyst

Method Component Assigned to all three method components, most active in the method component Design Context Set

Method engineer

Assigned to all three method components

49

CaaS


Business service manager Business analyst

Assigned to the method component Design Context Set Assigned to the method component Capture Context Element Assigned to the method component Prepare for Operational Use Assigned to the method component Capture Context Element Assigned to all three method components

Solution engineer Business service operator Solution architect Capability provider

Assigned to the method component Context Set Design

One conclusion in D2.3 regarding the organizational roles in capability management was that some of the CDD-related activities could benefit from more information about the kind of involvement in the activity. This would require explicitly defining who does what, who should be informed about the results of activities and who should support the roles under consideration. This information is provided in a RACI1 matrix as illustrated in Table 3-7.

Solution architect

R

C

A

Identify process variants

I

C

R

C

A

Analyse factors & goal fulfilment

A

C

R

I

A

Analyse dependency

A

C

R

C

A

Create a context element

A

C

C

R

Capability provider

Business service operator

C

Activities

Solution engineer

I

Roles

Business analyst

Method engineer

Identify gateways

CDD

Business service manager

Capability analyst

Table 3-7. RACI chart

C/I

1

RACI is an abbreviation for Responsible-Accountable-Consulted-Informed. Responsible role executes the work and ensures the completion of it. Accountable role delegates the role to the responsible role. Consulted role is the person, whose expertise is required to complete the work. Informed role must be notified about the status of the work and the results.

50

CaaS


Select context elements

A

C

C

R

C/I

Define context element ranges & indicators

A

C

C

R

C/I

Develop and link context set

A

C

C

R

C/I

Select context providers

R/I

C

C/I

A

Express calculations

R/I

C

C/I

A

Express adjustments

R/I

C

C/I

A

R = Responsible, A = Accountable, C = Consulted, I = Informed The roles of the stakeholders are described in respective method components under Contributors subsection.

3.4.2 Method Component: Capture Context Element Consisting of two steps, process model analysis and context element design, this method component analyses factors influencing variability in service provision to identify contextual information. Factors are drivers that cause variations in the process models, such as varying expectations of the stakeholders, changing user needs, technology advancements, scheduling constraints, market demands etc. An analysis of such factors helps to design a context element. In the first step the method component focuses on the analysis of business process models to identify gateways and process variants. In the second step, it identifies factors in the business process models that cause variability, analyzes dependencies between them, creates context elements and defines mechanisms on how to measure them. An overview of the method component is given in Figure 3-6.

51

CaaS


Figure 3-6. Method component Capture Context Element

3.4.2.1 Important Concepts The method component Capture Context Element comprises three concepts that are described in Table 3-8. The example column is taken from the dynamic passenger support use case described in section 7.1. Table 3-8. Concepts in Capture Context Element Component

Concept / Term Explanation

Example

Gateway

Instruments to represent join and split behavior of the flow of control between activities, events and gateways

Border control required? (cf. Figure 7-5)

Process Variant

See explanation in Table 3-1

The process of airport situation assessment may be executed in two ways (cf. Figure 7-8)

Context

Any information characterizing (i.e. changing, influencing) the design and delivery of a capability that fulfils enterprise goals in a changing environment

The occupancy rate of the airport before a flight

Context Element Context entities that affect the capability design and delivery by causing variability.

The type of the flight

Measurable Property

Attribute of a context element that help to measure its value. Measurable properties can also be used to monitor performance-related data

Country of departure

Variation Point

A specific gateway incorporating locations of variations in a business process model that influence the enterprise goals. All variation

Is the anomaly probability in a flight (delay,

Country of destination

52

CaaS


points are gateways, but not all gateways represent a variation point. Variation points are decisive for identifying context elements.

cancellation) high? (cf. Figure 7-6)

3.4.2.2 Procedure The method component requires certain outputs from the capability design steps, such as goal models and business process models. The procedures to be performed consist of a two steps process model analysis and context element design, which are described in this section. Step 1. Process Model Analysis

Input • •

Process models and workflows required for service provision (if these do not exist, please refer to the method extension described in section 4.1.1) Textual descriptions of processes

Objective Step 1 aims to capture the variability in the business processes that are required to deliver the capability. The main motivation is that such variations in the business process models arise due to the factors, from which context elements are extracted. Activities The Activity 1.1 and 1.2 can be performed in parallel (see also Guideline 1). Iterations are mandatory, since we investigate both gateways and process variants both on the operational and organizational process levels2. Activity 1.1: Identify Gateways • • •

Highlight all gateways with conditions and labeled paths in the business process models. Create a table with two columns. Enter the number of the gateway in the first column and condition expression in the second column (see Table 3-9). Consider gateways with same conditions and same diverging paths as identical.

Activity 1.2: Identify Process Variants A process variant refers to the adapted versions of a certain process due to any of the following reasons: new technologies, governmental rules, organizational context or adoption of new standards. In Activity 1.1, the focus was on the identification of gateways to investigate variability. However, process variability does not have to be represented only by the gateways. As an example, a business process model might be adapted by only adding and/or removing activities to/from them, although they do not incorporate any gateways. By both examining the variation points and process variants we make sure that context modelling method explicates variability elements in a 2

Organizational processes are high-level processes that are typically specified in textual form. Organizational processes determine the operational processes and they realize business goals. Operational processes are series of activities that are performed to achieve a particular result. In this work, we use the term “process” or “business process” instead operational processes (Weske 2012).

53

CaaS


business process model. Highlight process variants both on operational and organizational level. Number the process variants. Create a table with two columns. Enter the number of the process variant in the first column and conditions in the second column (see Table 3-10)

• • •

Guideline •

• •

Usually, it is a straight forward task to identify variability in organizational processes, since these exhibit a high level of abstraction, contain fewer model elements and include happy flows. On the contrary, identifying variability in operational processes may require more efforts and a higher number of iterations. It is probably easier to perform Activity 1.1 with consolidated business models. In a consolidated business process model, all possible variations of a process are represented in the same model, including all branches and activities. Guideline 1: Variability identification in organizational and operational processes

Output • •

Process variants and gateways in the business process models of the selected service The output should be documented in tabular form (see generic examples in Table 3-9 and Table 3-10).

Table 3-9. An example of gateway identification

Gateway

Condition

GW1

Important events in the calendar?

GW2

Temperature above 15 degrees?

GW3

Service booking below average?

GWn

…

Table 3-10. An example of process variant identification

Process Variant PV1 PV2 PV3

Condition Planning processes according to market attractiveness Procurement processes according to market attractiveness and the quality of economic infrastructure

Tools

54

CaaS


•

Anything can be used for tabular representation of gateways and process variants.

Contributors •

•

• •

Business analyst: Identifies variability in business process models that are implemented for the service provision, which is the core of the capability under consideration. Method engineer: In addition to tailoring the procedure and the notation used in the method component for certain needs, the method engineer ensures the shared understanding for the important terms related to context modelling in the enterprise. Business service operator: Validates the identified gateways and process variants. Solution architect: Identifies the responsible roles (if required) that should identify gateways and process variants.

Step 2. Context Element Design

Input • •

Process models of the respective service A view of process variants and/or a tabular list of gateways that are identified in Step 1

Objective Process variant implementation and gateway resolution may be influenced by the context, i.e. customer location, type of business service, degree of resource use etc. The main objective of this step is studying the factors causing variability in the service provision. Contextual influence may be traced back after analyzing the variability in business process models. By further specifying the variability, the method user aims to develop a context element. In order to do this, business process models, goals and KPIs should be present, their connection to the capabilities should be established. Activities The activities may be performed sequentially or in parallel. Iterations are highly recommended. Activity 2.1: Analyse factors and goal fulfilment • • •

• •

Take the list of the gateways identified in the last step of MC B and the process variants. Add the column “gateway analysis” to the table. (Please check Guideline 3 on how to proceed for the process variants) Study each gateway by asking following questions: o What is the reason for this gateway to exist? o Does the reason relate to enterprise objectives? o Is the reason too generic in a sense that a different enterprise would anyway consider it when offering similar services? Or is it specific? Add the column “factor” to the table. Derive the exact factors from your analysis, enter them in “factor” column. 55

CaaS


• •

Add the column “goal fulfilment” to the table. Analyse how those factors influence goals. They may have weak or strong contribution to goal fulfilment (see Table 3-11for an example). Discuss the findings with domain experts and validate the factors

•

Activity 2.2: Analyse dependency Filter and eliminate factors in the table that have a weak contribution to goal fulfilment Create a taxonomy between the gateways of remaining factors to identify dependencies (see Figure 3-7). o Resolving a gateway may resolve another gateway, although the evaluation of its condition expression does not directly influence a goal. Use contributes_resolving association between those gateways. o Resolving a gateway may determine, whether another gateway is needed. Use depends_on association (directed from the latter to the prior) between those gateways. Create a separate table and select the gateways which have “strong contribution” association to goals. Rename those as variation points (see also Guideline 2). (According to the example in Figure 3-7, the gateway GW4 should be renamed as VP2) Validate the results with the domain experts. Note that, if you only have separately modelled process variants, you do not have to consolidate them to perform this activity. Instead, extract the factors that cause modelling such variants and treat them as gateways. After that, analyze dependency.

• •

•

• •

Guideline •

•

Different than a decision point (represented by standard gateways), the branches of a variation point is always relevant for the service delivery and their execution contributes to the enterprise goals. As such, they are represented in context models. Variation points are not generic but often characteristic for process execution. On the contrary, the gateways which do not be captured as variation points are expected to be used in all kind of situations and they can appear in all possible process models. Guideline 2: Understanding the role of variation points

56

CaaS


Guideline •

•

Consolidated process models consist many gateways, since they incorporate all possible path executions in one single model. It is a fact that creating consolidated business process models is a complex and time-consuming task. An alternative to consolidated models are the models that represent each process variant separately. In such cases, you have many business process model fragments and most likely they do not incorporate those gateways that are relevant for context identification. In such cases, you should adapt Table 3-11 as follows: o Gateway column is renamed as process variant o Gateway analysis column is renamed as process variant analysis o Add column gateway after the column goal fulfilment (see Table 3-12). Following rule applies, when mapping the process variant numbers to the gateway numbers: o Map each factor to exactly one gateway. Assume that there are two rows in the table, corresponding to two process variants (PV1, PV2). The factors influencing the execution of the first variant (PV1) is “regulation”. The second variation (PV2) is required due to the factors “regulation, financial status and market size”. In that case, there are three gateways, regulation (GW1), financial status (GW2) and market size (GW3). Guideline 3: The activities may be altered for non-consolidated business process models

Activity 2.3: Create a context element • • • • • • •

Select the variation points resulting from the dependency analysis For each variation point, check the factor associated with it. For each factor, create an entity “context element”. Repeat this for all variation points. Identify how the values of context elements are obtained. These are called “measurable properties” (see Guideline 4). Refine the context elements into atomic entities if necessary (see Guideline 4). Model the entities as measurable properties.

57

CaaS


Guideline The analysed factors can be refined into atomic entities by observing what actually affects the service provision. For example, a company called “Dermott Sails” hires paddleboats in all type of weather situations, except for when the temperature is lower than 15 degrees. Hence, the context element will probably be “temperature” rather than weather. On the other hand, a competitor in that sector called “Meridian Sails”, hires the boats when the weather is good and defines good weather as “low precipitation with temperature over 20 degrees”. In this case, the context element will probably be “weather” which is measured by the precipitation and temperature. Check the factor and goal fulfilment analysis table. If there are factors, which have a weak or strong but indirect influence on goal fulfilment, then these may be used as measurable properties or context element ranges.

•

•

Guideline 4: Refinement of a context element

Output • • • •

A table including the gateways, list of factors, their analysis and contribution to goals (see Table 3-11 and Table 3-12). Dependency analysis, as modelled in Figure 3-7 Variation point(s) (see Table 3-13). An initial context model including the context elements and measurable properties. The context model incorporates all factors that cause changes in the service provision.

Table 3-11. An example of factor and goal fulfilment analysis based on identified gateways

Gateway Condition

Gateway analysis

Factor

GW1

Depending, whether the operational environment is affected from the influence of regulatory trends, additional processes are executed.

Influence Strong of regulatory trends

Regulated market?

Goal influence

Table 3-12. An example of factor and goal fulfilment analysis based on identified process variants

Process Variant

Condition

Process variants analysis

Factor

Goal influence

Gateway

PV1, PV2

Planning processes according to market

Depending on the attractiveness of the market, Planning processes

Market attractiveness

Strong

GW2

58

CaaS


attractiveness

may vary

Figure 3-7. An example of dependency analysis

Table 3-13. Renaming the gateways as variation points

Gateway

Variation Point

GW6

VP1

GW4

VP2

Tools • •

Anything can be used for tabular representation of change factors. CDT for developing context models

Contributors • • • •

•

Capability analyst: Associates the drivers that affect capability delivery with the enterprise goals. Business analyst: Analyses the impact of change drivers on the goal fulfilment and creating a relationship between various drivers. Solution architect: Creates context elements based on the dependency analysis. Business service operator: Contributes to the analysis of the factors that cause changes in the service provision and to the dependency analysis between such factors. Method engineer (see Step 1 for the task definition).

3.4.2.3 Notation This method component applies the CDT notation, which is depicted in Figure 3-8. For performing the factor and goal fulfilment analysis as well as documenting the gateways and process variants, tabular forms are used. 59

CaaS


Figure 3-8. CDT Notation for Context Modelling

3.4.3 Method Component: Design Context Set In CaaS project, the purpose is not to develop stand-alone context models, but to identify contextual influences in order to capture in what conditions the capability should be delivered. Design Context Set method component links the capability under study to the contextual influences by creating a “container” (a context set), including the permitted ranges of the context elements for capability delivery. Moreover, the properties of the context elements relevant to capability design (context indicators) are identified. An overview of the method component is given in Figure 3-9.

60

CaaS


Figure 3-9. Method component Design context set

3.4.3.1 Important Concepts The method component Design Context Set comprises three concepts that are described in Table 3-14. The example column is taken from the dynamic passenger support use case described in section 7.1. Table 3-14. Concepts in Design Context Set Component

Concept / Term

Explanation

Example

Context Element Range

Boundaries or permitted values of a context element for a specific context set. A context element range is inseparably connected to the capability3

The occupancy rate of the airport before a flight may be low, middle or high

Context Set

A container for context elements that are relevant for design and delivery of a specific capability. This container includes defined value ranges of a context element

For Dynamic Passenger support capability, the context set includes three context element ranges (cf. Figure 7-11)

Context Indicator

Property of the performance data used for monitoring capability delivery.

The amount of time saved before flight

3

If for instance there is only one capability which is deployed to many clients, then it is possible to define all possible values as context element ranges. We experienced this in the SIV case. Since there is a single capability with multiple deployments, the context element “commodity” would have the range: [“electricity”, “natural gas”, “district heating”, “water”], even if a given client has only contracted [“electricity”], i.e. has contracted a subset of what is actually possible. In this sense context element ranges are understood as maximal ranges.

61

CaaS


3.4.3.2 Procedure The method component includes one step “Context Set Design”. Step 3. Context Set Design

Input •

The initial context model resulting from the previous method component, including the context elements and measurable properties.

Objective • • •

Establishing a connection between the goals, business processes and business context Developing context sets consisting of various context element ranges and context elements. Refining the context model before preparing it for operationalization.

Activities The activities are performed sequentially. Iterations are recommended. Activity 3.1: Select context elements • •

Select relevant context elements for the capability. Validate the suitability of context elements for this capability with domain experts.

Activity 3.2: Define context element ranges and indicators • •

Define the permitted values for selected context elements by taking capability delivery into consideration (also see Guideline 4). Define the context indicators that are needed to monitor the performance data and refine the measurable properties, if needed4.

Activity 3.3: Develop and link context set In the context model: • • • •

Connect context elements with their ranges. Put all the ranges in a context set. Connect the context set with the defined capability. Connect the capability with goals and processes.

Output • •

The output from design context method component is refined by adding context element range, context set, context indicators for a selected capability. The model in this level only conceptually specifies how a capability is adjusted in line with its delivery context. It is yet not ready for an implementation.

Tools

4

In order to monitor the performance data in CNA, such as how many messages have been cleared (SIV case) or how many services have been highlighted successfully (everis case), CCP pushes the actual values of the measurable properties. As such, a measurable property is not only related to the contextual data, but also to the performance data.

62

CaaS

•


CDT for developing context models


•

Capability analyst: Selects relevant context elements and their ranges in accordance with the capability under consideration. Business service manager: Validates the designed context of the business service. Solution architect: Ensures that selected context elements and defined ranges are convenient for the capability under consideration. Capability provider: Cooperates with the solution architect to ensure that selected context elements and defined ranges are convenient for the capability under consideration. Method engineer (see Step 1 for the task definition).

3.4.3.3 Notation This method component applies the CDT notation (see Figure 3-8).

3.4.4 Method Component: Prepare for Operational Use The “Prepare for Operational Use” method component describes the way of adding part of the specifications such as preconditions for using the context model during operations to the context model. Other parts of the specifications are added in the Runtime Delivery Adjustments method component. More concretely, the context model will serve as input for configuring CNA and for defining deployments of capabilities. One of the main tasks is to define the binding of measurable properties to context providers from Capability Context Platform (CCP). This method component is a preparation before the Run-time Delivery Adjustments method component, where the calculations and adjustments are documented in a tabular form outside the CDT. In other words, the operations required for calculating the values of context elements as well as the actions to be taken in context situations are defined not within the CDT5. If the method user does not have to document expressions, she can just skip this method component and continue with the Run-time Delivery Adjustments method component, where the calculations and adjustments are directly coded in CDT. As such, the Prepare for Operational Use method component, illustrated in Figure 3-10, is considered optional.

5

Since the method user operates outside CDT, we use the term „express calculations“ instead “add calculations” in the activities.

63

CaaS


Figure 3-10. Method component Prepare for operational use

3.4.4.1 Important Concepts The method component uses the concepts listed in Table 3-15. The example column is taken from the dynamic passenger support use case described in section 7.1. Table 3-15. Concepts in Prepare for Operational Use Method Component

Concept / Term

Explanation

Example

Context Provider

Entities (web services, information systems) publishing information relevant for context calculations

Airport Operations Management System

Calculation

Codes implemented in Java or MathML to determine the value of a context element by using its measurable property. Calculations use measurable properties to obtain the values of a context element

IF Country of departure =/ country of destination THEN Flight Type = International

Adjustment

Codes implemented in Java or MathML to support decision making, whenever the business process requires resolving a variation point

IF fs = “low” AND ocr = “low, middle” AND flight type = “national” THEN implement Variant 1

Step 4. Design Binding

Input •

The context model produced in method component “Design Context Set”.

Objective 64

CaaS

•


Documenting the specifications and bindings for the context models.

Activities The activities can be performed in parallel. Activity 4.1: Select context providers • •

Identify the sources which provide data to obtain the values of context elements by calculating the measurable properties. Create a table where the sources are associated with the measurable properties

Activity 4.2: Express calculations We define three types of calculations in the CDD meta-model. This activity is related with the context calculation and context indicator calculation. It does not document the KPI calculation. • •

• •

For each context element, specify the mathematical operations to define the values of context element ranges. For context calculations, create a table with the following four columns o Context Calculations o Measurable properties that those calculations use o Context elements that are associated with the measurable properties o Value of context element ranges according to the calculations For each context indicator measuring the performance of the capability, specify the mathematical operations For context indicator calculations, create a table with the following two columns o Context indicator calculation o Measurable properties that those calculations use o Context indicators associated with the measurable properties

Activity 4.3: Express adjustments • •

Specify the decision logic to adjust the capability delivery according to the application context. Create a table including the adjustment logic in one column and process variants and/or patterns in another column.

Output •

A tabular view of calculations and adjustments that may help prior to the application of Run-time Delivery Adjustments method component. Please note that the resulting model cannot be implemented as it is, further specifications are needed, e.g. Input Data Associations (IDA).

Tools •

Anything can be used for tabular representation of calculations, providers and adjustments.

Contributors • •

Solution architect: Documents the calculations and adjustments before they are implemented in CDT. Capability analyst: Shares information about the operational context of the capability 65

CaaS


•

Solution Engineer: Contributes to the documentation of adjustments and calculations as well as the communication between the CDA, CCP, CDT and CNA Method engineer (see Step 1 for the task definition).

•

3.4.4.2 Notation This method component does not require any specific notation and documents the adjustments with tabular forms.

3.5 Reuse of Capability Design Although knowledge reuse through patterns has great potential in improving various aspects of Information System (IS) design, there is an ongoing debate whether they have positive or negative effect. This is due to the fact that very little effort is put into finding effective solutions for cataloguing and searching patterns, evaluating them, tracing IS back to applied patterns and assisting the designer in choosing the right pattern in a given contextual situation. These aspects are crucial for achieving better results in pattern based design of IS. The Capability Pattern Repository (CPR) together with other members of the CDD technology stack provide effective means for effective pattern governance and dealing with the previously mentioned issues. In CDD capability design and delivery (see Figure 2-2) are supported by feedback process that aims at capturing reusable knowledge components such as best practices, process fragment, and adjustment algorithms. To support the feedback process as well as to base the capability design on reusable knowledge, the CDD approach uses the pattern concept. The use of patterns in CDD is not limited to documenting and applying them, a novel approach for Pattern Performance Indicator (PPI) monitoring is used to track how the pattern helps in achieving organizational goals and meeting KPI target values under certain contextual situation. The pattern repository is available at http://cpr.vitk.lv/ and documentation of its API is available at http://cpr.vitk.lv/docs/cpr-api.

3.5.1 Overview of Method Component for Reuse of Capability Design The lifecycle of a capability pattern with relations to components of CDD environment is summarized in Figure 3-11. Patterns are modelled in CDT and described by a set of problem, context and solution diagrams. Diagrams are based on the elements from the Capability Meta Model. The designer can also enter a free-form text based version of problem, context, solution and usage guidelines, specify a category name for the pattern. It can be decided whether to document problem, context and solution in form of diagrams and/or free-form text.

66

CaaS


Figure 3-11. Capability pattern lifecycle

3.5.1.1 Procedures Procedures inform the method users about the actions to be performed as well as its orders. In the Reuse of capability design method two method components can be distinguished: •

•

Pattern Elicitation and Elaboration: the first step is pattern elicitation where a list of candidate patterns is created by analysing existing models or creating new ones. The feasibility of each candidate pattern is evaluated by reviewing its usefulness, quality and cost. The list of remaining pattern drafts is then finalized for publishing in CPR. Patterns can be published by using a CPR REST web service or by the user interface of CPR (see Figure 3-14). Pattern Application and Performance Evaluation: after the pattern has been published in CPR it can be used as a building block during creation of capabilities. Patterns discovery is performed by using the user interface of CPR or by its REST web services. When pattern is applied a reference to it is stored in the capability model in CDT keeping track of all patterns being used. To measure performance of a pattern under certain context and keep track of where patterns are currently used the capability is also deployed to the CPR. A scheduled adjustment in CDT is then configured to periodically send performance data to CPR which is used to calculate PPI and for analytical purposes. Based on this data designer can revise the capability design and substitute a pattern with alternative one.

The recommended sequence of method components and their relation to the CDD methodology phases is shown in Figure 3-12.

67

CaaS


CDD Phases Enterpr ise modelling

Design

Deliver y

Method components Pattern Elicitation and Elaboration

Pattern Application and Performance Evaluation Figure 3-12. Reuse of Capability Design method component relation to CDD phases

3.5.1.2 Concepts This section gives overview of the key concepts, the notation used, and the procedure used in the method component. Table 3-16. Patterns, key concepts

Concept / Term

Explanation

Context indicator

Context indicator measures the context values in capability delivery application run time.

Pattern

Patterns are reusable solutions for reaching business goals under specific situational contexts.

Pattern Performance A value showing to what extent is the target values of all Indicator (PPI) capability KPIs met when applying the pattern. All capabilities applying the pattern are used for the calculation and an average percentage is used as the PPI value. Pattern performance Evaluation of PPI values and historical data stored in CPR for evaluation reviewing the list of currently applied patterns. Pattern template

The format used for describing a pattern.

Fields in the pattern Pattern template consists of a number of fields, such as, template problem, context, solution, usage guidelines, keywords, and adjustment algorithms. Some of these fields can contain hyperlinks to other patterns or model fragments. Pattern language

A structure of patterns representing relationships among patterns. Currently, this term is no use in the CDD methodology.

Pattern elicitation

The process of identifying patterns in existing models and designs. After pattern elicitation a draft version of a pattern is obtained.

Pattern elaboration

The process of moving from the draft version of the pattern to the final version which is to be stored in the CPR.

Patter validation

The process of assessing the utility of a pattern. 68

CaaS


Concept / Term

Explanation

Pattern creators

Those that create patterns.

Pattern context

The context in which the pattern may be used

Scheduled adjustment

Scheduled adjustment is executed based on a predefined schedule. It is modelled and implemented in CDT as part of the capability model and then deployed to CNA for execution.

3.5.2 Method Component: Pattern Elicitation and Elaboration The purpose of this method component is to capture and represent reusable knowledge in the model form that can be used for capability design and delivery. The overview of the method component is given in Figure 3-13.

69

CaaS


PATTERN ELICITATION AND ELABORATION

PROCEDURE

Elicit candidate patterns Identify patterns from existing non-CDT models Identify patterns from existing CDT models

Develop draft version of the pattern

Identify patterns through creation of new models

Review patterns Evaluate usefulness

Evaluate quality

Evaluate cost

Summarize pattern evaluation results

Elaborate and publish patterns Finalize the pattern related information

Publish the capability pattern

Verify patterns CONCEPTS Pattern template

Pattern

Pattern context

IDA

NOTATION Template

Text

Enterprise models

CDT models

Figure 3-13. Method Component Pattern Elicitation and Documentation

3.5.2.1 Important Concepts The most important concepts used in the method are summarized in Table 3-16. 3.5.2.2 Procedure The steps proposed here should be seen as general stages in the process of moving from a specific solution model to a pattern applicable in similar cases. The pattern creation procedure consists of the following steps: Step 1: Elicit candidate patterns

Input •

Existing enterprise models, existing capability designs, needs for new capability designs, context models, feedback from capability design and delivery. 70

CaaS


Objective The objective of this step is to have list of potentially useful patterns and to obtain a draft version of each pattern having sufficient detail to allow proceeding with its evaluation. Activities During pattern elicitation a draft version of a pattern is defined serving as input for further evaluation and verification. Pattern draft is developed based on the pattern template and expressed as free form text (links to existing model fragments or patterns can be included). Activity 1.1a: Identify patterns from existing CDT models Existing capability and pattern models created in CDT are analysed to identify potentially applicable patterns. Some examples of patterns are summarized below: •

scheduled and event based adjustments implementing a specific goal oriented context aware adjustments (e.g. scaling the number of web server nodes in the cloud according to current load and QoS goals),

•

context calculations – reusable raw measurable property aggregation or prediction logic,

•

change of existing pattern granularity – merging of multiple capability patterns or deriving of a sub-patterns from a single capability pattern (CPR search facility can be used to ease the pattern discovery).

Activity 1.1b: Identify patterns from existing non-CDT models Additional information sources may also be used for creating patterns such as 4EM models, business documentation and information system designs. When applying 4EM models the initial source of knowledge is the repository of existing 4EM models. These can be models created in one or several EM projects. In principle any model that contains a valuable solution to a problem and is of adequate quality can be considered in this process. The following guidelines for analysing models can be used: •

Patterns as processes: A sequence of processes describing how a business goal is successfully achieved as well as measurement in terms of information objects. A particular emphasis should be paid to variation points and other areas of the process that deal with variability such as context related variables.

•

Patterns as hierarchies of goals: A goal model may be a pattern in that it reflects the business experience in successfully defining and understanding its (or a part of its) goal hierarchy.

•

Patterns as concepts: A concept model showing how the business has successfully designed the concepts of the domain. These concepts may be product structure, information models, and clarifications of terms used in other parts of the enterprise model.

•

Practices as relationships between actors and roles: showing the dependencies between roles, their goals and business processes they are associated with.

Activity 1.1b: Identify patterns through creation of new models 71

CaaS


It is traditionally assumed that patterns should not contain large model fragments because this reduces their understandability and cohesion, which in turn inhibits reuse. Hence, new models may need to be created especially to represent the solution proposed by the pattern. This can be done: •

based on new insights and experiences gained, and from new evaluations of business practice,

•

when existing models are too detailed or specific, or when models do not clearly relate to or solve specific problems.

New models can be drafted out in free-form text format or by using modelling environments such as CDT and their corresponding notation. Activity 2: Develop draft version of the pattern After elicitation of the candidate pattern its name and other essential components of its template must be filled in, namely: the problem tackled by the pattern, the context in which the pattern is applicable, and the solution proposed by the pattern to solve the problem. No specific ordering needs to be followed when describing each component; their description is made in natural language and links to existing enterprise models can also be established. Capability pattern template is given in Table 3-17. Table 3-17. Pattern template used for CDD

Name:

Each pattern should have a name that reflects the problem/solution that it addresses. Names of patterns are also used for indexing purposes.

Problem:

Describes the issues that the pattern wishes to address within the given context and forces.

Context:

Describes the preconditions under which the problem and the proposed solution seem to occur. This can be expressed in free text or represented by a Context Model fragment. In terms of the CDD meta-model “Context Set” needs to be specified in order to describe the set of Context elements that are relevant for the pattern.

Solution:

Describes how to solve the problem and to achieve the desired result. Solution describes the work needed. It can be expressed in natural language combined with 4EM and/or BPMN models. It can also be extended by drawings and/or multimedia objects. Solution can be backed up with references to other knowledge sources and other patterns by hyperlinks.

Usage Presents a set of usage tips to the potential user of the pattern about how Guidelines: the pattern can be tailored to fit into particular situations or to meet specific needs of an organization. Guidelines aim to give an idea of how the pattern can be tailored to create a specific business solution. Keywords:

A few keywords are defined for each pattern in order to facilitate search and retrieval.

Adjustment Specification of capability adjustment algorithms. algorithms:

72

CaaS


Output •

Initial list of candidate patterns with the following fields drafted – name, problem, context, and solution, including the initial sketches of the model fragments.

Tools •

CDT and CPR

Contributors •

Domain experts as pattern creators and external pattern methodology experts

Step 2: Review patterns

Input •

Initial list of candidate patterns

Objective To assess each candidate pattern obtained as a result of the step 1 and to evaluate it by domain experts in order to decide on further development actions for each candidate pattern. Activities We suggest that the list of candidate patterns is reviewed in a workshop setting with pattern authors and other relevant domain experts. The decision to further elaborate certain patterns from the list or do reject them is based on the consensus achieved in the workshop. Following activities are performed for each candidate pattern: Activity 2.1: Evaluate usefulness Usefulness is evaluated with respect to the following: •

Triviality: The degree to which the pattern addresses a problem that is of little importance to the business because the problem or solution is obvious.

•

Implementability: The extent to which the pattern is thought to be practical and implementable (possible to use in CNA and/or CDA), compatible with business strategies; trade-offs should be taken into account.

•

Confidentiality: If the pattern discloses confidential or sensitive business information and pattern creation and sharing would compromise the confidentiality commitments, then the pattern creation is probably not justifiable.

Activity 2.2: Evaluate quality Quality is evaluated with respect to the following: •

Complexity: The complexity of a pattern can be estimated by considering the number of domain concepts and ideas it contains. In general, patterns should not be overly complex because this will most likely make the application cumbersome.

73

CaaS


•

Generality: This concerns the abstraction level of the problem and proposal solution that which the pattern addresses them. We have found out in the evolution processes of patterns, experts do not appreciate guidance on an abstract level without concrete examples and specific guidelines how to apply the solution in their organization (see e.g. Persson, Stirna & Aggestam, 2008). Hence, the level of generality should not be too high. But it should not be too low either, because in that case the applicability will be low.

•

Understandability: This refers to the ease with which a pattern can be comprehended by decision-makers and/or domain experts.

•

External compatibility: The extent to which the pattern can be used by other users (projects or companies). This is influenced by the extent to which the pattern takes into account factors such as national or organizational culture, relevant technologies, and market conditions.

Activity 2.3: Evaluate cost Cost of the candidate pattern is influenced by the following: •

Level of experience required for its use: This is influenced by the need to involve external experts

•

Economic feasibility of the proposed solution: This refers to the expected cost of implementing the proposed solution.

Activity 2.4: Summarize pattern evaluation results Results from Activities 2.1-2.4 are summarized and the initial list of candidate patterns is reviewed. Rejected patterns are removed from the list while additional comments and ideas for improvement are added for the accepted ones. Output •

List of patterns excluding the rejected ones and containing comments and necessary improvements for accepted ones

Tools •

CDT and CPR

Contributors •


•

External stakeholders not directly involved in the pattern creation process may also be consulted.

Step 3: Elaborate and publish patterns

Input •

Final list of pattern drafts from Step 3

Objective •

To document the pattern in detail and to store it in the pattern repository.

Activity 3.1: Finalize the pattern related information 74

CaaS


Pattern is modelled in CDT by creating corresponding context (elements of the Context Model), problem (elements of the Goals Model) and solution (e.g. Event Based Adjustment, BPMN model) models. If context or problem models are not applicable they can be omitted. The textual representation of context, solution, problem and usage guidelines is finalized. Activity 3.2: Publish the capability pattern An archived CDT model can be published in CDT by using the user interface of CPR (see Figure 3-14) or its corresponding web-service (see API documentation). After being published the pattern is indexed in CPR by parsing the model.xmi and contained diagrams. This is important for enabling the discovery of patterns based on the contained elements (using web service or web-based interface of CPR).

Figure 3-14. Editing a pattern in CPR

Output •

Patterns stored in CPR.

Tools •

CDT and CPR

Contributors 75

CaaS

•



Step 4 Verify patterns

Input •

Existing patterns in CPR

Objective •

Obtain the final version of the pattern

Activities After a pattern has been fully documented and stored in the repository it should be verified by a broader group of the domain experts to ensure that the applicability and usefulness really is to the level envisioned by the pattern authors. This process can produce valuable feedback for improving existing patterns as well as serve as stimuli for creating new patterns. An example of capability pattern viewed in CPR is given in Figure 3-15. The designer can log in to the web-based interface of the CPR to finalize the textual description of problem, context, solution and usage guidelines in the WYSIWYG editor.

76

CaaS


Figure 3-15. Example screen of a pattern in CPR

Feedback about the pattern can be left in form of comments or by giving a rating of 1 to 5 stars. Output •

Feedback about pattern usefulness and corrective actions for pattern improvement

Tools •

Pattern repository

Contributors

77

CaaS

•


Domain experts and stakeholders

3.5.3 Method component: Pattern application and performance evaluation The purpose of this method component is to document the process of capability pattern application, performance data analysis and revision of capability and/or patterns contained within it. The overview of the method component is given in Figure 3-16.

Pattern application and performance evaluation

PROCEDURE

Pattern discovery Perform search

Choose search criteria

Review results

Pattern application Implementation of scheduled adjustment Elaborate and publish patterns Deploy to CPR

Deploy to CNA

Analysis of performance data Pattern feedback and revision CONCEPTS Pattern

CPR

CNA


NOTATION Text

CDT models

Figure 3-16. Pattern application and performance evaluation method component

3.5.3.1 Important Concepts The most important concepts used in the method are summarized in Table 3-16.

78

CaaS


3.5.3.2 Procedure The pattern application end performance evaluation procedure consists of the following steps: Step 1: Pattern discovery

Input •

Patterns contained in the CPR

Objective •

Locate a pattern applicable under current contextual situation and organizational goals

Activities Activity 1.1: Choose search criteria CPR supports pattern discovery by providing its name or information about contained elements (e.g. a specific context element or goal). Patterns can also be located by finding a capability applying them and then viewing the list of applied patterns in capability’s CPR page. Activity 1.2: Perform search Based on what criteria the designer has chosen a pattern search can be performed either in CPR user interface or using CPR web services. CPR user interface allows to search for patterns by choosing a specific element that should be contained in the pattern. When searching by a context element (see Figure 3-17) the designer can enter the name of the context element or browse through the list of all indexed context elements. Next to each context element a number of uses is displayed which shows the number of patterns containing the specific context element. For example, context element Backlog of messages is included in 3 patterns. The designer can also switch to capability view by changing the type filter to capability.

79

CaaS


Figure 3-17. Search patterns by context elements

When clicked on the chosen context element the user is presented with a list of related patterns and/or capabilities (see Figure 3-18). Another option is to use the faceted search functionality provided by CPR (see Figure 3-19).

Figure 3-18. Projects referencing context element 80

CaaS


Figure 3-19. CPR faceted search

In the given example results for patterns from message processing category containing “processing load” context element and “to complete on time goal” are shown. Activity 1.3: Review results After obtaining a preliminary list of patterns each of them is reviewed in detail to evaluate feasibility of the pattern for capability that is being designed. There are several indicators which could serve as input for pattern reviewing process: • • • •

models and textual representation of the pattern (see Figure 3-15), user rating of the pattern (see Figure 3-15) and comments, capabilities applying the pattern (see Figure 3-20), Pattern Performance Indicator or PPI (see Figure 3-20).

81

CaaS


Figure 3-20. Pattern Performance Indicator

Output •

A CPR registered pattern that is chosen for being applied in a capability design

Tools •

CPR, CPR web service REST client


Business analyst Capability analyst Solution architect Solution engineer

Step 2: Pattern application

Input •

A pattern chosen from CPR 82

CaaS


Objective •

Apply a pattern

Activities After the pattern has been identified its project is downloaded from CPR website. It is a standard CDT archived project that can be imported into CDT workspace of merged with existing project (merging of model.xmi from current project with model.xmi of the pattern and copying of pattern’s diagrams into the capability project). Pattern contains a generalized solution therefore after importing its contents into the capability project it needs to be adjusted for the specific use case. A pattern element also needs to be added to the capability and UUID needs to be set to one used in the CPR. This allows to keep track of patterns that were used for modelling the capability. Output •

CDT capability project containing version of applied pattern

Tools • •

CDT CPR



Step 3: Implementation of scheduled adjustment

Input •

CDT capability project containing version of applied pattern

Objective •

Implement ScheduledAdjustment ContextIndicator data to CPR

for

sending

KPI

and

Activities To send the KPI and context indicator data from CNA to CPR during runtime a scheduled adjustment must be added to the model. It is then connected to all relevant KPIs and associated context indicators using IDA connection type. Context indicator value update and KPI value update web services are then used for sending the data to CPR. Lastly an execution schedule is specified in the properties section of the scheduled adjustment (e.g. “0 0 * * * *” for sending the data once every hour). Output •

CDT capability project containing a scheduled adjustment implementation

Tools 83

CaaS

•


CDT



Step 4: Deployment of capability

Input •

Final version of the capability CDT project

Objective •

Deploy capability to CPR and CNA

Activities Activity 1.1: Deploy to CPR After the pattern has been adapted for the specific requirements and the design of a capability is completed it is deployed to CPR by using the provided REST web service. The deployment of a capability to CPR allows to browse patterns together with capabilities that are based on them. The previously established connection between pattern and KPI enables quantitative evaluation of patterns in CPR. A capability viewed in CPR is shown in Figure 3-21.

84

CaaS


Figure 3-21. Capability viewed in CPR

Activity 1.2: Deploy to CNA Capability is deployed to CNA from CDT. If this is the first export to CNA the user should navigate to CNA portal and add deployments, configure adjustment constants as needed. Output •

Capability is deployed to CPR and CNA

Tools •

CPR, CNA, CDT

Contributors 85

CaaS

• • • •



Step 5: Analysis of performance data

Input •

Performance data stored in CPR

•

Performance data stored in CNA

Objective •

Locate a pattern applicable under current contextual situation and organizational goals

Activities The capability performance data can be viewed in user interface of CPR (Figure 3-21) or CNA (Figure 3-22).

Figure 3-22. CNA indicators

86

CaaS


For more detailed information, the analyst can use REST web services provided by CPR. CPR provides KPI and context indicator values in csv, json and xml formats. It should be noted that certain patterns might perform different under unlike context situations, therefore the relation between KPI and context indicator values should be analysed in great detail. Output •

Analysis of pattern performance under current context situation

Tools • •

CNA CPR


Business analyst Capability analyst

Step 6: Pattern feedback and revision

Input •

Analysis of pattern performance under current context situation

Objective •

Provide pattern feedback and revise capability if needed

Activities Pattern application in practice generates new knowledge about the usefulness of the pattern under specific context situation as well as it triggers suggestions for improvements. This information needs to be captured and analysed. Every pattern page in the repository has the possibility of entering user feedback in form of comments or by rating the pattern. Furthermore, the CNA using the pattern might also generate feedback to be considered for improvement or development of new patterns. The feedback is then analysed by pattern creator and/or administrator and corrections and improvements are introduced in the capability and/or pattern. During the initial pattern creation stages feedback to each pattern should be monitored on a weekly basis. Once a pattern becomes reasonably stable it can be monitored on a monthly basis. If comments about pattern use have not been received for more than a year, the administrator should analyse for the reasons (e.g. the pattern has become obsolete) and consider actions for improvement. If it is determined that the applied pattern doesn’t perform well under the current contextual situation, a list of alternative patterns can be reviewed and a more appropriate pattern can be applied. Output •

Feedback about the pattern 87

CaaS


Tools •

CPR



3.6 Run-time Delivery Adjustments Capabilities are delivered in ever-changing contextual situations. The purpose of capability delivery adjustments is to alter capability delivery in response to the changing context and delivery performance without the need for redesigning the capability and CDA. The run-time delivery adjustment method component supports this objective by: •

enabling specification of complex contextual data processing logics;

•

providing reconfigurable data bindings.

The adjustments provide a uniform way of defining computations associated with the concepts defined in the capability model and primarily of those associated with context elements and indicators. These computations can be specified by a capability designer, and they are decoupled from the rest of capability delivery logics. That allows to make changes in context processing without changing the rest of the capability delivery application. Algorithms for context aware capability delivery adjustment are defined as capability adjustments and provide decision-making logics for capability delivery variation points. The reconfigurable data bindings are important to incorporate new context element in the capability design. The new context elements need to be incorporated because all context elements affecting capability delivery are not known in advance during the capability delivery. The context awareness precision can be improved by using the additional contextual information, and the reconfigurable data bindings allows changing the context processing in run-time with minimal impact on the rest of the capability delivery application. The method component provides guidance for designing adjustments. This guidance is used to develop use case specific adjustment algorithms while some of the adjustments are generic and applicable in multiple situations. The generic adjustment algorithm for performance based context evaluation is elaborated in Section 3.5.6. The adjustment design and execution was described in D5.2 from the technical perspective and the revised version focuses on methodological aspects of adjustment design. There are two main groups of adjustments (Figure 3-23): 1.

Calculation – used for calculating KPI and Context Element values.

2. CapabilityAdjustment – alters the capability based on context and other factors. Calculation is KPICalculation

further and

divided into ContextCalculation, ContextIndicatorCalculation. 88

CaaS


ContextCalculation is used for interpreting measurable properties (e.g. to calculate the value of a Context Element). Likewise, ContextIndicatorCalculation uses the measurable properties to calculate the performance indicators in the CNA, based on data from the CDA. KPICalculation is responsible for calculating target and current values of KPI based on various input data. The KPI values can be visualized using a set of predefined widgets in CNA or used as an input data for other adjustments. EventBasedAdjustment is used for enabling process-based capabilities, while ScheduledAdjustment allows to implement schedule based, in-code adjustments. In most cases CapabilityAdjustment instances rely on results received from Calculation instances. All adjustments have common attributes - name, type, input parameters, adjustment variables and an adjustment code. The name is used for reference and search purposes, additional parameters like tags and description can be added when working with large number of adjustments. Input parameters are the mandatory input data for the adjustment to be executed. Adjustment variables are used to implement the adjustment logic and they are accessible in the scope of the adjustment code. Input parameters are used for initializing the adjustment variable values, however there can be adjustments with no input data. Adjustment variables are initialized using Input Data Associations (IDA). There are multiple alternatives for implementing adjustments am4ong which are Java (in-code adjustments) and MathML (implemented using a visual tool with no need to write code manually). The Adjustment engine is responsible for execution of the adjustment code. It must be modular and extendable in order to support addition of new adjustment types (Drools, C++ etc.).

Figure 3-23. Adjustment groups

In CDD adjustments are modelled (to show what entities depend on the adjustment and 89

CaaS


what input data does it require), implemented (to add adjustment logic by implementation using a graphical interface or writing Java code) and validated in CDT, deployed to and executed in CNA. The adjustment deployment and execution is provided by the Adjustment engine, which is a component of the CNA. The Adjustment engine provides version control (change history, ability to bring new adjustment version to production, option to revert to previous adjustment version) and logging (log input parameters, adjustment variables and results). Details on adjustment execution are provided in D6.3. The examples of run-time delivery adjustments are provided in Appendices: • •

Appendix C: Example of using Scheduled Adjustment for capability delivery; Appendix D: Example of Performance Based Context Evaluation Adjustment.

3.6.1 Purpose and Preconditions This section briefly describes the purpose of the Adjustment method component and preconditions for using it. In CDD adjustments are used for: Calculating the values of context elements (ContextCalculation). Calculating the values of performance indicators (ContextIndicatorCalculation) • Calculating the target and current value of KPIs (KPICalculation). • Supporting implementation of capability delivery variation point (ScheduledAdjustment). • Supporting implementation of process variant variation point (EventBasedAdjustment). The adjustments are implemented and validated in CDT after what they are deployed to CNA. CDT provides multiple ways of implementing adjustments among which are programming (Java) and building adjustments using a visual tool (MathML). For each implementation option there is a different perspective in CDT and it can be extended to support more ways of implementing adjustments (in case of extending, changes need to be made in CNA too). • •

In order to start modelling adjustments in CDT, the following preconditions have to be met: All context elements have been added to the Context Model in CDT. All measurable properties have been added to the Context Model in CDT. All KPIs have been added to the CDD Model in CDT. All capability delivery variation points have been added to the Context Model in CDT. • All process variant variation points have been added to the Context Model in CDT. To start implementation and validation of the adjustments for each measurable property a CPP invocation URL needs to be provided (which means that the measurable property must be initialized in the CPP). The deployment of adjustments requires a valid instance of CNA. • • • •

90

CaaS


3.6.2 Overview of Method Components for Capability Adjustment The adjustment method component consists of three sub-components. This section briefly describes each of them and shows how they are related. 3.6.2.1 Procedures Procedures inform the method users about the actions to be performed as well as its orders. In the initial adjustment method three method components can be distinguished: Adjustment modelling and design: The first step is the adjustment modelling performed in CDT and adjustment IDA, to define what adjustment variables will be available and how exactly do they get their values. Based on the type of the adjustment, different entities can be subject to IDA. When performing IDA with a Measurable Property, aggregations can be optionally specified. When retrieving the aggregated value of the Measurable Property the necessary aggregation and input parameters are provided for the CCP, which performs the aggregation and returns the value. • Adjustment implementation and delivery: The adjustment logic is implemented in CDT and is different for Java and MathML adjustments. Java adjustment implementation is focused towards implementing a method of the Java adjustment template class. This type of adjustments is intended for developers and has unlimited possibilities to provide whatever functionality is necessary. MathML adjustments are implemented using a graphical tool and no programming knowledge is necessary, therefore they are more limited than the Java adjustments. In both scenarios the implementation is based on local adjustment variables that get their values from IDAs. Before adjustments can be deployed to CNA, they need to be validated in CDT. During validation the necessary data is retrieved from CPP and it is possible to identify problems with the measurable properties or flaws in adjustment logic. • Adjustment assessment and improvement: The adjustment development is an iterative process. The initial version of the adjustment can be changed during run-time without taking the capability offline. When a new adjustment version has been implemented and tested it can be activated and brought into production. The version control system allows to revert to the previous version if needed. The recommended sequence of method components and their relation to the CDD methodology phases is shown in Figure 3-24. •

91

CaaS


Figure 3-24. Method component relation to CDD phases

3.6.3 Method component: Adjustment modelling and design The “Adjustment modelling” method component describes the adjustment modelling procedure and deployment to CNA. The overview of the method component is given in Figure 3-25.

Adjustment modelling and design

PROCEDURE

Add adjustments to the model Add ContextCalculation

Add KPICalculation

Add EventBasedAdjustment

Add ScheduleBasedAdjustment

Add constants to the model Set initial value

Add AdjustmentConstant

Perform IDA IDA for ContextCalculation

IDA for KPICalculation

IDA for EventBasedAdjustment

CONCEPTS Calculation

Capability Adjustment

Adjustment Constant

IDA for ScheduleBasedAdjustment

NOTATION IDA

CDT

Figure 3-25. Method component Adjustment modelling 92

CaaS


3.6.3.1 Important Concepts The most important concepts used in the method are summarized in Table 3-18. Table 3-18. The most important concepts for Adjustment modelling

Concept/ Term

Explanation

Example

KPI

Key Performance Indicators (KPI) measure achievement of goals. For each KPI a target and current value can be measured.

For KPI Response time the current value is 3.5 while the target value has been set to 2.8.

Process variation point

Process Variant is a part of the Process, which uses the same input and delivers the same outcome as the process in a different way. A process variation point contains multiple process variants to choose from.

A travel request processing variation point contains process variants for resolving calendar conflicts, displaying warnings and travel request approval.

Capability delivery variation point

A capability delivery variation point is a specialization of a variation point and is intended for modelling non process-based capabilities (where process variation points are not suitable).

Cloud resources are constantly monitored and their performance is measured. In case of low performance, new nodes are added to the cloud. When the demand decreases, nodes are removed.

Context element

Run time Context is described as Context Elements representing any information that can be used to characterise the situation of an entity.

Traffic conditions with a value of “good” or “bad”

Measurable Measurable Property is any information about property the organization’s environment that can be measured. KPI calculation

Calculates (retrieves) the target and current value of a KPI.

Context calculation

Calculates context element value chiefly from measurable properties


Contains logics for executing context and performance aware decision making for capability delivery adaption according to a predefined schedule

Eventbased adjustment

Contains logics for executing context and performance aware decision making for capability delivery adaption according to request received for CDA

Temperature.

93

CaaS


Concept/ Term

Explanation

IDA

Binds adjustments with input data providers defined in the capability model

Example

Adjustment A value that is managed centrally in CNA and constant can be reused by multiple adjustments. Capability suitability

Context indicator calculation

The capability is suitable for the context element ranges specified in the capability design. Capability is suitable for the current context situation if context element values belong to the context element ranges. Calculates the performance indicators based Clearing duration of an on data from the CDA exceptional message

3.6.3.2 Procedure This section concerns definition of adjustment and linking them with other element of the capability model. The adjustments are identified without provided an actual implementation of these adjustments. Step 1: Add adjustments to the model

Input • • • • •

A list of KPIs. A list of process variation points requiring adjustments. A list of capability delivery variation points requiring adjustments. A list of context elements and measurable properties. A list of performance indicators.

Objective • •

To create all calculations and adjustments needed in the model. To link calculation and adjustments with their respective elements in the capability model.

Activity 1.1: Add Context Calculation The CDD model contains all context elements affecting the capability. The context element values are calculated from measurable properties. The resulting context element value belongs to the context element range and has a clear business meaning. The calculation is used to reduce flow of context measurements into comprehensible context values. The Context calculation element is added to the model (Figure 3-26). Short and long names are given to the element. It is suggested to include reference CtxCalc to the element type in the short name. The analyst can add textual description to the context element outlining the calculation logics. The context calculation is linked with the context element.

94

CaaS


Figure 3-26. Linking a Context Element to a Context Calculation

Context indicator calculation passes a performance data-containing measurable property from the CCP on to CNA, where some calculation is done that yields the desired performance indicator. Hence, they can also be added in this activity to the capability model, in a similar way to the context calculation element. Activity 1.2: Add KPI Calculation KPI used to evaluate capability delivery are defined in the capability model. Their values are also used in adjustments to adapt capability delivery. Two KPI Calculation elements are added for every KPI element (Figure 3-27). One element is used to calculate Target value and another is used to calculate Current value. Current value is based on data provided from CDA and represents current performance of capability delivery. Target value is supplied by capability owners and represents the desired KPI value from the business perspective. Short and long names are given to the elements. It is suggested to include reference KPICalc to the element type in the short name. The KPI calculation is linked with the KPI element.

Figure 3-27. Linking a KPI to a KPICalculation

Activity 1.3: Add Event Based Adjustment Event based adjustments are hosted by CNA and invoked by CDA to make capability delivery decisions depending on event occurring during the capability delivery. They can be used: 1. In association with process variant variation points to indicate process variant selection decisions during execution of process based capabilities; 2. Without reference with process variant variation points in the case of non95

CaaS


process based capabilities. Events occurring during capability delivery lead to execution of one of the process variants associated with a process variant variation point (Figure 3-28). The event based adjustment is added to corresponding variation points in the capability model. The event based adjustment contains business logics for deciding, which variant to use. When using Event Based Adjustment together with a process variant variation point, the Variation Point Binding element is used to specify what process instance specific values are passed to the event based adjustment and how are adjustment results used to choose the process variant. This way the variation point binding provides run-time link between CDA execution and adjustment services. Event Based Adjustments can also be modelled independently (i.e., no process variant variation point are specified in the case of non-process based capability). In this case the adjustment is invoked according to conditions specified in CDA.

Figure 3-28. Event based adjustment and it relationships with other elements.

Activity 1.4: Add Schedule Based Adjustment Scheduled adjustments are hosted by CNA and invoked according to a predefined schedule changing properties of the CDD environment to adjust capability delivery. They can act upon CDA and CCP as well as CNA itself by invoking appropriate API functions of these components. Scheduled adjustments are associated with capability delivery variation points signifying types of adaptation taking place during capability delivery (Figure 3-29).

Figure 3-29. Linking a Capability Delivery Variation Point to a Scheduled Adjustment

Output •

The initial adjustment model containing all the adjustments, entities that they support and their relations.

Tools • CDT Contributors •

Business Analyst 96

CaaS

• •


Capability Analyst Method Engineer

Step 2: Add constants to the model

Input •

Output from the previous step.

Objective •

To add all the Adjustment Constants to the adjustment model.

Activity 2.1: Add Adjustment Constant Context data are retrieved from CCP and KPI values are retrieved form CDA. Adjustment constants are maintained by CNA purely for capability delivery adaptation purposes. They are also defined in the capability model (Figure 3-30). They are stored in CNA and their values can be altered during runtime. Adjustment constants can be used for specifying local values of Context Calculation, KPI Calculation, Event Based Adjustment and Context Calculation. Changing the value of Adjustment Constant directly affects the dependent adjustments. It is recommended to reuse instances of Adjustment Constant whenever they have the same meaning to adjustments. Adjustment Constant can have different values per deployment.

Figure 3-30. Adjustment Constant element

Activity 2.2: Set initial value The initial values of adjustment constants are set in CDA. Selection of the value depends on business meaning of the capability. The values specified in CDT are the master values and can be later overridden in CNA per each deployment. Output •

The adjustment model from the previous step complemented by adjustment constants and their initial values.

Tools • CDT Contributors • • •

Business analyst Capability analyst Method engineer

97

CaaS


Step 3: Perform IDA

Input •

Output from the previous step.

Objective •

Adjustments use data from other elements defined in the capability model. Perform IDA step ensures that values from these elements are passed to the adjustments.

Activity 3.1: IDA for Context Calculation Context calculations use values from measurable properties and adjustment constants. All measurable properties and adjustment constants consumed by a context calculation element are linked to this element using the IDA association (Figure 3-31). As the result, these elements are provided as input variables to the context calculation.

Figure 3-31. IDA for a Context Calculation

The usage of IDA for measurable properties is summarized in Table 3-19. Table 3-19. Functionality provided by Measurable Property IDA

Function

Description

Shows which measurable For each Measurable Property that is used in context property is used element calculation there should be a separate Measurable Property IDA. Describes aggregation.

necessary Optionally the measurable property data can be aggregated. This is set by using attributes aggregation_function, aggregation_function_parameter of the Measurable Property IDA. The actual aggregation is performed by CCP during runtime.

To specify how parameters A Measurable Property might require mandatory of the Measurable parameters like country name, to return the temperature Property get their values. in Celsium. If a Context Element requires mandatory input parameters, they can be mapped to the mandatory input parameters of a measurable property, so that when Context Element value is retrieved from CNA during 98

CaaS


runtime and input parameters are specified, these are sent to CPP to get the needed Measurable Property values. Mandatory input parameters of Measurable Property can also be mapped to Adjustment Constant instances. Activity 3.2: IDA for KPI Calculation KPI calculations can use adjustment constant and context element values to compute the KPI value if it not provided by CDA or requires further processing. The calculations are specified for both current and target values of KPI (3-32). If a Context Element requires mandatory input parameters, then Context Element Value IDA can map them to Adjustment Constant. Context Element Value IDA also defines the resulting adjustment variable, which will hold the value of the Context Element. Adjustment Constant IDA also specifies the name of the adjustment variable that will get the Adjustment Constant value.

Figure 3-32. IDA for a KPICalculation

Activity 3.3: IDA for Event Based Adjustment Event based adjustments can use context element, adjustment constant and KPI in computations. Values of these elements are passes to event based adjustment by 99

CaaS


establishing relationships among them (Figure 3-33). Context Element IDA defines the resulting adjustment variable, which will hold the value of the Context Element. Adjustment Constant IDA specifies the name of the adjustment variable that will get the Adjustment Constant value. KPI IDA puts the target and current values of a KPI in the local variables of the adjustment.

Figure 3-33. IDA for an Event Based Adjustment

Scheduled adjustments also can use context element, adjustment constant and KPI in computations (Figure 3-34).

Figure 3-34. IDA for a Scheduled Adjustment

Output •

Model containing adjustments and their IDAs.

Tools • CDT Contributors • • •

Business analyst Capability analyst Solution architect 100

CaaS


3.6.4 Method Component: Adjustment Implementation and Delivery Once the adjustments are implemented in the capability model, they are deployed in CNA for execution. 3.6.4.1 Important Concepts The most important concepts used in the method are summarized in Table 3-18. 3.6.4.2 Procedure The “Adjustment implementation and delivery” method component describes the adjustment implementation and deployment to CNA. The overview of the method component is given in Figure 3-35.

Adjustment implementation and delivery

PROCEDURE Implement and validate adjustments Implement adjustments

Validate adjustments

Deploy to CNA Deploy adjustments

Configure CNA

NOTATION



Adjustment Constant

IDA

CDT

Figure 3-35. Method component Adjustment design and delivery Step 1: Implement and validate adjustments

Input •

Adjustment Constants, Context Calculations, KPI Calculations, Scheduled Adjustments, Event Based Adjustments are added to the model in CDT and they are link with the corresponding elements in the capability model.

•

All the needed Measurable Property instances are initialized in CPP.

Objective To implement the logic for Context Calculations, KPI Calculations, Scheduled Adjustments and Event Based Adjustments. Activities •

Implement adjustments in the following order – Context Calculations, KPI Calculations, 101

CaaS


Event Based Adjustments and Scheduled Adjustment. For each adjustment element follow the steps a-b. Prior to validating Context Calculations, Measurable Properties used by them must be initialized in CPP. Activity 1.1: Implement adjustments If the adjustment instance is of type Java, the developer needs to open the JAVA perspective in CDT and implement the execute method of JavaAdjustment template class (Figure 3-36). If the adjustment is of type MathML, it is implemented using the MathML perspective of the CDT. No programming skills are necessary for MathML adjustment implementation.

package Adjustments; /* * Any libraries can be included as long as they do not * conflict with the Java runtime system and are packed in the * resulting JAR file. */ import java.util.*; /* * An object of type Adjustments class would get initialized by the * Java runtime * */ public class JavaAdjustment { /* * Variables map stores all the adjustment local variables. They are set using * the following procedure: * 1. The Storage and execution module performs the IDA to retrieve * variable values. * 2. The Storage and execution module creates the adjustment object by using * Java runtime system and also sends variable names and their values. * 3. The Java runtime system makes the variable available to the object * by using the addVariable method. */ Map variables = new HashMap(); public JavaAdjustment() { /* * You can add initialization code here. */ } /* * This method is used for storing the variable names * and values in the variables map. */ public void addVariable(String name, String value) { this.variables.put(name, value); } /* * This method is used for retrieving the variable value. */ private String getVariableValue(String name) { return this.variables.get(name); } /* * The execute method needs to be implemented before the adjustment * can be called. Use getVariableValue method, to retrieve values * of adjustment variables. This method will be called after the * Java runtime system has initialized all adjustment variables and * the result would be returned to the Storage and Execution module. */ public String execute() { Integer calculation = Integer.parseInt(this.getVariableValue("var1"))*100; return calculation.toString(); } }

Figure 3-36. JavaAdjustment class template 102

CaaS


Activity 1.2: Validate adjustments To ensure that the adjustment implementation is correct, it needs to be validated. The validation is performed via the CDT. For Java adjustments a debugger can be used to toggle breakpoints and watch the local variables. For MathML adjustments the tester provides the mandatory adjustment input parameters (if any are required) and reviews the result. When using Measurable Property values CDT queries CPP during the validation activity. Output •

Adjustment Constants, Context Calculations, KPI Calculation, Scheduled Adjustment and Event Based Adjustment are implemented and ready for deployment to CNA.

Tools • CDT • CCP (for retrieving value of Measurable Properties) Contributors • • • •


Step 2: Deploy to CNA

Input •

Adjustments have been implemented in CDT.

Objective •

To deploy adjustments and related entities to CNA.

Activities The capability model developed in CDT is used to configure CNA. Calculations and adjustment constitute an active part of this configuration. They are deployed in and hosted by CNA as executable services. Calculations and adjustments are deployed to CNA as part of Export to CNA action performed in CNA. If calculations and adjustments are modified in CNA, they should be redeployed. However, redeployment does not require stopping either CNA or CDA and it can be performed during in the run-time mode of these applications. The changes take effect immediately. The configuration of CNA includes: •

Multiple deployments can be created for every user of the capability. The deployments are used if the same capability is used by several consumers. Monitoring results are displayed and adjustments are executed for every deployment separately;

103

CaaS


•

Selection of indicators for display in CNA. The most important indicators are displayed by selecting from the set of indicators both KPI and context indicators defined in the capability model. The indicators allow to monitor the current performance of the capability delivery;

•

Value of the adjustment constants can be changed.

The CNA also displays measurable properties and context set defined in the capability model. Output • Adjustments and constants are deployed to target environments Tools • CDT • CNA (on API level) Contributors • •

Solution architect Solution engineer

3.6.5 Method Component: Adjustment Assessment and Improvement The capability is delivered to its consumers and capability delivery performance is monitored as well as context indicators. If context situation changes or delivery performance targets are not achieved, then adjustment of the capability delivery is considered. The method component also discusses general aspects of capability delivery monitoring what is relevant to majority of method components and extensions dealing with the capability delivery phase. 3.6.5.1 Important Concepts The most important concepts used in the method are summarized in Table 3-18. 3.6.5.2 Procedure The “Adjustment assessment and improvement” method component consists of two main steps, namely, capability delivery performance monitoring and changing adjustments in the capability design (Figure 3-37). The monitoring is performed using CNA, data analysis is performed using specialized analytical software using API provided by CNA for data retrieval and modifications of adjustments are made in CDT.

104

CaaS


Adjustment assessment and improvement

PROCEDURE Identify required modifications Monitor capability delivery

Analyze capability delivery performance

Make the changes and activate new version Modify ContextCalculation

Modify KPICalculation

Modify EventBasedAdjustment



Adjustment Constant

Modify ScheduledAdjustment

NOTATION IDA

CDT

Figure 3-37. Method component Adjustment assessment and improvement Step 1: Identify required modifications

Input •

Context data and capability delivery performance data

Objective •

To assess adjustments made and to identify required modifications in the capability design.

Activities Required modifications are identified by monitoring and analysing capability delivery performance. The monitoring includes: •

evaluation of capability suitability;

•

observing of indicator values;

•

reviewing logs recording adjustments made.

The context is monitored to identify deviations from the capability suitability range. The capability is referred as non-suitable if the currently observed context value does not belong to the context range. The capability KPI are monitored using graphical displays in CNA. If performance does not meet the expected targets, then capability adjustment is considered. The reasons of non-performance are analysed using enterprise management and performance evaluation methods. These can be due to client’s internal inefficiencies or inappropriate capability delivery solution. In order to identify inappropriate capability delivery solution the performance monitoring results are compared to context monitoring results. The capability suitability is defined by the context set. If currently observed context values forming the context situation are outside the context element ranges defined for the context set, the capability is deemed unsuitable for the current context situation. If 105

CaaS


non-performance and non-suitability is observed then the capability redesign cycle is invoked. If non-suitability is observed without detecting non-performance than capability delivery cloud be continued concurrently with exploring options for improving the capability design. The capability consumer may choose to continue: 1) capability delivery risking adverse consequences on the performance; 2) stop capability delivery; 3) make major capability adjustment; or 4) switch to another capability The capability delivery logs displayed in CNA provide information about adjustments performed during capability delivery. The logging data can be compared with performance data and context data to identify contribution of the adjustments towards improving capability delivery performance.

Curre Targe t

Context element value

KPI

CNA provides means for observing current values of indicators. A more detailed analysis of the indicators can be performed using data analysis tools such as MS Excel or R. Historical data are retrieved from CNA using its API. Two typical charts used for visualization of historical capability delivery data are shown in Figure 3-38. The left panel shows visualization of historical KPI values relative to the target value. The right panel shows context values in the case of categorical context range. Every shaded segment represents one value from the context element range. The red shaded segment indicates a situation when context value was outside the context range considered for the given capability.

r 3

r 2

r Time

1

Time

Figure 3-38. Charts visualizing KPI and context values.

Output • The adjustments and constants that need to be modified have been identified. Tools • CDT • CNA user interface • CNA Adjustment engine (API level) Contributors • • • • • •

Business Analyst Capability Analyst Solution architect Business Service Manager CDD Provider Capability feedback provider

106

CaaS


Step 2: Make the changes

Input Adjustment Constants, Context Calculations, KPI Calculations, Event Based Adjustment and Scheduled Adjustment requiring changes. Objective •

To make changes in the capability design to accommodate previously unforeseen context situations or to improve ability of run-time adjustments to deal with changes. Activities The modification applies to all calculations and adjustments. Activity 2.1: Modify Adjustment Constant Modify Adjustment Constants in CNA. If it is acknowledged that Adjustment Constant needs to be changed, it has to be considered that this change would affect all the adjustments that use the Adjustment Constant. Modification of an Adjustment Constant instance has an immediate effect on the capability. After the change all dependent adjustments should be monitored by reviewing the log files to prove that the desired effect has been achieved. Activity 2.2: Modify Context Calculation A new version of the Context Calculation is created using CDT. Creation of a new Context Calculation version in CDT has no immediate effect on the capability. After the necessary changes are made, the adjustment has to be validated. During the validation Measurable Property values are retrieved from CCP. After the validation the new version of the adjustment can be deployed to CNA and activated, which has an immediate effect on the delivered capability. If Context Calculation needs to be changed, it has to be considered that this change would affect all the adjustments that use this Context Calculation. Activity 2.3: Modify KPI Calculation A new version of the KPI Calculation is created using CDT. Creation of a new KPI Calculation version in CDT has no immediate effect on the capability. After the necessary changes are made, the adjustment has to be validated. After the validation the new version of the adjustment can be deployed to CNA and activated, which has an immediate effect on the delivered capability. If KPI Calculation needs to be changed, it has to be considered that this change would affect all the adjustments that use the KPI Calculation. Activity 2.4: Modify Event Based Adjustment A new version of the Event Based Adjustment is created using CDT. Creation of a new Event Based Adjustment version in CDT has no immediate effect on the capability. After the necessary changes are made, the adjustment has to be validated. After the validation the new version of the adjustment can be deployed to CNA and activated, which has an immediate effect on the delivered capability. If Event Based Adjustment needs to be changed, it doesn’t have a direct effect on other adjustments, however CDA depends on the Event Based Adjustment. Activity 2.5: Modify Scheduled Adjustment A new version of the Scheduled Adjustment is created in CDT. Creation of a new 107

CaaS


Scheduled Adjustment version in CDT has no immediate effect on the capability. After the necessary changes are made, the adjustment has to be validated. After the validation the new version of the adjustment can be deployed to CNA and activated, which has an immediate effect on the delivered capability. If Scheduled Adjustment needs to be changed, it doesn’t have a direct effect on other adjustments, however it directly reacts on CDA. Output • Adjustments and constants have been improved. Tools • CDT • CCP (API level) Contributors • •

Solution architect Solution engineer

3.6.6 Method Component: Performance Based Context Evaluation Adjustment The capability is designed to ensure its efficient delivery for different value of the context elements. The delivery performance is evaluated using KPI, and adjustments are made if the capability delivery goals are not achieved. This method component describes a solution for evaluation and improvement of capability delivery performance by adjusting context element value calculation. It uses the generic adjustment specification methods described in the previous sections and elaborates a specific capability adjustment algorithm. The method component deals with three major challenges associated with designing and delivering capabilities: (1) diversity of process execution circumstances causes too much variability in business process designs; (2) not all context situations can be predicted at the design time; and (3) relationships between context and capability delivery performance are not well-understood. In the CDD approach, the former two issues are addressed by categorizing context values into a set of meaningful values, for which process design and execution indeed should be differentiated. The latter issue is addressed by adjusting context definitions during the run-time using a search procedure. A demonstration example for this method component is reported in Appendix D. 3.6.6.1 Purpose and Preconditions The purpose of the performance based context evaluation method component is: ● To improve the capability delivery performance. ● To find the most suitable categorization of the context values. The categories are used to select appropriate capability delivery variants. ● To ensure continuous updating of the categorization in the case of non-stable capability delivery environment. The preconditions of the successful application of the method component are: 108

CaaS


● The capability model is developed. ● Context element range is defined by enumeration and relationships between measurable properties and the context element range are not deemed as fixed (i.e., bound to specific business rules). ● The capability is delivered following the business process and business process variants are defined for specific context element ranges. ● Context models can be modified during the run-time. The method helps primarily in solving the following issues: ● How to categorize context element values? ● What are relationships between capability delivery goals and context elements? ● Does capability delivery process provide an adequate means for dealing with specific context situations? 3.6.6.2 Overview of Method Component The context elements are measured using their measurable properties. The context element value is either numeric (assumes values from the continuous range) or categorical (assumes values from the enumerated set of values). The categorical values are particularly useful to manage variability of capability delivery processes. The process variations are developed only for the context categories meaningful to the business. The set of permissible values in defined as the context element range. These values are identified by a business analyst during the capability design. Some of the values occur naturally in the business environment while others are derived as a result of expert judgment. In the case of limited information, the values ought to be redefined as more data become available. It is claimed that the way range values are defined can be used as an instrument to manage achievement of the capability delivery goals. The context evaluation adjustment redefines the way the categorized context element value is calculated using the measurable properties and depending on capability delivery performance. The method component for context range evaluation adjustment consists of six main steps. It utilizes concepts defined in the capability meta-model with additional concepts for representing technical details of the adjustment design. The main steps are as follows: 1. Define goals and KPI - the context range evaluation adjustment is performed to optimize achievement of the organizational goals measured by appropriate KPI. Therefore, the first step is definition of the goals and KPI. The goals and KPI generally are defined as a part of the capability modelling (Section 3.1). However, in this step particular attention is devoted to complete specification of KPI. 2. Define context - the context modelling is performed as prescribed in Section 3.3. In this step, particular attention is devoted to specifying expression for calculating the context element value and mapping of this value to the context element range.

109

CaaS


3. Define adjustment - formally defines dependence of the context element value to range mapping upon the capability delivery performance and a way this dependency should be redefined in the case of non-performance. 4. Monitor capability delivery – during the capability delivery phase, the need for context evaluation adjustment is identified. 5. Adjust context evaluation – the context evaluation adjustment is enacted if the capability performance targets are not met. 6. Adjustment feedback – during the feedback phase, some of the adjustment decisions made during the runtime can be incorporated in the capability design and made permanent. Steps one through three are performed during the capability design. Steps four and five are performed during the capability delivery without redeploying the solution. The runtime capability adjustment algorithm is actually executed in Step 5 (Figure 3-39). The key idea of the adjustment is that context value calculation expression is parameterised and made dependent on capability delivery performance (measured by KPI). The parameterisation described in Section 3.5.6.4 Step 2 and 3 allows changing the way context value is calculated. That in turn changes the capability delivery, which is steered by varying treatment of different context values. Capture measurable properties Evaluate context value Capture KPI

Adjust capability delivery

Calculate adjustment parameter

Figure 3-39. The context evaluation adjustment algorithm

The method component uses the key concepts from the capability meta-model and concepts used in technical definition of run-time delivery adjustment. These concepts include: ● ● ● ●

KPI Context Context range Calculation ○ Context element range definition expression ○ Intermediate context element value calculation - expression computing continuous context value from the measurable properties. ○ Context element value calculation- expression transforming intermediate context element value into a categorical value. ● Event based adjustment ○ Context evaluation adjustment

3.6.6.3 Cooperation Principles During the capability design phase, a Business analysis refines the goal model and 110

CaaS


elaborates the context model by specifying the adjustment. During the capability delivery phase, the involvement of stakeholders varies according to the adjustment mode - automatic or manual. In the case of automatic adjustment, a Capability analyst monitors impact of adjustments on the capability delivery. In the case of manual approval of capability adjustment, a Capability analyst provides information for the approval decision-making and a Business service manager makes the approval decision. The context evaluation adjustment provides important feedback from the run-time to design time. If the objective was to identify the right categorization of context values and the capability delivery environment is deemed as stable then the newly established context categories are set fixed in the next capability design cycle. This decision is made by a Business service manager and implement by a Business analyst or a Solution architect. The summary of stakeholders involved is provided in Table 3-20. Table 3-20. Assignment of Stakeholders to Method Components

Step Define goals and KPI

Stakeholders Business analyst

Defined context

Business analyst

Defined adjustment

Business analyst, Solution engineer

Monitor capability delivery

Capability analyst

Adjust context range evaluation Adjustment feedback

Business analyst, Business service manager, Solution architect Business analyst, Business service manager

3.6.6.4 Procedure The method component procedure describes step-by-step activities of capability delivery evaluation and adjustment. Step 1: Define goals and KPI

Input ● The capability model (possibly incomplete). Objective It is ensured that the goals and KPI are fully specified in the capability model and contain all the information required for defining the adjustment. Activities The adjustments are made to ensure that the desired capability delivery performance is achieved in varying circumstances. The delivery performance is measured and evaluated and measured using KPIs associated with the capability goals. This step is preparatory in case the capability model has not been fully specified from the measurement perspective. The KPI is specified as defined in 3.5.3.2. The target value is 111

CaaS


mandatory. Output ● Fully specified KPI of the capability model. Tools ● CDD Contributors ● Business analyst Step 2 Define context calculations

Input ● The capability model ● Search based adaption pattern Objective The objective of this step is to define the context value calculation. The context value calculation is specified using the generic framework as defined in Section 3.6.3.2. Specific context calculations and scheduled adjustments are specified to preform search based adaptation. Search based adaptation is used in many capabilities. It has been published as a pattern in the Pattern Repository. In this step, the pattern is retrieved from the repository to provide foundations for further design of the adjustment. Activities The context calculation is parametrized and depends on an adjustment constant, which in turn is adjusted during the run-time using a schedule adjustment. The capability model has a context element defined (Figure 3-40) and the Search based adaption pattern is insert in the capability model (elements belonging to the pattern are shown as a group in the figure). The model should be modified to integrate existing model elements with elements imported from the pattern repository: •

the context calculation should be associated with the corresponding context element using the calculates relationship;

•

IDA between the measurable property and the context calculation should be performed;

•

a generic KPI retrieved from the repository should be replaced with KPI used in adaptation by re-establishing the relationship between the scheduled adjustment and KPI.

112

CaaS


Figure 3-40. Search based adaptation adjustment as a part of capability model.

The context calculation contains a generic code for calculating value of the context element depending of the adaption constant. The generic code performs the following calculation: •

The intermediate value Vi is calculates as: Vi = f ( Pi ) ,

where the subscript refers to the ith context element, Pi = ( pi1 ,..., piM ) are measurable properties and f is a function specified by the modeler. •

Context element ranges are defined using expression bijL = ω( j −1)ΔVi and bijU = ω ( j × ΔVi ) ,

where bijL is the lower bound for jth item in the context element range and bijU is the upper bound for the jth range. ΔVi = Ni−1 ( max(Vi ) − min(Vi ) ) and ω is the adjustment constant (ACAdjConst). •

The categorical context value Ci maps the context element value to the context element range: ⎧ r , b L ≤ Vi < bijU , Ci = ⎨ ij ij U ⎩ riN ,Vi ≥ biN −1

where CRi = (cri1,..., criN ) is the context element range with its enumerated values. The categorization of the context depends upon decisions made business analysis and process owners. Some of the categories occur naturally in the business environment while others are derived as a result of expert judgment. In the case of limited information, the categories ought to be re-evaluated as more data become available. It is claimed that the way categories are defined can be used as an instrument to manage achievement of the process goals. 113

CaaS


The changes in the generic code can be made if necessary. Output ● Fully specified context model ● Context calculation Tools ● CDD and CCP Step 3 Define performance adjustment

Input ● Context elements ● Indicators Objective The adjustment modifies the way the intermediate value Vi is transformed into the context element value. The adjustment objective is to change categorization of the context element values in order to improve achievement of the capability delivery goals. Activities The performance adjustment is defined using the SearchBasedAdaptShdAdj element. This element contains the generic code for performing search based adaption. In this case search based adaption is performed for the adjustment constant ACAdjConst what in turns affects the way context element value is calculated. The generic expression for performance depended adaption of the adjustment constant is Target ⎧ ⎪ ω + Δωi , I j < I j ωi = ⎨ i Target ⎪ ⎩ωi − Δωi , I j ? I j

,

where Ij refers to the value of jth KPI and Δω is another adjustment constant set by a modeller. The specified dependency implies that greater values of ω contribute to improving indicator Ij (depending on indicator, the opposite may be true and the sign is reversed). Changing ω depending on KPI can be perceived as a search procedure to find the best value of the adjustment parameter. The adjustment is triggered according to the schedule defined in CDT. Too frequent adjustments might cause instability of the capability delivery process and increased computational load. Too rare adjustments might cause inflexibility of capability delivery and insufficient sensitivity of the search procedure. The adjustment can be overridden if the resulting categorization of the context is not deemed as appropriate from the business sense. Output ● Scheduled adjustment

114

CaaS


Step 4 Monitor capability delivery

Input ● Context situation ● KPI Objective The capability delivery performance and context situation are monitored during the capability delivery to identify a need for the adjustment. Activities The KPI data are represented in the CNA capability delivery dashboard. The KPI directly used in evaluation of the adjustment are highlighted. The context indicators are also represented in the CNA capability delivery dashboard. The context indicators are displayed as count data over selected business process instances. Correlation among the KPI and context indicators is illustrated and capability delivery evaluation report is generated to enable a Capability analyst and a Business service manager to track capability delivery performance. Output ● The capability delivery performance report showing KPI as a function of context element values. Tools ● CNA Step 5 Adjust context range evaluation

Input • • •

The context model Current values of the context indicators Current values of the adjustment parameters

Objective Categorization of context values is changed if capability delivery performance does not satisfy the business goals. Activities The adjustment is invoked in response to an event generated by CDA (e.g., CDA requires the adjustment according to calendar events or process counter events). The adjustment parameter v is evaluated in response. If its value has changed, CNA proposes the adjustment and the relationship between the intermediate context element value and the context element range is characterized graphically. The proposed adjustments is approved or rejected automatically or manually for the greater control of the capability delivery behaviour. If adjustments are approved manually then CNA notifies the responsible person, and she uses CNA services to approve or reject the adjustment. In the case of approval, the CNA log is updated to indicate that adjustment has been applied, and CECtxCalc expression with the updated value of the adjustment parameter is used to evaluate the context value. Output 115

CaaS


● Adjusted values of the adjustment parameters Tools ● CNA Step 6 Adjustment feedback

Input ● Adjusted context range definition Objective The adjusted context value calculation can be made permanent in the next capability design phase if a Business service owner perceives that it represents the true categorization of the context values. Making the adjustment result permanent reduces computational load of capability delivery and avoids potential instability of the capability delivery. However, that might result in a failure to react to further changes in the capability delivery environment and context. Activities The business service owner evaluates the adjustment results. If the desired capability delivery performance and a steady-state of context process have been achieved, the capability model is updated with a new context value calculation definition without using the adjustment. Output ● New context value calculation without adjustment

3.6.7 Method Component: Predictive analysis The adjustments are used to alter capability delivery in response to changes in the context. However, in dynamic environments changes take place very quickly and the responsive activities might lag actual events and the need for adjustments. Therefore, proactive adjustment of capability delivery should be considered. The proactive approach requires in advance knowledge of context data. Prediction methods are used to forecast context data and these predictions are used for proactive adjustment. The method component elaborates application of the prediction methods. The method component aims: To improve capability delivery performance by invoking adjustments proactively on the basis of predicted values of contextual information; • To predict potential violations of capability suitability as defined by the context element range; • To predict values of measurable properties and to use these values in evaluation of adjustments. The preconditions of the application of the method component: •

• • •

Capability model including adjustments; Availability of prediction pattern in the pattern repository. The prediction pattern defines a generic solution for predicting values of measurable properties. 116

CaaS


Indicators

Predictive analysis is used to perform capability delivery adjustment proactively. Differences between reactive and proactive approaches are illustrated in Figure 3-41. The chart tracks evaluation of the capability delivery performance in time and context indicators serves as a leading indicator of changes taking place in the capability delivery environment. The threshold value is minimum allowed value of the KPI. In the case of reactive adjustment, the adjustment is invoked only when non-performance is directly observed and there is a time delay before the adjustment brings performance improvements. During this delay, the capability delivery performance goals are not met. In the case of proactive approach, the application senses deterioration of the capability delivery performance and the adjustment is invoked earlier thus avoiding further worsening of the performance.

KPI KPI* CI Treshold

Reac`ve adjustment

Proac`ve adjustment

Series5 Series6

Time

Figure 3-41. Reactive vs proactive capability delivery adjustment

The Predictive analysis method component overview is shown in Figure 3-42. The important concepts and the capability design and delivery procedure is further elaborated in the following subsections.

2

PREDICTIVE ANALYSIS

PROCEDURE

Design Inspect

Run-time Apply prediction pattern

Monitor

CONCEPTS Factor/ Driver

Context Element

Context Type

Prediction based adjustment

NOTATION Measurable Property

Process Variable

BPMN

CDT

117

CaaS


Figure 3-42. Overview of the predictive analysis method component

3.6.7.1 Important Concepts The predictive analysis uses prediction of measurable properties and context element values generated by a prediction model usually developed on the basis of historical data. The concepts of prediction, historic data and prediction horizon are illustrated in Figure 3-43. Actual value for time moment t

Prediction horizon, h

Prediction for time moment t+h

Time

Historic data

Current time moment, t

Future time moment, t+h

Figure 3-43. Concepts of prediction, historic data and prediction horizon

The capability is designed to deliver expected performance for a certain range of context values as defined by the context element range. The capability is deemed as suitable for this context range (i.e., enterprise claims possessing the capability and ensures the specified delivery performance). This is referred as to capability suitability. If context situations beyond the specified context range occurs than the performance of the capability delivery cannot be guaranteed and the capability is deemed as unsuitable. If the capability is unsuitable then capability should be redesigned or replaced with another capability. That is triggered by capability monitoring in a form of capability redesign/switch adjustment. The main concepts are summarized in Table 3-21. Table 3-21. Important concepts of predictive analysis

Concept / Term Prediction Prediction model Prediction horizon Historical data Capability suitability

Capability

Explanation Example Expected future value of measurable properties, context element values or indicators A mathematical or logical model for Autoregressive model generating predictions Moving average Number of periods in advance a prediction One week should be made Previously observed measurable properties and indicators’ values The capability is suitable for the context element ranges specified in the capability design. Capability is suitable for the current context situation if context element values belong to the context element ranges. A type of adjustment invoked in the 118

CaaS

redesign/switch adjustment Adjustment


capability is evaluated as unsuitable for the context situation observed during the capability delivery Adjustments perform context processing Service promotion and context aware decision-making during algorithm the capability delivery. Adjustment algorithm adapts capability delivery in response to changes in the context to meet capability delivery goals.

3.6.7.2 Procedure The predictive analysis is a part of the capability delivery cycle proceeded by delivery monitoring. The prediction based adjustments are specified during the design cycle. Thus, the predictive analysis method components include both design-time and run-time activities. CDT is used to specify the prediction adjustment. CNA is used during runtime for monitoring and invoking the adjustment. Step 1: Inspection of the capability model

Predictive analysis is a part of the overall capability delivery process and it uses the capability design model as the development basis. Input The capability model developed as described in Sections 3.2. and 3.3. The most important parts of the capability model relevant to predictive analysis are the context modeling part and adjustments. Objective The objective is to check readiness of the capability design for modification by introducing the predictive analysis. Activities a) Identify of context elements requiring predictive evaluation. The prediction is useful for context elements exhibiting significant variation over time and have observable variation patterns. Variability and its patterns are evaluated using statistical analysis methods (Box and Jenkins, 2015) and data accumulated during the capability delivery (see Section 3.6.5) b) Identify measurable properties used in prediction. The prediction is performed by forecasting values of relevant measurable properties and the predicted values of measurable properties are used to calculate expected value of the context element. Figure 3-44 shows a fragment of the capability design created to use actual values of measurable property MP for calculation of the context element CECtx. The context element calculation logic is defined using the CE1CtxCalc element.

119

CaaS


Figure 3-44. A fragment of capability design using actual data

Output • Fully specified capability design model Tools • CNA – provides data for analyzing the need for predictive analysis. • CDT – shows capability design elements in question. Contributors • •


Step 2: Application of the prediction pattern

The initial capability design is modified to use predicted values of the relevant measurable properties. The initial capability design uses actual values of the measurable properties to calculate values of the context elements. The calculation is specified using an adjustment. The prediction pattern is used to replace the usage of the actual values with the usage of predicted values. Input • Fully specified capability design model • Prediction pattern Objective To modify the capability design from using the reactive approach to capability adjustment to using the reactive approach. Activities •

a) Retrieval of the prediction pattern from the repository. The prediction pattern is stored in the pattern repository. Prediction based context calculation defines the way predictions are made. b) Connecting of the retrieved design elements with the current capability design (Figure 3-45). The measurable properties to be predicted are bind to the prediction calculation, the adjustment constant enabling switching from the reactive to proactive mode is added and the prediction calculation is bind with the context element calculation indicating that the particular context element is calculated using the predicted value (the pattern usage guidelines provide additional instructions for using the pattern).

120

CaaS


Figure 3-45. Application of the prediction pattern

Output • The capability model including predictive adjustments Tools • CDT • Pattern repository Contributors • •

Capability analyst CDD provider

Step 3: Definition of the prediction model

The prediction pattern provides a generic solution to the prediction problem. This step elaborates the prediction model used for the particular context element. The prediction model is developed following the best practices used in forecasting (Makridakis and Wheelwright, 1997). From the capability design perspective, it is important to distinguish between development of the forecasting model and binding of the model with the capability design. The primary focus on the CDD methodology is the binding while forecasting model development is discussed only briefly. The forecasting model development includes selection of the appropriate forecasting method, model configuration and model evaluation. The forecasting model is selected from a range of typical forecasting models including moving average, exponential smoothing, autoregressive models, regression models or a completely new forecasting model is developed. Input • The capability model including predictive adjustments • Implementations of forecasting models if available Objective 121

CaaS


• To specify the model used in prediction of measurable properties Activities a) Development of the forecasting model. The forecasting model is implemented as calculation adjustment. If appropriate the default forecasting model can be used. b) Binding the forecasting model with the capability design. The calculation defined is bound to appropriate measurable properties, context element and constants. The default forecasting model is an autoregressive model (Box and Jenkins, 2015). It allows for uniform treatment of stationary time series as well as of seasonal time series. Let context element value calculation is specified as then CVi = f ( Pi ) , then predicted context element value is calculated as: ∂ i = f Pˆ , CV it

( )

where Pˆit is the set of measurable properties for the ith context element as predicted at the tth time period and µpikt = ρ + ∑πΠ=1 aπ pikt −π , µpikt ∈ Pˆit is the one-step-ahead forecast of the kth measurable property at the time period. r , Π and aπ are parameters of the autoregressive prediction model. The equation predicts future values of the measurable property according to the previously observed values of the measurable property. The model configuration includes specification of its parameters. In the case of the autoregressive model that includes identification of the autoregression structure (i.e., which past observations are used to make predictions) and estimation of the parameters (see Box and Jenkins (2015) for more details). The model configuration is used here as a rather general term since many different types of forecasting models could be used and configuration tasks depend upon the type. The forecasting model evaluation concerns accuracy evaluation and estimation of confidence intervals for the predictions made. Output • Fully specified capability model • Implemented prediction adjustment Tools CDT tool A tool used for development of forecasting models, e.g., MinitTAB, Microsoft Excel or R. Contributors • •

• • •

Business analyst Capability analyst Method engineer

Step 4: Proactive Adjustment Monitoring

During the capability delivery, context and performance indicators are monitored. The monitoring is performed as described in Section 3.6.5. In the case of proactive adjustment monitoring context element values are calculated using the prediction model 122

CaaS


Step 5: Prediction based adjustment of capability delivery

The predicted values of measurable properties are used to evaluate capability delivery adjustments. This way adjustments can be invoked proactively prior to actual changes in the context might have caused an adverse impact on capability delivery performance. The prediction based adjustment is performed to steer the capability delivery by accounting for context dependencies addressed in the capability design. Input • Predicted context element values Objective To perform proactive adjustment of capability delivery on the basis of predicted context. Activities •

•

Evaluation of proactive capability delivery adjustments. The values of measurable properties are predicted and used in calculation of context values.

•

Adjustment of capability delivery. The prediction based context values are used to evaluate context dependent decisions and to run adjustment algorithms, e.g., the services are promoted on the basis of predicted values in the SOA service promotion case.

Output •

Adjustment values for steering the capability delivery

Tools • CNA Contributors •

Capability analyst

123

CaaS


4. Method Extensions During adoption of the CDD methodology in the different industrial use cases, method extensions were elaborated which are tailored to the needs of the application areas of the use cases. These method extensions are part of the final CDD methodology and presented in this section: • • •

•

Section 4.1 presents the method extensions developed for business process outsourcing Section 4.2 describes the method extension for capability relationship analysis and modelling from a strategic perspective Section 4.3 focuses on method extensions for context aware collaborative software development, i.e. the integration of CDD and model-driven development of software Section 4.4 addresses method extensions for Project Management Office (PMO)

4.1 Business Process Outsourcing This section contributes to the final CDD methodology by presenting CDD methodology extensions related to the sector of Business Process Outsourcing (BPO). The method extensions have been developed iteratively and incrementally and address the following issues: •

•

•

The Capability Ready Business Services method extension covers the transition step from textual instructions and activity descriptions to business process models ready for capability modelling. With this extension many more business services in BPO can be subject to capability, i.e. the number of cases where the CDD methodology described in D5.2 can be applied is increased. The Prepare Local and Global Optimization method extension contributes to the optimization of service delivery by providing a way to balance between local optimization of services provided to a client and global optimization from a BSP perspective. The Evolutionary Development of Business Information Exchange Capability method extension helps organizations to develop capabilities in the case when pre-existing capability delivery solution must be tailored to the needs of a new client.

4.1.1 Method Extension: Capability Ready Business Services Business process outsourcing (BPO) has been proven to be an economically interesting way for companies to control their whole value chain by concentrating on their key business and leaving ancillary processes to highly-specialized service providers, thereby also securing a high level of overall quality. Lately it has been reported that BPO global market value has maintained a steady growth. In spite of the economic uncertainty, Gartner forecasts a compound annual growth rate of 5.6% from 2012 through 2015 and

124

CaaS


growth of 6.2% in 20146. The “Capability Ready Business Services” method extension captures the procedures defining how to provide capabilities from the informally defined business services as a business service provider (BSP) and enumerates the important concepts as well as their documentation. For the development of the method extension we investigated the procedures followed in MSCONS-clearing process by analysing secondary data and executing structured interviews in SIV Utility Services GmbH. Various experts at different levels, including a knowledge worker, capability analyst and a solution architect validated the resulting models. 4.1.1.1 Purpose and Preconditions The base methodology elaborated on cases, where the services provided by BSP are already captured as business process models. To do so, the base method analysed the variation aspects in the business process models and created context elements that influence the delivery of the capability. To summarize, the method emphasized the possible ways of offering capability based on business services that are modelled as business processes. However, our experience during the application of the base method has shown that not all of the services provided by SIV Utility Services GmbH were captured as business process models. One proof of this observation was the extensive use of the manual handling instructions, i.e. documents including case-based best practices on clearing a message. Handling instructions are textual descriptions that specify the way, how given failure conditions shall be cleared by the BSP. They are an indispensable part of the outsourcing contract between client and BSP. The instructions were supposed to support knowledge workers (or in terms of the CDD methodology business operators) at Utility Services, which was only to some extent possible due to following reasons. First the documentation was done on a textual level leaving room for different interpretations of solution implementation. Second, the low degree of formality did not allow automation of reoccurring tasks. Third and final, we identified imprecisely formulated best practices, which could have been identified if they would have been captured as business processes models. We generalize this observation in the first method extension and define ways of designing capability ready business services. By using the method, the BPO should be in the situation to develop capabilities for services, for which no business process models yet exist. Following preconditions must be fulfilled to apply the method extension: •

•

6

Method user has access to secondary data describing the workflows of the organization, the structures, roles and actors, goals and task allocations. Secondary data can include policies, service-level agreements, handling instructions, guidelines and best practices related to the subject under study, which has already been created in the enterprise for different purposes. Detailed descriptions of the business services and the service consumers exist.

https://www.gartner.com/doc/2740917/forecast-analysis-business-process-outsourcing, 07/2015

Last

access

125

CaaS


•

The business process models for the investigated service do not exist or not upto-date. If this is not the case, then the method user directly applies the context modelling method component for capability design (see section 3.2). Knowledgeable on the CDD base methodology introduced in D5.2.

•

4.1.1.2 Cooperation Principles Basically, the method extension involves the roles that have been defined in D5.2 “The Initial Version of Capability Driven Development Methodology”. In particular the business service operator, i.e. a knowledge worker in the SIV group context7, business service manager, solution engineer, solution architect as well as the capability analyst should be included in the application of method extensions. Based on our initial experiences of capability design the following competences should be possessed in order to use this method extension: • • •

Knowledgeable in enterprise modelling, specifically in business process modelling and goals modelling. Skills in elicitation techniques to identify and analyse relevant information in the respective business environment and to gather information from secondary data. Knowledgeable on the CDD methodology concepts introduced in D1.4 “Requirements Specification for CDD”.

4.1.1.3 Method Component: Capability Ready Business Services The process first capability modelling pathway introduced in D5.2 focused on the cases, where the organisations had pre-existing business process models that are used to implement certain services. On the contrary, during the method application we observed that BSP also provides services, which do not implement any business process models (cf. D2.2 for detailed explanation). Although following a procedure, the enterprise knowledge for such services was captured in form of textual specifications, yet no formal models were adopted for the implementation. As in D5.2, a capability is defined by specific business services, a defined application context for these business services and goals of the enterprise to be reached. In order to design the capability and its various application contexts, this method component first develops business process models based on the informal textual descriptions about the service provision as well as the enterprise goals. Then, the business models are further analysed to capture the variations in the business process models, which is essentially captured as a context model. Finally, the run-time adjustments are designed and implemented in response to the changing context and delivery performance of a capability. The procedure, concepts and notation of the method component are illustrated in Figure 4-1

7

Knowledge workers are highly trained BPO experts that handle complex cases. Knowledge workers primarily deal with tasks that require the assembly of disparate data types, ongoing collaboration across a broad range of personas, and interaction with a variety of knowledge bases in unstructured, semistructured and structured processes (Stavenko et al. 2013)

126

CaaS


Figure 4-1. Method Extension 1: Capability Ready Business Services 4.1.1.3.1 Important Concepts

In this section we shortly investigate the notion of services and then select a definition of business services. Furthermore, we present the general characteristics of the services and specify how the method component relates to them. Given many definitions of the term service, we identified some works that analyse definitions and derive important concepts from these analyses. (Sumita et al. 2012) collects service definitions from 15 papers and extracts 45 characteristics. The authors then define 3 groups, to which characteristics are related to, namely process, provision and value. Taken the definitions above, which are revisited in brackets in italics, provision implies the existence of a provider (economic entity) and a receiver (customers requesting a service). Process reflects the intangibility (competence), action (application of competence, delivering) and change of state in the situation of the receiver after being provided with the service (a change in the condition). Finally the value is associated with usefulness (benefit of another, delivering value). Likewise (Alter 2011) classifies the notion of service into three categories and provides for each category suitable definitions: • • •

Services as value creating activities that have certain characteristics Services as value creating activities that involve co-production by providers and consumers Services as any organized activities performed for the benefit of others

BPO services offered by SIV Utility Services GmbH relates to all these categories, whereas the first and second category plays a more important role. The certain characteristics stem from the application of the service in different environments, such as EU member and Non-EU states. This requires that the service provision is in line with the regulatory requirements, which are essentially captured in context models. The co-production aspect is caused due to the strong involvement of various market roles, such as grid access provider and balance supplier in the message clearing process, which act as the consumers of the BPO service provided by SIV Utility Services GmbH. Table 4-1 presents the important concepts used by the method component “Capability Ready Business Services”. Please note that the important concepts mentioned in Step 5 and 6 are listed in the respective parts of the context modelling method component (see section 3.4).

127

CaaS


Table 4-1. Important Concepts of the Method Capability Ready Business Services

Concept / Term

Explanation

BPO

Delegation of one or more Information Technology (IT) and labour intensive business processes to an external service provider that owns, administers and manages the selected processes (Dayasindhu 2004)

Capability

see Table 3-1

Goal

Goal is a desired state of affairs that needs to be attained. Goals can be refined into sub-goals forming a goal model. Goals should typically be expressed in measurable terms such as KPIs.

KPI

Key Performance Indicators (KPIs) are measurable properties that can be seen as targets for achievement of Goals.

Process

see Table 3-1

Business Service

see Table 3-1

4.1.1.3.2 Procedures Step 1: Analyse and model goals

Goals are used to model the intentional perspective of organizational design. In order to align the enterprise goals with the capability design, this step describes what the enterprise and its employees want to achieve or to avoid. If there is already an up-todate goal model, then the method user continues with Step 2. The input, objective, activities, output, tools and contributors of goal modelling has been already extensively discussed in D5.2, pp. 31, in Enterprise Modelling Method Component of the CDD methodology. Step 2: Select the service

In this step the capability analyst and the business service manager select the service and set the scope of the capability design. The selection of the service is related to enterprise goals and can depend on various factors, such as optimizing the services with high process costs, managing services that frequently change and require the adjustment of business processes or services where the co-production of the value with the customer is the highest. These stakeholder wishes have already been captured in the first step. A service may be composed of other services. Here, we distinguish between top-level and low-level business services (Andersson et al. 2009). Top-level services are service groups and low-level services realize top-level business services. To name an example, top-level services of SIV include Energy Data Management (EDM), Billing and End Customer services, which are provided by various subsidiaries of the company. A lowlevel service is called Change of Service Provider that relates directly to EDM and offered by the BPO subsidiary SIV Utility Services. Usually the top-level services are identified on the business model level (cf. D2.1). A requirement to execute this step is that the enterprise has clearly defined business services. If this is not the case, then the approach suggested in (Tohidi 2011) can be 128

CaaS


used to describe business services. Input • • •

Service portfolio and business models of the enterprise, such as structure models, value models or policy models. Goals model and KPIs Existing policies and standards

Objective The first step focuses on the selection of services for which the enterprise aims to possess a capability. Activities Following activities of this step are rather incremental than sequential: • •

•

Select a top-level service where BPO plays a central role. Identify the low-level service that satisfies the following service enhancers (SE)8: o SE1-Quality: Automated services have a certain level of quality whereas non-automated services might not continuously promise this level since they rely on human effort. Identify the service with the participation of the knowledge worker. o SE2-Time: Certain deadlines apply for the service provision. o SE3-Flexibility: The service is subject to change based on regulations or customer demands and offered in a dynamic environment. o SE4-Cost: Identify the service where the failure of provision causes high process costs or where the co-production of the value with the customer is highest. Select the low-level service which is only informally defined, i.e. the service must not be specified in a business process model.

Output Selected low-level service related to the goals of the enterprise and a tabular form illustrating the relation between the low-level service and service enhancers. Tools In this step no specific tools are required. Anything can be used for tabular representation to service descriptions. Contributors • • •

Business service manager and capability analyst to identify the services for which capabilities need to be designed Business analyst to support the method user in terms of low-level service identification Solution architect relating the service to the strategic goals

8

Service enhancers are success factors of business processes. The listed enhancers (time, quality, flexibility, cost) in this work have been identified as the fundamental factors (Andersson et al. 2009). The list can be extended in line with the other enhancers that are perceived to be important from the enterprise point of view.

129

CaaS


Step 3: Collect and analyse data related to service provision

(Friedrich et al. 2011) claims in his article “content management professionals estimated that 85% of the information in companies is stored in (…) an unstructured way, mostly as text documents”, which is in line with our experiences from the base method application. The authors conclude that texts such as policies, reports, forms, manuals etc. are relevant sources of information for the construction of conceptual models. Based on this assumption, the method user performs text-based fact elicitation in this step. Input Selected low-level service from step 2. Objective Collecting knowledge worker´s expertise and detailed description about the service provision, including the role of the service consumer (client, customer), tasks of the service provider as well as agreements between two partners. The main objective is creating a knowledge base and extracting data, which will establish the basis for the business process modelling in Step 3. Activities •

• •

•

Find and analyse secondary data related to selected service. The documents and/ or models should consist of instructions which are written informally comprising of the information about the workflow of service provision and allocation of tasks during the business process outsourcing. The textual documents can be policies, reports, forms, handling instructions etc. Update the information by interviewing related stakeholders and/ or arranging workshops (see Contributors). Extract the information that is closely related to the tasks of the business service operator. Focus on parts of the textual descriptions and/or models, where different variations for a service provision are required. Continue with step 4.

Output Textual information collected from the analysis of secondary data. The information is related to the processes that are executed during the provision of the selected service. Moreover, it provides detailed description about the service provision, including the role of the service consumer (client, customer), tasks of the service provider as well as the contractual agreements between two partners. Tools A tool supporting the tabular representation of procedures and activities. Contributors • • •

Business analysts that may point the relevant secondary data associated with the selected business service Business service managers, knowledgeable about the service provision Business service operators, who execute the tasks as specified in the service descriptions or policies.

130

CaaS


Step 4: Model business processes

Input Collected information from Step 3 serves as input to this step. Objective Business process management aims to increase the efficiency and effectiveness of enterprises by analysing and improving business processes. This step includes activities for creating formal models of textual descriptions, which are easier to understand and communicate. Moreover, formal models can assure the soundness of a workflow by eliminating the ambiguity of the informal textual specifications. Activities • •

The user transforms the textual description in BPMN manually. Validate the resulting models and update them if necessary. Here the main focus should be the gaps in the business process models due to the ambiguous definitions in the textual description.

Output Business process models of the selected low-level service in BPO Tools Eclipse BPMN2 Plug-in Contributors • •

Modelling experts, business analysts and business service operators to design and validate the process models Solution engineers to align the process models with the company specific BPMN and to implement the executable model into system

Step 5: Apply Context Modelling Method Component

A capability is defined by specific business services, a defined application context for these business services and goals of the enterprise to be reached. Based on secondary data consisting of textual descriptions, the first four steps specify the enterprise goals and services by modelling them as business processes. The fifth step adopts Context Modelling Method Component to specify the potential application context where the business service is supposed to be deployed. This specification also has to capture at what points in the business processes what variation will have to happen. The specification of the deployment contexts in which a capability can be used is captured in a context model. The input, objective, activities, output, tools and contributors of context modelling method component have been extensively discussed in section 3.4. This step simply uses the procedures supplied in the context modelling method component as well as the notions and important concepts. Step 6: Apply Run-time Delivery Adjustments Method Component

Capabilities are delivered in ever-changing contextual situations. The purpose of capability delivery adjustments is to alter capability delivery in response to the changing context and delivery performance without the need for redesigning the capability and CDA. 131

CaaS


The input, objective, activities, output, tools and contributors of this method component have been extensively discussed in the initial method version (see D5.2, pp. 72). To summarize, the method component first designs and models adjustments based on the context modelling method component, such as the specification of the value calculation for measurable properties as well as input parameters for Capability Context Platform (CCP). Then the adjustment logic needs to be implemented in CDT. Finally, the last method component, adjustment assessment and improvement, allows for altering the adjustment versions without taking the capability offline. 4.1.1.3.3 Notation

The “Capability Ready Business Services” method component uses BPMN 2.0 and CDT notation, as depicted in Figure 3-8. 4.1.1.3.4 Summary

The method extension “Capability Ready Business Services” emphasized the possible ways of offering capability based on business services that are not yet modelled as business processes. As motivated in D2.2, the requirement stemmed from the experiences made during the application of base methodology. We encountered services provided by SIV Utility Services GmbH which informally described the processes followed by a knowledge worker when clearing a message, for instance in form of manual handling instructions and other textual documents including case-based best practices. The “Capability Ready Business Services” method extension captures the procedures defining how to provide capabilities from the “informally defined” business services as a BPO and enumerates the important concepts as well as their documentation. In order to do so, the method focuses on analysis of secondary data related to the business service offered, such as policies, service level agreements, handling instructions, guidelines and best practices related to the subject under study. The informally defined data is extracted and transformed into a formal business process model in BPMN. In addition to that the process models are extended with context models and delivery adjustments. The method extension consists of 6 steps, whereas Steps 1, 5 and 6 reuse Enterprise Modelling, Context Modelling and Run-time Delivery Adjustments Method components respectively, which are extensively discussed in this document.

4.1.2 Method Extension: Prepare Local and Global Optimization In business process outsourcing, capability management does not only serve the purpose of increasing flexibility when adapting outsourcing services to new delivery contexts but also supports optimizing the service delivery in accordance to policies of the BSP and service agreements with the customers. This method extension contributes to this aim by providing a way how to balance between local optimization of services provided to a client and global optimization from a BSP perspective. The method extension is defined as a method component, i.e. the structure of this section follows the method description template developed in WP5 (Sandkuhl and Stirna, 2014). •

Section 4.1 Purpose and Preconditions: introduction to the purpose of the method extension and the preconditions required for using it

132

CaaS


•

Section 4.2 Cooperation principles: Competences, roles and organisation structures needed to use the method component Section 4.3 Method Component: the description of the actual method components consisting of important concepts, procedure and notation.

•

4.1.2.1 Purpose and Preconditions This section describes the purpose of the method extension and preconditions for using it. The focus of the method extension is on monitoring and optimizing a capability in business process outsourcing. In business process outsourcing monitoring of capability delivery primarily focuses on two different aspects which might cause capability adjustments: •

the business service provider has to make sure that the capability is provided in accordance to the contractual service-level agreement with the client. Typically, such agreements include maximum processing time for a business transaction, maximum waiting time before a business transaction is processed, capacity to provide for the client in terms of knowledge workers, etc.

•

internal policies and standards of the business service provider have to be met. Examples are the way to decide what business unit is responsible for a certain business transaction and in what order the cases have to be processed (dispatching), the quality assurance measures to be performed for each case, the targeted maximum processing time, average processing time or waiting time until processing.

Both aspects usually are reflected in performance indicators which ideally can be captured automatically in the runtime environment. Furthermore, the context model for a capability often reflects both aspects by including context elements mirroring the decision strategies. An advantage of the CDD approach of particular importance for BPO is the possibility to differentiate between different levels of monitoring during capability delivery. From a technical perspective, BPO frequently uses different installations of the capability delivery application (e.g. separate installations for clients with high volume of business transactions) which potentially are deployed on different technical platforms (e.g. in the computing center of the client, at the service provider’s premises or on cloud resources). Thus, the “local view” of each CDA installation and the “global view” of all local installations will have to be subject of monitoring and optimization. Furthermore, the BPO also is interested in additional views while monitoring, like all business transactions of a certain client, all business transactions of a certain category, the cases currently processed in a department, all cases delayed independently of the installation and service type, etc. The local view of each CDA installation usually is equipped with an own monitoring application (e.g. a business process activity monitor of the workflow engine used), but the global view and additional views cannot easily be provided as they require an aggregation and filtering of local view data on a higher level. Furthermore, an optimization strategy on global level might require modifications in the decision logic on local level and vice versa. With many local installations a manual intervention on either local or global level is too time consuming, i.e. dynamic adjustments require a technical integration of local and global level. In the CDD approach, CNA offers the possibility to establish a global monitoring and 133

CaaS


optimization level on top of local CDA installations with the additional option to not only use indicators captured in the runtime environments but also from other context sources, even outside the enterprise IT. However, if the subject of integrated local and global optimization is addressed, capability model and adjustment algorithms have to be prepared for this purpose, e.g. by reflecting the indicators required for optimization in context elements and different optimization strategies in appropriate context sets and ranges. The method extension proposed in this section is addressing the subject of capability modelling for integrated local and global monitoring and optimization. One of the aims in this context is to minimize the interventions in local systems. The issue of optimizing a set of systems with potentially different „local” strategies from a global perspective, i.e., for a “global” strategy, has been subject of study in operations research and production systems before. Often, the optimization problem can be expressed in a formal way, e.g., as optimization model, and established optimization approaches can be applied, e.g. linear optimization, mixed integer programming, network-based optimization or non-linear optimization. In this context, the method component aims at supporting problem analysis and development of the optimization model by identifying the required decision variables and restrictions. However, the actual development of the optimization model is not part of this method component, as this topic is already covered in existing literature. Independently of the actual optimization approach, there are different ways to implement the actual optimization in enterprise IT on local level (i.e. in CDA) and global level (i.e. in CNA). In the context of this method component, we consider two different approaches and support decision making on what approach to use: •

Global-as-local: assumes that the overall optimization requires changes in behaviour of the local system which requires information about the global situation

•

Local-as-global assumes that local systems adapt their behaviour using only information about their local situation and the overall optimization is done by coordinating the local systems on a global level.

Global-as-local typical would be applicable in the following situations: •

Implementation of specific strategies for overall resource usage which depend on actual situation of these resources

•

Strategies which require human intervention at central point

•

Strategies which require information not available at local systems

Selected situations when local-as-global is adequate are •

Low update frequency of global parameters, often in combination with high latency

•

High performance requirements for transactions, i.e. there is no possibility to suspend a process for receiving information from the central unit

•

Local status affects global optimization (e.g. rare kind of exception)

Implementation of global-as-local typically would either include that the local system asks the global system for instructions how to continue before proceeding with a business case, which technically is similar to a blocking remote procedure call. If nonblocking behaviour is required, the global system would have to update decision 134

CaaS


variables of the local system whenever there is a change in scheduling strategy. However, this is only adequate if the scheduling is not dependent on the individual case but the overall resource availability. In an implementation of local-as-global the local system typically decides independently of the global system but notifies the global system. The global system then will have to re-assign resources based on the notification information. Example When describing details of the method extension, we will use a running example which is introduced step-by-step when explaining the method component’s procedure (see section 4.3.2). This example is also summarized in the attachment. The example considers a business service provider offering a capability which includes two major variations V1 and V2. The required services for the two variations are performed by two organisation units A and B which have a need to achieve better load balancing between them. The use of the method component aims at (a) identifying the decision variables and restrictions for implementing workload balancing between organisation units A and B, and (b) at deciding whether local-as-global or global-as-local has to be implemented for V1 and V2. Preconditions The following preconditions exist for applying this method extension: •

For capability delivery different local systems are used, i.e. there are several CDA instantiations or several CDAs.

•

There is a need to improve or optimize operations of these local systems on a global level. CNA shall be used for this optimization.

•

The capability model including context model exists, i.e. for each BPO service the existing context sets are known.

4.1.2.2 Cooperation Principles This section briefly describes the organisational preconditions to be established before using the method extension. This includes both, the structures and roles within the team using the method extension, and the enterprise where the method component is applied. Since we propose an extension of the CaaS base methodology, the roles and stakeholders identified in the base methodology also apply for the extension and are taken from D5.2 (Bērziša et al., 2015). However, we additionally need to involve an expert regarding the local optimization. The so-called CDA expert knows how the monitoring of CDA currently is done, which optimization strategy is applied and what indicators are used for this optimization. Table 4-2. Stakeholders required for different steps of the method extension shows the steps of the method extension’s procedure (from section 4.3.2) and the stakeholders involved in each step. Table 4-2. Stakeholders required for different steps of the method extension

Steps of Method Extension

Stakeholders

135

CaaS


Capability Analyst, CDD Provider, Business Service Manager, Method Engineer Capability Owner, Business Service Information gathering Manager, Method Engineer Capability Owner, Business Service Extract desired Manager, Method Engineer, Capability decision logic Analyst Identify decision Capability Owner, Solution Architect, variables Method Engineer Decide on local-asglobal or global-asCapability Owner, Method Engineer local Implement local-asSolution engineer, method engineer global Implement global-asSolution engineer, method engineer local Scoping

The actual tasks of each stakeholder are described in the method component’s procedure description (section 4.3.2) in the subsection “Contributors”. 4.1.2.3 Method Component: Prepare Local and Global Optimization This section describes the actual method components and includes three parts: • • •

4.3.1 Important Concepts: overview to the terminology and important concepts used in the method extension 4.3.2 Procedure: describes the procedure of working, i.e. what steps to take for applying the method component 4.3.3 Notation: provides a recommendation how to document the results of the procedure which reflects the concepts used.

Figure 4-2 provides an overview to the method component. PREPARE3LOCAL3AND3GLOBAL3OPTIMIZATION

PROCEDURE Scoping

Informa2on3 gathering

Extract3 desired3 decision3logic

Iden2fy3 decision3 variables

Decide3on3localAasA global3or3globalAasA local

CONCEPTS Local3 System

Global3 System

Decision3 Variable

Implement3either3 localAasAglobal3or3 globalAasAlocal

NOTATION Excep2on

Business3 Transac2on

CDT

Textual3 representa2ons

TableAbased3 representa2ons

Figure 4-2. Method Extension 2: Prepare Local and Global Optimization 4.1.2.3.1 Important Concepts 136

CaaS


In this section the important concepts for the method extension are described. The method extension uses some of the concepts introduced in Deliverable 5.2, but also introduces the new concepts. Table 4-3 shows the relevant concepts from D5.2. Table 4-3. Concepts used in the method extension from D5.2

Concept / Term Context Element Value Range Measurable Property Rule Context Set

Explanation Parameterized factors that cause changes. These factors have attributes, measurable properties and value ranges. Boundaries of permitted values for a specific Context Element (D 1.4) Property of a particular Context Element that can be measured Constraints that hold in a certain context setting Set of context elements (D 1.4)

Example Weather [-40 °C, 50 °C], [1kmh, 200kmh] Temperature, Wind Weather information is only relevant in EU Countries. Context Set including weather and location information

Table 4-4. Additional concepts defined by the method extension

Concept / Term Local System

Global System

Decision variable

Explanation Set of computational resources required for delivering a business service for a specific context set whose behaviour is controlled by a set of parameters called the local context which is derived from information sources within this system. Computational resources can include different hardware and software systems. These resources are not necessarily dedicated to only one business service but can be used for several services. Global system: set of local systems whose operation jointly is subject to optimization. We assume that a global system is controlled by a set of parameters (set of parameters used for deciding on changes in behaviour and operations performing them. Global system can use operations on local systems). Note that global systems in other application situations could be considered as local systems, e.g. when optimizing all capabilities offered by a company for a client.

Example Workflow engine including business activity monitor dedicated to the business transactions for a specific client

Set of all workflow engines of those clients who run a specific business service

Variable whose value is required to make Backlog size decisions regarding optimization or change in behaviour on either local or global level 137

CaaS


Business transaction Exception

Processing activity in local system which is needed to process one business activity or data set Condition which was not planned or expected during processing of a business transaction

Processing of one message sent to the client Error in message processing: unknown message type

4.1.2.3.2 Procedure

This section describes the procedure to be taken for performing the method extension. This procedure includes the following steps: 1. 2. 3. 4. 5. 6.

Scoping Identify and gather relevant information Extract desired decision logic Identify decision variables Decide on local-as-global or global-as-local Implement either local-as-global (6 a) or global-as-local (6 b)

Step 1: Scoping

Input •

Optimization potential observed in everyday practice which triggered the use of the method extension

Objective •

to decide for which capability or capabilities local or global optimization shall be prepared

Activities a) Document the reasons that triggered the wish for optimization. Examples: Is this wish rooted in optimization of resource use in the organization, triggered by demand from client side, driven by the need to lower costs for service provisioning? b) Identify the capabilities related to the observed optimization demand. c) If more than one capability has been identified, the method extension should first be used for each identified capability and afterwards for related capabilities. Select the capability which shall be subject of consideration by the method extension. Output •

capability which will be subject of preparing local and global optimization

•

documented reasons why this optimization is triggered

Tools •

text processing tools for documenting the motivation

Contributors •

capability owners who see a need for optimization 138

CaaS


•

business service manager who has an overall view across capabilities regarding the economic and service level perspective method engineer who documents scope and motivation

•

Example •

A business service provider (BSP) offers capabilities to clients which partly use the same resources (computing systems, personnel working on business transactions, software platforms, etc.). Thus, the optimization of resource use is important for the BSP within each capability and sometimes even across capabilities.

•

The capability owner decides that the capability “message clearing” will be subject to analysis as there is an optimization demand regarding the resources used for this capability. This capability currently has two major variations, each of them provided to several clients with different local systems. The capability is called “message clearing”. Its purpose is to process large amounts of messages sent to the clients of the BSP i.e. the example requires mass data processing. Each message contains as “payload” a business transaction, which has to be extracted from the message, processed in the client’s local system and confirmed by replying to the sender upon successful completion. In this context, the BSP takes care of errors and exceptions (in case there are any) during processing of the message.

•

The two variants we consider in our example are for two different message types. Most of the clearing process is identical for both message types but a few process steps are different, i.e. there are some specific process steps for each message type which constitute the variants. The underlying business processes for both variations of the capability are modelled as business processes. The resulting process model can be executed in a workflow engine and – in more than 95% of the messages and business transactions – can be completed in a fully automatic fashion without human intervention. However, if inconsistencies in the messages’ payload or in processing of the business transaction occur, exception handling by a so called “knowledge worker” is required. Depending on the agreement with the client, this knowledge worker either is an employee of the client or – most commonly – of the BSP.

Step 2 Identify and gather relevant information

Input • •

capability owners who see a need for optimization business service manager who has an overall view across capabilities regarding the economic and service level perspective

Objective •

To gather all relevant information required for the analysis process. This includes earlier analysis results, in particular from capability modelling, contractual agreements with the client, internal policy documents and ideas about potential optimization strategies

139

CaaS


Activities a) If capability modelling or context modelling was performed earlier, get access to the modelling results. b) Get the contractual agreements with those clients who use the selected capability. From the contractual agreements, the service-level agreement and penalties included (if any) are most relevant. c) If existing, get internal policy documents or information about the internal strategies regarding resource use and resource optimization. d) Interview the capability owner and capture existing ideas regarding potential optimization strategies. Output •

Collection of models and documents relevant for the analysis process including capability models, context models, service-level agreements, policy documents and potential optimization strategies.

Tools •

No specific tools provided.

Contributors •

•

capability owner, business service manager and capability analyst who have access to required models and documents and can contribute to optimization strategies method engineer who collects the relevant documents for use in the future process

Example •

Capability model / context model: The context model for the capability is shown in Table 4-5.

•

Policy information / work organization: If the BSP is handling exceptions in the first variation (V1) the knowledge workers from organisation unit A are responsible. For variation 2 (V2), organisation unit B is taking care of the exceptions. As the exceptions from V2 are related to those of V1 but V2 exceptions are far more complex, the knowledge workers from organisation unit B would also be qualified to work on exceptions from V1, but not vice versa. Balancing of work load between the two units currently is not optimal as no overall view on global level is available. If the capability owner has the impression that organization unit A has too much work and the organization unit B has free capacity, work is redistributed from A to B until B starts to complain.

•

Service-level agreements: For V1, the service-level agreements with all clients uniformly state that up to 50 exceptions per working day will be handled by the respective client with own personnel and more than this until the upper level of 200 has to be managed by the BSP. In case there are more than 200, the exceptions will be handled by the client again, unless the client changes the upper limit. In V1 all exceptions are sent by the local system to the task 140

CaaS


management system of organisation unit A or to the clients’ task management systems, i.e. in organisation unit A all knowledge workers pick their jobs from the same queue provided in the task management system. The BSP receives for V1 a flat-rate fee for handling the agreed number of exceptions. For V2, the service-level agreements with the clients are structured similar to V1. For V2 it states that up to 10 exceptions per working day will be handled by the client; each exceptions on top until max. 50 has to be managed by the BSP. In case of more than 50, the exceptions will be handled by the client unless the client changes the upper limit. All exceptions to be handled by the BSP are sent to the task management system of organisation unit B. For V2, the BSP receives a compensation based on the number of exceptions handled. The service-level agreement with two of the clients includes a penalty for each exception whose handling time exceeds a certain time limit. Table 4-5. Context elements extracted from the context model

Context Element Operating platform

Measurable Property kVASy deployment

Context Element Range {data center, customer}

cloud,

Schedule (planned BSP knowledge worker capacity per date {low, average, high} availability and org. unit) Market role

Role segment

{grid access provider, balance supplier, MDC, MOp, consumer}

Message exchange format Format segment

{MSCONS, UTILMD}

Process subtype

Subtype segment

{VL, LG}

Message version

Version segment

{2.2a, 2.2b, 5.0, 5.1}

Backlog threshold

Backlog size

[0-5]

Exception type

BAM notification

{list of exception types}

Business Service

Process type

{list of business services}

Step 3: Extract desired decision logic

Input •

Collection of models and documents relevant for the analysis process including capability models, context models, service-level agreements, policy documents and potential optimization strategies.

Objective • •

To draft an idea how the desired optimization could be reached To prepare the identification of decision variables needed for implementing the desired decision logic 141

CaaS


Activities a) Analyse the service-level agreement for penalties to be avoided or reward to be achieved. What be an appropriate decision logic to avoid the penalties or secure the rewards? b) Analyse the resource use during business service provisioning. What are the most scarce and most critical resources? Which are the most expensive resources, i.e. which resources have to be used most economically? What would be an appropriate decision logic to protect the resource or facilitate economic and efficient operation? c) What are the inter-dependencies between different capabilities, different clients or context ranges in the capabilities? How can these inter-dependencies be used for optimization, i.e. what would be the decision logic to be used? d) If any of the activities a, b or c result in a decision logics or ideas for a decision logic, document them. Output •

Desired decision logic documented as text document or in a formalized way.

Tools •

text processing tools for documenting the desired decision logic


capability owner, business service manager and other stakeholders in the organisation who can contribute to defining the desired decision logic method engineer who documents the desired decision logic

Example •

•

The desired optimization for V1 is as follows: IF the sum of jobs in the task management queue is higher than what is the capacity of organisation unit A for a given time period AND organisation unit B still has capacity available THAN the dispatcher on duty asks organisation unit B to also work on exceptions of V1 OTHERWISE additional resources have to be called in by the dispatcher for the next shift. For V2 the capability owner puts the priority on avoiding penalties with at the same time optimizing resource use in organization unit B. The wish of the capability owner is to assign priorities to exceptions, i.e. each exception should get a priority number. The priority number is calculated using the average waiting time and the contracted maximum processing time agreed on with the client.

Step 4: Identify decision variables

Input •

Desired decision logic documented as text document or in a formalized way.

Objective 142

CaaS


•

To identify the decision variables needed for implementing the desired decision logic

Activities a) Identify decision variables for the local systems Go through the list of context elements. If a context element is required for decision making in the local system, put the context element in column A and the measurable property in column B of Table 4-6. The resulting list in column A of this table is the initial list of local decision variables. Go through all decision variables in column A. Note down in column C if a decision variable is captured in the local system or not. Revisit the desired decision logic from step 3. Is all information required for decision making represented by the decision variables in column A of Table 4-6? If this is the case, continue with 4 b). If the missing information is captured in the local system, add a decision variable to the list. If the missing information is captured on global level, activity 4 c) has to be performed after finishing 4 b). Table 4-6. Support for identifying decision variables

A Decision variable

B Measurable Property

C Captured in the local system?

Enter context elements in this column which are Enter measurable Enter YES or NO required for decision property here here variables b) Identify decision variables on global level Go through the list of context elements. If a context element is required for decision making on global level – either as it is or as part of a calculation, put the context element in column A of a second table which is structured as Table 4-6. The resulting list in column A of this table is the initial list of global decision variables. Go through all decision variables in column A. Note down in column C if a decision variable is captured in the local systems or not. Revisit the desired decision logic in step 3. Is all information required for decision making represented by the decision variables in column A? If this is the case, continue with step 5. Otherwise continue with activity 4 c). c) Add missing information for decision making This activity only has to be performed if either activity 4 a) or activity 4 b) showed that some information for decision making is not represented in the context model. As this information has to be evaluated in CNA, it has to be added to the context model. Use the context modelling component to model the required information as part of the context model. Afterwards, repeat activity 4 a) and 4 b) in order to complete the initial tables from the first iteration with the missing decision variable(s). 143

CaaS


Output •

Decision variables required in local systems

•

Decision variables required on global level

•

Information about the sources and dependencies about the decision variables

Tools •

Table structure shown above in steps a, b and c (e.g. Table 4-6)


capability owner and solution architect who know about sources for decision variables and their inter-relationships method engineer who documents the decision variables

Example •

The results of steps a to c are shown in Table 4-7 to Table 4-10 below. The preliminary results of the different steps are in more detail shown in the attachment.

Table 4-7. Decision variables in the local system for V1

Decision variable

Measurable Property

Captured in the local system?

Backlog threshold for the Backlog size exception leading to V1

YES

Exception type

YES

BAM notification

Table 4-8. Final list of decision variables for V1 on global level

Decision variable BSP human resources

Measurable Captured in the Property local system? Schedule (planned capacity per date NO and org. unit)

SUM of the backlog sizes of all local systems for Backlog size the exception leading to V1

YES

Exception type

YES

BAM notification

Task management data (current number of tasks Current workload in BSP NO and average processing time per org. unit) 144

CaaS


Table 4-9. Final list of decision variables in the local systems for V2

Decision variable

Measurable Property

Captured in the local system?

Backlog threshold for the Backlog size exception leading to V2

YES

Exception type

BAM notification

YES

Processing priority

Calculated based on maximum processing time, NO average processing time and current workload at BSP

Table 4-10. Final list of decision variables for V2 on global level

Decision variable BSP human resources

Measurable Captured in the Property local system? Schedule (planned capacity per date NO and org. unit)

SUM of the backlog sizes of all local systems for Backlog size the exception leading to V1

YES

Exception type

YES

Maximum time

BAM notification

SLA information processing (for each exception NO type and client: max. hours)

Average processing time

operations average (for each exception NO type: average processing time)

Task management data (current number of tasks Current workload in BSP NO and average processing time per org. unit)

Step 5: Decide on local-as-global or global-as-local

Input 145

CaaS


•

Decision variables required in local systems

•

Decision variables required on global level

•

Information about the sources and dependencies about the decision variables

Objective •

To decide whether local-as-global or global-as-local should be implemented

Activities If one of the decision variables for local systems (for the example listed in Table 4-7 and Table 4-9) is not captured in the local system, global-as-local has to be implemented. In this case continue with step 6a. Otherwise, local-as-global can be implemented which requires step 6b. Output •

Decision that local-as-global or global-as-local has to be implemented

Tools •

No specific tools

Contributors •

capability owner and method engineer

Example •

For V1, all decision variables required in the local systems are captured locally. This means that step 5 “implement local-as-global” has to be performed.

•

For V2, not all decision variables in the local systems are captured locally. Thus, step 6 “implement global-as-local” has to be performed.

Step 6a: Implement local-as-global

Input •

Decision that local-as-global has to be implemented

Objective •

To design the way of implementing the capturing of decision variables and the communication between local system and global level

Activities a) Define the way the local system is providing the required measurable properties to the global level. This could be by defining a context source connected to the local systems or by defining a direct communication link. b) Specify and implement the way defined in a). This specification and implementation is out of the scope of this method extension. c) Define the decision logic as adjustment algorithm in CNA. The way to this is defined as a separate method component. 146

CaaS


Output •

Decision logic implemented in CNA

•

Communication between local system and global system defined and implemented

Tools •

No additional tool support than what is provided by the method component for defining the adjustment algorithm

Contributors •

Solution engineer and method engineer

Example •

Optimization for V1 happens on global level, which means that the local decision logic remains unchanged. The only activity related to the local systems is to register for each local system a context source which provides the measurable properties “backlog size” and “BAM notification” whenever an exception in the local system occurs. These two measurable properties are required on global level.

•

On global level, the desired decision logic identified in step 3 has to be coded as adjustment rule in CNA using the context elements corresponding to the identified decision variables.

Step 6b: Implement global-as-local

Input •

Decision that global-as-local has to be implemented

Objective •

To design the way of implementing the capturing of decision variables and the communication between local system and global level

Activities a) Define the way the local system is receiving the information relevant for the local decision variable from the global system and for providing the required measurable properties to the global level. This usually requires a direct communication link. b) Specify and implement the way defined in a). This specification and implementation is out of the scope of this method extension. c) Define the decision logic as adjustment algorithm in CNA. The way to this is defined as a separate method component. Output •

Decision logic implemented in CNA

•

Communication between local system and global system defined and implemented 147

CaaS


Tools •

No additional tool support than what is provided by the method component for defining the adjustment algorithm

Contributors •

Solution engineer and method engineer

Example •

The analysis showed that the optimization for V2 cannot happen only on global level but also affects the local systems due to the required priority calculation. For our example, we decide to implement this using a publish-subscribe mechanism:

•

The priority value for each client is calculated on global level as soon as new information is available. Whenever there is a change in the priority value, the value is published together with the client number. All local systems subscribe to the publish service and receive the update upon change

•

On global level, the desired decision logic identified in step 3 has to be coded as adjustment rule in CNA using the context elements corresponding to the identified decision variables.

4.1.2.3.3 Notation

The method extension does not define a specific notation. For context modelling, the notation defined in the context modelling notation component is applied. For all information captured in this method extension, either textual or table-based representations are used.

4.1.3 Method Extension: Evolutionary Development of Capabilities Delivered as Software Service Bundles Software-service bundles (SSB) are combinations of software products and services aimed at providing packaged offerings for specific applications. Software vendors provide these solutions to their clients. These services have different configurations with regards to functionality provided. Vendors have a wealth of information about their software used by other clients. That includes contextual information describing unique operating circumstances of the client as well as information about performance achieved by using specific configurations of the solutions. Vendors and clients can collaborate for finding the right configuration for every client on the basis of sharing historical context and performance data. This way every client would receive a configuration appropriate for its operating context as well as some estimates of expected performance of the solution. The method extension is a generalization of the collaborative data exchange capability described in D2.2. The method extension also focuses on evolutionary development, which implies that the capability delivery solution is developed in step-by-step manner in response to capability delivery monitoring results. The method component relates to existing research on selection of packaged applications and version management. Jadhav and Sonar (2009) reviews methods for 148

CaaS


selecting the packaged applications. The multi-objective approach allows for comprehensive evaluation. However, the existing methods are geared towards to comparison of different vendors. The selection tends to be based on the generic set criteria and the alignment of these criteria with business needs is not ensured. Capilla et al. (2014) describes methods for designing different versions of business software depending on the application context. These works focus on software architecture and design issues rather than the software management decisions. Evolutionary development is also one of the key techniques used in software engineering (Sommerville 2015) and it focuses on the operational level evolution of atomic development requirements. 4.1.3.1 Purpose and Preconditions The vendor offers its clients a software-service bundle S. SSB consists of a software product, know-how and supporting services ranging from helpdesk to business process outsourcing. S is designed in a way to deliver desired performance in different contextual situations, i.e., the vendor possesses the capability of providing the softwareservice bundle. S is provided in one of N configurations Oi ,..., ON and the configurations differ by their price (they are ordered ascendingly starting with the lowest costs configuration). Delivery of S depends on M context factors C1 ,..., CM and its performance is measured by L key performance indicators K1 ,..., K L . Combinations of values of the context factors yield a context situation describing specific solution delivery circumstances. It is assumed that certain configurations provide better performance for specific context situations than other, i.e., they are better suited for these context situations. For instance, a configuration including an outsourcing service works better in the case of highly variable demand for troubleshooting services. There are P clients using one of the configurations. It is assumed that existing clients have an incentive to share anonymized values of context factors and key performance indicators (KPI) during operations of the software-service bundle. Two decision-making challenges are: 1) to select appropriate configuration for a new client; and 2) to upgrade configurations used by existing clients in the case of changing circumstance or unsatisfactory performance. In the former case, selection is performed by matching a context situation of the new client with context situations supported by the vendor of the software-service bundle. In the latter case, an existing client switches from one configuration to another to adapt to changing circumstances. 4.1.3.2 Cooperation Principles The roles and stakeholders identified in the base methodology apply for this method extension, which are extensively described in D5.2 (Bērziša et al. 2015). 4.1.3.3 Method Component: Evolutionary Development The method component is concerns both design time and run-time issues of the capability driven development. It relies on the capability meta-model as its conceptual basis. The method component overview is shown in Figure 4-3.

149

CaaS


Figure 4-3. The overview of evolutionary development method component 4.1.3.3.1 Important concepts

The vendor offers SSB to its clients. SSB comprises general competencies possessed by the vendor. Even though SSB is designed with respects to customer requirements, it is not explicitly aligned with specific circumstances faced by individual clients. By using the capability driven approach, SSB has been contextualized in alignment with specific delivery goals. Possessing the capability backs the vendor claim of being able to service the clients in different circumstances. A capability is said to be suitable for a range of context situations, for which the vendor possesses the capability. The capability can be delivered in different ways for particular clients, i.e., appropriate components of the business service are packaged according to the requirements. This specific combination of the components is referred as to a capability delivery solution. Some of capability delivery solutions deemed as, e.g. commercially viable, are offered as out-of-box solutions. The summary of the most important concepts for evolutionary design is provided in Table 4-11. Table 4-11. Concepts used in the method extension

Concept / Term Vendor Client

Explanation Example Vendor possesses a capability based on SIV SSB and offers capability delivery to clients A company procuring SSB from the Energy company vendor 150

CaaS


Concept / Term Delivery solution Design element Capability suitability

Explanation Example A part of the capability model describing Business process the actual capability delivery Different types of objects used in capability design (e.g., process variant, pattern, adjustment) The capability is suitable for the context element ranges specified in the capability design. Capability is suitable for the current context situation if context element values belong to the context element ranges.

4.1.3.3.2 Procedure

The vendor provides SSB based capability as a service. The capability can be delivered in various contextual situations and various SSB configurations are provided for these context situations. These configurations are provided out-of-the-box and an appropriate configuration is selected for a new client (Figure 4-4). The capability delivery performance is monitored using the indicators defined for the capability model. If performance targets are not achieved or context values venture outside the defined context element range, the capability delivery solution is adjusted. Potential adjustments are: 1) selection of a more appropriate out-of-the-box configuration; or 2) designing a completely new configuration using the capability delivery patterns. The capability monitoring and adjustment are performed cyclically and the capability delivery solution evolves according to the business requirements of the client. Define capability model

Create CSM

Engage new client

Select appropriate configuration

Deploy solution Change configuration

Update CSM Update capability model

Monitor delivery Goals not achieved Context has changed

Figure 4-4. The evolutionary capability development process

The vendor develops its out-of-the-box capability delivery configurations on the basis of its expertise and historical data. The configuration can be suitable for various contextual situations. The vendor continuously updates the out-of-the-box configurations to include support for new context situations. The client selects the capability delivery solution to performance and cost objectives. In the case of business information exchange capability provided by SIV (see D2.2), the context elements describing SSB are summarized in Table 4-12. The main information exchange goals are timely data processing, correction of data exchange errors as well as cost minimization and efficient utilization of resources involved in the information exchange process. These goals are measured by the corresponding KPIs. For instance, the timely information processing goal is measured as the processing time KPI.

151

CaaS


Table 4-12. Context values and their context ranges

Context element

Context element range

Processing load (CPL)

Low, medium, high

Processing load volatility (CLV)

Low, medium, high

Backlog (number of messages waiting for 0…1000 processing) Calendar (scheduled hours for human 0…100 resources)

Step 1 Create Capability support matrix

Capability support matrix shows expected context situations and the corresponding capability delivery mechanisms for addressing the context situations. The Capability support matrix is developed by the vendor as its strategic offering to the clients. For instance, if Processing load level is evaluated as low and Load volatility is evaluated as Low, the vendor offers using the manual processing of messages as the most efficient solution. The capability support matrix is developed on the basis of historical data analysis or according to judgement of the vendor. As an example in the case of the information exchange capability, three configurations are offered to clients: O1 – manual processing of information exchange exceptions; O2 – automated processing of information exchange exceptions; and O3 – combination of automated processing of information exchange exceptions with availability of exceptions handling outsourcing services. Input • •

Software, service bundle – software, services and knowledge possessed by the vendor and offered to its customer. Capability design – capability design showing goals and SSB dependency on context.

Objective •

To evaluate coverage of the capability delivery design with respect to potential capability delivery context situation.

Activities a) List capability selection context elements and their values. The capability design includes all context elements affecting the capability. Some of the context elements are used for run-time capability delivery adjustment while others affect the capability design at the strategic level. This activity selects the context elements affecting the strategic decisions and serving as differentiators among the capability delivery solutions. b) Name configurations of SSB.

152

CaaS


c) Mark configurations used for particular context values. The correspondence among configurations and the context values is established. d) Identify context situation and corresponding configuration. The potential context situations are developed by generating all possible combinations of the context element values (CS1 ,..., CSL ) = CR1 × ... × CRN , where CS denotes context situation and CR denotes context ranges. Table 4-13 shows a sample capability support matrix. The context elements and their values are listed in rows, and the configurations are listed in columns. The corresponding cells are marked if the process variant addresses the given context value. If a context situation is not supported by any configuration then the capability is not deemed as suitable for this context situation. Table 4-13. Capability support matrix

Processing level

load Load volatility

O1

O2

O3

Low

Low

1

Low

Medium

1

Low

High

1

Medium

Low

1

Medium

Medium

1

Medium

High

High

Low

High

Medium

1

High

High

1

1

1 1

1

Output •

Capability support matrix

•

List of potential context situations and the configurations supporting these context situations.

Tools • •

CDT Spread sheet



Step 2 Select SSB configuration

The SSB configurations are offered to potential clients. A new client selects the 153

CaaS


appropriate configuration according to its context situation. Only context elements relevant to setting up the information exchange capability are used for these purposes. The context element values for a new client are evaluated using expert judgment or by analysis of available data for evaluation of the context element value from measurable properties. For example, the new client’s context situation is (Processing load level = low, Load volatility = low). Therefore, the configuration O1 is chosen. Input • •

List of SSB configurations Customer requirements

Objective •

To select initial capability delivery SSB configuration according to the customer requirements

Activities a) Definition of the client context situation. The context situation is defined by analysis of the customer requirements. The context element values are assigned either directly or by using measurable properties deemed suitable for the client. The clients can have different measurable properties for the same context elements. These measurable properties are used to calculate context element values. b) Selection of the configuration. The client context situation is matched with the context situations defined for different configurations. The most lightweight configuration meeting the requirements is selected. c) Deployment of the selected configuration. The selected configuration is deployed following the business service deployment procedures used by the vendor in accordance with procedures used by the client. Output •

Deployed capability delivery SSB configuration

Tools • • • • •

CDT CNA CCP Spread sheet Business service implementation and deployment tools

Contributors • • •

Business analyst Capability analyst Solution engineer

154

CaaS


Step 3 Capability delivery monitoring

The client uses the initial configuration and performs capability delivery performance monitoring. If context situation changes or delivery performance targets are not achieved then adjustment of the capability delivery is considered. The adjustment can be performed in an evolutionary manner implying that new features are added at every stage of development as necessary. The method extension uses the monitoring principles also described in Section 3.6.5. Input •

Deployed capability delivery solution

Objective •

To discover a need for capability delivery adjustment in the case of changing context situations and delivery non-performance

Activities a) Capability delivery performance evaluation. The capability KPI are monitored using control charts. If performance does not meet the expected targets then capability adjustment is considered. The reasons of non-performance are analysed using enterprise management and performance evaluation methods. These can be due to client’s internal inefficiencies or inappropriate capability delivery SSB configuration. In order to identify inappropriate configuration the performance monitoring results are compared to context monitoring results. b) Monitoring of context situation. The context is monitored to identify deviations from the capability suitability range. The capability is referred as non-suitable if the currently observed context value does not belong to the context range. c) Identification of capability support violations. If non-performance and nonsuitability is observed then the capability redesign cycle is invoked. If nonsuitability is observed without detecting non-performance than capability delivery cloud be continued concurrently with exploring options for improving the capability design. Figure 4-5 shows a sample capability delivery monitoring results for the first stage. The message processing time is used as main performance indicator and there is a threshold value for the acceptable performance. Future values of the processing time are predicted by extrapolation of the current trends and taking into account future resource availability and calendar events. The company is also aware that new features of the capability delivery cannot be introduced immediately and there is a ramp-up time for adjusting the capability (even though some of the adjustments can be introduced in runtime). The monitoring results show that with a ramp-up time of new capabilities the processing time threshold could be exceeded and adjustment of the solution is highly desirable.

155

CaaS


120 100

Value

80 60

Processing `me

40

Processing `me threshold

20

Predicted processing `me Ramp-up `me

0 0

5

10

15

20

25

30

35

Time

Figure 4-5. Capability delivery monitoring results in the first stage

Output •

Monitoring results

•

Request for capability design adjustment

Tools •

CNA


Capability user Capability analyst

Step 4 Evolutionary capability design adjustment

Evolutionary capability design adjustment is triggered by the request for capability delivery adjustment received from the monitoring. Capability design adjustment requires going back to the design cycle and capability redeployment. A new capability delivery SSB configuration is either selected from the existing configurations or created anew if appropriate configuration is not available. Input •

Request for capability design adjustment

Objective •

To choose a capability SSB configuration suitable for delivery in the new context situation.

Activities a) Selection of a new capability delivery SSB configuration – the Capability support matrix is used to select a configuration with a matching context situation 156

CaaS


if available. That essentially accounts for returning to Step 2 having defined the context situation using the actual monitoring results. b) Design of a new capability delivery SSB configuration – if there is no appropriate configuration available in the Capability support matrix then a new configuration is developed. Two situations are distinguished: 1) context situation is known in the capability design but not supported out-of-box; and 2) context situation is not known in the capability design. In the former case, the core of the capability design remains the same and a new configuration is created. In the latter case, the capability redesign is required. In the example, the new context situation evaluation yields that the context element Processing load level is predicted to assume value Medium what is not supported by the initial capability delivery configuration. The company decides switching to O2. However, predictions show that service level violation could occur in future. None of the configurations available are deemed appropriate for dealing with further increases in the processing time. Therefore, a configuration is designed by using the patterns as described in method components Section 3.5. Output •

Deployed capability delivery solution

Tools • •

CDT Pattern repository


Capability analyst CDD provider

4.1.3.4 Summary The evolutionary development method extension helps organizations to design capabilities and to select appropriate capability delivery solutions. It provides a solution for managing multiple versions of SSB offered by software vendors to a range of clients. The evolutionary development example is presented in Grabis and Sandkuhl (2016). The paper also reports an evaluation of the method component.

4.2 Capability Relationship Analysis and Modelling from a Strategic Perspective A business capability is related to the business goals and the context within which it exists. A business analyst, especially in the situations where one organization collaborates with others to deliver value, i.e. an analyst working with partners, needs to have a conceptually clear view of what might constitute a capability so that a revealing dialogue with partners may take place in order to ensure that the capabilities are identified, information about them is recorded, and finally an initial model is built and 157

CaaS


validated by the partners. This motivates the need for a capability collaboration concept in order to be able to express the possible relations among the different business capabilities within a company. In the context of collaboration there is a need to distinguish between internal capabilities and external capabilities. The details of external capabilities owned by some other enterprise may not be important to know, or indeed as will probably be the most common case - may never be known, since such capabilities are considered as competitive advantage to the owner’s enterprise. What matters however, is that such an external capability is required in order to deliver an internal capability, i.e. capability of the organization for which the capability design is created. Hence it is of an importance to demonstrate the ownership of each capability. Organizations need to be supported in their efforts of analysing their capability portfolio in terms of what capabilities it currently possesses, i.e. is able to deliver, what capabilities it wants to deliver in the future, and it is able to achieve that. Hence a concept of capability status needs to be considered. To this end two method components (1) for capability relationship analysis, and (2) for strategic capability analysis have been proposed.

4.2.1 Analysis of Capability Relationships and Mapping to Delivered Services Purpose and Preconditions According to the definition as used in CDD, a capability is the ability and capacity that enable an enterprise to achieve a business goal in a certain context. Thus, a capability has a defined application context, and goals of the enterprise to be reached. Since the CDD methodology is focused on the notion of capability, this notion needs to be defined in such a way so as to assist analysts and modellers who, working with business stakeholders, can identify what is a relevant business capability and describe it in such a way so as to support the development process in an effective and efficient manner. In order to achieve this, there is a need to identify characteristics of “business capability” that would render identification and description viable. The preconditions for carrying out this method component are: •

Capability model in CDT

The purpose of this method extension is: • • •

To improve the design of capabilities To enrich the business analysis of capabilities To map capabilities to the delivered services of the company

Cooperation Principles The roles and stakeholders identified in the CDD methodology also apply for the extension and are described in deliverable D5.2. However, the involved stakeholders need to have certain competence when it comes to MDD. In Table 4-14, we list the stakeholders and their needed competence. Note that the stakeholder is described in D5.2. 158

CaaS


Table 4-14. Stakeholders required for the method component

Stakeholder

Competence

Capability analyst: Analyses information about Operate CDD analysis and capabilities and operating context, to predict identify capabilities evolution of the context and to take advantage of these predictions by providing new services or improving existing services. Capability provider: Responsible capabilities to the customer.

of

providing Knowledge of how the capabilities are delivered.

Method engineer: Person who has knowledge about Competence in the current CDD methodology and can tailor it for certain needs. use of CDD tools. Solution engineer: configures and carries out Competence in CDT tool business solution implementation, such as the extensive implementation implementation and configuration of IT system support. Solution architect: works closely with solution engineer to ensure proper implementation. Solution architect is the link between the needs of the business and the solution engineer.

Comprehension of the conceptual aspects of capability representation. Understanding of integration issues.

Method Component: Analysis of Capability Relationships The method component overview is shown in Figure 4-6, below. The procedure and main concepts will be elaborated in the following section.

159

CaaS


Analysis of Capability Relationships And Mapping to Delivered Services PROCEDURE Identify capability ownership

Explore the collaboration relationship among capabilities

CONCEPTS Composition relationship

Explore the composition relationship among capabilities

Map capabilities to delivered services

NOTATION

Collaboration relationship CDT

Ownership

Relation to services

Figure 4-6. Overview of the Analysis of capability relationships and Mapping to Delivered Services method component

Important Concepts A business goal is a desired state of affairs that needs to be attained. Goals can be refined into sub-goals forming a goal model. The goal model typically consists of a goal hierarchy with more strategic goals on the top and more operational goals below. According to the CDD approach a Goal requires one or several capabilities that help achieving it.

A business capability is associated with a specific owner. Within a certain case study as the i-Symbiosis example the owner of capabilities is the company itself. However, in a particular business situation there may be a multitude of owners and this is particularly important in the era of collaborating enterprises to understand how a business service may be delivered through a collaboration of capabilities. Collaborations with external capabilities (and indeed between internal capabilities, as one can assume) may exist; these should be modelled and analysed if one is engaged in a capability-driven development approach. Collaborations may be effected through shared procedures, exchange of information or common policy adoption. A business capability may be composed of other sub-capabilities. This assumption occurs from a more in depth analysis of capabilities whereas there are differences among capacities and abilities that deliver a capability and capabilities which when composed are delivering a different capability. Capabilities are describing the business structure of a company. The linkage among capabilities and services will depict how specific capabilities are utilized in terms of exploitation. Procedure Step 1: Identify capability ownership

Input 160

CaaS

•


Business analysis of the company.

Objective •

The objective is to classify capabilities into internal and external ones by specifying their ownership.

Activities a) Study the current business status of the company b) Identify capabilities. See section 3.2 for a detailed description on how to do this. c) Distinguish internal from external capabilities. An external capability may be identified as the capability that a company has to “borrow” or buy from a third company in order to deliver a specific service or product. d) Design ownership in the capability diagram Output •

Capability diagram with ownership marked

Tools CDT based syntax for depicting capabilities, extended with symbols for ownership. Contributors •

• Capability analyst and capability provider • Solution architect and solution engineer Example The following example (Figure 4-7) shows a model with ownership included. Owner: CLMS Capability S_CAP3

Capability S_CAP4

Application development capability

Continuous engineering capability

Owner: External partner

Capability E_CAP1

Capability E_CAP2

Semantic repository capability

Resource classification capability

Figure 4-7. Example of capability ownership, (see D3.2 for details)

Step 2: Explore the collaboration relationship among capabilities

Input 161

CaaS

• •


Business analysis of the company. Capability ownership, as defined in step 1

Objective •

The objective is to examine if there is a relationship of collaboration among different capabilities and specify the type of collaboration.

Activities a) Examine possible collaboration of capabilities After having defined the capabilities and their ownership, it is useful to depict how internal and external capabilities are working together. This is achieved graphically and conceptually through a collaboration connector. Collaboration may appear within the internal capabilities as well, since it is common that a company has to combine different capabilities to deliver various services. b) Identify type of collaboration (e.g. shared procedures, exchange of information or common policy adoption) c) Document the collaboration of capabilities including the collaboration in a capability diagram. The collaboration can be expressed as being specifically between two capabilities, or as a general collaboration between two owners. Output • Collaboration of capabilities diagram, see example in Figure 4-7. Tools Combination of: • CDT based syntax for depicting capabilities. • An extension of CDT to include the collaboration arrows. Contributors • Capability analyst and capability provider • Solution architect and solution engineer Example See an example of output in Figure 4-8. ownership is also included.

Note that in the figure the concept of

162

CaaS


Owner: CLMS Capability S_CAP3 Application development capability

Capability S_CAP4 collaborates

Continuous engineering capability

Owner: External partner

Capability E_CAP1 Semantic repository capability

Capability E_CAP2 collaborates

Resource classification capability

Figure 4-8. Example of collaboration of capabilities, (see D3.2 for details)

Step 3: Explore the composition relationships among capabilities

Input • Identified capabilities Objective The objective is to identify and analyse the set of capabilities that describe the business status of the company, with the use of decomposition concepts. Activities •

a) Analyse the main capabilities in depth b) Define sub-capabilities c) Design the capability diagram with composition connectors As concluded from the analysis, a company may possess different assets and knowledge which can be described as different and unique capabilities. In a further analysis though, it was noticed that a capability can be decomposed to different sub capabilities which describe in a more comprehensive way how the company delivers and maintains their main capabilities. Output The capability diagram that depicts the composition of sub-capabilities to the main capabilities. An example is presented in Figure 4-9. Tools Combination of: • CDT based syntax for depicting capabilities. • An extension to depict composition. Contributors • •

Capability analyst and capability provider Solution architect and solution engineer 163

CaaS


Example The following figure (Figure 4-9) shows the result of applying composition in the iSymbiosis case.

CapabilityS_CAP1 Architecture Design

Capability S_CAP2

Capability S_CAP3

Capability S_CAP4

Domain Analysis

Application Development

Continuous Engineering

Capability S_CAP6

Capability M_CAP1

Capability S_CAP5

Cloud Migration

Adaptive and Extensible Software Development

Integration APIs Connectivity Infrastructure

Capability S_CAP7

Capability S_CAP8

Capability S_CAP9

Business Intelligence

IT Change Management

Software Development as a Service

Figure 4-9. Example of composition of capabilities Step 4: Map capabilities to delivered services

Input •

Capability diagram, with external partners

•

List of services/products that a company delivers

Objective The objective is to group and map the capabilities with the set of services offered by the company. Activities •

A business capability produces some business output (i.e. performed services, products, consulting). To this end, it is useful to correspond the identified set of capabilities and their collaborative relationships to the delivered services of the company. a) Examine the list of services. A company may have different delivered outputs. While examining the list is useful to classify the business outputs to services and actual products. For example, CLMS is mainly offers services which are the delivered applications created in zAppDev. However, they are also provide to the market zAppDev as a commercial product. b) Based on the set of capabilities already defined, explore which of them where used during the delivery of each of the services. The delivery of a service may require a set of capabilities in collaboration. Repeat for every listed service. c) Create a table depicting the mapping of capabilities to services. Output • A table depicting all the offerings related to capabilities. Tools 164

CaaS

•


No tools needed.

Contributors • Capability analyst and capability provider Example An example of this mapping table is presented in Table 4-15. Table 4-15. Example - mapping capabilities to services

Main Capabilities

Provided Services Financial Services Procurement Services Technical Services

Maritime management capability

Operational Services HR Services Chartering Services ISM Services Service of social networking-Forums API

Social networking capability

Service of Web-conference Advertising Service

Information management capability Maritime Compliance capability

Web privacy service Service of Unified DB Rule Compliance service

4.2.2 Strategic Capability Modelling Purpose and Preconditions A capability always is defined by some business goal and an application context, as well as it is delivered by some business process. In a situation of strategic planning we need to focus on strategic goals and analyse how they can be achieved on a fairly high level. At this level the details of exactly which patterns and business process variations will be involved may be unknown as well as they may be unimportant. What should be analysed is organization’s ability and capacity to reach its vision in general. Preconditions for carrying out this method component are the following: • • •

the overall vision of the organization is reasonably clear; a goal model describing organization’s vision is created. in cases of modelling capability collaborations with external partners their goal and/or capability structure should also be available.

Purpose of this method component is

165

CaaS


•

to create and document business goal alignment with capabilities on a strategic level, and to map capabilities among each other.

•

Cooperation Principles The roles and stakeholders identified in the CDD methodology also apply for this method component. The following stakeholders are to be involved: Table 4-16. Stakeholders required for the method component

Stakeholder

Competence

Business analyst: a person who analyses the business a person who analyses the models and proposes and guides changes in the business models and proposes business models. and guides changes in the business models. Capability analyst: Analyses information about Operate CDD analysis and capabilities and operating context, to predict identify capabilities evolution of the context and to take advantage of these predictions by providing new services or improving existing services. Capability provider: Responsible capabilities to the customer.

of

providing Knowledge of how the capabilities are delivered.

Customer (client): The end user who benefits from Provides the overall vision for the capabilities the capabilities analysed and feedback to the design. The way of working should be based on participatory stakeholder involvement with the main focus on capturing the knowledge, i.e. creating the model. Hence, simple tools for documenting might be useful and the team does not necessarily need to use the Capability Design Tool. It is also possible that while using this method component the developers may also switch to method component Capability Design in order to focus on detailed design of a selected capability.

166

CaaS


4.2.3 Method Component: Strategic Capability Modelling

Figure 4-10. Overview of the Strategic Capability Modeling method component

Important Concepts Capability. Capability is the ability and capacity that enable an enterprise to achieve a business goal in a certain context. Capabilities may be considered as internal capabilities and external capabilities. The details of external capabilities owned by some other enterprises. They have relationships with business goals of external partners. A Goal is a desired state of affairs that needs to be attained. Goals can be refined into sub-goals forming a goal model. Goals should typically be expressed in measurable terms such as KPIs. Other modelling components such as problems, opportunities, and causes may also be included in goal modelling. In case of modelling collaboration with external partners it is recommended that the goal hierarchies of the capability delivery organization and partners be clearly identified. Process. Process is series of actions that are performed in order to achieve particular result. A Process supports Goals and has input and produces output in terms of information and/or material. Context Set. Context Set describes the set of Context Elements including their permitted ranges that are relevant for design and delivery of a specific Capability. For this method component the links to Context Elements may be omitted, because they might be unknown at the time of strategic capability modelling. Procedure The procedure considers organization’s vision and its business partner goals as input. In case this information is unavailable, outdated, or likely conflicts are identified, method component Enterprise Modeling should be used for modeling of the strategy or the organization.

167

CaaS


Step1: Identify goals in the goal hierarchy

Input • •

Business analysis of the company and its business partners. Existing enterprise models

Objective The objective is to identify goals in the goal hierarchy that would be appropriate for motivating capabilities. Activities Goal hierarchies typically have strategic goals on the top and operational goals on the bottom. Many of the top goals are visionary statements and are refined into sub-goals. Those sub-goals that are formulated reasonably concretely and have specified KPIs should be considered for motivating capabilities. Output •

A selection of relevant strategic goals and areas of the goal model for further capability analysis

Tools •

Existing tools used for EM, and CDT

Contributors •

Business analyst

•

Capability analyst

Step 2: Analyse goal sub-hierarchies.

Input •

Relevant strategic goals and areas of the goal model for further capability analysis

Objective •

To analyse how the goal sub-hierarchies can be supported by capabilities and decide which goals should be supported by capabilities.

Activities Typically goals and sub-goals are further refined into more sub-goals in such a way that the overall goal hierarchy consists of sub-hierarchies each of them dealing with a particular aspect of the organization. Many sub-goals in principle are similar to the goals immediately above them in the goal hierarchy, i.e. they are expressed reasonably precise, have sub-goals on their own, and are linked to KPIs. These kinds of goals should be considered for motivating capabilities. Output •

Goals that should be supported by capabilities.

Tools •

Existing tools used for EM and CDT for documenting the goals for which capabilities should be designed. 168

CaaS


Contributors •

Business analyst

•

Capability analyst

Step 3: Define capabilities for the selected sub-goals.

Input •

Goals that should be supported by capabilities.

Objective •

To create initial capability definition for the selected goals. At this stage only capability name is to be created.

Activities There can be several capabilities supporting one goal. Hence, naming of capabilities should reflect the difference, e.g. for what context it is suitable. In the identification of capabilities, driving questions such as “What does the organisation do in order to achieve the goals?”, “What abilities does the personnel possess in order to achieve the goals?” etc. Output •

Goals and capabilities that support them

Tools •

CDT

Contributors •

Business analyst

•

Capability analyst

Step 4: Define context sets for each capability.

Input •

Goals and capabilities that support them

Objective •

To define context sets for each capability in order to outline the context dependence for each capability.

Activities At this stage the context sets can be expressed without explicit definition of ranges of context elements. This is permitted because identifying context elements can be done later by using Capability Design method component that requires analysing what measurable properties are available and can be monitored at run-time. Output 169

CaaS

•


Capabilities and context sets defined

Tools •

CDT

Contributors •

Business analyst

•

Capability analyst

Step 5: Identify external capabilities by analysing collaborations with external partners.

Input • •

Business analysis of the company and its business partners. Existing enterprise models of business partners

Objective •

To identify relevant capabilities of organization’s business partners with the organization’s capabilities need to be collaborating

Activities Consider partner goal hierarchies and analyse how partner goals are related to capability delivery organization’s goals. For the related goals repeat steps 1 to 4, in order to identify capabilities that are involved in business collaborations. If partner goal models are not available, analyse the overall business model and collaboration mode. Output •

Relevant capabilities of business partners involved in delivering organization’s capabilities.

Tools •

Existing tools used for



Step 6: Develop capability relationships.

Input •

Capabilities and partner capabilities from steps 4 and 5.

Objective •

To specify how the different capabilities are related amongst themselves and with capabilities that are provided by external business partners. 170

CaaS


Activities This can be accomplished by following method component Analysis of Capability Relationships. At this stage both internal and external capabilities are analysed. Relationships among capabilities are also specified, in terms of capability ownership if capabilities are delivered by external partners; capability collaboration if several capabilities are used to achieve goal; as well as, capability composition if a capability consists of smaller capabilities. Output •

Capability map depicting strategic goals and capabilities required by the goals.

Tools •

CDT



4.3 Integration of CDD and MDD This method extension describes how to extend organisation’s existing IT systems and development tools with CDD tools and methods that allow the analysis, design and monitoring of capabilities and their contexts. The extension aims to enable a coexistence between CDD Environment design and run-time tools, and existing software design tools. A key component of CDD is the use of graphical models, which is something it shares with Model Driven Development (MDD) tools and methods. MDD is an approach for software development where models of software systems are created in a formalized way, enabling automatic transformation of the models into an executable system. MDD puts the use of models as the central part of software production, i.e. models are design artefacts that need to be well designed, maintained, and delivered as part of the final product (France & Rumpe, 2007). In essence, MDD strives towards increasing the abstraction level of development by replacing software code as a development artefact with conceptual models. One of the benefits of modeldriven approaches is that developers are working on a higher level of abstraction and hence are able to produce more complex systems with less effort (Kleppe, et. al, 2003). Parallels can be drawn to the evolution of programming languages from assembly languages to modern high-level programming languages such as C# and Java. Some authors point towards the use of models for software development as the next step in this evolution (Lano, 2009) (Selic, 2003). The MDD tool used in WP3, the zAppDev tool, is an excellent example of an advanced MDD tool that can be used for a complete system implementation. The method extension “Integration of CDD and MDD” bridges between the CDD approach and MDD by proving guide of their integration. Just like MDD, CDD has models as a key component. However, the models used in CDD have a focus on describing capabilities, their contexts, goals etc., while models developed according to the MDD principles focus on components of software systems, such as, data objects, information management procedures, user interface components etc. CDD does not include specific methods and tools for the detailed creation of information systems. 171

CaaS


Thus, combining the CDD approach with MDD gives the possibility to have support for capability analysis and monitoring (provided by CDD) and the detailed implementation of information system (provided by MDD). In essence, MDD can be used to develop new Capability Delivery Applications (CDAs) in a way that is integrated with capability development.

4.3.1 Purpose and Preconditions The purpose of providing means for the integrated use of CDD and MDD is to leverage the strength of both approaches and to address the need for supporting the development of new CDAs without which CDD is mostly able to either support the configuration of existing CDAs or development of new software in conventional ways. As pointed out earlier, the benefit with MDD is that it allows development on a higher level of abstraction, which in turn leads to quality and efficiency gains. However, there are a number of challenges when it comes to making use of MDD to address business capabilities (Bērziša, S., et al, 2015): •

•

•

•

The gap between high-level business requirements and current MDD techniques. MDD approaches and tools still operate with artefacts defined on a relatively low abstraction level. For example, the CDD approach contains the use of goal model, which is commonly absent in MDD tools. Inability to model execution contexts. In dynamically changing business environments, modelling just a service providing business functionality in a limited context of execution is often not sufficient. High cost for developing information systems that are able to work in different business contexts. Developers, especially SMEs, have difficulties to market their software globally because of the effort it takes to adhere to localization requirements and constraints in the business context of where the software will be used. Limited support for adaptability in applications. The current context-aware and front-end adaptation systems focus mainly on technical aspects (e.g., location awareness and using different devices) rather than on business context awareness.

The CDD contains specific means, such as goal model and context models to address the above issues. Thus it is beneficial to combine them with MDD. The purpose of this method extension is: • • • •

To make it easier to combine CDD and MDD and use the resulting integration for development of CDAs. To make it possible to, on a case-by-case basis, outline the benefits of a combined CDD and MDD approach. To make it possible to discern which integration approach that needs to be in place for combined CDD and MDD use. To have a basis for the implementation of software components that bridge the CDD tools and MDD tools.

The integration of CDD and MDD is appropriate if an organisation intends to use CDD and MDD. In essence this requires that the organisation has an MDD tool in place. The component has thus the following precondition for use: 172

CaaS


• •

The concepts and use of the CDD should be well understood. An MDD tool should be in place, and its concepts and use should be well known.

This method extension furthermore relies on that the overlap of functionality between the CDD environment and the MDD tool can be understood, as well as that the organization has certain maturity in using both methodologies and tools. The analysis of this functionality overlap is supported by a separate method component in the extension, see section 4.3.4.

4.3.2 Cooperation Principles The roles and stakeholders identified in the CDD methodology also apply for the extension. However, the involved stakeholders need to have certain competence when it comes to MDD. In the following table (Table 4-17), we list the stakeholders and their needed competence. Table 4-17. Stakeholders required for the method extension

Stakeholder (from CDD)

Specific competence required for this method extension

Method engineer: Person who has Competence in the current use of MDD knowledge about CDD methodology and tools. can tailor it for certain needs. Business analyst: A person who analyses Basic understanding of MDD principles the business models and proposes and and how it is used in the organization. guides changes in the business models. Solution architect: works closely with solution engineer to ensure proper implementation. Solution architect is the link between the needs of the business and the solution engineer.

Competence in the technical implementation of the MDD and CDD tools. Ability to discern integration needs and risks thereof.

Solution engineer: Configures and carries out business solution implementation, such as the implementation and configuration of IT system support.

Capable of performing tool integration, in particular competence regarding information sharing and synchronization.

In addition to the above, the business analyst needs to be in close contact with the business service manager to get feedback on proposed changes.

4.3.3 Method Component: Selection of Integration Approach for CDD and MDD The method component overview is shown in Figure 4-11, below. The procedure and main concepts will be elaborated in the following section.

173

CaaS


Selection of Integration Approach for CDD and MDD

PROCEDURE CDD analysis

Select design time integration options

CONCEPTS Run-time integration

Design time integration

Select run-time integration options

Summarize integration support needed

NOTATION List of selected options

Figure 4-11. Overview of the selection of integration approach for CDD and MDD method component

4.3.3.1 Important Concepts Central to the use of this component is the concept of Model-driven development, MDD. The base for MDD is the increasing complexities of the tasks which software needs to perform, and the growing demand for shorter development cycles, that have exposed the limits of technologies that are based on traditional coding (Selic, 2003). Models are recognized as suitable candidates for increasing the abstraction level of development and for supporting the migration through different phases of development (analysis, design, implementation, etc.). They can be used to increase the quality, effectiveness, and reliability of software development (Selic, 2003). To exploit the full potential of automation, complete and functional programs should be generated from models. MDD refers to those emergent and model-centric development approaches, where models are essential parts. Models in MDD steer the development process and carry vital information in various forms. MDD enables developers to create abstractions of what needs to be built, or the problem domain, as opposed to abstractions of how it will be done, referring to high-level development platforms and languages, called the solution domain (Schmidt, 2006). Those abstractions, or models, help in filling the problem-implementation gap that separates the problem domain from the software solution (France & Rumpe, 2007). Models need to possess certain characteristics to be suitable for MDD, for example completeness (Sottet et al, 2008), executability (Henkel & Stirna, 2010), inexpensiveness (Atkinson et al, 2003), and understandability (Selic, 2003) (Henkel & Stirna, 2010) (Moody & Shanks, 2003). However, MDD includes more than just the models themselves. Meta-models, transformations between models, a process for creating and managing the models and their transformations, as well as tools to support the process, are all necessary for an MDD approach to serve its purpose (Kent, 2002). Meta-models are central aspects of MDD, since they enable the formal description of the concepts used in the models. As such, the meta-model provide a language in which models can be expressed. Concepts in the meta-model commonly have an associated graphical notation. For example, the meta-model may contain rules on how goals in a goal model can be related, while the associated notation describes how goals and their relationships are displayed. 174

CaaS


Transformations enable a controlled transition between the phases of the development process, moving from one abstraction to another, and adding or hiding details to make the design executable. When defined between models written developed in the same language, the transformations are based on the language of the models. However, when models are written developed in different languages, the transformations need to refer to the meta-models. As discussed in the section detailing the purpose and precondition of this method component, current MDD tools still exhibit some weaknesses when it comes to the representation of contextual information and adaptability. These weaknesses may be addressed by the integration of CDD with MDD. 4.3.3.2 Procedure This section details the procedure for performing the method component. It contains the following steps: 1. 2. 3. 4.

Perform CDD analysis, as defined in the CDD method Select design time integration option Select run-time integration option Summarize integration support needed

Step 1: Perform CDD analysis

Input •

The access to the CDD Environment and in particular the CDT tool for modelling

Objective: •

To model capabilities and their contexts.

Activities This step consists of applying the CDD method components to create a model of the capabilities and their goals. Note that the difference between global and local context elements and measurable properties is important. Output •

A model, or models, depicting the capabilities under study and their context in form of context elements and measurable properties.

Example: The following example (Figure 4-12) shows the result of performing the step for a case. The case contains one main capability and three sub-capabilities. Note that the goals and KPIs have been omitted from the example.

175

CaaS


Measurable Property 1 Locations of organizations in the current database

Capability 1

Context Set 1 measured by

Enabler of Web Industrial Symbiosis

Context Element 1

Context Element Range 1.1 Measurable Property 2 List of available transport means per location

measured by

Measurable Property 3 Number of org in the platform

Measurable Property 4

measured by

Relative availability of transport network information.

Context Element 2 Availability of transport option descriptions

0-100%

Context Element Range 1.2 Capability 1.1 0-100%

measured by

is affected by Determine relevance rating

Number of org that have transport information

Measurable Property 4 Local property: Match relevance

Measurable Property 5

measured by

Context Element 3

Context Element Range 1.3

Local context: Matching strength

Strong(>60%, RR11

…

RCJ > RR1J

…

…

…

…

CS CS

CS RC1 > RR1

…

CS RCJ > RRJ

Tools •

Spreadsheet

Contributors •

Capability analyst

Step 5: Analyze capability delivery capacity

The capacity evaluation results shown in the capacity evaluation matrix depend upon multiple of controllable factors including resource capacity, attributes and categorization of context ranges. The analysis is performed to discover the most significant factors and to investigate ways for expanding the capability delivery 199

CaaS


capacity. Input • • • •

Capacity evaluation matrix Context range definition Resources model Constants

Objective To test factors substantially affecting capability delivery capacity and to identify ways for expanding capability delivery capacity Activities Several types of studies are performed by changing values and concepts in the capability design and reevaluating the capacity evaluation matrix. • • •

Study of relationships between resource capacity availability and capability delivery capacity Study of relationships between the constants and capability delivery capacity Redefinition of context element range

In the first activity, the resource capacity is modified in a structured manner to identify resources having the most substantial impact on the capability delivery capacity. The results of this study suggest potential changes in resource capacity to expand the capability delivery capacity. In the second activity, the constants used in capacity requirements calculation are modified in a structured manner to quantify their impact on the capability delivery capacity. It is assumed that these constant characterize efficiency on the capability delivery solution and capability delivery capacity can be expanded by improving this efficiency. For instance, one of the constants characterizes effort multiplier describing additional effort needed to process complex incidents in the PMO case. If this multiplier could be reduced (e.g., by having better qualified support specialists), the capacity requirements are reduced. In the third activity, calculation of context ranges is redefined. If capability delivery capacity is insufficient for some of the range values, the range definition could be refined. For instance, if the context element Incident flow intensity has a range value CRIncidentFlow = (low, high ) and the capability delivery capacity is insufficient, then the range ' can split into CRIncidentFlow = (low, high, very high ) and the reevaluation could show that there are sufficient resources for the high level while an insufficient capacity for the very high level. If a lack of capability delivery capacity cannot be resolved by adjustments or other means, the capability design should be changed to exclude the corresponding range value because the company should be able to deliver capability for all context situations defined in the capability model. The capacity evaluation matrix can be perceived as a kind of decision table (Triantaphyllou, 2000) as methods used in the analysis of a decision table can be adopted for usage in capacity evaluation. Output •

List of factors substantially affecting capability delivery capacity 200

CaaS

•


Analysis of observations and suggestions for potential adjustments

Tools • •

CDT Spreadsheet


Business analyst Business service provider

201

CaaS


5. Summary and Conclusions This deliverable presents the final version of the CDD methodology consisting of a number of method components and method extensions supporting different aspects of the CDD process. More concrete, methodology components addressing how to get started with CDD, capability design, enterprise and business process modelling, context modelling, supporting reuse, as well as adjusting capability delivery at run-time have been developed. The CDD methodology is described according to three conceptual aspects of a methodology – (1) the modelling languages in terms of concepts and notations used to represent the modelling product, i.e. the models and capability designs created. (2) The way of working, the procedures and tools used, in order to arrive at a capability design of good quality i.e. the modelling process, as well as (3) the technical foundation and formal definition of algorithms for run-time adjustments of capabilities have also been elaborated. In the following table we revisit the initial vision and method requirements elicited in WP1 and documented in D1.4. The table below shows the activities and required method components, the use cases requesting the method components and the status of method component development. Table 5-1. Summary of method component vision of D1.4 and the Final Version of the CDD methodology

Activity

Required method components

Use case

Supported by method component

Capability and context modelling

M1. Method and meta-model for capability and context modelling

All

M2. Method for representing context dependence and points of variation

SIV

Capability Design Process; Context Modelling; Capability relationship analysis

All

Context Modelling; Runtime Delivery Adjustment

M4. Method, meta-model and tool support for pattern elicitation

All

Reuse of Capability Design

M5. Method for identification of the appropriate patterns for the given capability definition

SIV

Reuse of Capability Design, Evolutionary Development of Capabilities

M3. Method for evaluation of the context set from the given context elements Capability composition from patterns

M6. Method and tool support for SIV creating process variations using patterns

Reuse of Capability Design, Context Modelling, Enterprise Modelling

202

CaaS


Activity


Use case


Capability evaluation

M7. Method for static evaluation of the capability M8. Method for dynamic evaluation of the capability

EVR SIV

Context Modelling; Runtime Delivery Adjustment

Development of capability delivery application

M9. Method for automated development of CNA

FR

Subject to D6.3

Monitoring of indicators

Analysing context and predicting capability delivery performance

M10. Method for integrating of the EVR, capability development SIV, environment including CLMS integration of platform-specific constraints into patterns; integration of CDD methodology with business case specific methodology and integration of context indicator (specifications and measurement process) into patterns; integration of CDD methodology with context platform adaptation process

Reuse of Capability Design, Evolutionary Development of Capabilities, Local and Global Optimization, Runtime Delivery Adjustment, Integration of CDD and MDD

M11. Method for presenting the monitoring results

All

Subject of D6.3

M12. Method for context situation evaluation and predicting the capability delivery performance

All

M13. Method for identification and application of the capability delivery adjustments

EVR, FR, CLMS

Evolutionary Development of Capabilities, Runtime Delivery Adjustment

M14. Method for evaluation of the current context situation and matching it to the defined capability’s context set

All

Subject of D6.3

EVR

Evolutionary Development of Capabilities

M15. Method for predicting the expected capability delivery performances

Subject of D6.3

203

CaaS


Activity


Delivery adjustment

M16. Method for evaluation and invoking of capability delivery adjustment

Use case

Runtime Delivery Adjustment Capability Relationship Analysis, Evolutionary Development of Capabilities

M17. Method for detecting patterns addressing these change needs as part of the context monitoring in CDD delivery Capability update

Pattern update

M18. Method for identification and incorporation of new context elements into the capability design.


FR, EVR

M19. Method for updating and maintenance of the capabilities

All

M20. Method for refining and/or adding patterns to the patterns repository

SIV

Capability Relationship Analysis, Evolutionary Development of Capabilities , Local and Global Optimization, Capability Relationship Analysis, Evolutionary Development of Capabilities , Reuse of Capability Design

As it can be seen from the above table, all required method components have been developed and provided to the use cases. Furthermore, some activities can be performed in different ways which leads to support by different method components. Future work in the methodology work package (WP) until the end of the CaaS project will aim at providing the methodology documentation packaged in a better way for exploitation than in this project deliverable style.

204

CaaS


References Alter, Steven (2011): Making a Science of Service Systems Practical: Seeking Usefulness and Understandability while Avoiding Unnecessary Assumptions and Restrictions: Springer US. Available online at http://link.springer.com/chapter/10.1007/978-1-4419-8270-4_4/fulltext.html. Andersson, Birger; Johannesson, Paul; Zdravkovic, Jelena (2009): Aligning goals and services through goal and business modelling. In Inf Syst E-Bus Manage 7 (2), pp. 143– 169. DOI: 10.1007/s10257-008-0084-2. Atkinson, C., et al. (2003) Model-Driven Development: A Metamodeling Foundation. IEEE Softw 20(5): p. 36-41 Bērziša S., España S., Grabis J., Henkel M., Jokste L., Kampars J., Koç H., Sandkuhl K., Stirna J., Valverde F., Zdravkovic J. (2014a), Task 5.1 Result Report: State-of-theArt in relevant methodology areas, CaaS – Capability as Service for digital enterprises, project no 611351, caas-project.eu Bērziša, S., Bravos, G., T. Gonzalez Cardona, U. Czubayko, S. España, J. Grabis, M. Henkel, L. Jokste, J. Kampars, H. Koc, J. Kuhr, C. Llorca, P. Loucopoulos, R. Juanes Pascual, K. Sandkuhl, H. Simic, J. Stirna, J. Zdravkovic (2014b), Deliverable D1.4: Requirements specification for CDD, CaaS – Capability as a Service for Digital Enterprises, FP7 project no 611351, Riga Technical University, Latvia, caas-project.eu Bērziša, S., et al. (2015a) Capability Driven Development: An Approach to Designing Digital Enterprises. Business & Information Systems Engineering 57(1): p. 15-25. Bērziša, S., S. España, T. Gonzalez Cardona, J. Grabis, M. Henkel, L. Jokste, J. Kampars, C. Llorca, J.J. Roig Ferrer, I. Vilar Roldan, H. Simic (2015b) Deliverable: D4.3 CaaS Method Extension: Capability Modelling for PMO and SOA Technological Platforms, CaaS – Capability as a Service for Digital Enterprises, FP7 project no 611351, caas-project.eu Box, G.E.P, Jenkins, G.M., Reinsel, G.C., Ljung, G.M. (2015), Time Series Analysis: Forecasting and Control, Wiley-Blackwell Bubenko, J. A. j., Persson, A. and Stirna, J. (2001), User Guide of the Knowledge Management Approach Using Enterprise Knowledge Patterns. Deliverable D3 IST Programme project Hypermedia and Pattern Based Knowledge Management for Smart Organisations, Project no. IST-2000-28401, available at: ftp://ftp.dsv.su.se/users/js/d3_km_using_ekp.pdf (accessed February, 2014). Capilla, R., Ortiz, O. & Hinchey, M. (2014), Context variability for context-aware systems, Computer, vol. 47, no. 2, pp. 85-87. Carlos Llorca Quevedo, Sergio España, Marta Esparza García, Alberto Gisbert Hita, Tania González Cardona, Janis Grabis, Martin Henkel, Raúl Juanes Pascual, Lauma Jokste, Francisco Valverde Giromé.: Deliverable 4.2: Capability Models for SOA technological platforms, proj. no. 611351 (2014). Dayasindhu, N. (2004): Information Technology Enabled Process Outsourcing and Reengineering: Case Study of a Mortgage Bank. In AMCIS 2004 Proceedings. Available online at http://aisel.aisnet.org/amcis2004/437. France, R. and B. Rumpe, Model-driven Development of Complex Software: A 205

CaaS


Research Roadmap, in 2007 Future of Software Engineering. 2007, IEEE Computer Society. p. 37-54. Friedrich, Fabian; Mendling, Jan; Puhlmann, Frank (2011): Process Model Generation from Natural Language Text. In Haralambos Mouratidis, Colette Rolland (Eds.): Advanced information systems engineering. 23rd international conference, CAiSE 2011, London, UK, June 20-24, 2011: proceedings. Heidelberg: Springer (LNCS sublibrary. SL 3, Information systems and applications, incl. internet/web, and HCI, 6741), pp. 482–496. Grabis, J., Sandkuhl, K. (2016), Selection and Evolutionary Development of Software Service Bundles: a Capability Based Method, Advanced Information Systems Engineering Workshops CAiSE 2016 International Workshops, Ljubljana, Slovenia, June 13-17, 2016, Proceedings. Goldkuhl G., Lind M., Seigerroth U. (1998) Method integration: the need for a learning perspective, IEE Proceedings Software, Vol 145 (4), pp 113-118 Han, R., Guo, L., Ghanem, M.M., Guo, Y. (2012). Lightweight Resource Scaling for Cloud Applications. 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), pp. 644-651 Jadhav, A.S., Sonar, R.M. (2009), Evaluating and selecting software packages: A review, Information and Software Technology 51, 555-563 Lorido-Botran, T., Miguel-Alonso, J., Lozano, J.A. (2014) A Review of Auto-scaling Techniques for Elastic Applications in Cloud Environments. Journal of Grid Computing 12(4), 559-592 Grüne, Guido; Lockemann, Stephanie; Kluy, Volker; Meinhardt, Stefan (2014): Mapping Business Processes in the Process Industry: Selected Examples. In: Business Process Management within Chemical and Pharmaceutical Industries: Markets, BPM Methodology and Process Examples. Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 69–162. Available online at http://dx.doi.org/10.1007/978-3-642-11717-6_3. Hallerbach, A., Bauer, T. & Reichert, M. (2010), Capturing variability in business process models: The Provop approach, Journal of Software Maintenance and Evolution, vol. 22, no. 6-7, pp. 519-546. Henkel, M. and J. Stirna (2010), Pondering on the Key Functionality of Model Driven Development Tools: The Case of Mendix, in Perspectives in Business Informatics Research, P. Forbrig and H. Günther, Editors. Springer Berlin Heidelberg. p. 146-160. Kent, S., Model Driven Engineering, in Proceedings of the Third International Conference on Integrated Formal Methods. 2002, Springer-Verlag. p. 286-298. Kleppe, A.G., J. Warmer, and W. Bast, MDA Explained: The Model Driven Architecture: Practice and Promise. 2003: Addison-Wesley Longman Publishing Co., Inc. 170. Lano, K. (2009) Model-Driven Software Development With UML and Java. Course Technology Press. 437. Loucopoulos, P., Kavakli, V., Prekas, N., Rolland, C., Grosz, G., Nurcan, S. and others (1997), “Using the EKD approach: the modelling component”. Makridakis, S.G., Wheelwright, S.C., Hyndman, R.J. (1997), Forecasting: Methods and Applications, John Wiley & Sons 206

CaaS


Milani, F., Dumas, M., Ahmed, N. and Raimundas Matulevicius (2013), Modelling Families of Business Process Variants: A Decomposition Driven Method, CoRR, abs/1311.1322. Montgomery , D.C. (2012) Design and Analysis of Experiments, John Wiley & Sons Moody, D.L. and G.G. Shanks (2003) Improving the quality of data models: empirical validation of a quality management framework. Inf. Syst. 28(6): p. 619-650. Murguzur A,, De Carlos X., Trujillo S., Sagardui G. (2014) Context-Aware Staged Configuration of Process Variants@Runtime. CAiSE 2014. pp.241-255 OMG, “Business Process Model and Notation”, available at: http://www.bpmn.org/ (accessed 27 February 2014). Persson A., Stirna J., (2010) Towards Defining a Competence Profile for the Enterprise Modeling Practitioner, P. van Bommel et al. (eds.), in proc. of PoEM 2010, proceedings, Springer LNBIP 68, ISBN 978-3-642-16781-2, p. 232-245 Persson, A. and Stirna, J. (2001). An explorative study into the influence of business goals on the practical use of Enterprise Modelling methods and tools. In Proceedings of the 10th International Conference on Information Systems Development (ISD 2001), Kluwer, London. Persson, A., Stirna, J. and Aggestam, L. (2008), How to Disseminate Professional Knowledge in Healthcare, Journal of Cases on Information Technology, Vol. 10 No. 4, pp. 41–64. Ravichandar, R., Arthur, J., Broadwater, R., (2006), Reconciling Synthesis and Decomposition: A Composite Approach to Capability Identification. arXiv. Sandkuhl K., Stirna J., Persson A., Wißotzki M. (2014): Enterprise Modeling - Tackling Business Challenges with the 4EM Method. The Enterprise Engineering Series, Springer, ISBN 978-3-662-43724-7, pp. 1-299 Schmidt, D.C. (2006), Model-Driven Engineering. IEEE Computer, 39(2). Selic, B. (2003), The Pragmatics of Model-Driven Development. IEEE Softw. 20(5): p. 19-25. Sommerville, I. (2015), Software Engineering, Pearson. Sottet, J.-S., et al. (2008) A Model-Driven Engineering Approach for the Usability of Plastic User Interfaces, in Engineering Interactive Systems, G. Jan, et al., Editors, Springer-Verlag. p. 140-157. Stavenko, Yulia; Kazantsev, Nikolay; Gromoff, Alexander (2013): Business Process Model Reasoning: From Workflow to Case Management. In CENTERIS 2013 Conference on ENTERprise Information Systems / ProjMAN 2013 - International Conference on Project MANagement/ HCIST 2013 - International Conference on Health and Social Care Information Systems and Technologies 9 (0), pp. 806–811. DOI: 10.1016/j.protcy.2013.12.089. Stroppi (2011), A BPMN 2.0 Extension to Define the Resource Perspective of Business Process Models. Sumita, Kouhei; Kitamura, Yoshinobu; Sasajima, Munehiko; Mizoguchi, Riichiro (2012): Are Services Functions? In : International Conference on Exploring Services Science: Springer Berlin Heidelberg, pp. 58–72. Available online at 207

CaaS


http://link.springer.com/content/pdf/10.1007%2F978-3-642-28227-0_5.pdf. Triantaphyllou, E. (2000), Multi-Criteria Decision Making Methods: A Comparative Study. Kluwer, Dordrecht and Boston Tohidi, Hamid (2011): Modelling of business services in service oriented enterprises. In World Conference on Information Technology 3, pp. 1147–1156. DOI: 10.1016/j.procs.2010.12.186. Weske, Mathias (2012): Business process management. 2. ed. Heidelberg: Springer (Computer science)

208

CaaS


6. Appendix A: Meta-model of Capability Design

209

CaaS


Capability Description Purpose

Associations

Attributes

Capability is the ability and capacity that enable an enterprise to achieve a business goal in a certain context. Capability is the core element that describes the capability of the business that will be designed and delivered by CDD approach. Capability formulates the requirements for the ability of accomplishing a business goal, realized by applying a solution described by a capability delivery Pattern. Capability influences KPI: During the capability delivery phase Goal KPIs are measured. Capability influences Context indicator: During the capability delivery phase Context Indicators are measured. Capability is required by Goal: A Capability supports fulfilment of a Goal, i.e. the goal needs to be satisfied during the capability delivery. Capability requires Process: Capability requires one or several a Business Processes. I.e. a Capability is delivered by executing Business Processes. Capability requires Context set: A Capability is designed to be used in a certain context situation that is represented by a Context Set. Capability is supported by Pattern: The Pattern component describes the actual solution for realizing a Capability in the given context situation (represented by Context Set at design time) and by Context Situation during run time. -

Goal Description

Goal is a desired state of affairs that needs to be attained. Goals can be refined into sub-goals forming a goal model. Goals should typically be expressed in measurable terms such as KPIs. Other modelling components such as problems, opportunities, and causes may also be included in goal modelling. From a point of view of organizational design goals are operationalized by business rules and business processes. According to the CDD approach a Goal requires one or several capabilities that help achieving it.

Purpose

Goal describes the vision of the organization, what it wants to achieve or avoid. Goal achievement requires Capabilities.

Associations

Goal requires KPI: Achievement of a Goal is measured by one or several Key Performance Indicators. Goal requires Capability: Goal requires one or more Capability in order to be satisfied during capability delivery. 210

CaaS


Goal motivates Process: Goals are operationalized by business processes and, hence, in EM terms we consider that a Goal motivates one or several processes at some decomposition level. Attributes

-

Indicator Description

Purpose

Associations Attributes

Indicator is a property of the business design that can be used for monitoring Capability delivery by measuring the Context (Context Indicator) for monitoring achievement of KPIs. Indicator is a generalization of two types: Context Indicator measures the context values in Capability delivery application run time. Key Performance Indicators set targets for achievement of the Goals in Capability delivery application run time. The Context Indicators are designed according to the relevant context situations and measured during run time by aggregating the Measured Properties., Indicator influences Capability: Capability delivery is monitored and adjusted on the basis of Indicators. Value

Context Indicator Description Purpose

Associations

Attributes

Context Indicator is a property of the context relevant to the capability design and useful for monitoring capability delivery. Context Indicator represents an aggregation of Measureable Properties used for monitoring the Capability Delivery Application at run time. Context indicators should be designed in such as way that it allows monitoring according to the KPIs. Context Indicator requires Measurable property: A Context Indicator used for monitoring the context situation. A Context indicator is based on values of one or several Measurable Properties. -

KPI Description Purpose Associations

Key Performance Indicators (alias KPI) are measurable properties that can be seen as targets for achievement of Goals. KPI describes the measurable properties of the business Goal in order to support monitoring of goal fulfilment. KPI is specialization of Indicator: KPI is a type of Indicator relevant to measuring the achievement of the Goals. KPI is required by Goal: In order to check if business goals are 211

CaaS

Attributes


satisfied during the capability delivery phase, KPIs are used to measure the achievement of Goals. KPI has value KPI Value: this association is used to store the actual KPI values achieved at run-time -

Resource Description

Purpose Associations

Attributes

A Resource is something considered valuable for at least one actor. Resources can be explicit (external resources), such as goods, money and people or intangible (internal resources) such as knowledge and goodwill. The difference between internal Resources and external is that internal Resources are not possible to directly transfer between actors. Resource describes material, staff and other assets that are needed to ensure the Capability delivery. Resource relates to Measurable property: Resource is related to one or several Measurable Properties. Resource is part of Process: Business process design specifies the use of resources because Processes are executed by consuming Resources. Value

Process (alias Business Process) Description

Purpose

Associations

Process is series of actions that are performed in order to achieve particular result. A Process supports Goals and has input and produces output in terms of information and/or material. When initiated a process is perceived to consume resources. Process describes the actions that need to be performed to deliver the Capability and support business one or several business Goals. Process is required by Capability: Capability is delivered by a business Process. Process is motivated by Goal: A Process defines how Goals are fulfilled in general. Process is generalization of Process Variant: A process may consists of process variants that show what needs to be changed depending on context. Process is aggregation of Resource: Processes are executed by consuming resources which needs to be specified in the business design. Process is associated with Event Based Adjustment: This association is used to associate relevant process value used for adjustment calculations at run-time. 212

CaaS

Attributes


-

Process Variant Description Purpose

Associations

Attributes

Process Variant is a part of the Process, which uses the same input and delivers the same outcome as the process in a different way. Process Variant describes the variability in the business process and capability delivery. Used for adjustment of a master process (e.g., a reference process) to specific requirements building the process context (Hallerbach et al., 2010) Process Variant is a part of the capability delivery process execution which depends upon the context. Process Variant is a part of Process: Process can consist of one or more process variants. Process Variant is a part of Capability Delivery Pattern: Pattern describes which process variant should be used in each context situation. Process Variant is associated with Process Variant Variation Point: this relationship defined the location of the variation in the business process model. -

Capability Delivery Pattern (alias Pattern) Description

Purpose

Associations

Patterns are reusable solutions for reaching business Goals under specific situational contexts. The context defined for the Capability (Context Set) should match the context in which the Pattern is applicable. Patterns will represent reusable solutions in terms of business processes, resources, roles and supporting IT components (e.g. code fragments, web service definitions) for delivering a specific type of capability in a given context. The Context Indicators are used to monitor at runtime whether the Pattern applied for delivering the Capability is valid for the concrete Context Situation. Pattern consists of Process Variant: Pattern describes which Process Variant should be used in each Context Situation. Pattern requires Context set: Patterns describe which Process Variants should be used in which context modelled by Context Set. Pattern supports Capability: The Pattern describes an actual solution for realizing a Capability in different context situations during the run time. There can be patterns that document a specific best practice or solution and are some point of time are not connected to any capability. Pattern is associated with Capability Delivery 213

CaaS

Attributes


Variation Point: this relationship defined the location of the variation in the capability delivery solution. Problem/Goal: states what problem the pattern solves, why it should be applied Solution: Describes the solution in textual form if necessary Links: links to model fragments, e.g. Process Variants Usage guidelines: guidelines for pattern application and tailoring if needed.

Context Set Description Purpose

Associations

Attributes

Context Set describes the set of Context Elements that are relevant for design and delivery of a specific Capability. Context Set represents different Context Situations when a capability or pattern is applicable. Each Context Set is specified by several Context Element Ranges; Context Set also specifies how the actual context should be monitored at run time, represented by Context Situation. Context Set is required by Capability: A Capability is designed to be adequate for the certain context situations represented by a Context Set. Context Set consists of Context Element Range: Context Set is a composite object consisting of one or more Context Element Ranges that specify the range of a particular Context Element include in the Context Set . Context Set is required by Pattern: Context Set specifies the context when a pattern is applicable. It allows selecting patterns for capability design by matching capability and pattern context sets as well as identification of potentially applicable patterns during the run-time by matching the patter context set with the current capability delivery context situation. Context set has Context situations: Context Set defines relevant Context Situations that should be monitored at runtime. -

Context Situation Description Purpose Associations

Context Situation captures the actual context during the system run time. Context Situation is a run time element that describes a certain context affecting capability delivery during the run time. Context situation is not modelled in the design phase. Context situation is required by Pattern: during the capability delivery application run time context is monitored and appropriate Pattern for each Context Situation is applied. Context Situation has Context Set: Context Situation is defined according to the Context Set. 214

CaaS

Attributes


Context Situation consists of Context Element Value: A Context Situation consists of a set of actual values for a set of Context Elements Values based on Measurable Properties. -

Context Element Range Description

Purpose

Associations

Attributes

Context Element Range is used to specify boundaries of permitted Values for a specific Context Element and for a specific Context Set. The purpose of Context Element Range is to represent the actual ranges of value of relevant Context Elements for a specific Context Set. The attribute Calculation expression is used to specify the calculation of the context element value using measurable properties. Context Set consists of Context Element Range: Context Set includes one or several Context Element Ranges. Context Element Range is related to Context: Each Context Element Range represents values of a specific Context Element. Value Calculation expression

Context Element Description Purpose

Associations

Run time context is described as Context Elements representing any information that can be used to characterise the situation of an entity. Context Element is any information that is relevant to capability design, delivery and pattern application. The Context Element only defines the context conceptually, the runtime values are represented by Context Element Value and design time ranges by Context Element Range. Context Element has Context Element Value: Each Context Element has a value which is measured during the runtime. Context Element is related to Context Element Range: Each Context Element used in capability design can be related to one or more Context Element Ranges. Context Element is identified by Context Type: Context Elements can be structured in different types thus making them easier to recognize during capability design and to choose the most appropriate Pattern (e.g. static context affects Capability delivery differently then dynamic Context). Context Element is measured by Measurable Property: Context Element should have value, they may be based on a 215

CaaS

Attributes


number of Measurable Properties. Context Element is associated to Variation Aspect: This association is used to specify what variations may be caused by a particular Context Element. -

Context Element Value Description Purpose

Associations

Attributes

Context Element Value is a value of a specific Context Element at a given the runtime situation. Each Context Element is represented by many Context Element Values each occurring at various situations. Context Element Value has a certain value calculated from measurable properties. Context Element Value is a part of Context Situation: A Context Situation represents a set of actual Context Element Values. Context Element Value describes Context Element: Each Context Element has a value at a certain situation. Context Element Value is calculated by Context Calculation: This association is used to link the values of the context element with relevant calculations. Context Element Value is use for KPI Calculation: Value Calculation expression

Context Element Type (alias Context Type) Description Purpose

Associations Attributes

Context Element Type allows structuring Context Elements in different groups and/or categories. Context Elements can be described by Context Element Type, e.g. static context, dynamic context, social context. Context Element Type supports finding the most appropriate pattern for a certain context situation, and defining relevant contexts during capability design. Context Element Type identifies Context Element: Each Context Element can be characterized by one Context Element Type. -

Measurable Property Description Purpose

Measurable Property is any information about the organization’s environment that can be measured. Measurable Property allows measuring a context and amount of Resources thus identifying the most appropriate 216

CaaS

Associations

Attributes ------


Pattern for a particular Context Situation. Measurable Property is related to Resource: Availability of amount Resources can be seen as relevant information to be measured and used in capability design. Measurable Property is required by Context Indicator: Context Indicators should be defined and measured in order to support capability adjustment.. Measurable Property provides data for measuring Context Element: context is measured by one or several Measurable Properties. Measurable Property is used in Context Calculation: This association is used to specify the measurable properties that are used in Context Calculations. Value

KPI Calculation Description Purpose

Calculates the target and current value of a KPI. The objective of the class KPICalculation is to calculate a value of a KPI. A KPI has two values – a target value and the current value. For each of them an instance of a KPICalculation is created, which is implemented in CDT (specify IDAs, calculation logic, perform validation) and executed in CNA. Both values of KPI can be used as input for CapabilityAdjusment instances and they are also visualized in CNA using a set of predefined widgets.

Associations

KPI Calculation is based on Context Element Value: this association is used to specify which Context Element Values are use in the algorithms for calculating KPI Values. KPI Calculation calculates KPI Value: this association is used to assign the value calculated by KPI Calculation to KPI Value.

Attributes KPI Value Description

KPI Value represents the actual value of a KPI at runtime.

Purpose

KPI Value is calculated by KPICalculation and based on the Context Element Values KPI Value is for KPI: this association is used to specify values of KPIs at run-time KPI Value is calculated by KPI Calculation: this association is used to assign the value calculated by KPI

Associations

217

CaaS


Calculation to KPI Value. Attributes Context Calculation Description

Calculates Context Element Value.

Purpose

The objective of the class ContextCalculation is to calculate the value of ContextElement. To calculate the value AdjusmentConcept and MeasurableProperty are used. Each ContextCalculation can use multiple input data, however it can only return a single value (the value of the context element). The instances of the ContextCalculation are executed and managed in CNA, while values of measurable properties are retrieved from CCP during run-time. At first ContextCalculation input parameters and IDAs are modeled, then the adjustment logic is implemented and validated. The final step is ContextCalculation deployment to CNA.

Associations

Context Calculation uses Context Element Value: this association is to specify which values are used in calculation. Context Calculation uses for calculation Measurable Property: this association is used to access the measurable properties that are needed for calculations in the adjustments.

Attributes Calculation Description

Calculates context element or KPI value.

Purpose

Calculation is used to group two kinds of adjustments – ContextCalculation and KPICalculation. Calculation adjustments do not directly adjust the capability however the result from the calculation are used for instances of CapabilityAdjusment which directly alter the capability delivery.

Associations

Calculation has two sub-classes Context Calculation and KPI Calculation Calculation is a specialization of Adjustment

Attributes

Context Indicator Calculation Description

Calculates Context Indicator.

Purpose

The objective of the class ContextIndicatorCalculation is to calculate the value of ContextIndicator. To calculate the 218

CaaS


value AdjustmentConcept and MeasurableProperty are used. Each ContextIndicatorCalculation can use multiple input data, however it can only return a single value (the value of the context indicator). The instances of the Context Indicator Calculation are executed and managed in CNA, while values of measurable properties are retrieved from CCP during run-time. At first ContextIndicatorCalculation input parameters and IDAs are modelled, then the adjustment logic is implemented and validated. The final step is ContextIndicatorCalculation deployment to CNA. Associations

Context Indicator Calculation uses for calculation Measurable Property: this association is used to access the measurable properties that are needed for calculations in the adjustments.

Attributes Scheduled Adjustment Description Purpose

Associations

Supports implemented Capability Delivery Variation Point ScheduledAdjustment is executed based on a predefined schedule and it cannot be called through a web service. It is implemented (using programming language) and validated in CDT, deployed to CNA. ScheduledAdjustment cannot be called from external components (no API provided) however it can interact with other components if they provide an API. ScheduledAdjustment is mainly used for supporting decision making in CapabilityDeliveryVariationPoint (nonprocess based capability, e.g. scaling in the cloud based on the current load). Scheduled Adjustment supports implementing Capability Delivery Variation Point: this association is used to specify which variation point is affected by the adjustment. Scheduled Adjustment is a specialization of Capability Adjustment

Attributes Event Based Adjustment Description Purpose

Supports implementing Process Variant Variation Point. EventBasedAdjustment is implemented (both Java and MathML types are supported) and validated in CDT, deployed to CNA. After the deployment it can be called through web services 219

CaaS


hosted in the CNA, which allows external systems to get a result of EventBasedAdjusment whenever it is required. EventBasedAdjustment supports decision making in ProcessVariantVariationPoint. When using EventBasedAdjustment to choosing the right process variant during run-time, process instance values can be passed to the adjustment via VariationPointBinding. Associations

Event Based Adjustment is associated with Process Variant Variation Point: this association is used to support decision making and to specify which adjustment is related to the adjustment. Event Based Adjustment is associated with Process: this association is used to specify which process instance data are used in the adjustment calculation. Event Based Adjustment is a specialization of Capability Adjustment

Attributes Adjustment Description

The Adjustment is a superclass for representing the common technical characteristics of all adjustments.

Purpose

All adjustments can use AdjustmentConstant for adjustment variable value calculation and are further divided into Calculation and CapabilityAdjustment. The structure of the class Adjustment is shown in Fig. 3-23. Adjustment uses for calculation Adjustment Constant: this association is used to link the adjustment with global values stored in the CNA.

Associations

Attributes Capability Delivery Variation Point Description

Purpose

Associations

A capability delivery variation point is a specialization of a variation point and is intended for modelling non process-based capabilities (where process variation points are not suitable). Capability Delivery Pattern may represent a complete solution or it can consist of several “sub-patterns” each of them focusing on a specific part of the solution. Variation amongst such pattern may be specified by Capability Delivery Variation Point. Capability Delivery Variation Point is defined in Pattern: this association is used to specify how the capability adjustments can lead to variation. 220

CaaS


Capability Delivery Variation Point is associated with Scheduled Adjustment: this association is used to specify the adjustment algorithm related to the variation point. Attributes Process Variant Variation Point Description Purpose

Associations

Process Variant Variation Point contains multiple process variants to choose from. Process Variant Variation Point is the specialisation of the Variation Point concept and represents the location of changes in process variants. Process Variant Variation Point is defined in Process Variant: this association specifies how the different process variants can be associated with each other. Process Variant Variation Point is associated with Event Based Adjustment: this association is used for specifying the decision making related to choosing the needed Process Variant.

Attributes Variation Point Description Purpose

Associations

Locations of variations in a business process model or capability delivery. A Variation Point identifies the business service model element, where a variation with respect to a specific variation aspect occurs; they are the locations of variations in a business service model. A variation point is specialized to Capability Delivery Variation Point and Process Variant Variation Point. Variation Point depends on Variation Aspect: this association is used to specify on which aspects a Variation Point depends on.

Attributes Variation Aspect Description

Purpose

Causes and types of variations in business processes of an enterprises where alternative flows, functions or procedures are possible. Variation Aspect identifies the causes and types of variations that can be relevant for different business services and at different 221

CaaS

Associations


positions in the business service model. Context Elements are related to different business drivers that cause variations in processes. Each Variation Aspect consists of one or several Context Elements. Variation Aspect is based on Context Element: this association used to specify which how a context element influences variability. Variation Aspect determines Variation Point: this association used to specify which Variation Points depend on which Variation Aspects.

Attributes Adjustment Constant Description Purpose

Associations

AdjustmentConstant represents a constant value that managed centrally in the CAN and it is used in adjustments. AdjustmentConstant refers to a system wide constant that can be used for altering the capability without modifying its actual code. Instances of AdjustmentConstant can be reused in all adjustments and are centrally managed using CNA user interface. Adjustment Constant is used by Adjustment: this specifies which Adjustment Constants are used by which Adjustments.

Attributes

222

CaaS


7. Appendix B: Application of Context Modelling Method Component 7.1 An Example from the Airline Industry This section introduces a fictional use case, where context plays a vital role on capability delivery. For the use case, we assume that the enterprise objectives are already captured as goal models and the service provision is represented in business processes models. A worldwide airline called ComfortFly designs a capability that supports passengers` time optimization ahead of their flights. The capability “Dynamic Passenger Support” is delivered via an application and by using the app, the passenger should be at the airport, check in and go to her gate just in time. Based on the current situation, the app calculates the probability of a delay and cancellation. In case of a high probability, capability is adjusted, i.e. it recommends actions to the passenger, such as contacting the airline customer services or checking the flight status from the respective webpage. The recommended action depends on the context of respective flight, which is affected by the airport situation, number of the delays or cancellations in the prior flight as well as on the traffic situation. These factors affect the travel time of the passenger. A simple screenshot is illustrated in Figure 7-1where the delivery is adjusted and the user is automatically informed about its respective flight.

7.1.1 Enterprise objectives

Figure 7-1. A screenshot from the app

ComfortFly conducted a participatory goal modelling session a few months ago, which was triggered by the problem of costs caused by longer delay and cancellations. The stakeholders reached a consensus and stated the respective goals as follows: • • •

We need to reduce the costs caused by longer delay and cancellations. We aim to reduce the accumulation rate caused by the passengers that arrive airport too early (because they are not aware of a huge delay probability). We aim to assure preciseness by calculating the flight situation, airport capacity use and the travel time to the airport. Moreover, we want to advise the user with the right action in case of an abnormal situation. 223

CaaS


•

We aim to develop an application, which monitors and processes passengers´ situation to optimize her timing.

A simplified fragment of ComfortFly´s goal model is shown in Figure 7-2.

Figure 7-2. A simplified fragment of ComfortFly´s goal model

7.1.2 High-level Processes

Figure 7-3. The workflow of the application

To fulfil the enterprise objectives, the capability should be designed in a way that the application is prepared for various scenarios, i.e., its workflow has to cope with the changes occurring at run-time to provide the passenger with the right action. The base process is illustrated in Figure 7-3. In the first task, the passenger logs in and selects the flight, for which she will be recommended with an action at the end of the process. Then, the application assesses the situation with an algorithm based on the following information: •

Flight situation assessment: Number of delays and cancellations from the departure point as well as at the destination location will used as input data to calculate the anomaly probability fs. The fs can assume values low, middle, high and for each value, the actions to be taken may change for the passenger. From a business process perspective, the flights of Comfort Fly from departure and to the destination points are analysed. If anomalies are identified, then also the flight situation of other airlines must be checked. This is shown in Figure 7-4.

224

CaaS


Anomalies in the departure?

Check airline flights from departure

Yes

Assess flight situation Check all flights from departure Anomalies in the destination?

No

Yes

No

Check all flights to the destination

Calculate anomaly probability fs

Check airline

flights to the destination

Figure 7-4. Flight situation assessment

•

Airport situation assessment: In order to recommend the precise action to the user, the application analyses the capacity use in the check-in desks and the availability of the staff. The flight assessment type is required to identify whether the flight is national or international and whether the flight requires a border control. In such cases, the analysis of the queue on the pass control is also added to the workflow (see Figure 7-5). Based on the results, the occupancy rate ocr is calculated, which may assume the values “low, mid, high”.

Figure 7-5. Airport situation assessment

After assessing the flight and airport situations, the application checks the traffic situation to calculate the required time to arrive at the airport. For this, the application requires access to the user location. Next, the travel time tt to the airport is calculated. In the last step, the application advices user an action. The app takes the user context into account, i.e. the anomaly probability of the flight fs, the flight type and the current ocr to support the passenger with an appropriate recommendation. A total of seven different recommendations are possible depending on the user context, as listed in the following (see Figure 7-6 for detailed and Figure 7-7 for a consolidated view): •

•

Leave in (tt + 90) minutes before the flight: This action is advisable, when the passenger attends to a national flight from a low or mid-occupied airport, where the anomaly probability is low. Leave in (tt + 120) minutes before the flight: This action is advisable, when the passenger either attends to a national flight from a high occupied airport (anomaly not regarded), or to an international flight from a low occupied airport, where the anomaly probability is low or mid. 225

CaaS


•

Leave in (tt + 140) minutes before the flight: This action is advisable, when the passenger attends to an international flight from a low or mid occupied airport, where the anomaly probability is low. Leave in (tt + 150) minutes before the flight: This action is advisable, when the passenger attends to a national flight from a mid-occupied airport, where the anomaly probability is middle. Contact customer service: If the context of the passenger is one of the following, then the passenger should contact the customer service to ask for the most current information about the flight. o The passenger attends to a national flight from a highly occupied airport with a middle anomaly probability, o The passenger attends to a national flight from a mid- or highly occupied airport with a high anomaly probability, o The passenger attends to an international flight from a mid- or highly occupied airport with a middle anomaly probability, o The passenger attends to an international flight from a low-occupied airport with a high anomaly probability. Contact customer service and check the airline webpage: This action is advisable, when the passenger attends to an international flight from a midoccupied airport, where the anomaly probability is high. In the check airline webpage activity, the application directs the passenger is automatically to the online flight status query page. Contact customer service, check the airline webpage and do not pass the border control: This action is advisable, when the passenger attends to an international flight from a highly occupied airport, where the anomaly probability is also high. If the passenger is already in the airport due to any reason, the application recommends not passing the border control. The reason is that after passing the passport screening, the passenger can only leave the secured area after a very complex procedure. Hence, in case of a longer delay, crossing the border control means practically killing time where everything is overpriced.

•

•

•

•

226

CaaS


Figure 7-6. Actions recommended by the application based on user context, detailed view 227

CaaS


Figure 7-7. Actions recommended by the application based on user context, consolidated view

228

CaaS


7.1.3 Practical Application of Context Modelling Method Component Step 1. Process Model Analysis The input to this step is the process models of the selected service and textual information about them. After a thorough analysis, the business analyst identifies in the following the locations where variability happens. Figure 7-3 illustrates the high-level workflow. There are yet no gateways in the business process model. But the business analyst expected this situation (see Guideline 3) and thus has to investigate the sub-processes for further variability. The first sub-process is related to the flight situation assessment (see Figure 7-4). Here, the business analyst identifies two gateways. The task “assess airport situation” consists of further sub-tasks, which are shown in Figure 7-5. The business analyst identifies here only one gateway, “border control required?”. The value of this gateway influences whether the task “analyse the passport control” is executed or not. The tasks “check traffic situation” and “calculate travel time tt to airport” are automated and executed exactly the same way each time. There are no gateways here. In the last task, the application recommends user an action. As shown in Figure 7-6 (detail view) and Figure 7-7 (consolidated view), finding the right action and supporting the user with the precise recommendation depends on how the gateways before them are resolved. The business analyst captures all of the gateways and after getting the approval of the business service operator, she documents them in Table 7-1. Please note that the gateways with same conditions and same diverging paths are considered identical. For simplicity purposes, we eliminated the identical gateways from Table 7-1. Table 7-1. Capturing the gateways

Gateway

Condition

GW1

Anomalies in departure?

GW2

Anomalies in destination?

GW3

Border control required?

GW4

Anomaly probability?

GW5

Flight type?

GW6

Airport occupation?

An important remark concerns the application of Activity 1.2, Identify process variants. Upon the request of the business service operator, the business analyst analyses all the business process models related to the service provision. She concludes that the variability can be analysed only by investigating the gateways. This is closely related to the design decision of the business process modeller at ComfortFly. To give an example, the task “assess airport situation” could be modelled as depicted in Figure 7-8A and B (with and without border control, respectively). The difference between the models shown in Figure 7-5 and in Figure 7-8 is that the former one represents variability with a gateway and the latter one with process variants. This is the reason, 229

CaaS


why context modelling method component supports the analysis of both gateways and process variants.

Figure 7-8. Two process variants of the task “assess airport situation”

Step 2: Context Element Design This step uses the list of process variants and/or gateways that are identified by the business analyst and validated by the business service operator in Step 1. In Step 2, the capability analyst, business analyst and business service operator are responsible for studying the factors causing variability. For this, they use the list of gateways (see Table 7-1) and alter it by adding the columns “gateway analysis” and “factor”. For each gateway, they should denote why they are needed. After that, the aforementioned roles investigate the extent, to which the factors influence goal fulfilment and adds a column “goal influence” to the table. They find out that resolving all gateways except for GW3 have a strong contribution to goal fulfilment, i.e. only factors related to the resolving GW3 are not represented in goal models. Table 7-2. Identifying and analyzing factors causing variability

Gateway Condition

Gateway analysis

GW1

Anomalies in departure?

If there are anomalies in the Anomaly Strong departure, then not only the flights of probability calculation ComfortFly, but of all the airline companies are checked. Anomalies in the departure are required to calculate the anomaly probability (fs)

GW2

Anomalies If there are anomalies in the in destination, then not only the flights destination? of ComfortFly, but of all the airline companies are checked. Anomalies in the departure are required to calculate the anomaly probability (fs)

Anomaly Strong probability calculation

GW3

Border control

Airport occupancy

If border control is required, then its capacity utilization is taken as an

Factor

Goal influence

Weak 230

CaaS


required?

input to calculate the occupancy rate (ocr). On the other side, the results of the calculation are not expected to raise the preciseness of recommendation

rate calculation

GW4

Anomaly The anomaly probability (fs) is a probability? must have input required to advise the right action to the user

Anomaly Strong probability calculation

GW5

National flight?

Flight type Strong

GW6

Airport The occupancy rate of the airport occupation? (ocr) is a must have input required to advise the right action to the user

The passengers attending to an international flight have to be at the airport 30 min. earlier than the passengers of a national flight

Airport Strong occupancy rate calculation

Figure 7-9. Dependency analysis between gateways

The team removes GW3 from the table and conducts a dependency analysis between gateways. The GW1 and GW2 contributes resolving GW4, since the anomalies in departure and anomalies in destination are calculated to find out the anomaly probability (fs). It means that their actual contribution to goal fulfilment after they are resolved is due to GW4 and hence indirect. The capability analyst documents this by creating a simple taxonomy between gateways (see Figure 7-9). Then with the gateways that have a direct and strong goal contribution, she creates the variation points (see Table 7-3). The variation points will help them to establish the connection between the context elements and important gateways in the context model. After this, the capability analyst consults the findings with the capability analyst, business analyst and business service operator.

231

CaaS


Table 7-3. Renaming the gateways as variation points

Gateway

Variation Point

GW4

VP1

GW5

VP2

GW6

VP3 The factors causing variability in the business processes are analysed and discussed with domain experts thoroughly (see Table 7-2). As a result, the solution architect model the factors that have both strong and direct influence on goals as context elements 9 . The remaining factors are not “idle”, i.e. they are typical candidates used to specify the properties of a context element, which help to measure its value. In context modelling method component, these attributes are called “Measurable Property”. After reading Guideline 4, the method user decides to use GW1 and GW2 as measurable properties.

A Context Element (CE) is measured by one or more Measurable Property (MP). The context model including only two model elements (CE and MP) is illustrated in Figure 7-10. As one can notice, not all the measurable properties are extracted from the idle gateways. Figure 7-10. Initial context model For instance, to find out the value of CE “Flight type”, one way is to determine the country of departure and destination of the flight. Also the business process models can help to define the MPs. To calculate the ocr value (CE 3), the application needs to calculate the percentage of staff availability (MP5), check-in desk occupancy rate (MP6) and pass control occupancy rate (MP7). This can be extracted from the business process models depicted in Figure 7-5.

9

Context elements are context entities that affect the service design and provision by causing variability and they are related to enterprise objectives

232

CaaS


Step 3: Context Set Design As of now, the stakeholders have an overview of the enterprise goals, the pre-flight service that is to be designed context-aware, the business processes and the context, which is required to adapt the behavior of the application (recommending the user what to do). Regarding the “Dynamic Passenger Support” capability, the capability analyst selects all three context elements and designs their allowed values from the textual descriptions. The results are confirmed by the solution architect and the capability provider. There is a strong relationship between the capability and the context element ranges. For example, when we further decompose the capability and express it as “Dynamic Passenger Support in High Anomaly Probability”, then the Context Element Range 1 only assumes the value “high”. Likewise, the capability can be defined as “Dynamic Passenger Support in International Flights”, which requires assuming only “international” as the value of Context Element Range 2. It means that the context model provides ComfortFly with the required flexibility, in case they need configurations and adaptations in the application. Figure 7-11 depicts the context model for the “Dynamic Passenger Support” capability10, which is validated by the business service manager.

Figure 7-11. Context model including capability, as a connector of all three views

Step 4: Design Binding This is an optional step. By performing the step, the capability analyst documents the required context providers, calculations and adjustments. The output of this step can be used in Run-time Delivery Adjustments method component by the solution engineer,

10

Please note that we do not add the context indicators to the model for the sake of simplicity.

233

CaaS


when for instance the java classes are added to the context model or context providers are created in CCP. The capability analyst first selects context providers. The context providers are the sources, which provide data to obtain the values of context elements by operating on the measurable properties. By monitoring the changes and calculating the values after each change, the system should be able to adapt its recommendations to the user. The solution engineer is informed about the selected context providers as well as their communication within the CDD environment. In that example, the application needs to monitor the Airport Operations Management System for receiving the information on MP1, MP2 and MP7. The remaining measurable properties are taken from the ComfortFly´s own ERP system. Following that, the capability analyst documents mathematical operations to define the values of context elements ranges. This is illustrated in Table 7-411. Table 7-4. Adding context calculations to the context model

Context Context Calculation Element

Obtained CER from

%1-4 of all flights are delayed or cancelled at the MP1 point of departure %1-4 of all flights are delayed or cancelled at the MP2 point of destination

CE1

%5-9 of all flights are delayed or cancelled at the MP1 point of departure %5-9 of all flights are delayed or cancelled at the MP2 point of destination

Middle fs

Over %10 all flights are delayed or cancelled at the point of departure

MP1

Over %10 all flights are delayed or cancelled at the point of destination

MP2

Country of departure =/ country of destination

MP3, MP4

International

Country of departure = country of destination

MP3, MP4

National

75-100% of staff is available

MP5

50-100% of check in desks are unoccupied

MP6

50-100% of pass control lines are unoccupied

MP7

50-74% of staff is available

MP5

50-100% of check in desks are unoccupied

MP6

CE2

CE3

Low fs

High fs

Low ocr

Middle ocr

11

As we did not specify context indicators in step 3 for brevity reasons, we do not document here how they are calculated (context indicator calculation).

234

CaaS


50-100% of pass control lines are unoccupied

MP7

0-50% of staff is available (other values disregarded in that case)

MP5

High ocr

0-50% of check in desks are unoccupied (other values have to be disregarded in that case)

MP6

High ocr

0-50% of pass control lines are unoccupied MP7 High ocr (other values have to be disregarded in that case) After that the decision logic is expressed, i.e. which action should the application recommend to the user in what circumstances. In CDD meta-model, the decision logic is termed as adjustments, because the system behaviour (in that case, the recommendation) is adapted in accordance with the specified adjustments. The adjustments are shown in Table 7-5. Table 7-5. Adding adjustments to the context model

Adjustment

Process Variant

If fs = “low” AND ocr = “low, middle” AND flight type = “national”

PV1

If fs = “low” AND ocr = “high” AND flight type = “national”

PV2

If fs = “low” AND ocr = “low” AND flight type = “international”

PV2

If fs = “low” AND ocr = “middle, high” AND flight type = “international”

PV3

If fs = “middle” AND ocr = “low”

PV2

If fs = “middle” AND ocr = “middle” AND flight type = “national”

PV4

If fs = “middle” AND ocr = “high” AND flight type = “national”

PV5

If fs = “middle” AND ocr = “middle, high” AND flight type = “international”

PV5

If fs = “high” AND ocr = “low” AND flight type = “national”

PV2

If fs = “high” AND ocr = “middle, high” AND flight type = “national”

PV5

If fs = “high” AND ocr = “middle” AND flight type = “international”

PV6

If fs = “high” AND ocr = “high” AND flight type = “international” PV7

7.2 An Example from the Pharmaceutical Industry The first use case reports a fictional case of the enterprise “AutoPhar” and demonstrates the application of the context modelling method component. With mergers and acquisitions, competitive pressures and strict regulation, firms 235

CaaS


operating in the biotech and life-science sectors need to be able to analyse and streamline core business processes and deliver corporate and regulatory governance to the highest standards. In the pharmaceutical and biotech industry, compliance, accuracy and accountability are critical (Grüne et al. 2014). Automated business processes provide better internal controls and improved efficiency, reduce risk and gain a competitive advantage by reducing time to market12. This chapter illustrates a case from a company called “AutoPhar, which offers business process outsourcing (BPO) services in pharmaceutical industries.

7.2.1 Enterprise objectives The pharmaceutical companies are reserved regarding the implementation of new systems and changing the way of working. Nevertheless, they are aware of the benefits of business processes digitalization, such as improved audit-controls, reduced go-to market cycles and improved documentation. AutoPhar identifies this gap and offers the pharmaceutical companies (clients of AutoPhar) business process outsourcing services (BPO). BPO has been proven as an economically interesting way for companies to control their whole value chain by concentrating on their key business and leaving ancillary processes to highly specialized service providers, thereby also securing a high level of overall quality (Dayasindhu 2004). In the use case, the clients delegate one or more Information Technology (IT) and labor-intensive business processes to AutoPhar, which owns, administers and manages the selected processes to meet the following objectives: • • • • • •

Identify the influence of compliance and regulatory requirements in the client´s environment Develop solutions to meet the regulatory requirements Develop standardized processes that apply to the clients in the pharmaceutical industry Increase the digitalization rate of client operations Help the clients to get new products to the market faster and safer Allow for an information exchange between the players of pharmaceutical industry

AutoPhar aims to be one of the fastest growing BPO companies worldwide. To do so, the company envisions to offer the capability of adapting its business service provision (BSP), i.e. depending on a number of factors, the service provision and the underlying business processes should be adjusted automatically to the industry landscape of the client. In particular, properties of the client ́s business model (e.g. attractiveness of client ́s market, the amount of emerging players, the influence of regulatory trends and the economic infrastructure) should determine the processes that AutoPhar supports. The capability is termed as “Business model sensitive BPO”. The contextual changes in the business model of the client should be supported as the variants in the business processes (see section 7.2.2), which should be easy to configure for another client ́s case. Both the tasks and their sequences may change, depending on the application context of the service. The aforementioned goals are modelled in Figure 7-12.

12

http://www.integrify.com/workflow-pharmaceuticals-biotech/

236

CaaS


Figure 7-12. Simplified goal model of AutoPhar

7.2.2 High-level Processes

Figure 7-13: High-level process (organizational processes)

The high-level process model showing the process areas is standardized and applied in all industrial landscapes (Figure 7-13). What is adapted to the business model context is represented on a lower level. In the use case, we will take a closer look to that business processes. Planning. This process is executed in two different ways. To select the right variant, the attractiveness of client´s market has to be known. This is obtained by the growth potential of the market and average inflation rate. If the client operates in attractive market, then planning consists of only one activity, namely plan production (see Figure 7-14A). In case of a highly attractive market, demand and supply plan will also be conducted before the production plan (see Figure 7-14B). AutoPhar does not provide service to the clients in unattractive markets.

237

CaaS


Figure 7-14. Variations in "Planning" Process

Procurement. The procurement process can be executed in four different ways, depending both on the attractiveness of client´s market as well as the economic infrastructure in the industrial landscape of the client. The economic infrastructure is obtained by the networked readiness index and a healthcare quality index 13 . A calculation of these values assesses, whether the economic structure is weak or strong. In attractive markets, the procurement plan will be operational regardless of the economic infrastructure of the industrial landscape (see Figure 7-15A), whereas in a highly attractive market, AutoPhar supports development of strategic purchasing plans (see Figure 7-15B). Next, information regarding the ingredients of the respective product is inquired, which can always be purchased from the distributors (see the final activities in Figure 7-15). In the landscapes with high economic infrastructure, enterprises in pharmaceutical industry are well networked and they are allowed to buy the ingredients from each other (Figure 7-15C-D). Development. This process covers two basic tasks, namely product development and creation of the product instructions (see Figure 7-16A). For the client´s that operate in environments with high economic infrastructures, AutoPhar supports creation of online instructions, so that they are also available on the internet (see Figure 7-16B). Regulated Production. The high-level process is only applied to the cases, where the influence of regulatory trends to the operational environment is high. This value is obtained by measuring the number of yearly enforced regulations. In non-regulated markets, AutoPhar skips this high-level process, i.e. the gateway represented in Figure 7-13 is resolved as “No”. If the influence of the regulations is high, then after producing the medicine, three additional activities are conducted, which are illustrated in Figure 7-17. Please note that those activities are skipped in case of a production in a nonregulated environment.

13

https://www.vision2021.ae/en/national-priority-areas/national-key-performance-indicators

238

CaaS


Figure 7-15. Variations in "Procurement" Process

Figure 7-16: Variations in "Development" Process

Figure 7-17. Activities in highly regulated environments

Quality Assurance. This process area is covered with a simple activity, namely “check product quality”, which is represented in Figure 7-18. AutoPhar executes the activity in any possible contexts, i.e. no variants of the depicted process exist.

239

CaaS


Figure 7-18. Single activity in the high-level process “Quality Assurance”

Storage and Delivery. AutoPhar executes the processes related to the post-production based on the level of the economic infrastructure. In the environments with a low economic infrastructure, the product is only stored, delivery activities are not supported (Figure 7-19A). In contrast, if client´s benefits from a higher economic infrastructure, then the product is not only stored but also can be delivered, which requires enabling the supply chain security (Figure 7-19B).

Figure 7-19. Variations in "Storage and Delivery" Process

Sales and Marketing. The sales and marketing activities depend on the number of the emerging players in the environment, where the enterprise operates in. This is obtained by measuring the number of research contractor use, the number of doctors and healthcare providers as well as the number of biotech firms and can assume values low or high. If the value is low, i.e. there are not many emerging players in client´s landscape, AutoPhar aims to strengthen the direct sales and at the same time train the personnel (Figure 7-20A). The increase in the amount of the competitors require investigating more in the sales and marketing process. Concretely, AutoPhar supports strengthening the indirect sales, fostering the customer relationships and preparing marketing campaigns in such cases. Moreover, the complaints for the product are collected and return rates are calculated (Figure 7-20B).

240

CaaS


Figure 7-20. Variations in "Sales and Marketing" Process

Context is the central concept to adjust the capability delivery to the client´s business landscape. Figure 7-21 depicts an example of this, where the processes are executed in an attractive market, which has a low economic infrastructure. Based on the calculations, AutoPhar perceives the amount of emerging players in the area to be low. Apparently, the client operates in a non-regulated landscape, which is why the regulation process is skipped.

Figure 7-21: Process execution in an attractive market with low economic infrastructure and low amount of emerging players

The next example extends the aforementioned case and shows how the process execution is adapted when the influence of regulatory trends changes from low to high. As presented in Figure 7-22, AutoPhar is highly flexible and thus automatically adds the three activities of “Regulated Production” high-level process. Please note that only those three activities represented in Figure 7-17 are placed between the “Development” and “Quality Assurance” process areas, when the environment is highly regulated.

241

CaaS


Figure 7-22. The adaptation of process execution depicted in Figure 7-21 to the application context

7.2.3 Practical Application of Context Modelling Method Component Step 1: Process Model Analysis The business analyst uses the business process models depicted in Figure 7-13, Figure 7-14, Figure 7-15, Figure 7-16, Figure 7-17, Figure 7-18, Figure 7-19 and Figure 7-20 are used as an input in this step. The business process models of AutoPhar are non-consolidated. As addressed in Guideline 3, it is less likely to identify the gateways in such models. Hence, the business analyst documents one gateway (Table 7-6) and continues to investigate the process variants. Table 7-6. Capturing variations

Gateway

Condition

GW1

Regulated market?

Each identified process variant is numbered with the condition causing the execution of the tasks (Table 7-7). Table 7-7. Numbering process variants

Process Condition Variant PV1 PV2

Planning processes according to market attractiveness

PV3 PV4 PV5

Procurement processes according to market attractiveness and the quality of economic infrastructure

PV6 PV7 PV8 PV9 PV10

Development processes according to the quality of economic infrastructure Storage processes according to the quality of economic infrastructure

242

CaaS

PV11 PV12


Sales & Marketing processes, according to the amount of emerging players

Step 2: Context Element Design This step uses the list of process variants and/or gateways that are identified in Step 1 by the business analyst and validated by the business service operator. In Step 2, the capability analyst, business analyst and business service operator study the factors causing variability in the service provision by creating Table 7-8 and Table 7-9. Table 7-8. Identifying and analyzing factors causing variability (gateway view)

Gateway Condition

Gateway analysis

Factor

GW1

Depending, whether the operational environment is affected from the influence of regulatory trends, additional processes are executed.

Influence Strong of regulatory trends

Regulated market?

Goal influence

As illustrated in the last column of Table 7-9, process variants are numbered as gateways. Each factor can be mapped to only one gateway. For instance, the market attractiveness is influencing the planning processes and procurement processes, we still represent it with the same gateway (GW2). This was also expressed as a guideline in the method component (see Guideline 3). Table 7-9. Identifying and analyzing factors causing variability (process variant view)

Process Variant

Condition

Process variants analysis

Factor

Goal influence

Gateway

PV1, PV2

Planning processes according to market attractiveness

Depending on the attractiveness of the market, Planning processes may vary

Market attractive ness

Strong

GW2

PV3, PV4, PV5, PV6

Procurement processes according to market attractiveness and the quality of economic infrastructure

Depending on the attractiveness of the market combined with the quality of economic infrastructure, Procurement processes may vary

Market attractive ness, Quality of economi c infrastru cture

Strong

GW2, 3

PV7, PV8

Development processes according to the

Depending on the quality of economic infrastructure,

Quality of economi

Strong

GW3

243

CaaS


quality of economic infrastructure

Development processes may vary

c infrastru cture

PV9, PV10

Storage processes according to the quality of economic infrastructure

Depending on the quality of economic infrastructure, the processes required for storing a product may vary

Quality of economi c infrastru cture

Strong

GW3

PV11, PV12

Sales & Marketing processes, according to the amount of emerging players

Depending on the amount of emerging players in the market, Sales & Marketing processes may vary

Amount Strong of emerging players

GW4

The next activity filters the factors having a weak contribution to goal fulfilment. In the case of AutoPhar, the identified factors influence goal achievement strongly. To evaluate the gateways, the aforementioned roles apply the dependency analysis (Figure 7-23) and rename the gateways with direct and strong contribution as variation points (Table 7-10). The aim here is modelling the influence of context elements to the business processes and goals by associating them to the special gateways, which we term as variation points.

Table 7-10: Renaming the gateways

Gateway

Variation Point

GW1

VP1

GW2

VP2

GW3

VP3

GW4

VP4

Figure 7-23. Dependency analysis

244

CaaS


Step 3: Context Set Design The stakeholders have an overview of i) the enterprise goals, ii) the BPO service that is to be designed context-aware, iii) the business processes and the context, which is required to adapt the behavior of the application (implementing the right variants). For the “Business model sensitive BPO” capability, , the capability analyst decides that all context elements are relevant and should be selected14. The context model for this capability is illustrated in Figure 7-2415, which is validated by the business service manager.

Figure 7-24. Context model including capability, as a connector of all three views

Step 4: Design Binding This is an optional step. By performing the step, the capability analyst documents the required context providers, calculations and adjustments. The output of this step can be used in Run-time Delivery Adjustments method component by the solution engineer, when for instance the java classes are added to the context model or context providers are created in CCP. The capability analyst first documents the relevant context providers. The context providers are the sources, which provide data to obtain the values of context elements by calculating the measurable properties. By monitoring the changes and calculating the values after each change, the system should be able to adapt its recommendations to the user. For obtaining the values of CE1 market attractiveness and CE4 economic infrastructure, the system should monitor the growth rates from World Bank´s database16. The solution engineer is informed about the selected context providers as well as their communication within the CDD environment. She provides the information that, the name of the respective country should be provided manually, where the 14

One can design other capabilities, such as “Regulation sensitive BPO in attractive markets”. In that case the method user would select two context elements (CE 1 and CE 3), whereas CE1 would only include the range “attractive”. 15 Please note that we do not add the context indicators to the model for the sake of simplicity. 16 http://data.worldbank.org/indicator/NY.GDP.MKTP.KD.ZG

245

CaaS


AutoPhar´s client aims to operate in. Regarding the regulations, “”product market regulation database” of OECD database should be monitored17. Last but not least, the calculate the amount of emerging players, the system is connected with the Global Health Observatory (GHO) database of World Health Organisation (WHO)18. Following that, the capability analyst specifies mathematical operations to define the values of context elements ranges. This is illustrated in Table 7-1119. Table 7-11. Expressing the context calculations

Context Context Calculation Element CE1

CE2

CE3

CE4

Obtained CER from

Growth rate between 9%-14%

MP1

Attractive

Growth rate > 15%

MP1

Highly attractive

Nr. of competitors entered to the market this year / Sum of all competitors 0.3

MP2, MP3

High

Nr. of yearly enforced regulations < 10

MP4

Low

Nr. of yearly enforced regulations >= 10

MP4

High

Country is ranked in the 50 of Networked Readiness Index

MP5

Country is ranked in the top 50 of Healthcare Quality Index

MP6

Country is not ranked in the top 50 of Networked Readiness Index

MP5

Weak

Country is not ranked in the top 50 of Healthcare Quality Index

MP6

Weak

Improved

After that the decision logic is specified, i.e. which action should the application recommend to the user in what circumstances. This is termed in CDD methodology as adjustments, because the system behaviour (in that case, the implementation of the right process variant or pattern) is adapted in accordance with the specified adjustments. The adjustments are shown in Table 7-12. Table 7-12. Expressing the adjustments

Adjustment

Process Variant

17

http://www.oecd.org/eco/growth/indicatorsofproductmarketregulationhomepage.htm http://www.who.int/gho/database/en/ 19 As we did not specify context indicators in step 3 for brevity reasons, we do not document here how they are calculated (context indicator calculation). 18

246

CaaS


If market attractiveness = “highly attractive” AND amount of emerging players = “high” AND influence of regulatory trends = “low” AND economic infrastructure = “weak”

PV1

If market attractiveness = “highly attractive” AND amount of emerging players = “high” AND influence of regulatory trends = “high” AND economic infrastructure = “weak”

PV2

If market attractiveness = “highly attractive” AND amount of emerging players = “high” AND influence of regulatory trends = “low” AND economic infrastructure = “improved”

PV3

If market attractiveness = “highly attractive” AND amount of emerging players = “low” AND influence of regulatory trends = “low” AND economic infrastructure = “weak”

PV4

If market attractiveness = “attractive” AND amount of emerging players = “low” AND influence of regulatory trends = “low” AND PV5 economic infrastructure = “weak” If market attractiveness = “attractive” AND amount of emerging players = “low” AND influence of regulatory trends = “high” AND economic infrastructure = “weak”

PV6

…

…

7.3 Application in SIV Case In this section we demonstrate how the context modelling method component (cf. Section 3.4) can be applied to SIV´s case, which is detailed in D2.2, D2.3 and the extra report.

7.3.1 Enterprise objectives SIV Group aims to constantly deliver value to the kVASy clients, which outsource clearing services to SIV Utility GmbH. One way to fulfil this main goal is implementing the change requests of the clients of SIV Utility Services in an agile way, i.e. quickly adapting to the regulatory changes in the market communication, supporting the message exchange between utility market players. The business vision of the enterprise is depicted in Figure 7-25 which is associated with the goals of the utility companies20.

20

The detailed enterprise objectives of SIV Group can be found in D2.3, section 3

247

CaaS


Figure 7-25: Simplified Goal Model of SIV Group

7.3.2 High-level Processes Creation and execution of a process instance is always triggered by the occurrence of an exception in the client’s ERP system. Clearing is a multiply nested process consisting of a top layer (see A in Figure 7-26) and at least two sub-processes. The former basically represents the decision logic, whether or not the BSP shall clear the current case. The latter consists of two levels. In the 1st level, the knowledge worker distinguishes between the cases to select the appropriate clearing pattern from the repository (see B Figure 7-26). In the 2nd level, usually small sections of the handling instructions selected in the 1st level are altered (see Figure 7-28).

Figure 7-26: High-level clearing process

A detailed illustration of the 1st level sub-process is provided in Figure 7-27, where the 248

CaaS


knowledge worker clears the exceptional case based on a certain handling instruction. Here, each path corresponds to a specific handling instruction. A handling instruction may thus be considered a best practice (pattern). The type of the current exception decides on the pattern that is to be chosen from the repository. Currently, there are 15 different solutions for each exception type.

Figure 7-27: 1st level sub-process to implement the appropriate handling instructions

7.3.3 Practical Application of Context Modelling Method Component Step 1: Process Model Analysis The input to this step is the process models of the clearing capability and textual information (secondary data) about them. After a thorough analysis, the business analyst identifies in the following the locations where variability happens (Table 7-13). Table 7-13: Capturing the gateways

Gateway

Condition

GW1

Is the BSP responsible?

GW2

Which handling instruction is appropriate to clear this exception?

GW3

Specific condition 1

GWn

Specific condition n

On the 2nd sub-process level, there are gateways that regard to very specific conditions, 249

CaaS


such as whether the client is allowed to make changes in the values transmitted by UTILMD messages. An example of this is shown in Figure 7-28. Such gateways are also documented, but for the simplicity purposes we do not illustrate all of them and represent these as GW3 and GWn, both of require very specific conditions to be resolved.

Figure 7-28: Process model for clearing exception type „NZM-1122“.

Step 2: Context Element Design This step uses the list of process variants and/or gateways that are identified by the business analyst and validated by the business service operator in Step 1. In Step 2, the capability analyst, business analyst and business service operator are responsible for studying the factors causing variability. For this, they use the list of gateways (see Table 7-13) and alter it by adding the columns “gateway analysis” and “factor”. For each gateway, they should denote why they are needed (Table 7-14). Table 7-14: Identifying and analysing factors causing variability

Gateway Condition

Gateway analysis

Factor

Goal influence

Backlog difference, Market role, Commodity, Exception type, Contract time span

Strong

Exception type

Strong

GW1

Is the BSP responsible?

Clearing can be done either by the client or by the SIV Utility Services GmbH. This gateways is required to determine, which party is responsible for clearing

GW2

Which handling instruction is appropriate to clear this exception?

A handling instruction specifies operative conditions, upon which the service provider shall take care of failed MSCONS process

250

CaaS


instances. The gateway is required to find out, which handling instruction should be followed to clear the case.

GW3

Specific condition

Small sections of handling instructions

The analysis scope is very narrow, hence not considered relevant

Weak

GWn

Specific condition

Small sections of handling instructions

The analysis scope is very narrow, hence not considered relevant

Weak

The gateways are analysed by extracting the exact factors that help to resolve them. Here, it becomes clear that only gateways GW1 and GW2 contribute to the goals. Hence, the dependency analysis is conducted within the remaining gateways, where the relationship between GW1 and GW2 is investigated. This is depicted in Figure 7-29. Following this, only the GW1 is renamed as VP1, i.e. the exact location in the business process model that requires run-time context information in order to proceed further (Table 7-15) GW2 depends on GW1, meaning that i) the evaluation of GW2 is determined by GW1 and ii) the associated factor is already represented within GW1. For instance, if the BSP is not responsible for clearing the case, then GW2 is irrelevant. In the opposite case, the system already knows the factor needed to resolve GW1, namely exception type.

Figure 7-29: Dependency analysis in SIV case Table 7-15: Renaming the gateways as variation points

Gateway

Variation Point

GW1

VP1

The factors causing variability in the business processes are analysed and discussed with domain experts thoroughly. As a result, the factors that have both strong and direct influence on goals as context elements (cf. Table 7-14 and Figure 7-29). The aforementioned results are enriched with the findings from the investigation of secondary data (see also D2.2), which pointed out the measurable properties that are 251

CaaS


required to determine the value of the context elements. The initial context model including the context elements and measurable properties are shown in Figure 7-30.

Figure 7-30: Initial context model

Step 3: Context Set Design SIV will only have one capability (dynamic clearing of the cases), which includes all of the context elements. The capability model is going to be exported to the CNA only once. After exporting the capability model to CNA, different deployments (per client) will be created. Each client will have a unique “clientID” and each clearing case will have a “caseID” (cf. D2.3). A context element range is inseparably connected to the capability. Since the associated roles opt having only one capability, the concept context element range represents in that case the property of the capability as such and not a client’s specific contractual

252

CaaS


context21. The resulting context model including the capability and goals are illustrated in Figure 7-31.

Figure 7-31: Extended context model, including capabilities, processes and goals

Step 4: Design Binding By performing this optional step, the capability analyst documents the required context providers, calculations and adjustments. The output of this step can be used in Run-time Delivery Adjustments method component by the solution engineer, when for instance the java classes are added to the context model or context providers are created in CCP. The capability analyst defines context providers as process monitor and clearing policy. The former provides the CNA with the relevant properties of the exceptional message such as the market role, as well as the values of the current backlog for a specific client. The latter monitors and pushes the value changes in the agreement between the client and SIV Utility Services GmbH. Following that, the capability analyst documents mathematical operations to define the values of context elements ranges. Table 7-16: Adding context calculations to the context model

Context element Backlog difference

Context element calculation ∆𝐵 = 𝐵 − 𝐵!"#$#!%&

Obtained CER from MP1 MP2

Difference >0

21

As a result, context element ranges in that case will always reflect what the capability in question can do and not what may be applicable for any individual client. Example: The context element “commodity” will have the range: [“electricity”, “natural gas”, “district heating”, “water”], even if a given client has only contracted [“electricity”], i.e. has contracted a subset of what is actually possible. In this sense context element ranges are a maximal ranges.

253

CaaS


(∆𝐵) Market role (𝑅)

𝑅 =

Commodity (𝐸)

𝐸 =

Contract time span (𝐿)

𝐿 = 𝐹

Exception type (𝐹)

=

𝐹! ,

1,

if 𝑅Promo ∈ {𝑅}Policy 0, else

MP3 MP4

[LF,NB]

1,

if 𝐸Promo ∈ {𝐸}Policy 0, else

MP5 MP6

[E,G,F,W]

if 𝑇!"#$% ≤ 𝑡 ≤ 𝑇!"# 0, 𝑒𝑙𝑠𝑒

MP8

[Valid contract]

MP7

[𝐹!,…, 𝐹! ]

1,

if 𝐹Promo ∈ 𝐹! , 𝐹! , … , 𝐹! , 𝑤ℎ𝑒𝑟𝑒 𝑘 = 1, ⋯ , 𝑁 0, else

Following the calculations of the context elements, the adjustments need to be specified, i.e. which action should the application recommend to the user in what circumstances. The adjustments are shown in Table 7-12. Table 7-17: Expressing the adjustments

Adjustment 𝑃! = 𝑃! = 𝑃! =

Pattern

𝑋! ,

if (𝐹 = 𝐹! ) ˄ (∆𝐵 > 0) ˄ (𝑅 = 1) ˄ (𝐸 = 1) ˄ (𝐿 = 1) Pattern 1 false, else

𝑋! ,

if (𝐹 = 𝐹! ) ˄ (∆𝐵 > 0) ˄ (𝑅 = 1) ˄ (𝐸 = 1) ˄ (𝐿 = 1) Pattern 2 false, else

𝑋! ,

if (𝐹 = 𝐹! ) ˄ (∆𝐵 > 0) ˄ (𝑅 = 1) ˄ (𝐸 = 1) ˄ (𝐿 = 1) Pattern n false, else

254

CaaS


8. Appendix C: Example of using Scheduled Adjustment for capability delivery The example is used to illustrate usage of scheduled adjustments. The scheduled adjustment is exemplified as a part of the Cloud service scaling capability. This capability enables digital enterprises to run their services on the basis of scalable cloud computing resources. It considers on-demand scaling of computational resources in the cloud. Different methods and computational platforms have been proposed to address this issue (e.g., Han et al. (2012) and Lorido-Botran et al. (2014)). The methods differ by scaling algorithms used, performance measures used and contextual factors considered. The proposed application of capability modelling and run-time adjustments allows for flexibility to use these different algorithms, performance measures and contextual factors within a single framework. The Cloud service scaling capability is shown Figure 8-1. It is assumed that a company delivers a service using appropriate CDA. This service has high computational requirements and volatile load. For instance, in the PMO scenario municipality services has highly variable load depending on calendar events. The capability does not concern the service itself but deals with scaling of computational resources available to the service. These computational resources are provided by a cloud platform, which is external to the service delivery CDA though its performance can be observed by means of context monitoring and adjustments can change its characteristics. The capability model shows main goals and context factors relevant to the capability. Scaling in the cloud platform is achieved by adding additional containers executing service delivery logics. Using additional containers allows performing computations faster while that also incurs additional cost. There is a strong motivation to have an optimal number of containers. The service requests, which cannot be processed immediately, are stored in the messaging queue. Queuing of messages affects service delivery time. However, the message queue waiting time is measured in the cloud platform as context while service delivery time is measured in CDA as KPI. The capability model is modified to include adjustments and their implementation logics following the procedure described in method components Adjustment Modelling and Design and Adjustment Implementation and Delivery.

255

CaaS


Figure 8-1. Cloud service scaling capability.

8.1 Adjustment modelling and design The adjustment modelling and design is performed in CDT and takes the initial capability design as an input. That adds technical details about context processing and adjustments. For instance, the initial model shows that Message queue waiting time measurable property measures Message queue waiting time context element without specifying further details. This additional information is added in the following steps. Step 1 Add adjustments to the model

Calculations and adjustments are added to the capability design (Figure 8-2). The figure shows that context calculation MsgQueueWaitTimeCtxCalculation is added to the models. It is responsible for transforming Message queue waiting time measurable property in the corresponding context element. The scheduled adjustment is also added in the model. This adjustment will be invoked periodically to change characteristics of the cloud platform used to deliver digital services.

256

CaaS


Figure 8-2. Selected calculations and adjustments added to a fragment of the capability design Step 2 Add constants to the model & Step 3 Perform IDA

The calculations and adjustments were added to the capability design and associated with their corresponding elements. However, other elements from the models such KPI, adjustments constants and other context elements could be used in calculations. In step 2, adjustment constant managed by CNA are added. The MaxNodesAdjConst adjustment constant is added in the example (Figure 8-2). This constant restricts the maximum number of containers activated in the cloud platform. It can be adapted during the run-time if the current maximum level is too restrictive. The data bindings established by performing IDA are underlined in the figure. As the result, the bound elements can be used in the corresponding calculations and adjustments.

257

CaaS


Figure 8-3. Data bindings and adjustment constant added to the model (a fragment).

8.2 Adjustment implementation and delivery Previously added elements serve as containers for implementing calculations and adjustments. In order to perform these calculations and adjustments during the capability delivery, their computational logics should be developed. Step 1 Implement and validate adjustments

In this case, the computational logics is developed using Java programming language. Computations can be of various complexity. Figure 8-4 shows calculation of the Messaging Queue Waiting Time context element using MsgQueueWaitTimeCtxCalc element. This elements contains the Java code performing a simple transformation of the raw measurable property received from CCP. Figure 8-5 shows implementation of the ScaleCloudResourcesSchAdj scheduled adjustment. The adjustment uses run-time data values from other elements of the capability design either to increase the number of containers or to reduce the number of containers depending on the current context situation. The scaling decision is made according the adjustment rules specified in the model. An actual scaling is performed by invoking cloud platform API (the call is implemented using the scale function).

258

CaaS


Figure 8-4. A sample context calculation package Mosaic; import import import import import import

java.io.BufferedReader; java.io.DataOutputStream; java.io.IOException; java.io.InputStreamReader; java.net.HttpURLConnection; java.net.URL;

public class ScaleScheduledAdjustment { public String execute(int min_nodes, int max_nodes, int max_wait_time, int queue_size, int nodes_count, int avg_time_in_queue, int busy_nodes) { try { // Empty queues and surplus of workers if (min_nodes < 1) return ""; this.debug("nodes cur-" + nodes_count + " min-" + min_nodes + " max-" + max_nodes + " busy-" + busy_nodes); // Scale up if requests in queue, average time exceeds constant and // max nodes not reached if ((queue_size > 0) && (avg_time_in_queue > max_wait_time) && (nodes_count min_nodes) && (min_nodes > 0) && (busy_nodes < nodes_count)) { String response = this.scale("down");

259

CaaS


}

return + + +

"CASE2: scaling down to " Integer.toString(nodes_count - 1) + " nodes (cur:" nodes_count + " min:" + min_nodes + " max:" max_nodes + ") " + response;

// Scale up if node count is less than min else if (nodes_count < min_nodes) { this.scale("up"); return "CASE3: scaling up to " + Integer.toString(nodes_count + 1) + " nodes (cur:" + nodes_count + " min:" + min_nodes + " max:" + max_nodes + ")"; } // Scale down if node count is larger than max else if (nodes_count > max_nodes) { this.scale("down"); return "CASE4: scaling down to " + Integer.toString(nodes_count + 1) + " nodes (cur:" + nodes_count + " min:" + min_nodes + " max:" + max_nodes + ")"; } // Scale up if number of workers is twice smaller than queue size // and max node count not reached else if (nodes_count < max_nodes && (nodes_count < (queue_size / 2))) { this.scale("up"); return "CASE5: scaling up to " + Integer.toString(nodes_count + 1) + " nodes (cur:" + nodes_count + " min:" + min_nodes + " max:" + max_nodes + ")"; } else return "CASE6:no scaling needed (cur:" + nodes_count + " min:" + min_nodes + " max:" + max_nodes + ")"; } catch (Exception e) { return "ERR:Got error while scaling"; } }

Figure 8-5. Java code implementing ScaleCloudResourcesSchAdj scheduled adjustment Step 2 Deploy to CNA

Adjustments and constants are deployed to CNA using CDT. Figure 8-6 shows CNA generated for the Cloud service scaling capability. The Indicators panel allows monitoring current values of context indicators and KPI. User can choose which indicators to display and configure appearance of the indicators. The Constants panel shows constants deployed from the capability model and allows changing values of these constants. The Context Set panel monitors capability suitability for the current context situation. The Event Log panel lists all adjustments performed during the capability delivery.

260

CaaS


Figure 8-6. CNA of the Cloud service scaling capability: a) indicators; b) adjustment constants; c) context situation monitoring; and d) log of adjustments.

261

CaaS


9. Appendix D: Example of Performance Based Context Evaluation Adjustment Application of the performance based context evaluation adjustment is illustrated using the travel management exampled also discussed in deliverable D1.4. The overall travel management process delivering the Travel Management capability consists of four main activities (Figure 9-1). The travel planning specifies purpose, destination and time of the business trip. The travel budgeting specifies the planned travel expenses in compliance with internal and external regulatory requirements. During the trip, the travel objectives are achieved and expenses are accumulated. The travel results and expenses are reported upon returning. The capability delivery is affected by several contextual factors such as travel conditions and related calendar events. Adjustments are used to

Figure 9-1. Overall travel management process

Step 1 Define goals and KPI The Travel Management capability goals and associated KPI important to the adjustment are given in Table 9-1. Trips are affected by different types of uncertainties such as weather conditions and unexpected events. These uncertainties might cause delays leading to extra costs and scheduling conflicts. Goal G1 sets travel planning policies of minimizing risks associated with such delays. Travels take time away from other activities, and the organization aims to ensure that traveling is complementary to the primary duties with a minimum adverse effect (G2). Travel management involves a certain amount of paperwork and it is aimed to streamline the travel management procedures and to avoid extra paperwork (G3). Additional paperwork frequently occurs because of extra travel costs, travelling delays and scheduling conflicts. E.g., in case of many scheduling conflicts an employee has to spend time on rescheduling, finding replacements etc. Table 9-1. Selected travel management goals and associated performance indicators

Goal

Key Performance indicator

G1. To complete trip on time

I4. Number of trips not completed on time I5. Sum of days late

G2. To minimize scheduling conflicts

I6. Average severity of scheduling conflicts

G3. To minimize travel management paperwork

I7. Percentage of trips requiring additional evaluation/approvals

KPI I6 and I7 reference to goals G2 and G3, measure the travel planning activity and the target values are set as 0.1 and 20%, respectively. I6 is evaluated as weighted and normalized sum of overlapping hours during the trip and I7 is measured as a percentage of trips categorized as having significant of critical conflict and thus requiring additional conflict resolution (rescheduling, finding replacement etc.). 262

CaaS


Achievement of the goals depends on different environmental factors and circumstances. For instance, travel costs might increase because of a major event taking places at the planned destination, or a trip cannot be completed on time because of bad weather or unexpected important events are added to the organizational calendar. The process execution context can capture some of these circumstances. Therefore, contextualization of the travel management process is highly desirable.

Step 2 Define context calculation As an example, the travel planning activity of the travel management is contextualized (Figure 9-2). The travel planning tasks are affected by such context factors are travel conditions, calendar and weather. The travel conditions characterizes general conditions at the planned destination, e.g., the USA State Department issuing warnings and alerts for visiting certain countries. The calendar represents a university-wide calendar of events to evaluate significance of overlapping between planned travel dates and other events. The calendar contains both general events of varying importance and events assigned to specific employees. The weather context affects ability to complete trips on time what is more relevant to the Taking the trip activity while depending on planning horizon and type of weather conditions they can affect travel planning as well.

Figure 9-2. The expanded travel planning activity

The example focuses on capability delivery adjustment to achieve goals G2 and G3, which are affected by the calendar context element. The calendar context element is defined in Table 9-2. It relies on the organization-wide calendar of events to evaluate the significance of overlapping between planned travel dates and other events. The calendar contains both general events of varying importance and events assigned to specific employees.

263

CaaS


Table 9-2. Definition of the Calendar context element

Context element Calendar

Measurable properties

Context Element Range p1 is the count of the scheduled hours of regular No conflict, Mild importance overlapping with travel dates conflict, p2 is the count of the scheduled hours assigned to the Significant employee and overlapping with the travel dates conflict, Critical p3 is the count of the scheduled hours overlapping with Conflict the travel dates and marked as high importance

The intermediate context element value is calculated as (and formally specified using ContextCalculation class): Vc =

w1 p1 +w2 p2 +w3 p3 w3 H

where c refers to the calendar context element, H is the total duration of the trip in hours, p1 is the count of the scheduled hours of regular importance overlapping with travel dates, p2 is the count of the scheduled hours assigned to the employee and overlapping with the travel dates, p3 is the count of the scheduled hours overlapping with the travel dates and marked as high importance, and wj are appropriate weight coefficients indicating importance of every measurable property in calculating the measure. The context element value calculated ContextCalculation class):

as

(and

formally

specified

using

⎧⎪r , b L ≤ Vi < bijU , Cc = ⎨ ij ij U ⎪⎩ riN ,Vi ≥ biN −1

where Cc is the context value bcL = ( j − 1)ΔVc is the lower bound for jth range, bcL = j × ΔVc is the upper bound for the jth range and ΔVi = ( max(Vc ) − min(Vc ) ) 4

Step 3 Define performance adjustment The context element calculation defined in the previous step is static and can be adjusted only manually. In order to support automatic adjustment, it is parameterized using the adjustment parameter ϖ and redefining the context calculation using bcjL = ω( j − 1)ΔVc and bijU = ω × j ×ΔVc . The adjustment parameter is changed during the capability delivery according the degree of goals’ attainment as defined in Step 3 in Section 3.5.6. The business logics for making this adjustment is that: 1. More trips categorized as having a high level of conflict results into increasing amount of paperwork, thus, negatively affecting goal G3; 2. More trips categorized as having a low level of conflict results into increasing level of scheduling conflicts, thus, negatively affecting goal G2. The goals are mutually contradicting. Achieving G3 would favor adjustment by decreasing ω while achieving G2 would favor adjustment by increasing ω . 264

CaaS


The impact of ω on context range evaluation is illustrated in Figure 9-3, where context element category is shown depending on the intermediate context element value. ω = 1 gives evenly distributed ranges of context values. If ω is increased more context values are categorized to belonging to the upper categories. If ω is decreased majority of context values fall into the lower categories. ω=0.5

r4

ω=1 ω=2

R

r3 r2 r1 V

Figure 9-3. Impact of ω on context range evaluation

Step 4 Monitor capability delivery Simulation is used to evaluate the capability delivery. The capability delivery is simulated as follows: 1. 2. 3. 4.

Generate trip data including starting date, duration and destination. Generate the measurable properties. Evaluate context category. Simulate scheduling conflict resolution. If the resolution activity is required then it is assumed that an employee reduces the number of overlapping number by a certain amount. 5. Evaluate process performance. 6. Update ω using. The trip duration is distributed as N(4,1), where N denotes normal distribution with mean 4 and standard deviation 1. Similarly, measurable properties p1, p2 and p3 are generated using N(1,1), N(2,1) and N(0.8, 0.5), respectively. The conflict resolution is simulated using the following rules. If Rc = ”No conflict” no adjustment is performed. If Rc = “Mild conflict” then a non-binding warning is displayed to an employee about presence of the scheduling conflict and the employee voluntary resolves some of the scheduling conflicts. The reduction is done by h percent where h1~N(10,5) (it is applied to all measurable properties). If Rc ∈ (Significant conflict, Critical conflict ) an employee enters the conflict resolution task resulting in conflict reduction by h percent, where h is distributed N(30,10) and N(75,25) for respective categories. These values imply that all conflicts are not necessarily resolved, though the percentage of conflicts resolved correlates with the severity of scheduling conflicts as identified by the calendar context element. The initial value of ω = 1 and that yields the capability delivery performance bellow the target values (first row of Table 9-3).

265

CaaS


Step 5 Adjust context range evaluation The context processing adjustment is performed according to both I6 and I7. ω is increased if the I6 target is not met and is decreased if I7 target is not met. The starting value of ω is one. 500 trips are simulated and ω is updated after every 10 trips with Δω = 0.1 . Figure 9-4 shows the convergence of ω values according to a number of adjustments performed. It suggests that the search procedure quickly identifies an improved categorization of the Calendar context element. Settling on ω < 1 indicates that the process goals can be better achieved if fewer cases are categorized as having high level of conflict. ω fluctuates between 0.5 and 0.6 because G4 and G5 are contradicting each other and an equilibrium satisfying both goals cannot be found (Table 9-3). At ω = 0.5 , the paperwork reduction target is achieved while the severity of scheduling conflicts target is not satisfied. Increasing of ω leads to deterioration of I7. The table also reports evaluation results for two other selected values of ω . These evaluation results shows that for the particular case the adjustment alone cannot ensure achieving of all business goals and other process improvement options should be considered, too. 1.2 1

ω

0.8 0.6 0.4 0.2 0 0

5

10 Trips x 10

15

20

Figure 9-4. Convergence of ω Table 9-3. Business process performance

ω

1 (initial) 0.5 (adjusted) 0.6 (adjusted) 2 0.2

I6 0.07 0.14 0.13 0.04 0.15

I7 93 1 15 99 0

The evaluation results depend upon the way I6 is calculated and other parameters. These parameters are set up during the context aware process design and can be updated during the process execution if necessary.

266