Keywords

1 Introduction

Strategic planning is the process of defining/formulating such a general plan for an organization encapsulating its intentions and actions, encompassing a certain period of time, to achieve its vision. Traditionally, the planning process assumes that the business environment in which the organization will execute the strategic plan will remain reasonably stable for the duration of the foreseen time period. In modern world this however becomes less of a norm because new and unexpected business opportunities and threats arise, demands change, as well as environmental and security risks increase.

To respond to the need of continuous adaptation an EU-FP7 project “Capability as a Service in digital enterprises” (CaaS) has been initiated [1]. Its aim is to develop a support for the capture and analysis of changing business context in the design of information systems (IS) using the capability notion. Capability is seen as a fundamental abstraction to describe what a core business does [2]. Capability is defined “as an ability and capacity for an enterprise to deliver value, either to customers or shareholders, right beneath the business strategy” [3], or “the ability of one or more resources to deliver a specified type of effect or a specified course of action” [4]. The CaaS project strives towards developing an integrated methodology for context-aware business and IT solutions, under the name Capability Driven Development (CDD).

The CDD methodology is based on Enterprise Modeling (EM), context modeling, variability modeling, adjustment algorithms, and patterns for capturing best practices. The current thrust of the capability driven approach to IS development is to make IS designs more accessible to business stakeholders by enabling them to use the capability notion to explicate their business needs especially concerning context dependent variability. This can be seen as capability support on an operational level. It is however insufficient for business planners because they need to assess the organization’s capabilities on a strategic level. To this end the objective of this paper is to extend the CDD approach with a strategic planning phase.

In essence CDD follows the principles of the Model Driven Development (MDD) paradigm, which implies a built-in drawback because it mostly relies on models defined on a relatively low abstraction level. In contrast, EM captures organizational knowledge and provides the necessary motivation and input for designing IS. Hence there is a need to connect the development of CDD with more strategic way of working. We envision that EM has a potentially important role to play in this process because it has been used for strategy development and in particular in the context of IS development [5, 6].

The rest of the paper is organized as follows. Section 2 outlines the research approach. Section 3 summarizes the current use of the capability concept and the CDD methodology. Section 4 presents the method component for Strategic Capability Modeling. Section 5 presents one of the application cases and briefly summarizes the current experiences of capability modeling relevant to the proposed method component. Section 6 provides concluding remarks and issues of future work.

2 Research Approach

The work in this paper is motivated by the industrial use cases that are a part of the CaaS following the principles of Design Science Research (DSR) [7].

By adopting DSR as a paradigm, IS engineering aims to resolve problems by creating innovative scientific artifacts through development- and evaluation cycles within a real life context. The creation of artifacts is iterative and incremental leading to a practical solution. The essential activities of DSR concern the explication of the problem, an outline of the artifact with the related requirements, an artifact’s design and development, as well as its application, evaluation, and communication.

The CDD methodology is the main design artifact of the CaaS project. Its purpose is enabling development of IS able to adhere to changes in business context through variability at run-time. CDD methodology as design artifact should be seen as a composite. Its parts, such as the meta-model and the various method components (e.g. capability design and context modeling) are also design artifacts in their own right. This paper presents one such CDD method component, one that addresses strategic capability modeling.

During the DSR process, knowledge was attained through iterative and incremental cycles of constructing the design artifact according to the needs of multiple stakeholders including researchers, technology developers, and practitioners using capability designs for their business purposes. More specifically, participatory modeling workshops, focus-group sessions, interviews with experienced practitioners, and on-line questionnaires were the main techniques used for problem explication and requirements elicitation. The results of this work are reported in [8]. The artifact presented in this paper was developed and validated during a number of design cycles, based on the use cases at SIV (Germany) and CLMS (UK).

3 Background to Capability Driven Development

3.1 Capability as a Concept

The notion of capability has a growing presence in the current business and IT alignment and IS development frameworks starting from more business-oriented such as Business Architecture and Business Modeling, towards the alignment-oriented represented by Enterprise Architecture (EA), and EM. In brief, the emergence of the use of the capability notion seems to have three key motivations: (a) in the context of business planning, it is becoming recognized as a fundamental component to describe what a core business does and, in particular, its ability of delivering value that is relevant to the business strategy; (b) in IS development, it makes IS designs more accessible to business stakeholders by enabling them to use the capability notion to describe their requirements; and (c) it supports the configurability of operations on a higher level than services, business process, resources, and technology solutions.

Capability is used in a wide variety of approaches and frameworks and while there are clearly identifiable similarities, there are also substantial differences in its use. For example, OMG’s proposal for Business Architecture (BA) [9] uses business capability for describing what a business does - specifically, it is an ability or capacity that the business may possess or exchange to achieve certain outcome. The resulting capability map encompasses the whole view of what a business does. The Value Delivery Modeling Language (VDML) [10] defines a modeling language for analysis and design of the operations of an enterprise with a focus on the creation and exchange of value. Its aim is to provide an abstraction of the operations appropriate for business planners. VDML links strategy and business models to the activities, roles, and capabilities that run the enterprise. VDML defines capability as the ability of an organization to perform a particular type of work and may involve people with particular skills and knowledge, intellectual property, defined practices, operating facilities, tools and equipment.

Capability is also a key concept of EA frameworks. E.g., Department of Defense Architecture Framework (DOFAF) [11] defines capability as “the ability to achieve a desired effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities”. Condition means the state of an environment or situation in which a performer performs; desired effect means desired state of a resource; resource means data, information, performers, materiel, or personnel types that are produced or consumed.

The NATO Architecture Framework (NAF) [4] defines capability as “the ability of one or more resources to deliver a specified type of effect or a specified course of action”. The NAF meta-model defines the following key relationships of capability:

  • Capabilities may be specialized into more specific capabilities, composed of several capabilities, as well as dependent on other capabilities.

  • Capability when applied is associated with measurable categories.

  • Capability elaborated into Capability configuration package, which is used to configure resources for capability implementation.

  • Enterprise phase exhibits a capability. The connection between capabilities and goals is realized through enduring phase of the enterprise.

  • Capability support an enduring task by defining capability for task.

In summary, the current use of capability is concerned with organization’s ability for delivering a business function. The “integrational” nature of capability is used to bind the strategic/intentional part of the organizational design with the operational or technical parts. Hence, capability should be seen as a key concept relevant to both strategic planners as well as operational planners. In some of the approaches capability has its own view, for instance, the EA frameworks used in military (e.g. DODAF, NAF), including several sub-views. The capability-centric views are then linked to other views - for services, processes, infrastructure, etc. The majority of the frameworks is so far not providing a methodological guidance for capability elicitation and development.

3.2 Overview of the CDD Methodology

The CDD methodology consists of method components [12]. To structure the methodology, the components have been divided into upper-level method components and method extensions. Each upper-level component describes a certain application area and may also contain sub-components. The upper-level method components are currently the following:

  • Capability Design Process guiding how to design, evaluate and develop capabilities by using process models, goal models and other types of models.

  • Enterprise Modeling guiding the creation of enterprise models that are used as input for capability design.

  • Context Modeling analyzing the capability context, and the variations needed to deal with variations.

  • Reuse of capability design guiding the elicitation and documentation of patterns for capability design.

  • Run-time Delivery Adjustment adjusting capability at runtime.

The overall CDD process includes three cycles (1) capability design; (2) capability delivery; and (3) capability refinement/updating. The capability design cycle often starts with Enterprise Modeling, i.e. by a business request for a new capability - the request might be initiated by strategic business planning, changes in context, or discovery of new business opportunities requiring reconfiguration of existing or the creation of new goals, business processes or services, and other EM elements. This is followed with a formalized definition of requested capabilities and definition of the relevant contexts according, linking with relevant capability delivery patterns as well as supporting IT applications (design).

In addition, several method extensions addressing specific business challenges to which the CDD methodology have been developed by the CaaS consortium:

  • The Capability Ready Business Services method extension covers the transition step from textual instructions and activity descriptions to business process models ready capability modeling. With this extension many business services in Business Process Outsourcing can be subject to capability based redesign.

  • The Prepare Local and Global Optimization method extension for the optimization of service delivery and balancing local optimization of services provided to a client and global optimization from a service provider perspective.

  • The Evolutionary Development of Business Information Exchange Capability method extension for developing capabilities in the case when pre-existing capability delivery solution must be tailored to the needs of a new client.

  • The Integration of CDD and MDD method extension is analyzing the potential of integrating MDD and CDD concepts in situations when a new capability delivery application needs to be developed, which can be done by an MDD tool.

  • The Analysis of Capability Relationships method extension is proposing an analysis of capability relationships and mapping of capabilities to delivered services. Through the business case analysis of the CaaS project, it was noticed that during the process of identifying business capabilities it was useful to describe them in relation to other capabilities.

  • The Predictive analysis method component describes capability delivery adjustment using predicted context values to attain proactive behavior.

  • The Capacity evaluation method component evaluates capability delivery capacity requirements to determine capability’s suitability to context ranges.

3.3 Capability Meta-Model

The theoretical and methodological foundation for pattern use in capability-oriented software applications is provided by the core capability meta-model (CMM) in Fig. 1, and in details presented in [13]. CMM is developed on the basis of requirements from the industrial project partners, and related research on capabilities. Within CDD, patterns are envisioned as reusable solutions for reaching business goals under specific situational context. Individually, they are intended to describe best practices for businesses, and in a collection to form a repository of capability delivery patterns.

Fig. 1.
figure 1

A core meta-model for supporting Capability Driven Development.

Full size image

In brief, the meta-model has three main sections:

  1. (a)

    Enterprise model, representing organizational designs with Goals, KPIs, Processes (with concretizations as Process Variants), and Resources;

  2. (b)

    Context, represented with Context Set for which a Capability is designed and Context Situation at runtime that is monitored and according to which the deployed solutions should be adjusted. Context Indicators are used for measuring the context properties (Measuring Property); and

  3. (c)

    Patterns, for delivering Capability by reusable solutions for reaching Goals under different Context Situations. Each pattern describes how a certain Capability is to be delivered within a certain Context Situation and what Processes Variants and Resources are needed to support a Context Set.

Figure 1 is a simplified version of CMM showing only the key components of CDD and omitting, for instance, constructs for representation of goal decomposition relationships and process variants. Complete version including definitions of components is available in [1, 12].

3.4 The Process of Capability Design

The process of capability design considers existing Enterprise Models and other organizational design as well as patterns in order to elaborate a capability design. The process is essentially comprised of three phases as shown in Fig. 2.

Fig. 2.
figure 2

Capability flow.

Full size image

  • Step 1: Capability Design. There are three alternative pathways of proceeding with capability design, shown in Fig. 3.

    Fig. 3.
    figure 3

    Alternative approaches for capability design.

    Full size image

  • Step 2: Capability Evaluation. This step checks capability development feasibility from the business and technical perspective before committing to capability implementation.

  • Step 3: Development of Capability Delivery Application. The 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. The indicators for monitoring and the adjustment algorithms are packaged and passed over to a Capability Navigation Application (CNA) for monitoring capability delivery.

4 Strategic Capability Modeling

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 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, the ownership of a capability should be shown.

Organizations need to be supported in their efforts of analyzing 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 a method component for strategic capability analysis is proposed. In the reminder of this section we will describe it according to the method-component format used in [12] – purpose and preconditions, cooperation principles, important concepts, and procedure.

4.1 Purpose and Preconditions

According to [12] a capability is the ability and capacity that enable an enterprise to achieve a business goal in a certain context. Thus, a capability is always 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 analyze 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 analyzed is organization’s ability and capacity to reach its vision in general.

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

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

4.2 Cooperation Principles

The roles and stakeholders identified in the CDD methodology [12] also apply for this method component. The following stakeholders are to be involved:

  • 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 and guides changes in the business models.

  • 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.

  • Capability provider: responsible of providing capabilities to the customer.

  • Customer (client): The end user who benefits from the capabilities.

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.

4.3 Important Concepts

The following concepts are used in this method component:

  • 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.

  • Goal. Goal is a desired state of affairs that needs to be attained. Goals can be refined into sub-goals and should typically be expressed in measurable terms such as KPIs. Other modeling components such as problems, opportunities, and causes may also be included in goal modeling. In case of modeling 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. While using this method component the links to Context Elements may be omitted, because they might be unknown at the time of strategic capability modeling.

4.4 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.

  • Step1: Identify goals in the goal hierarchy that would be appropriate for motivating capabilities. Goal hierarchy typically has 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.

  • Step 2: Analyze goal sub-hierarchies. 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 precisely, have sub-goals on their own, and are linked to KPIs. These kinds of goals should be considered for motivating capabilities.

  • Step 3: Define capabilities for the selected sub-goals. There can be several capabilities for reaching one goal. Hence, naming of capabilities should reflect the difference, e.g. for what context it is suitable.

  • Step 4: Define context sets for each capability. 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 analyzing what measurable properties are available and can be monitored at run-time.

  • Step 5: Identify external capabilities by analyzing collaborations with external partners. Consider partner goal hierarchies and analyze how their goals relate to capability delivery organization’s goals. For the related goals repeat steps 1 to 4 to identify capabilities involved in business collaborations. If partner goal models are unavailable, analyze the overall business model and the collaboration mode.

  • Step 6: Develop capability relationships. This can be done by following the method component Analysis of Capability Relationships described in [14]. At this stage both internal and external capabilities are analyzed. Relationships among capabilities are specified in terms of: capability ownership if capabilities are delivered by external partners; capability collaboration if several capabilities are used to achieve a goal; and capability composition if a capability consists of smaller capabilities.

5 Experiences of Capability Modeling

The CDD methodology components have been developed in the CaaS project and applied in the four industrial use cases, namely at

  1. 1.

    SIV AG (Germany) for standard business processes outsourcing and execution capability,

  2. 2.

    Fresh T Limited (UK) for maritime compliance capability,

  3. 3.

    CLMS Ltd (UK) for collaborative software development using the MDD technology and industrial symbiosis application in particular, and

  4. 4.

    Everis (Spain) for service promotion capability, marriage registration capability, SOA platform capability.

For the purpose of illustrating the proposed method component we have chosen to present the use case of CLMS. Its core business is model driven software development with the zAppDev toolFootnote 1. This use case is based on development and running a website for industrial symbiosis (i-symbiosis) to facilitate the exchange of waste materials among organizations; more in depth presentation of the case and the corresponding capability designs is available in [14]. Considering the core business of CLMS, the following capabilities have been identified: Domain analysis, Architecture design, Business intelligence, Cloud migration, IT change management, Application development, Continuous engineering, Integration APIs connectivity infrastructure, and Software development as a service. They all contribute to the overall core capability of CLMS, namely, Adaptive and extensible software development. In principle they reflect what a software development company of this kind normally does to reach its business goals. For the case of i-symbiosis, some of these capabilities of CLMS need to be combined with external partner capabilities to deliver capability “Enabler of web industrial symbiosis”. This capability encompasses the CLMS capabilities and two supporting capacities of an external partner, namely, Semantic repository capability and Resource classification capability. The map of capabilities relevant to development and running the i-Symbiosis is shown in Fig. 4. This is however not sufficient, because there are specific cases of context changes that require sub-capabilities of capability 1, shown in Fig. 5. Due to space limitations this model omits the process variants needed for delivery of sub-capabilities.

Fig. 4.
figure 4

Capability map of CLMS, adapted from [14].

Full size image
Fig. 5.
figure 5

Capability design for capability enable web industrial symbiosis [14].

Full size image

Based on the three contextual factors that can affect the industrial symbiosis (location, resources, legislation), three sub-capabilities where designed for situations when the monitoring and adjustment of the existing capabilities was deemed necessary. In each situation three different levels of adjustments are possible: automated adjustments, semi-automated adjustments, and manual adjustments.

The ‘Determine Relevance Rating’ sub-capability (Capability 1.1 in Fig. 5) makes it possible to calculate a relevance rating based on the type of resources and organizations offering these resources. Matches with high relevance rating are used for proposing synergies. The i-Symbiosis platform shows the possible matches for synergies after calculating a rate of relevance of the two organizations. If this rate is lower than 60 % then the platform rejects the remaining weak matches.

The ‘Resource Description and Classification’ sub-capability (Capability 1.2) enables the detailed description of resources in order to enable a better match between organizations. The Capability Navigation Application monitoring the performance of i-Symbiosis is checking the compatibility of resources during the match making procedure. The successful resource compatibility is essential for every possible synergy between two organizations. The descriptions of resources to exchange can impact the number of possible synergies (matches). If their quality is low, there will be difficulty to perform matching and hence create synergies. Hence, monitoring this sub-capability would be the early detection of loss in matching power.

The ‘Compliant with Regulations’ capability (Capability 1.3) ensures that the proposed synergies are correct according to the legislative context because it affects the way goods and materials can be handled. E.g. what is being considered as hazardous can differ between countries and change over time. The current capability is designed for a certain legislative context, in this case Greece. If the context changes, the capability may vanish or become useless, hence changes in the legislation need to be monitored and if they are detected their impact should be assessed with respect to possible capability redesign. This should normally be done manually.

Considering other use cases of the project, the method component presented in this paper has not been applied in its entirety at this point. Its parts (the different steps and modeling components) however have been applied and hence we can argue for a partial validation of this method component. In this regard, Table 1 summarizes the steps of the procedure and how they have been carried out in the use cases.

Table 1. Overview of strategic capability modeling in CaaS use cases.
Full size table

6 Concluding Remarks

The CDD methodology currently focuses on IS development and supports designing and running business applications that need to be adjusted according to changes in the application context, which can be seen as capability support on an operational level. This paper proposes a CDD methodology component for strategic capability modeling in order to support business planners. The proposed component is to be used for analyzing the organization’s capabilities on a strategic level. In essence, it aims to bridge the gap between the outcomes that the contemporary approaches for strategic planning produce with the kinds of inputs that are typically needed for application design and adjustment according to situational contingencies. CDD encompasses application design and monitoring in an integral way. The possibility of designing organization’s own capabilities together with capabilities offered by external partners help solving the difficulties of assessing what parts of the capability are delivered by outside companies including raising awareness about what aspects of the capability delivery cannot be immediately influenced once changes are needed. Once the capability is running, the proposed method component allows organizations to monitor capability delivery from a more strategic perspective e.g. by providing an overview of performance vs targets. The use of models for capability designs reduces some of the complexity of this task, which would essentially contribute to capability driven management of organizations.

Concerning issues for future work, the key area of work is adoption of the CDD methodology in practice. According to the investigation of what aspects of EM approaches stimulate their productization and hence their adoption [15] the following factors should be considered: (1) EM maturity gap particularly focusing on industrial relevance of the method, (2) method and tool development process, (3) application context, (4) marketing and sales aspects, as well as (5) product aspects. The process of CDD methodology development has been primarily focused on the first three factors targeting inbound productization [16] by ensuring industrial relevance by user driven and systematic methodology development resulting in a methodology that is easily extendable according to situational needs. The later two factors directly targeting outbound productization [16] can be seen as issues for future work even if marketing aspects are well addressed by having a methodology that address real business problems and provides value to its users. Development of the product aspects such as alignment with standards, packaging the methodology and tool as well as focusing on the needs of a specific market are being elaborated currently and are also issues for future work.