Value-Based and Context-Aware Selection of Software-Service Bundles: A Capability Based Method

. In many application areas, vendors offer to their clients combinations of software products and services, which can be considered as software-service bundles. The clients select a combination of software product and associated service best suited to their individual requirements and circumstances. The bundle usually has to be configured by the vendor to fit the specific situation of the client. When circumstances change, the software-service bundle or its configuration need adaptation. The article proposes a method helping clients to select the most appropriate combination or configuration. The method is based on information sharing between the vendor and client and also supports the continuous improvement of the solution in response to changing circumstances. The method applies principles and techniques of the Capability Driven Development to specify performance objectives and contextual factors affecting delivery of a software-service bundle. Application of the method is shown using an illustrative case of a data processing service from utility industries.


Introduction
In many application areas, vendors offer combinations of software products and services that provide packaged offerings for specific applications.Such software-service bundles are provided by vendors as solutions to their clients.Depending on the client individual requirements and circumstances, the solutions have different configurations with regards to functionality provided.The configurations also differ by costs borne and benefits attained by clients.In order to nurture long-term vendor-client relationships, both parties are interested in rightsizing the service offering to maximize benefits [1].
Balancing of client needs, functional capabilities, and associated development costs have long been acknowledged in the software engineering community.The Boehm's spiral model [2] for software development emphasized that in every iteration before adding new features a costbenefit analysis should be conducted.Taudes et al. use option pricing models to evaluate information technology investment decisions and apply these models in software upgrading case study [3].These early works focus on individual software applications rather than on software families and related services.Software product line engineering [4] investigates the problem of constructing the software solutions efficiently from the vendor perspective.Clients on the other hand are interested in the most feasible and efficient solution meeting their specific requirements.This problem is investigated in research on software selection [5] though this research mainly takes into account information available to a client, i.e., the vendor perspective is neglected.However, vendors have a wealth of information about their software's use by different clients [6].This information could include contextual information about specific operating circumstances of individual clients as well as information dependencies between specific configurations of the solutions and the achieved performance.It is argued that by sharing historical context and performance data vendors and clients can collaborate for finding the right configuration for every client.This way every client would be provided a configuration appropriate for its operating context as well as estimates of expected performance of the solution [7].From a service science perspective, the collaboration between client and vendor (i.e., cocreation of value) is considered as precondition for successfully implementing the service part of software-service bundles.Data and knowledge sharing has been shown to create substantial mutual benefits by suing techniques such as vendor managed inventory [8] and best practice based configuration of enterprise applications [9].
In order to enable the aforementioned approach, a framework for defining contextual information and performance objectives is required.Recently, capability driven development (CDD) has been proposed as an approach for ensuring that solutions can be delivered in different contexts at the desired level of performance [10].The approach presumes that rather than providing a simple business solution the vendor possesses certain capabilities and is able to provide such a capability to its clients facing different operating circumstances.It is a model based approach and encompasses three development phases: 1) capability design explicitly defines performance goals, context factors affecting capability delivery, and context-dependent capability delivery solutions; 2) capability delivery phase concerns monitoring of context and performance data and adjusting the solution in response to changes in these data; and 3) feedback phase provides information for updating of the initial design.
The objective of this article is to elaborate a CDD based method allowing collaboration between vendor and client in selection of the right configuration of software-service bundles and continuous improvement of the selected configuration.It is assumed that a vendor has multiple clients.The clients share usage information about the software-service bundle.In the case of preparing a bundle for a new client, this information is used to create a decision-making matrix for selecting an appropriate configuration for this new client.The new client usually starts with a minimum satisfactory configuration; performance of this configuration is continuously monitored and if necessary the client upgrades its configuration which here is referred to as evolutionary development in analogy to evolutionary software development [11].
The main contributions of the article are: 1) combination of vendor and client perspectives in an information sharing based method for selection of software-service bundles; and 2) selection of software-service bundle as an interplay among contextual data and performance objectives (i.e., selection is made in a context-aware performance driven fashion).The rest of the article is organized as follows.Section 2 provides overview of the method.Section 3 elaborates stages of the evolutionary development.The application example is provided in Section 4. Related work is reviewed in Section 5. Section 6 summarizes findings and future work.

Method Overview
The evolutionary development method for software-service bundles is based on the CDD approach and uses the capability model underlying the software-service bundle as a starting point for providing appropriate configurations to clients.

Problem Statement
The vendor offers its clients a software-service bundle S. The software-service bundle 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 software-service bundle.
S is provided in one of N configurations ,..., 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 (KPIs) during operations of the software-service bundle.
Figure 1 illustrates the software-service bundle selection problem.The illustration shows that the vendor maintains a set of predefined configurations, which are used by the existing clients.The usage information from the clients is accumulated in the performance and context data database.A new client together with the vendor identify his context situation and use it to select an appropriate configuration.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 circumstances 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 softwareservice bundle.In the latter case, an existing client switches from one configuration to another to adapt to the changing circumstances.

Evolutionary Development Process
The aforementioned challenges are addressed following an evolutionary development process (Figure 2).A vendor uses the CDD approach [10] to develop a capability model.The model specifies capability delivery goals, context, and solutions (i.e., software-service bundles and their appropriate configuration) for capability delivery offered to clients (see Section 2.3 for further discussion).The capability model covers all configurations supported by the vendor.Relationships among context situations and configurations are described in a capability support matrix (CSM).The matrix indicates configurations suitable for a particular context situation.It is used by the vendor and clients to find appropriate solution for client needs.CSM is developed on the basis of historical data analysis or according to judgment of the vendor.CSM defines whether a configuration meets client requirements while a service-software bundle (SSB) selection model addresses business value concerns.It evaluates expected returns from using a particular configuration.These expected returns are computed according to the goals specified in the capability model.
Upon engaging a new client, its typical context situation is assessed and the most beneficial configuration supporting this context situation is selected.The most beneficial configuration is evaluated using the SSB selection model, which is configured according to the needs of the new client by weighting his most important selection considerations.The selected configuration is provided to the client.It is used for capability delivery and delivery performance is monitored using the indicators defined in 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 configuration; or 2) designing a new solution.The capability monitoring and adjustment are performed cyclically and the capability delivery solution evolves according to the business requirements of the client.The vendor accumulates capability delivery performance and context data from multiple clients and uses this information to update the capability delivery solution and validate CSM.

Capability Modeling
The capability model defines vendor's ability and capacity to provide a solution to clients facing specific circumstances.Figure 3 provides a simplified overview of the key elements used in capability modeling as well as their relation to the configuration concept used in this article.Goals are business objectives the capability allows to achieve.They are measured by KPIs.The capability is designed for delivery in a specific context as defined using context elements.The context elements name factors affecting the capability delivery while context situations refer to combinations of context element values.The process element specifies a capability delivery solution.Process variants describe the capability delivery process for a specific context situation while the associated configuration of the solution encompasses all technical, human, and knowledge resources necessary to execute the process.Consequently, the configuration enables capability delivery.Multiple configurations can be used for capability delivery.
A configuration can include multiple process variants.The client can switch from one process variant to another or invoke them simultaneously during solution delivery depending on context situation.
In order to ensure that capability is delivered as expected in different contextual situations, adjustments are used to adapt capability delivery [12].The adjustments take context data and KPIs as input and evaluate potential changes in capability delivery.Changing the configuration from one to another is perceived as one of the possible adjustments.Thus, the adjustments can be used to implement the SSB selection model.From the evolutionary development perspective, the key aspects are that: 1) capability can be delivered in different context situations while each individual client faces just some of these context situations; 2) process variants specify a solution for dealing with one or several context situations (for software-service bundle these variants cover both, different process variants in the software product if this product has a process-oriented architecture and different variants for the service bundled with the software product as a part of configurations); and 3) relationships among context situations, performance, and process variants are not necessarily known in advance and can be induced from the solution's usage data.

Evolutionary Development Stages
The evolutionary development process includes two distinctive phases: 1) design stagewhen the initial configuration of the software-service bundle is selected and deployed for a new client; and 2) delivery stagewhen the software-service bundle is used by the client and it is adjusted according to changing circumstances.

Design Stage
During the design stage, SSB is selected by matching context situations and by evaluating expected business value of tentative configurations.

Matching Context Situations
At the beginning of the design stage the vendor develops a capability model corresponding to the software-service bundle to be provided to clients.Every context factor used in selection of the configuration has a finite set of values or context range 1 ( ,..., ) , where i T represents a number of values for the ith context element.These values are obtained by categorizing actual values of context observations also referred as to measurable properties [13].The categories enable for relative comparison of clients.
Combination of context element values form the context range yields a set of context situations 11 ( ,..., ) ...
(H is the number of context situations).CSM is defined as a matrix with elements , 1,..., , 1,..., , where relates context situations to suitable configurations.The matrix element 1 ij a  indicates that configuration O j is suitable in the case of context situation CS i .The same configuration could be suitable for multiple context situations.One configuration could encompass multiple process variants.
Upon engaging a new client, its most plausible context situation is identified as CS new .Appropriate solutions are identified by where  is a set of matching configurations for the new client.
Eq. 1 finds matching configurations appropriate for the context situation faced by the new client.If no appropriate configuration is available, the client has a choice to select a configuration having the highest level of overlapping with support context situations.

Value-Based Selection
The context matching step yields a set of tentative configurations without a regard to their potential business value balancing costs and benefits associated with using a particular configuration.It assumed that the value-based selection can be conducted on the basis of information provided in the goal model of the overall capability model.It selects the configuration providing the best expected business value what is formally expressed as 11 max( ( )) ( ,..., , ,..., ) V is an estimated SSB value for the client depending on the configuration selected, the superscript refers to the new client, 1 ,.During the design stage (t = 0) some of the KPI values are known, some can be estimated and some are known or irrelevant.The weights set to zero for the latter KPI.An example of the known KPI is fixed licensing fee while fee per every service request can only be estimated during the design stage.
The value calculation function F is specified in the capability model as an adjustment.That enables specification of any desired functional form of the function and the same specification can be used during the run-time to evaluate a need for switching to a new configuration.
Assuming that a client sets target values for KPI 1 ,....,  , where the subscript l refers to the KPI, an exact form of the value function can be specified as a weighted sum of ratios between KPI values and their targets (Eq.3).
  where if KPI and business value are positively correlated, otherwise The configuration selected based on the above considerations is set up for the client and made ready for operations.In this context, there might be a setup time required for deploying the configuration.

Delivery Stage
During the delivery stage, actual context situations and delivery performance are monitored.The performance monitoring is carried out by gathering real-time values of KPI new it K , where superscript identifies the client, the subscript i refers to KPI being measured and t refers to the measurement time.The current value is compared to the performance target.If new new it i K   then the ith performance objective is not met and a recommendation to revise the solution is issued.Obviously, one should evaluate to what extent the software solution is responsible for underperformance.
The context monitoring is performed by comparing the observed context situation new t CS for the new client at the tth time moment to the context situations supported by the current configuration, i.e., relationship new tO CS  CS , where O CS is a set of context situations supported by configuration O j used by the client.If the relationship does not hold then a warning is issued notifying that the observed context situation is not explicitly supported by the current configuration.The context monitoring serves as an advanced warning system to potential performance deterioration since it is not known whether the current configuration is suitable for the observed context situation.That might lead to an unexpected behavior.

Evolution
Evolution in software and systems engineering commonly is described as the process of gradually adapting a (software) system to requirements and changes which could not be anticipated at the time of systems development, but occurred during its time of use [14].Three main causes for the evolution of a software-service bundle can be distinguished: (1) the client's requirements regarding the service remain unchanged but runtime shows that the features of the software do no longer meet these requirements, (2) the client demands regarding the service change and require changes in the software, and (3) the vendor's requirements to the software change and require changes in the software-service bundle.
In this article, the focus is on the first cause, i.e., when the software during runtime does not longer meet the requirements.Violations of performance objectives or observation of unsupported context situations triggers a warning suggesting an upgrade of the current configuration.In response to this warning a client might decide on upgrading the current configuration by selecting a more suitable configuration from CSM.This is a suitable approach if the actual context situation is different from the one identified during the design stage or it has changed.However, if underperformance is observed for the supported context situation and it is attributed to the software product then the vendor might need to reevaluate CSM or a special software-service bundle has to be developed for the particular client.
For the second evolution cause, changing client demands, new agreements between vendor and client regarding the software-service bundle and its configuration are required.The third cause, changing requirements to the software, might in some cases lead to a new software version which does not have any effects on the agreement with the client, i.e., the client would not notice that there is a new version.But a new software version could also have effects on the service quality.If this is the case, new agreements with the client might be needed.

Application Example
Business processes in many industries require collaboration among two or more companies.Often this collaboration involves business information exchange in a form of data exchange messages [15].Such messages can contain errors, which need to be corrected before further utilization of the information.The correction of errors might require manual interventions which will be referred to as "clearing services".The example discussed in this article is motivated by a real-life case in the energy industry, where a software development company provides software for exchanging energy consumption data as well as associated business process outsourcing services for handling data errors [16].

Case Description
Since the end of the 1990's, energy industry in many European countries has undergone serious changes due to market liberalization and the separation of energy grid and energy production.Energy distribution companies are facing a changing business context caused by (a) new regulations and laws from regulating authorities and (b) innovative technical solutions, e.g., for implementing smart grids.Software solutions in this area have to support the business functions within energy distribution companies and data exchange between the different market roles (market communication).Examples for typical business functions are assets accounting, processing and examination of invoices, automatic billing initiated by meter readings, meter data evaluation, maintenance management (disposition, workforce management and mobility), and order management.Market communication related to these business functions includes exchange of information about consumption of energy, changes in customer data, or usage of energy gridto name only some examples.Given the constantly rising complexity of the market communication, public utilities and other energy distributors increasingly implement outsourcing of their business processes to external service providers.
The application case considered in this article is a medium-sized company in Germany offering a software solution for energy distribution companies supporting the abovementioned business functions, andbased on the same software solutionbusiness process outsourcing services for their clients.Thus, the company acts both as an independent software vendor (ISV) and as a business service provider (BSP).The software solution is widely used by public utilities in Germany, in particular for electricity, natural gas, district heating, and water.The focus of the BSP part are business processes that deal with market communication.Given the complexity of the market relationships, exchanged data may get into conflict or create inconsistencies with other data.If this is the case, manual intervention or clearing is required.Thus, the BSP acts as a "clearing center" for the occurring exceptions if they are covered by the contractual agreement between client (e.g. a public utility) and the BSP.
Within this clearing center, different kinds of services are offered, some of them specializing on the kind of utility offered (energy, gas, water), others offering different levels of clearing support.These services usually are bundled with the case company's software solution, i.e., the client buys or leases the software solution and orders clearing services.The case company offers several software-services bundles, two of which are "clearing support" and "enhanced exception handling":  Clearing support.If exceptions occur during data exchange, the erroneous data records are registered and forwarded to the BSP.Each record is analyzed and, depending on the contractual agreement with the client, the record is either corrected by the BSP or forwarded to the responsible unit at the client side.Examples for such clearing support software-service bundles are processing and consolidation of meter readings which are offered in different variations to energy, gas, and water suppliers.The software part provides automated processing of meter readings (mass, data; several thousands of records per week) exchanged between grid operator and metered service provider.The service part complements the automated processing with manual clearing of exceptions, which is done with the same software product, but requires manual entry of data. Enhanced exception handling.In some cases, erroneous data records cannot be corrected by the clearing support because of so far unknown errors or missing data.In these cases manual intervention by highly skilled experts is required which are called "knowledge workers".This manual process basically follows a case handling strategy and sometimes requires interaction of BSP and client.Similar to the clearing service above, the enhanced exception handling is also offered to energy, gas and water suppliers.Evolution of these services often means to adapt the strategy of how to assign different qualifications of knowledge workers and software functionality in order to fulfill the contractually agreed service level.

Software-Service Bundle
From the perspective of software-services bundles, the situation described in Section 4.1 can be generalized as follows: A vendor offers business information processing services.These services typically consist of data processing software, data processing services and,if requiredclearing services by the back office staff of the vendor based on knowledge about the most common data exchange exceptions.The data processing services ensure business information processing on behalf of the client.Clients can choose between doing data processing and clearing in-house or outsourcing it to the vendor.Figure 4 shows an overall data exchange process from the client's perspective.The client receives a message.Depending on a decision-making logic the messages are processed along one or several process branches.The first branch represents a manual processing (client's employees correct errors).The second branch represents an automated processing using the knowledge base on common exceptions provided by the vendor.However, some of the exceptions might require manual intervention ("clearing").A client uses the outsourcing service provided by the vendor to deal with exceptions in the third branch.The client transfers the exceptions to the outsourcing service and receives back the remedied data.Multiple branches can be used simultaneously.For example, the client mainly uses in-house automated processing and invokes the outsourcing service only if internal resources are overloaded.This decision is made during the service delivery.Nevertheless, the solution should be configured in a way to support both automated in-house processing and usage of the outsourcing service.
The process execution goals are timely processing of all messages and handling of all exceptions.The main context factors affecting the process execution are the number of data exchange messages received or processing load and load volatility.The load volatility characterizes variations in the processing load what might have adverse consequences on scheduling of resources assigned to the manual processing.

Model
The vendor possesses the data exchange capability provided to its clients by means of the software-service bundle.The data exchange capability model (Figure 5) is created using the concepts defined in Section 2.3.Goals, context, and process variants are the main elements of the capability model important for the software solution selection method.The capability goals are timely data processing, correction of data exchange errors as well as cost minimization and efficient utilization of resources involved in the data exchange process.These goals are measured by the corresponding KPIs.The timely data processing goal is measured as the processing time KPI PT K .The cost efficiency goal is measured by return on investment KPI, which is calculated using KPIs measuring revenues from message processing, fixed configuration setup cost and variable message processing cost.
The context elements affecting the capability are defined in Table 1.The processing load context element is measured by the number of messages received per day and it assumes values from the range of values.Not all context elements are used in configuration selection for the software-service bundle.Current backlog and schedule context elements are used for run-time decision-making.
The capability model also defines the overall data exchange process including three processing variants (Figure 4).These process variants serve as the basis for defining configurations of the software solution.The Allocate messages gateway represents decision logics for run-time allocation of messages among process variants if several of them are included in the configuration.Three configurations are offered to clients: O 1manual processing of data exchange exceptions; O 2automated processing of data exchange exceptions; and O 3combination of automated processing of data exchange exceptions with availability of exceptions handling outsourcing services.The configurations also vary by the fixed setup prices.The setup price of O 1 is assumed as a baseline or 100%.The setup price for O 2 in the terms of the baseline price is 250%, and it is 300% for O 3 .
CMS is prepared according to the vendor's expertise and historical data (Table 2).The matrix lists context situations as combinations of values of C PL and C LV context elements.It shows that, for instance, configuration O 1 is suited for . If multiple configurations are suitable for a context situation, then the value-based selection is used to select one of the configurations.

Results
The aforementioned capability model provides a foundation for delivering data exchange solutions to clients.A simulated experiment is conducted to illustrate the software-service bundle selection method.It simulates a flow of data exchange messages for a single client and the client attempts to process these messages using one of the solutions provided by the vendor.Execution of manual data processing activities in all configurations requires human resources drawn from a limited pool of resources and has a variable duration depending on complexity of exceptions.
The message flow D t varies over time and is described as an autoregressive process The coefficients  and  affect processing load volatility, i.e., larger values of these coefficients result in a more volatile message flow.In this experiment .The value of  is varied to evaluate different context situations: 1) in the first experiment (EXP1)  is set to 10 to evaluate a low processing load situation; and 2) in the second experiment (EXP2)  is increased from 10 to 100 during the course of message processing simulation to evaluate the impact of changes in context.Numerical values used in the experiments are practically grounded though do not represent actual observations.
A new client defines that its typical context situation . That is supported by either O 1 or O 2 .The most suitable configuration is selected according to the estimated value.In this case, the value is determined by the return on investment KPI (i.e, all other KPIs have zero weights).The return on investment KPI (Table 3) is calculated as a ratio between profit and total costs and assuming that in the case of O 1 there is 20% difference between single message processing fee and costs, while this difference is 180% for O 2 .The calculation is performed for three years period taking into account the expected load.At the design stage, KPI values can only be estimated and actual values are evaluated once the configuration is up and running.
Since O 1 has a better expected value of the return on investment KPI, this configuration is setup for the client.That implies client receiving data exchange software and using manual exceptions handling.

 
The experimental results demonstrate that context observations can be used to drive selection of appropriate configurations on the basis of the common capability model.

Related Work
Related work can be found in the areas of selection of packaged applications and version management.The multi-objective methods for selecting packaged applications allow for comprehensive evaluation of offerings by different vendors [5].The selection is based on the generic set criteria and the alignment of these criteria with business needs is not ensured.Importance of explicitly accounting for various business and operational goals in selection of commercial-of-the-shelf applications is emphasized in [17].Capilla et al. [18] describe 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 in software engineering [11] concerns the operational level evolution of atomic development requirements.A value-driven approach to design of serviceoriented systems is proposed by Thomas and vom Brocke [19].They use modeling to identify various options for designing services and creating orchestrations.The cost-benefit analysis of various options is conducted considering investment in different layers of Service Oriented Architecture (SOA).
In literature the adaptation and evolution of software systems to changing situations is also addressed in the field of "system maintenance".Much work in this field observes that systems are insufficiently prepared for quick adaptation and evolution, i.e., there is the criticism of poor flexibility [20].According to [21], 65% of system modification costs are caused by adapting the system to changed requirements when the system already has been deployed to the client.Several approaches have been proposed aiming at more agile and flexible software systems, among them is shortening the software development process by improving the methods applied in this process [22].In this context, [23] sufficiently prepared for application areas, where system boundaries are not static, but are subject to continuous change.
Continuous Software Engineering (CSE) [24] develops methodologies, concepts and techniques for evolvable software systems.The central goal of CSE is producing long-living, evolution-capable software systems, which are of high quality and can be forward developed continuously [25].An essential part of the CSE approach is to achieve consistency and transparency between (a) all artifacts of a software development process within a development cycle (e.g.specification, design, and implementation) and (b) the various forward development cycles of a software system and their modifications.This requires the identification of invariants and dependencies in order to predict the potential impact of initial and induced modifications.
Evolution of information systems also attracts substantial research work.Here, an important topic to be tackled is achieving more agile and flexible methods for information system development [26].Furthermore, the implementation of more flexible systems based on component-based approaches is discussed [27].[28] argues that there are different forms of flexibility in software development which can be analyzed from a control theory perspective.The method proposed relies on several existing methods.Goal modeling techniques [29] help to identify the relevant objectives.Business activity monitoring techniques allow measuring the process performance according to the specified goals and to identify significant changes in performance [30].Context model techniques [31] help to identify relevant context factors and to represent their impact on process design.The software-service bundle selection method developed in this article extensively uses categorized context values.A similar approach is used by [32] to model context-driven business processes.Furthermore, there is related work in the field of service management from a service science perspective.In recent years, the perspective on what is characterizing a service has shifted from an intangible product to a more processoriented focus [33].A service process "… can be viewed as a chain or constellation of activities that allow the service to function effectively" [34 p. 68].Existing work tries to understand service processes from three overall perspectives: input, transformation process and outcome [35].In contrast to manufacturing-based production processes, also customers provide significant input in service processes [36].This is clearly visible in our product-service bundle.However, this input is not only limited to one customer, but also multiple customers which is also acknowledged by service science [37].The transformation process "entails the service delivery and consumption process, and involves customer participation in the service delivery/consumption process" [35 p. 1016].For software-service bundles, we thus can divide this perspective into the continuum of service co-production [38] and consumption process flow.The latter is considered as a characteristic of services from a service operations management perspective.The final outcome of the service is determined by the service provider as well as by the service beneficiaries [39].

Summary and Future Work
The article presented and discussed the method for evolutionary development and configuration of software-services bundles.The article showed that the vendor-client collaboration for selecting the most suitable configuration of a given software-service bundle is feasible and represents value co-creation between the vendor and client.The capability concept and the CDD approach have been useful for this method to provide the common basis for defining software solution and explicitly representing relationships among performance, context, and solutions.The method so far is evaluated only using a simulation approach, and experiences from realworld application cases are needed for further validation.
There are multiple directions of further research.Updating the capability support matrix according to monitoring results is an important part of the method that requires further elaboration.Classification and machine learning methods can be used for these purposes.The decision to upgrade the solution is not an automated decision and usually involves a number of considerations (e.g., business relations) not covered by the evolutionary development method.Switching to a new configuration incurs additional costs.This factor also could be incorporated into the decision-making process to evaluate cost-benefit aspects currently not considered in the article.
In this article, process-oriented applications are considered.That could be generalized to other types of applications and services assuming that multiple alternative capability delivery solutions exist.
Another aspect which so far has not been sufficiently covered in our research is the business value of the overall approach, i.e., is it worthwhile to invest in context modeling, definition of capability matrix, software-service bundling, and evolutionary development?So far, our simulation primarily addresses the evolutionary development aspect.When it comes to the business value of context modeling, results from the Capability as a Service (CaaS) project indicate that context modeling and capability design result in transactional and informational benefits [40].This experience from CaaS and the positive result of our simulation can be taken as indication that also the combination of both parts can be expected to have a positive business value.However, this needs a more thorough investigation in future work.
From a service science perspective, the co-production of services has to be seen as a continuum which "can vary from none at all to extensive co-production activities by the customer or user" [41, p. 8].When specifying service processes, it thus has to be highlighted which tasks are performed by which entity of the service system or service system network.For software-service bundles, modeling of the service process with explicit distribution of tasks between vendor and client could be a way to further optimize gathering of relevant data.This will be part of future work.
iN OO and the configurations differ by their price and other characteristics.Delivery of S depends on M context factors 1 ,..., M CC and its performance is measured by L key performance indicators 1 ,..., L KK .Combinations of values of the context factors yield a context situation describing specific solution delivery circumstances.

Figure 1 .
Figure 1.Contextualized and performance driven software-service bundle selection problem

Figure 3 .
Figure 3. Key concepts of capability modeling

Figure 4 .
Figure 4.The overall business information exchange process (Msgmessage)

Figure 5 .
Figure 5. Data exchange capability model results (Figure 6.b) show that O 2 delivers satisfactory performance after the change in the context.However, , new PT t K is close to its threshold.Assuming, that a similar behavior is observed also for other clients using O 2 in similar conditions, the vendor might decide on updating CSM and recommending to use exclusively O 3 in context situation

Figure 6 .
Figure 6.Dynamics of simulated delivery results and configurations used: a) EXP1 and b) EXP2 .., weights indicating relative contribution of each KPI toward the overall business value and F is a functional relationship between V and KPI.It is assumed that KPIs are positively correlated with business value and large values are preferable (if small values are preferred then the negative value of KPIs is included in Eq. 2).
KKare values of KPI at time period t, 1 ,..., L ww are

Table 1 .
Context values and their context ranges

Table 2 .
Capability support matrix for data exchange software-service bundle where  and  are coefficients defining process shape and context element C PL is expressed as depicted in Eq. 4.
and affects the processing load context element.The relationship between t D and value of the processing load

Table 3 .
Estimated KPI values at the design time The processing load context element C PL is constant while load volatility C LV exhibits slight variations and occasionally assumes medium value not explicitly supported by the current configuration O 1 .More importantly, emphasizes that software engineering techniques are not