Department of Computer and Systems Sciences (DSV)

ISSN 1101-8526

Licentiate Thesis in Computer and Systems Sciences, Sweden 2018

Designing Situated Capability ViewpointsAdapting the general concept of capability to work practices

Anders W. Tell

Anders W. Tell

Design

ing Situ

ated Capability V

iewpoin

ts

D e s i g n i n g S i t u a t e d C a p a b i l i t y V i e w p o i n t s : A d a p t i n g t h e g e n e r a l c o n c e p t o f c a p a b i l i t y t o w o r k p r a c t i c e s

Anders W. Tell DSV Report Series No. 18-012

Designing Situated Capability Viewpoints Adapting the general concept of capability to work practices

Anders W. Tell

© Anders W. Tell, Stockholm University 2018 ISSN 1101-8526 Printed in Sweden by E-Print AB 2018 Distributor: Department of Computer and Systems Sciences, Stockholm University

Abstract

Capability is a long-established term and concept that has found its way to be used to describe organisations. It provides the basis for a genre of analysis, design and planning methods used in several fields. In enterprise architecture frameworks, capability has become a central architectural and fundamental element. In the field of strategic management, it was used in the 1990s to describe the resources and core competencies that a company needs in order to compete in a market, while in military applications, the concept of capability is used for mission planning. It has also been suggested that the design of information systems could be based on the concept of capability. There is no broad agreement on the nature of capability in the enterprise architecture, strategy, planning and engineering literature. This may lead to problems, as differences in perception and use in and across work practices may hamper the utility of the concept of capability in practical approaches encompassing many different kinds of stakeholders, perspectives and work practices. The overall research goal of this thesis is to design a general concept of capability, a capability viewpoint and a capability situating method that can be used to adapt the concept of capability for use within enterprise architecture frameworks, to support different work practices, and at the same time to support coherence between work practices. The research methodology used in this thesis is based on the design science paradigm, which has the primary aim of creating innovative artifacts and new knowledge to solve general and practical problems. The thesis contributes to a deepened understanding of the varying uses and utility of the concept of capability in different work practices, through an empirical case study of a mega-scale programme. This work also presents three novel artifacts, a general capability pattern, a base capability viewpoint and a capability situating method, which can be used to increase the relevance, use and utility of the concept of capability in the different types of work people do themselves and together with others in organisations. The method provides a way to adapt and tailor the concept of capability to existing enterprise architecture frameworks and to different work practices, in order to lower the barriers of application, and to improve the facilitating conditions for and actual use of capability analysis, design and planning. The results contribute to the field of enterprise architecture by enabling the creation of ISO 42010 compliant situated capability viewpoints through the application of this method. Keywords Capability, enterprise architecture, strategic planning, situational method engineering, capability-based planning, interweaving

List of papers

The following papers are included in this thesis:

A. Tell, A. W., Henkel, M., (2018). Capabilities and Work Practices - A Case Study of the Practical Use and Utility. WorldCIST'18 2018: Trends and Advances in Information Systems and Technologies (pp 1152-1162). Springer International Publishing.

B. Tell, A. W. (2014). What Capability is Not. In International Conference on Business Informatics Research (pp. 128-142). Springer International Publishing.

C. Tell, A. W., Henkel, M., Perjons, E. (2016). A Method for Situating Capability Viewpoints. In International Conference on Business Informatics Research (pp. 278-293). Springer International Publishing.

D. Tell, A. W. (2014). Interpreting Service Using an Upper-Level Ontology. In 2nd International Workshop on Ontologies and Information Systems (pp. 66-77). CEUR Workshop Proceedings.

The author of this thesis also contributed to the following articles and technical report, which are not included in this thesis:

I. Tell, A. W., Perjons, E. (2009). Management of Large Scale Knowledge Bases through Contextualisation. In International Workshop On Value Modeling And Business Ontologies. Accepted. Available online.

II. Tell, A. W. (2012). Deconstructing Abilities—In Search for An Ability Viewpoint. PoEM. CEUR Workshop Proceedings.

III. Tell, A. W., Henkel, M. (2018). Differences and Similarities Between the Concepts of Capability and Process—An Explanatory Model. Technical report, Stockholm University.

Table of contents

1 Introduction ............................................................................................... 1 1.1 Background .............................................................................................................. 1 1.2 Research problem .................................................................................................... 4 1.3 Research questions and goals ................................................................................. 6 1.4 Structure of the thesis .............................................................................................. 6 1.5 Structure of contributions from papers ...................................................................... 7

2 Related Work .......................................................................................... 11 2.1 Enterprise architecture ........................................................................................... 11 2.2 Capability-related research..................................................................................... 13 2.4 Knowledge foundation ............................................................................................ 21

3 Research Methodology............................................................................ 27 3.1 The choice of design science paradigm as a foundation ........................................ 27 3.3 Research processes of the thesis .......................................................................... 28 3.4 Contributions of papers to the research process .................................................... 44 3.5 Ethical considerations ............................................................................................ 48

4 Results .................................................................................................... 49 4.1 Insights into the use and utility of the concept of capability .................................... 49 4.2 Artifact 1: General capability pattern....................................................................... 55 4.3 Artifact 2: Base capability viewpoint ....................................................................... 64 4.4 Artifact 3: Capability situating method .................................................................... 66

5 Discussion .............................................................................................. 75 5.1 What does the concept of capability really add? ..................................................... 75 5.2 Research quality .................................................................................................... 76 5.3 Limitations and possible improvements .................................................................. 78

6 Conclusion .............................................................................................. 81 6.1 Contributions .......................................................................................................... 81 6.2 Future research ...................................................................................................... 83

7 Appendix ................................................................................................. 84 7.1 Appendix A: Capability pattern poster .................................................................... 84 7.2 Appendix B: Situated capability definition template ................................................ 85 7.3 Appendix C: Situated capability viewpoint - ISO 42010 Documentation Template . 86 7.4 Definitions .............................................................................................................. 87

8 References ............................................................................................. 90

Abbreviations

AD Architecture description ADM Architecture description method AF Architecture framework ATM Air traffic management ATMD Air traffic management domain BFO Basic formal ontology BITA Business and IT alignment CDD Capability-driven development DoDAF DoD architecture framework DSRM Design science research method EA Enterprise architecture EAD Enterprise architecture description EAF Enterprise architecture framework IIBA International Institute of Business Analysis IS Information systems ISA Information systems architecture ISO 42010 ISO/IEC 42010 – Architecture description ME Method architecture NAF NATO architecture framework NMM NATO architecture framework metamodel OASIS Organization for the Advancement of Structured Information Standards RBV Resource-based view SE Systems engineering SOA Service-oriented architecture SME Situational method engineering TOGAF The Open Group architecture framework VRIN Valuable, rare, imperfectly imitable and non-

substitutable

1

1 Introduction

This chapter presents the background to this work and the overall problems addressed in this thesis, followed by a description of the main research question and the goals of the research.

1.1 Background The terms ‘capability’ and ‘ability’ have been part of natural language since 1300–1400 AD (Longman) , and the underlying concepts have been used to represent the inner workings of societies, organisations, man-made artifacts, and organisms. These concepts have a long history and have acquired common-sense meanings. A search for the keywords ‘capability’ and ‘ability’ in the abstract and citation database Scopus indicates coverage of over 27 different subject areas. During the last decade, the concept of capability has been found beside, on top of, or as a replacement for well-known ideas. Concepts and theories centred around strategy, process, components, service, goals, function and resources are all adjacent to or potentially overlap with the concept of capability. As such, the concept of capability can be considered a new concept for solving a wide range of problems. The concept of capability has become an important part of theories and has been practiced within fields such as enterprise architecture (EA), strategic management and planning, business analysis, information system design, and human development. The scope of this thesis lies primarily within the field of EA, which is a multi-stakeholder, multi-practice and multi-perspective approach to enterprise and business information system analysis, design, and planning (Sowa and Zachman 1992). The concept of capability provides an important perspective on enterprise and business architectures . Capability provides a unit of planning and investment for enterprises and IT organisations, linking vision, business units, processes, resources needed and sourcing with migration plans (The Open Group 2018).

1.1.1 Informative example of use of the concept of capability In the case study (Paper A) presented in this thesis , the successful use of the concept of capability is reported, in which the concept of capability is used in strategic dialogues and for master planning within the air traffic management domain (ATM). In the mega-scale ATM programme studied here, the concept of capability is

2

used as something important to talk about and something for the different stakeholders to agree on and invest in. Capability becomes a means for referring to (i.e. a talking point) and agreeing on that which is important and provides some potential capacity or power to cause or achieve certain results. The actual capabilities that were important in the programme were grounded in and based on a thorough understanding of current and future ATM concepts, strategies, ways of doing business, operational concepts and procedures, and technical enablers. An example from the master plan of the ATM programme was the introduction of the new operational concept of trajectory management, an approach to airspace design and management. Trajectory management provides a service to airspace users by enabling aircraft to achieve their preferred route and time of arrival. This operational concept is supported by the capability of system-wide information management (SWIM). Here, SWIM is an information systems concept that focuses on improving the information supply chain in terms of decision making, to improve performance by creating an information-rich and information-sharing environment. Thus the concept of capability was used, in the programme, as a means to refer to parts of ATM that should be analysed, design, invested in, and be built. The research reported in this thesis supports the preceding example in two ways. Firstly, it provides capability analysts with a situated way of thinking about air traffic management via the lens of capability. This lens can be customised to directly fit various types of working environments, since these may require different kinds of capabilities. Secondly, it provides methodology developers with a method for tailoring existing (EA) frameworks and methods that include capability-based analysis and planning so that the methodology can support specific work and jobs, such as investment planning in the preceding example.

1.1.2 Areas in which the concept of capability is used The concept is used in a wide variety of subject fields, disciplines and practices. This section provides a short summary of the fields in which the concept of capability is used (see Section 2: Related Work for more information on key fields). Enterprise Architecture: EA involves knowledge about systems and their architecture, i.e. the “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (ISO/IECIEEE 2011). This system and architectural knowledge is organised according to concerns relevant to stakeholders . Here, capability has become one of the central concerns used for enterprise analysis, design, planning, and conformance monitoring purposes. The Open Group Architecture Framework (TOGAF) is

3

a widely used enterprise framework in the information systems field that uses the concept of capability (The Open Group 2018). EA is a rich, multi-stakeholder, multi-practice and multi-perspective domain, and incorporates the fields described in the following sections. Military planning: In military applications, the concept of capability is used for mission analysis and planning, deployment, monitoring and preservation purposes. The NATO framework NAF (NATO 2009) and the DoD Architecture Framework (Object Management Group 2012) are examples of two frameworks that provide capability viewpoints. Both incorporate traditional EA principles. Human development: In the fields of human development, welfare economics, and political philosophy, the capability approach developed by Amartya Sen, a Nobel Laureate, has had an impact as a broad normative framework (Sen 2009). The capability approach is used for assessment of human development and functioning (‘being’ and ‘doing’) including social policy, individual well-being, social arrangements and education (Robeyns 2003). Strategy planning: The concept of capability is used in the field of strategic planning and management. It was used in this sense in the 1990s to describe the resources and core competencies that a company needs in order to compete in a market (Kusunoki et al. 1998). For more details relating to the creation of customer value, see The Essential Advantage: How to Win with a Capabilities-Driven Strategy by Leinwand/Mainardi (Leinwand and Mainardi 2013); for the creation sense-and-respond organisations, see Adaptive Enterprise by Stephan Haeckel (Haeckel 2016); and for the organisation of resources and their allocation, see How dynamic can organizational capabilities be? Towards a dual-process model of capability dynamization by Schreyögg et. al. (Schreyögg and Kliesch-Eberl 2007). The concept of dynamic capability (Teece 2007) has been used to describe the ability of an organisation to change its capabilities. Processes: The concept of capability may focus on what the business does to create value for customers, meaning that capability therefore comes close to the field of business process design and management (Harmon 2011) and approaches such as functional groupings (Ulrich and Rosen 2011) and actor-centred perspectives (Danesh and Yu 2014). Quality management: Capability is used in the ISO 9000 (ISO/IEC 2015) international standard for quality management, and is defined as the “ability of an object to realize an output that will fulfil the requirements for that output”. Business analysis: Within the field and practice of business analysis, the concept of capability is used in analysis activities and is a resource for assessing gaps preventing an organisation from meeting business needs and achieving desired outcomes (International Institute of Business Analysis 2015).

4

Practitioners have also used capability maps (Beimborn et al. 2005) (Ulrich and Rosen 2011) to create an overview of the capabilities of an organisation. Furthermore, business capability maps are used within enterprise (and business) architecture management in order to map out an organisation’s structure, resources, and inherent potential (Aleatrati Khosroshahi et al. 2018). Information systems: It has been proposed that information system design could be based upon the use of capabilities. The capability-driven development (CDD) approach (Bērziša et al. 2015) aims to apply enterprise models representing enterprise capabilities to create executable software with built-in contextualisation and model-based patterns, thus leading to CDD. In the field of information technology strategy and management, McKeen and Smith define capability as “the ability to marshal resources to affect a predetermined outcome" (McKeen and Smith 2011). SOA: Within the field of information systems, we find service-oriented architecture (SOA). SOA is a kind of software architecture in which software applications or software components provide services to other consumer applications or components. A service can be viewed as an offer of the results (or real-world effect), in the form of an internal capability, to other consumers (The Open Group 2011). The organisation OASIS sees SOA as a “paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains” (OASIS 2006) (OASIS 2009)

1.1.3 Work practice Based on the wide range of application areas outlined in the preceding section, it is clear that the usage of the concept of capability differs across subject fields, disciplines and work practices. In this thesis, the concept of work practice is used to characterise work being done and the requirements on the use of the concept of capability. See Section 2.3 for more information on work practices and practice theory.

1.2 Research problem What can be noted in the wide range of applications is the large number of conceptualisations and uses of the concept of capability. Dosi, Nelson and Winter stated in their book The Nature and Dynamics of Organizational Capabilities (Dosi et al. 2001): “The term ‘capabilities’ floats in the literature like an iceberg in a foggy Arctic sea, one iceberg among many, not easily recognized as different from several icebergs nearby.” The proliferation of definitions and usages shows few signs of slowing down. Capability is perceived and used differently in different domains and work practices, which may reduce the use and the utility of this concept.

5

Furthermore, a particular kind of capability used in one work practice may not be considered relevant to other work practices, despite expectations of its usage across an organisation (see Section 4.1: Results) (Tell and Henkel 2018). The manifold variants of capability can be difficult to understand, compare and integrate with adjacent concepts, since they are to a certain degree bound to their domain or field of application. Furthermore, a common understanding of a particular kind of capability can be hampered by hidden assumptions, non-essential meanings that authors of frameworks or theories have not clearly stated, or non-essential meanings that have been overlaid on top of and embedded into a more general sense of capability. Currently, there exists no capability construct that simultaneously considers both the general concept of capability and the possibility to situate and create specific variants of the concept that are applicable to particular fields and work practices while enabling comparability between specific variants of capability. It may be tempting to let one profession, such as business or enterprise architects (NATO 2009) (The Open Group 2018), determine a single way to define, analyse and use capability, which is not transferable, generalisable and relevant to other work practices. However, the risk is that such a narrow, single-sided representation may fail to incorporate other essential aspects relevant to an organisation. Thus, different stakeholders may be required to use the same concept of capability while in reality being interested in different points of view and aspects of it. Instead of providing a source of cohesion and stability, the concept of capability can cause problems here in terms of alignment between work practices such as business and IT alignment (BITA). This can become problematic for multi-stakeholder, multi-practice, and multi-perspective approaches to capability based analysis and planning, such as EA frameworks. Thus, despite the fact that EA frameworks are inherently multi-stakeholder, multi-practice and multi-perspective approaches, they do not in general include specific mechanisms that facilitate the adaptation and tailoring of general concerns, such as capability, to situations and the specific work practices of stakeholders. Overall problem The overall research problem of this thesis is as follows:

The differences in perception and use across work practices, may hamper the utility of using the concept of capability. However, at the same time, a single, and focused definition of “capability” may miss to incorporate essential aspects needed in work practices.

6

1.3 Research questions and goals The overall research problem presented in the previous section forms the basis for the overall research question and goal of the thesis. Main research question The main research question of this work is as follows:

RQ: How can a concept of capability be designed and made adaptable so that it can be used in different work practices and at the same time support coherence between work practices?

By coherence, we mean that departments such as human resource management and marketing can use the concept of capability in ways that fit into their own professions and work, while at the same time their kinds of capability are comparable and can form a united, orderly and consistent whole. Overall goal The overall goal of the thesis is as follows:

To design a method and an adaptable viewpoint for the concept of capability so that it can be used in different work practices and at the same time support coherence between work practices.

Sub-goals The overall goal of the thesis has been divided into several sub-goals, as follows:

RG 1: To design a general concept of capability that can be situated and therefore adapted to specific work practices. RG 2: To design a method for situating the general concept of capability to specific work practices. RG 3: To design capability viewpoints that can be effectively integrated with existing enterprise architecture frameworks.

1.4 Structure of the thesis The thesis is structured around the basic IMRAD format (introduction, method, results, artifacts, discussion) (Dixit 2011) (Sollaci and Pereira 2004), with extensions (evaluation, conclusions) suggested by the design science researchers Gregor and Hevner (Gregor and Hevner 2013) and discussed by Johansson and Perjons (Johannesson and Perjons 2014). Note that the results of this work are presented in two places. The main results and contributions are presented in the Results section (Chapter 4). Intermediate outputs from the design science research process are presented integrated in the section entitled Research Process of the Thesis (Section 3.3).

7

The thesis is structured as follows: 1. Introduction 2. Related work

Related research Knowledge foundation

3. Research methodology Research process of the thesis

Intermediate outputs from the research process Contributions of included papers

4. Results (major results and contributions) Insights into problems using the concept of capability Designed and developed artifacts 1–3

5. Discussion Research quality and limitations

6. Conclusion Practical and theoretical contributions Future research

Appendix with supplementary material and glossary

1.5 Structure of contributions from papers

1.5.1 Structure of included papers Figure 1 illustrates the relationships between the overall research problem, research question and goals. This figure also illustrates the direct and indirect contributions of the included papers to the research goals. See Section 3.4 for information about the contribution of each paper to the research process and results.

8

Figure 1: Papers and their contribution to research goals.

1.5.2 Paper A: Capabilities and work practices—A case study of the practical use and utility Reference: WorldCIST'18 2018: Trends and Advances in Information Systems and Technologies (pp. 1152-1162) Publisher: Springer International Publishing Author(s): Anders W. Tell, Martin Henkel This paper contributed indirectly to research goals RG1 and RG2 by explicating problems involving the concept of capability. The author of this thesis was the main contributor to this paper, with a contribution of 95%.

1.5.3 Paper B: What capability is not Reference: BIR 2014, International Conference on Business Informatics Research (pp. 128-142).

Overall problemThe differences in perception and use across work practices, may hamper the utility of using the concept of capability. However, at the same time, a single, and focused definition of “capability” may miss to incorporate essential aspects needed in work practices.

Research questionHow can a concept of capability be designed and made adaptable so that it can be used in different work practices, and at the same time support coherence between work practices?

Sub-goal 1To design a general concept of capability that can be situated and therefore adapted to specific work practices.

Overall research goalTo design a method and an adaptable viewpoint for the concept of capability so that it can be used in different work practices, and at the same time support coherence between work practices.

Sub-goal 2To design a method for situating the general concept of capability to specific work practices.

Sub-goal 3To design capability viewpoints that can be effectively integrated with existing enterprise architecture frameworks

A) Capabilities And Work Practices: A Case Study Of The Practical Use And Utility.

B) What Capability Is Not.

D) Interpreting Service Using An Upper-Level Ontology.

C) A Method For Situating Capability Viewpoints.

inform & guide

indirectly

directlydirectly

9

Publisher: Springer International Publishing Author(s): Anders W. Tell This paper contributed directly to research goal RG1 through the identification of non-essential characteristics of the concept of capability and a proposed solution, the general capability pattern. This paper contributed indirectly to research goal RG3 through the design of a general capability pattern that can be integrated with EA frameworks. The thesis author was the main contributor to this paper, with 100% authorship.

1.5.4 Paper C: A method for situating capability viewpoints Reference: BIR 2016, International Conference on Business Informatics Research (pp. 278-293) Publisher: Springer International Publishing Author(s): Anders W. Tell, Martin Henkel, Erik Perjons This paper contributed directly to research goals RG2 and RG3 through the design of a solution, the capability situating method, that can be integrated with EA frameworks. This paper contributed indirectly to research goal RG1 by enabling the creation of situated capabilities. The thesis author was the main contributor to the paper, contributing 85% of the content.

1.5.5 Paper D. Interpreting service using an upper-level ontology Reference: WOIS 2014, 2nd International Workshop on Ontologies and Information Systems (pp. 66-77). Publisher: CEUR Workshop Proceedings Author(s): Anders W. Tell This paper contributed indirectly to (i.e. informed and guided) research goal RG3 through the exploration of conceptual analysis and design techniques, and the development of the analytical tools, lead-to pattern, result chain and result horizon. The paper also contributed to the understanding of how EA frameworks and their underlying ontologies can simultaneously accommodate multiple concepts such as capability, service, process and organisational designs. The author of this thesis was the main contributor to the paper, with 100% authorship.

10

11

2 Related Work

This chapter presents research related to this work, with the purpose of presenting a context for existing applications of the concept of capability, and to provide a knowledge base for the research presented in this thesis. The focus of this thesis is located at the intersection of the fields of EA, the standardised ISO 42010 approach for organising architectural knowledge - viewpoint, the concept of capability, and work practice.

Figure 2: The research focus of the thesis

2.1 Enterprise architecture Enterprise architecture framework: Introduction The field of EA has a long history, starting in the 1980s in the area of business information systems and business system planning. It is an established practice with the possibility for practitioners to become certified (The Open Group 2018). In EA, a variety of methods, techniques and types of knowledge are used to deliver business outcomes in the age of information and disruption by offering recommendations and advice to business and IT leaders. Today, there are hundreds of EA approaches, frameworks, theories, practices and commercial products such as TOGAF (The Open Group 2018), NAF (NATO 2009), and the DoD Architecture Framework (DoDAF) (Object Management Group 2012). The concept of EA has now acquired a tradition and an international standard, ISO 42010 (ISO/IECIEEE 2011), which codifies existing practices for one aspect of EA: the structure and documentation of architectural knowledge. Architectural knowledge is considered here to be the “fundamental concepts

12

or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (ISO/IECIEEE 2011). One central EA practice is the analysis and documentation of enterprises according to the world-views and perspectives of different stakeholders, including perspectives on capability. These activities result in a holistic view of an enterprise and its fundamental elements that facilitates the solution of problems and an understanding of changes. EA therefore covers a wide range of professions, practices and points of view across and within organisations. The ISO 42010 standard recognises many stakeholder groups, such as users, operators, acquirers, business analysts, designers, regulators, planners, reviewers, certifiers, compliance assessors, owners, suppliers, developers, builders and maintainers of systems. Furthermore, this standard recognises the diverse range of interests or concerns that the stakeholders may hold, such as functionality, feasibility, usage, system purposes, system features, system properties, known limitations, structure, behaviour, performance, resource utilisation and reliability (ISO/IECIEEE 2011). In modern enterprise architecture frameworks, capability is one of these concerns, together with adjacent concerns such as process and service. TOGAF Method EA frameworks can include a methodology as a complement to architecture description practices. Some EA methodologies are intended to be used to adapt and tailor the framework itself to suit a particular purpose. TOGAF is a widely used and open industry consensus framework for EA that is primarily used in the information systems field (The Open Group 2018). TOGAF consists of several aspects, including an architecture development method (ADM). In the preliminary phase of ADM, the TOGAF framework itself can be tailored to fit the scope of a project and the target enterprise and organisation. However, this step does not explicitly handle adaptation and tailoring of concepts to stakeholders’ work practices. The guidance for the ADM preliminary phase advises that the terminology and concepts used during execution of the method should be “generally understood across the enterprise”. This suggests that the use of artifacts such as the general capability pattern (see Section 4.2) is a recommended practice, since it may be used across an enterprise. Thus, the artifacts presented in this thesis can be used to extend TOGAF. Zachman Framework The Zachman Framework (now called Zachman Enterprise Ontology) is part of the EA heritage. It was invented in the late 1980s by John Zachman (Sowa and Zachman 1992). The framework addresses information systems architecture (ISA) in a similar way to the architecture of buildings.

13

The ontology primarily consists of a matrix that organises architecturally relevant knowledge. This matrix is a classification ontology and claims to be able to represent anything, and enterprises in particular. Each cell in the matrix represents the semantic intersection of columns and rows. The columns represent linguistic interrogatives (when, why, who, where, how, what), i.e. different ways to describe the world, while the rows represent different audiences and perspectives (planners, owners, designers, builders, subcontractors) of an ISA (Sowa and Zachman 1992). The rows do not represent increasing levels of detail or decomposition of the interrogatives, but rather the roles, perspectives, interests, models and constraints of the audiences. As such, the rows can be seen as representing different and interlinked work practices. The artifacts presented in this thesis can be used to enrich and adapt the rows and subsequently the content of the cells based on work practice knowledge.

2.2 Capability-related research This section presents fields and situations in which the concept of capability is used. The research in this thesis covers situations where more than one work practice is relevant, i.e. multi-stakeholder, multi-practice and multi-perspective contexts. This section therefore presents multiple fields of application and definitions of the concept of capability: • Enterprise architecture: A multi-practice and multi-perspective

approach to designing and describing enterprises and their architecture. The EA field furthermore incorporates key aspects of the following fields presented in this list.

• Capability-based management: Strategic management of organisations and their resources.

• Human development: Human capabilities in social and organisational contexts.

• Business analysis: Analysis and design of businesses and organisations. • Information system: Information systems and services design and

management.

Each of these fields uses different languages and involves different ranges of topics that participants consider to be important to talk about and address within their field. The research in this thesis relates to the identification of a shared general pattern that underlies such surface- and domain-specific languages (see Section 4.2: General Capability Pattern for a description of this pattern). The research conducted in this thesis does not aim to replace the existing

14

applications of and local variations in the definitions of capability, but rather to facilitate structured comparisons between approaches through the use of the general capability pattern and by facilitating the recognition and inclusion of situational, contextual and work practice knowledge into capability approaches and theories and EA frameworks.

2.2.1 Enterprise architecture The concept of capability has found its way into EA frameworks as one of many concepts. TOGAF is an example of an EA framework that incorporates the concept of capability in two ways (The Open Group 2018), firstly through guidance and advice on the capabilities needed for the performance of a sustainable TOGAF architecture practice, and secondly by the inclusion of a planning technique in the ADM method, based on the concept of capability, which focuses on achieving business outcomes. Examples of overlaid and embedded meanings In order to exemplify how the concepts of capability can be applied in an EAF, the Nato Architecture Framework (NAF) (NATO 2009) is chosen as basis. This choice is motivated by the fact that NAF is actively used for planning and incorporates the concept of capability, and can therefore be seen as a typical EAF. NAF was also used by the organisation studied in the ATM case study. The military use of NAF supports use cases such as mission analysis, planning, configuration, deployment, monitoring and preservation of resources, and NAF contains a wide variety of concepts in order to support these. The concept of capability shares the framework with other concepts such as operational activity, organisation, system, service, function, project, resource, standard, environment and physical asset. The framework includes seven viewpoints (referred to as ‘views’ in NAF) that govern and frame the documentation of capability-related knowledge, in order to support NAF use cases. These viewpoints are capability vision, capability taxonomy, capability phasing, capability dependencies, capability-to-organisational deployment mapping, operational-activity-to-capability mapping, and capability-to-service mapping. The NATO architecture framework metamodel (NMM), which provides definitions of major concepts in NAF by relating the terms used in NAF to each other in the form of a metamodel, incorporates the concept of capability in a specific structure that is of interest in this work. The structure in NMM separates the concept of capability into three distinct parts: capability; capability configuration; and composition of resources (see (A) in Fig. 3). These distinctions enable us to separate the specification of the result that is needed for a mission (the capability) from the source factors that realise the result. The capability configuration then represents the composition of a set of chosen and configured resources. More than one capability configuration can potentially realise a capability. In decision making, a single capability configuration can be seen as both an option and the subject of balance and

15

trade-off analysis compared to other options, that is, to other comparable capability configurations. This structure builds on two patterns: the specification-realisation pattern (B in Fig. 3) and the composition pattern (C in Fig. 3). These two patterns are general and can be applied almost everywhere, including in conjunction with processes and services. For example, they can also be used to define a process and a corresponding process configuration. The inclusion of these two patterns is an example of embedded semantics and practices, i.e. non-essential aspects added to the concept of capability that can be found in EAFs and other capability approaches. In this particular case, the specific additions are deemed suitable for military work practices.

Figure 3: Example of the structure of a NAF capability

NAF does not include support for situational method engineering or for the tailoring of concepts to fit different use patterns and work practices. This thesis presents a novel approach that specifically supports superimposed semantics and local specific additions while preserving the general semantics of the concept of capability.

2.2.2 Capability-based management The second field in which the concept of capability was used in its early stages was strategic planning and management, and the basic ideas and theories started to appear in the 1980s. A central idea explored in this field is that access to specific kinds of capabilities often leads to a competitive advantage. The concept of capability is used for many purposes, such as establishing a common strategic language, (strategic) planning and management, sourcing and procurement, supply chain management, and analysis of competitiveness. This field is of interest in a multi-practice context, since it provides a foundation for capability in strategic planning and management work practices. The wide range of capability applications and theories in strategic planning

16

and management result in a situation where “ambiguity and disagreement exist regarding foundational concepts such as the definition of resource characteristics that create value, the meaning of competitive advantage, and the logic used to link resource characteristics to performance outcomes” (Leiblein 2011). This range of conceptualisations and uses of capability provide motivation for the overall research problem of this thesis. The field has evolved into a mixture of resource-based, strategic factor market, and dynamic capability theories and logics, as described by Leiblein (Leiblein 2011). The resource-based view (RBV) of a firm is an interdisciplinary approach that to some extent precedes capability approaches. Capability approaches can be seen as the next step of RBV approaches, and are largely informed by or based on RBV thinking. In general, RBV theories are based on the idea that possession, ownership, control of or access to resources is positively and causally related to certain performance measures of the firm (Leiblein 2011). Here, resources, including capabilities, should possess qualities that enable (source) resources to lead to valuable results, such as sustained competitive advantage (Sanchez 2008). Examples of important and beneficial qualities of resources (and capabilities) within the strategic planning and management field are that they are valuable, rare, imperfectly imitable and non-substitutable (VRIN). It should be noted here that this approach and underlying pattern are specifically supported by the general capability pattern artifact developed and presented in this thesis (see Section 4.2), through the elements of the pattern: sources, lead-to and results. A key aspect of capability- and resource-based approaches is how the capabilities, resources, knowledge, tangibles or intangibles (that is, the factors of production) and other source factors could and should be invested in and acquired (Leiblein 2011). Companies can access and acquire capabilities (and resources) on (source) factor markets to develop and improve their strategies, leading to a competitive advantage. Strategic factor market theories can be used to address these kinds of questions (Maritan and Florence 2008). In the domain of strategic management, capabilities often lead to particular types of results, the most frequent being ‘competitive advantage’, or ‘sustained competitive advantage’. The definition of these particular result concepts are the subject of active discussion (Leiblein 2011). The variations in these concepts are partly based on different ideas of what constitutes a value, and what economic rent and opportunity cost mean. It should be noted here that capabilities in different use domains are defined for different kinds of results, as these are considered to be relevant and salient to a particular use domain. This is supported by the artifacts presented in this thesis, the general capability pattern and the capability situating method, both of which enable the specification of specific and qualified results (see Sections 4.2 and 4.4).

17

Another category of capability approaches involves organisational capabilities (Sanchez 2008; Harmon 2011; Ulrich and Rosen 2011). Organisational capabilities are those that primarily focus on actions within organisations, such as “repeatable patterns of action” (Sanchez 2008) or “the set of activities the enterprise performs, the knowledge it has, …” (International Institute of Business Analysis 2015). An example of a capability framework that includes processual and knowledge resources was developed by Ken Kusunoki et al. (Kusunoki et al. 1998), who defined a capability framework based on multi-layered knowledge and the way in which source knowledge leads to organisational performance results (productivity, product quality, innovativeness). In this framework, capability consists of “knowledge that [is] created and accumulated within the firm”. Local knowledge is embodied in people or embedded in things, and architectural knowledge is embedded both in the linkages between people and between things. This kind of knowledge interweaves people, organisation and things in stable patterns, structures or configurations. Processual knowledge is embedded in the dynamic interactions between people, organisational units, machines, and things. Its analysis emphasises the importance of organisational and processual capabilities: “Process capabilities play a fundamentally important role as core capabilities for product development of Japanese firms” (Kusunoki et al. 1998). Organisational capabilities vary in terms of their focus and definition. In their book The Essential Advantage: How to Win with a Capabilities-Driven Strategy(Leinwand and Mainardi 2013), Leinwand and Mainardi explore this area and advise that a good fit between the strategic direction and distinctive capabilities of an organisation leads to the creation of customer value and the “right to win” in chosen markets. In his book Adaptive Enterprise (Haeckel 2016), Stephan Haeckel shifts the focus to “organizational subsystems” that can lead to results that “contribute to the organization’s purpose”. What can be noted in these examples are the differences in focus and the choice of what constitutes source factors and results. These differences could be explained by the differences in their capability use cases, although an investigation of why these definitions and approaches are different is outside the scope of this thesis, as is an evaluation of these and other differences against each other. Paper C illustrates the inclusion of organisational (and processual) capabilities (International Institute of Business Analysis 2015), (Leinwand and Mainardi 2013), (Haeckel 2016) in a multi-practice context. Another category of capability approaches includes the concept of dynamic capability, which has been be used to describe the ability of an organisation to change and improve its capabilities (Teece 2007) (MAKADOK 2000; Winter 2003; Schreyögg and Kliesch-Eberl 2007; Rafati and Poels 2014). A dynamic capability can be seen as a second-order capability, i.e. as an operant that

18

operates on other (operant) capabilities. It can also be considered as analogous to second-order learning (doing the right thing), as opposed to first-order capabilities (doing the things right). To exemplify the concept of dynamic capability, Eisenhardt and Martin (Eisenhardt and Martin 2000) define dynamic capabilities as “the firm's processes that use resources, specifically the processes to integrate reconfigure gain and release resources to match and even create market change. Dynamic capabilities thus are the organisational and strategic routines by which firms achieve new resource configurations as markets emerge, collide, split, evolve, and die”. Javidan (Javidan 1998) presents an approach in which capabilities are organised in a hierarchy, where each level adds more value to ensure long-term success. Javidan defines four competency levels: resource, capability (processual competence), competence, and core competence (Javidan 1998). These competence levels are relevant to different strategy levels and work practices: resources are relevant to functional strategy (departmental functions), as are capabilities; competences are relevant to business strategy (strategic business units); and core competences are relevant to corporate strategy (chief executive officers) and to the mission statement (chief executive officers). Javidan’s framework provides an example in which multiple kinds of capabilities are organised in a multi-practice context. The capability situating method presented in this thesis assists in the identification of levels, such as those defined by Javidan, and relevant work practices, and subsequently the adaption and tailoring of specific kinds of capabilities that suit each work practice.

2.2.3 Human development and the capability approach The concept of capability is used in the field of human development, with a focus on individual well-being and social development. This field is of interest in a multi-practice context, since it integrates insights and guidance into one central aspect, the nature of human capabilities (Stanford University 2011). Human capabilities are relevant in social, firm, organisational, architectural, and information system contexts. The foremost pioneer in this field is Amartya Sen, a Nobel Laureate who developed the capability approach (Sen 2009; Sen 2011). The focus of the capability approach is the functionings, which are a person’s ‘beings and doings’. A capability relates to the various combinations of functionings that a person can achieve. An important aspect is the qualification of the possibilities a person has that actually can lead to something valuable (‘beings’, ‘doings’) for the person, such as meaningful life or work, happiness, education and justice. It is not sufficient that it is possible to achieve a certain result; this possibility should be associated with freedom, substantial freedom or a real

19

and effective opportunity. In simple terms, source elements such as market production, income to use, availability of goods and services, social institutions and norms, environmental factors and many others, together with an individual’s conversion factors, provide a capability set (i.e. opportunity set of achievable functionings) that can lead to functioning results through social influences, personal preferences and choice. Work by Sen has been taken up by authors such as Ingrid Robeyns (Robeyns 2003) (Robeyns 2005) and Martha Nussbaum (Stanford University 2011). In their work, they further analyse and specialise the general idea of capability, and both of these authors focus on social justice, humanity and democracy. As an example, Nussbaum identifies a list of prescribed human capabilities: life; bodily health; bodily integrity; senses, imagination and thought; emotions; practical reason; affiliation; other species; play; and control over one’s environment (Stanford University 2011). The capability approach focuses on human capital, a kind of capability that is relevant (with other kinds of capabilities) to an organisation or community with multiple work practices. An example is found in the development of strategy maps by Kaplan and Norton (Kaplan and Norton 2008), in which human capital is part of the learning and growth perspective of a company. See Paper C for an illustration of the inclusion of human capabilities in a multi-practice context. The underlying structure of the capability approach is also supported by the general capability pattern artifact presented in this thesis (see Section 4.2).

2.2.4 Business analysis Business analysis provides yet another field and type of work practice in which the concept of capability is used. The concept of capability is used in business analysis activities as a key element and an input for identifying and assessing the gaps preventing an organisation from meeting business needs and achieving desired outcomes. Practitioners can use capability maps (Beimborn et al. 2005) (Ulrich and Rosen 2011) to create an overview of the capabilities that an organisation has, intends to design, or acquires as a basis for business analysis. Furthermore, business capability maps are used within enterprise (and business) architecture management, again as a basis for carrying out business analysis (Aleatrati Khosroshahi et al. 2018). The International Institute of Business Analysis (IIBA) offers support for a capability-centric view of the enterprise, and defines capability as: “The set of activities the enterprise performs, the knowledge it has, the products and services it provides, the functions it supports, and the methods it uses to make decisions” (International Institute of Business Analysis 2015). This definition of capability is an example of a specific definition tailored to

20

suit IIBA work practices and analysis methods. Business-process-oriented capabilities can be used together with other kinds of capabilities in an organisation or community with multiple work practices. See Paper C for a demonstration of the inclusion of processual capabilities in a multi-practice context. The underlying structure of the IIBA approach is also supported by the General Capability Pattern artifact presented in this thesis (see Section 4.2).

2.2.5 Information systems Another field where the concept of capability has attracted attention and use is information systems (IS). There are a wide variety of applications of capability, which has become a part of enterprise and business architecture frameworks and business analysis practices, as described in the preceding sections. McKeen and Smith (McKeen and Smith 2011) also incorporate capabilities when addressing information technology strategy and management. Moreover, it has been proposed that IS design could be based upon the use of capabilities. The CDD approach (Bērziša et al. 2015) aims to apply enterprise models representing enterprise capabilities to create executable software with built-in contextualisation and model-based patterns, thus leading to CDD. Service-oriented architecture (SOA) is a kind of software architecture where software applications or components provide services to consumer applications or components. Here, a service can be viewed as an offer of the results (or real-world effect) of an internal capability to other consumers (The Open Group 2011). The organisation OASIS sees SOA as a “paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains” (OASIS 2006) (OASIS 2009). The Open Group organisation defines capability in their SOA Reference Architecture as “an ability that an organization, person, or system possesses to deliver a product or service” (The Open Group 2011). Requirement engineering is a major phase or activity in IS development. In this phase, capabilities can be introduced, as exemplified by the actor-centric approach I*, in which the concept of capability has become a recent addition (Danesh and Yu 2014). The artifacts presented in this thesis are designed to be general and adaptable to the specific IS applications discussed above.

2.2.6 Learning points from capability-related research The manifold fields and work practices in which the concept of capability is used, as well as the many conceptions and local variations, create difficulties for shared understanding, use and utility across work practices. The majority of the capability approaches that have been studied do not include

21

a method that can actively adapt and tailor the concept of capability to specific work practices. This is likely to be because specific approaches are related to only one domain and work practice. However, enterprise architecture frameworks represent a type of framework that addresses the needs of many types of stakeholders, but not explicitly their work practices. Furthermore, the ISO 42010 standard does not explicitly support the creation of viewpoints that support situational knowledge and work practices.

2.3 Work practices The idea of practice and practice theory provides a knowledge foundation for the understanding, analysis, and specification of situations and work practices in which the concept of capability is relevant and used. The idea of practice is important within the field of social science; while not supported by a unified practice theory, the study of practices provides insight into human activities (Johannesson and Perjons 2017). A practice can be difficult to define. Adler et al. (Adler and Pouliot 2011) identify five characteristics that show that a practice should be interpreted in a wider sense compared to a profession:

1. It is a process of doing something 2. It contains repetitions of actions 3. It can be performed correctly or incorrectly 4. It rests on accumulated knowledge 5. It combines the use of communication with the material world

Furthermore, Brown (Brown and Duguid 2000) points out that a practice is driven by tacit knowledge. Activities carried out in an organisation can be seen as a fluid scene of multiple practices carried out at the same time (Nicolini 2012). In this thesis, the concept of practice is used to characterise both work being done and the requirements on the use of the concept of capability in such work.

2.4 Knowledge foundation This section presents the knowledge used as a base for the created artifacts, which includes theories, models and methods.

2.4.1 Situational method engineering The discipline of situational method engineering (SME) provides foundational knowledge and rigor for the design and development of the capability situating method presented in this thesis. Method engineering (ME) is a discipline that aims to design, develop, adapt

22

and tailor methods, techniques, work products, and tools for specific usage. SME is a major part of method engineering, which encompasses aspects of the creation of development methods for specific situations (Henderson-Sellers and Ralyte 2010). SME enables the creation of specific methods by using and tailoring existing and reusable method fragments from method repositories. SME involves activities specifying method requirements, including use requirements, method selection and assembly, and domain-driven adaptation. ME and SME are focused on the localised construction of organisation or project-specific methods, as opposed to acquiring off-the-shelf methods from method suppliers. In this thesis, the resulting capability situating method chunk is aligned with the view presented in (Ralyte et al. 2003) that a tailored method should include the context of its use.

2.4.2 Lattice of theories The lattice of theories (Sowa 2005) provides foundation knowledge and rigor for the analysis of the similarities and differences between concepts of capability. Furthermore, this method and these principles enable an analysis of how definitions of general and specific theories relate to each other, including the identification of patterns by comparing the addition and removal of belief-representing sentences. The lattice of theories (Sowa 2005) is a structure and a method for describing how theories are related, using a step-wise refinement from one theory to another. In this method, a theory, such as a definition of capability, consists of parts that are beliefs about the world, each expressed in a sentence. Similarities and differences can be analysed via a comparison of these parts (belief-representing sentences). The shift or move from one theory to another is considered to be a set of belief revisions. According to John Sowa (Sowa 2005), four key types of belief revisions can be defined:

• Contraction: A sentence is removed, forming another, simpler belief set.

• Expansion: A sentence is added, and nothing is removed. • Revision: A combination of contraction and expansion is created, in

which a sentence is added at the same time as other sentences are removed.

• Analogy: The structure of the belief sentence is maintained, but the names of the types, relations and individuals that appear in the belief sentence axiom are changed.

In order to create the lattice, theories need to be represented by belief-representing sentences, possibly expressed in a formal language such as common logic (ISO/IEC 2007).

23

A lattice of theories with the various types of belief revisions is illustrated in the following diagram.

Figure 4: Lattice of theories and belief revisions

2.4.3 Basic formal ontology The basic formal ontology (BFO) is an upper-level ontology that provides a knowledge foundation, rigor and a comparative base for analysed concepts. BFO provides the top-level theory for the lattice of theories, and is used for the specification of concepts such as capability and adjacent concepts such as process, service and resource. The definitions of capability analysed are formulated as theories, that is belief representing sentences, and can derived from the top-level theory through belief revisions. BFO also includes the concept of ‘disposition’, which bears a strong resemblance to capability. The BFO specification states: “Dispositions ... are introduced into BFO in order to provide a means for referring to what we can think of as the potentials or powers of things in the world without the need to quantify over putative ‘possible worlds’ or ‘possible objects’”. BFO is an upper-level ontology that supports the creation of lower-level, domain-specific ontologies. The BFO project (Smith and Grenon) started in 2002, with initial theoretical contributions from Barry Smith and Pierre Grenon. Its aim is to provide a genuine upper ontology that can be extended by domain ontologies developed for scientific research. With respect to other public domain ontologies such as DOLCE, SUMO and CYC, BFO provides a smaller core that is extendable and adaptable to specific domains (Smith and Ceusters 2010), thus making it suitable for the creation of capability and service-specific extensions. The BFO ontology was chosen over more information-system-oriented ontologies such as the Bunge-Wand-Weber (Wand and Weber 1993), since it is an upper-level theory, has a strong basis in natural sciences, and promises to bridge natural, social and technically oriented applications and work practices. In this thesis, BFO is used to inform and guide the analysis and design of the general capability pattern and the service deconstruction (see paper D). For future work, BFO offers a foundation for a full logical and ontological formalisation of the general capability pattern.

24

Key concepts from BFO are described in the Glossary.

2.4.4 ISO 42010 architecture description standard The ISO 42010 is an international standard that regulates existing practices within the field of enterprise architecture EA (ISO/IECIEEE 2011). The aim of ISO 42010 is to address “the creation, analysis and sustainment of architectures of systems through the use of architecture descriptions” (ISO/IECIEEE 2011). By basing the research on this standard, rather than a specific EA framework (EAF), this research is applicable to a wide range of EAFs that conform with this standard. ISO 42010 includes a standardised mechanism by which knowledge (for example about capability) can be defined, explicated, documented and related to other kinds of knowledge, such as knowledge about processes, services, equipment, facilities etc. However, the ISO42010 standard does not include an explicit mechanism by which knowledge can be adapted and tailored to the work people do with others. ISO42010 provides a mechanism for organising knowledge according to concerns relevant to stakeholders. Current EA practices use this mechanism to document architectural and system knowledge by partitioning knowledge based on stakeholder concerns; this has proven to be effective in practice, and thus has become a standard part of EA frameworks over time. The major terms defined in ISO 42010 that are relevant to this thesis are as follows:

• A concern is “a ‘system’ interest in a system relevant to one or more of its stakeholders, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences “(ISO/IECIEEE 2011).

• A stakeholder (of a system) is “an individual, team, organization, or classes thereof, having concerns with respect to a system” (ISO/IECIEEE 2011).

The actual architectural information in an architecture description through its views and models:

• An architecture description is a “work product used to express an architecture” (ISO/IECIEEE 2011).

• A view is a “work product expressing the architecture of a system from the perspective of system concerns” (ISO/IECIEEE 2011).

• A model is a “discrete part of an architecture view consisting of architecture description elements” (ISO/IECIEEE 2011).

A view is documented according to the conventions defined in an architecture framework, with corresponding viewpoints. A model is similarly documented according to corresponding model kind conventions.

25

• An architecture framework is the “conventions, principles and

practices of architecture description established within a specific domain of application or community of stakeholders” (ISO/IECIEEE 2011).

• A viewpoint is a “work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns”. A viewpoint is documented with reference to typical stakeholders and related concerns, one or more kinds of model, and its sources, such as its author, history and bibliography (ISO/IECIEEE 2011).

• A model kind provides “conventions for a type of modelling” and is documented with the languages, notations, conventions, modelling techniques, analytical methods and/or other operations to be used on models of this kind (ISO/IECIEEE 2011). Examples of model kinds include capability maps, data flow diagrams, class diagrams, Petri nets, balance sheets, organisation charts and value streams.

The following diagram (Figure 5) illustrates the architecture framework and its key relationships to the architecture description.

Figure 5: Key concepts in ISO 42010

In this thesis, the term interested party, which is by preferred by ISO and defined as a “person or organization that can affect, be affected by, or perceive themselves to be affected by a decision or activity”, is sometimes used as a synonym for stakeholder. The following diagram (Figure 6) presents key concepts of ISO 42010 with their primary relationships. The concepts shown in grey form part of an architecture description.

26

Figure 6: Key constructs of ISO 42010, shown in relation to an architecture framework and an architecture description

27

3 Research Methodology

This chapter describes the methodology used in the research reported in this thesis. This work was conducted within the field of EA, which has a strong focus on the design of systems (The Open Group 2018), (ISO/IECIEEE 2011). The design science paradigm was chosen as the foundation for the research methodology applied here. The research is grounded in an empirical case study aimed at characterising the overall situation and problems occurring when the concept of capability was used within several work practices.

3.1 The choice of design science paradigm as a foundation The research questions and goals addressed in this thesis focus on the use and utility of the concept of capability. The research presented here has been conducted in the field of EA, where it has become common practice to document architecturally relevant knowledge in a structured way. The international standard ISO 42010 (ISO/IECIEEE 2011) standardises existing EA practices of documentation. Through the use of ISO 42010, it is possible to document an architecture description that is partitioned according to concerns relevant to a stakeholder. Knowledge corresponding to a concern is framed and governed by rules and guidance described in a viewpoint construct (see Section 2.2.5 for information about ISO 42010 and viewpoints). The concept of capability is a commonly defined concern that is framed using capability viewpoints, which are often included in EA frameworks. Design science primarily aims to create artifacts, including constructs, which are “terms, notations, definitions, and concepts that are needed for formulating problems and their possible solutions”; models, which are “representations of possible solutions to practical problems, so a model can be used for supporting the construction of other artifacts”; methods, which “express prescriptive knowledge by defining guidelines and processes for how to solve problems and achieve goals”; and instantiations, which are “working systems that can be used in a practice” (Johannesson and Perjons 2014). The overall goal of this thesis is to design capability viewpoints and a method for their uses. The design science paradigm was therefore chosen as the foundation, and this can be justified by the type of research outcome desired .

28

3.3 Research processes of the thesis The overall research strategy divides the research process into two stages: the first focuses on discovery, design theory building and the creation of a set of artifacts to solve the identified problem and satisfy the requirements; the second shifts the focus to justification and design theory testing by refining the design of the artifacts and empirically evaluating their use and utility. The results of the first stage are reported in this thesis. The research was performed iteratively, and each paper contributed to one or more DSRM activities. IDEF0 description technique Each DRSM activity within the research process is described using the IDEF0 process description technique (IDEF). The IDEF0 focuses on describing a transformation function that takes inputs (arrow from left) and transforms them into outputs (arrow to the right, see Fig 8). The transformation is controlled (arrow from top) by some knowledge, in this case the chosen research strategies and research methods. The transformation is also founded on certain mechanisms (arrow from the bottom), which in this case are theories, constructs, and methods. Figure 8 illustrates the application of IDEF0 notation to a single generic design science research activity.

Figure 8: The IDEF0 description technique

3.3.1 Starting point: Initial problems The starting points or seeds for the research can be divided into two types. The first set of seeds arose from the author’s own international experiences in developing, tailoring and using EA frameworks. At the outset of the research, capability was a concept that had been relatively recently introduced into EA frameworks, and capability modelling practices overlapped with business process modelling practices. Experiences, initial problems and questions such as ‘If process modelling and analysis can already be done, then what does

29

capability add?’, and ‘Why do so many definitions of capability look similar to those of processes and business components?’ provided seeds for the research effort. The second set of seeds arose from the large number of conceptualisations of capability that had emerged from the literature and research.

3.3.2 Identify problem and motivate The DRSM activity “Identify problem and motivate” aims to explore and frame the problems motivating the design and development of the artifacts. The initial problem for this thesis was explicated and refined using an empirical case study in the ATM domain. This is reported in paper A, a study of problems that occur when the concept of capability is expected to be used across several work practices (see Section 4.1: Results for summaries of the findings and problems). The following diagram summarises the “Identify problem and motivate” activity using the IDEF notation.

Figure 9: Summary of the DSRM activity ‘Identify problem and motivate’

3.3.2.1 Method and foundation The research methods used in paper A to identify and refine problems were as follows: • Research strategy: Case study (Myers 2008) • Data collection method: Semi-structured interviews (Myers 2008) • Data analysis method: Thematic analysis (Braun and Clarke 2006).

The case study was an initiative launched by the European Commission, and was a research programme with a five-billion-Euro budget in the ATM domain.

30

Data were gathered through semi-structured interviews with experts in five work practices that were using or expecting to use the concept of capability. The interview questions were focused on the participants’ experiences of their own use of the concept of capability and its utility. The participants were explicitly not asked about how they defined “capability”. At least two persons from each work practice were interviewed, giving a total of eleven respondents. All interviewees were assigned to the ATM programme as senior experts. The knowledge foundations used were knowledge about capabilities, and knowledge about EA and EA frameworks.

3.3.2.2 Result: Explicated problems We focus here on the four explicated problems that were refined in paper A, expressed here in a condensed form for brevity. Problem 1: Manifold and variety

Explicated Problem 1. The kinds of the concept of capability, their use and the utility are many and varies between work practices.

This practical problem of multiplicity and variety can lead to a reduced uptake of the concept of capability, due to fragmentation of knowledge and skills, and consequently incoherent and ineffective use across projects or organisations. A fragmented understanding of concepts such as capability may be an indicator that the concept has acquired a general and common-sense meaning that has specific relevance, interest, importance and use for more than one type of person or work practice. In the ATM case study, none of the respondents rejected the use of the concept of capability, although their experiences and attitudes ranged between positive, wait-and-see, neutral, and negative. Problem 2: Expectations and Relevance

Explicated Problem 2. The concept of capability is expected to be used by many people, although some people use it by referring or linking to others use, do not use it themselves, or see little utility of using it.

The ATM case study found that despite expectations of use, the utility had in many cases had not yet materialised or had not been institutionalised. In other cases, “old-fashioned” concepts were used instead of capability, such as system, sub-systems, and functions. The differences in terms of uptake and experiences in the ATM case study indicate a low relevance for this concept to the various stakeholders in the work they do.

31

Problem 3: Single definition in enterprise architecture framework Explicated Problem 3: Using an enterprise architecture framework with a single definition of capability to integrate different kinds of work products within a project may not lead to a consistent and beneficial use of the concept of capability.

In the second phase of the ATM programme studied here, the nature of the programme shifted to a structured engineering approach. The large-scale systems engineering (SE) approach included the development of requirements and an EAF based on a modified version of NAF. This framework included capability modelling with a set of capability views and a single concept of capability. The EAF was used to integrate different kinds of work products from all parts of the ATM programme. The importance of the EAF suggests that the integration of capability artifacts with EAFs is important. In the ATM case study, it was found that when the use of the concept of capability evolved through learning by doing (in the first phase), it was perceived as being significantly more beneficial than when it was reintroduced through an SE approach and an EAF with a single definition of capability. Problem 4: Overlaid meanings

Explicated Problem 4. The concept of capability is overlaid with non-essential meanings and aspects.

Specific definitions and use of the concept of capability can often be found to have meanings and aspects from other areas superimposed on them. This leads to fusion between non-essential aspects and the concept of capability, and this can obfuscate the unique contributions of working with the concept of capability. In the ATM case study, a number of aspects that were overlaid on top of the general concept of capability were identified (see Paper A for more information). Concepts are often created and defined by experts for use by others. When a general concept is overlaid with other meanings and aspects, this may become a problem, since additional meanings and aspects may be primarily relevant to the experts and only secondarily or not at all relevant to the intended users.

3.3.3 Define the objectives of a solution The DRSM activity “Define the objectives of a solution” aims to define the requirements of the artifacts that will inform and guide their design, development and evaluation. This activity was directly addressed in papers A, B and C.

32

The elicitation of requirements through a conceptual analysis resulted in a set of identified requirements for the artifacts. This activity also resulted in the identification of a set of demonstration cases and ‘what capability is not’ test cases, which were used to inform and guide the design, demonstration, and evaluation activities(Tell 2014a). The following diagram summarises the activity “Define the objectives of a solution” using the IDEF notation.

Figure 10: Summary of DSRM activity ‘Define the objectives of a solution’

3.3.3.1 Method and foundation The research method used was conceptual analysis (Olivé 2007) (Object Management Group 2017), which included a specialised ‘What capability is not’ analysis(Tell 2014a). The knowledge foundations used were knowledge about capabilities, and knowledge about EA and EAFs.

3.3.3.2 Result: Types of artifacts An analysis of the problems leads to the identification of three types of artifact that address the problems and are the objects of requirements: ◦ A construct artifact that enables a way to describe, define, compare,

tailor and reason about the concept of capability. This led to the creation of Artifact 1, the general capability pattern (see Section 4.3).

◦ A model artifact that enables the integration of the concept of capability with a wide range of EAFs. This led to the creation of Artifact 2, the base capability viewpoint (see Section 4.3).

◦ A method artifact that enables the concept of capability to be tailored to certain situations and capability approaches. This led to the creation of Artifact 3, the capability situating method (see Section 4.4).

During the iterative course of the research process, the type and nature of the artifacts were refined until the structure and behaviour presented here were achieved.

33

3.3.3.3 Result: Defined requirements The elicitation of requirements allowed the following context and requirements to be identified for the artifacts. The overall context for the requirements is as follows:

An enterprise, organisation or project in which the concept of capability is suggested, expected or actually used in more than one work practice.

The requirements are as follows:

Requirement 1: The general capability pattern, base capability viewpoint and capability situating method should be generally applicable to different domains and work practices.

The artifacts designed here should be generally applicable to different domains and should be able to be combined with existing capability analysis methods. In this way, the barriers to the application of the method are lowered, thus improving the conditions for and the actual use of capability analysis within an organisation or project. This requirement therefore addresses Problem 1 Manifold and Variety), Problem 2 (Expectations and Relevance), and Problem 4 (Overlaid Meanings).

Requirement 2: The general capability pattern should enable similarity and differences comparisons between a general concept of capability and a specific and situated capability concept.

The aim of this requirement is to facilitate a comparative analysis between different kinds of capability concepts and approaches, thereby providing assistance and precision for definitional work in efforts towards harmonisation by researchers and practitioners, and in the incorporation of these concepts into existing theories, frameworks and methodologies. The process of comparing definitions of capability and capability-oriented theories becomes easier when the underpinning assumptions and additional characteristics and aspects are made visible, described and argued for (Leiblein 2011). This requirement therefore addresses Problem 1 Manifold and Variety) and Problem 4 (Overlaid Meanings).

Requirement 3: The base capability viewpoint and capability situating method should be compliant with the ISO 42010 standard ontology for architecture descriptions.

34

The ISO 42010 standard codifies existing EAF practices, and basing the artifacts on this standard therefore simplifies and improves integration with existing EAFs and support for multiple work practices in EAFs, with their potentially different uses of the concept of capability. This requirement therefore addresses Problem 3 (EAF).

Requirement 4: The capability situating method should produce situated capability viewpoints in an efficient way, by supporting the structured consideration of situational work aspects.

This requirement ensures that qualities such as job fit, performance and output expectancy, intention-to-use and subsequent actual use of capability analysis are considered in the development of the method. This is an important prerequisite for organisations that are starting to use the capability situating method. These are all aspects of the well-known theory of the technology acceptance model (Venkatesh et al. 3AD). This requirement addresses Problem 2 (Expectations and Relevance), Problem 1 (Manifold and Variety), Problem 3 (EAF) and Problem 4 (Overlaid Meanings).

Requirement 5: The general capability pattern should conform to the anti-requirements expressed in the ‘what capability is not’ cases.

The ‘what capability is not’ cases contain examples of which definitions of capability should not be incorporated. Being able to distinguish the essential aspects from the non-essential ones, and which aspects are relevant in specific circumstances, strengthens the precision of the conceptual analysis and design. This requirement therefore addresses Problem 1 (Manifold and Variety), and Problem 4 (Overlaid Meanings).

3.3.3.4 Result: “What capability is not” cases The “what capability is not” cases provide a foundation for a partial evaluation of internal validity (see the definition in Section 3.3.6) of the general capability pattern artifact. Evaluation through informal argumentation is supported by the use of test capability cases, in which a particular definition of capability can be assessed as being consistent with the non-essential aspects and distinctions that are explored. These cases are formulated using vocabulary and concepts from the general capability pattern (see Section 4.2). The identification of the “what capability is not” test cases is inspired by the work of Robert I. Sutton and Barry M. Shaw, in What Theory is Not (Sutton and Staw 1995), and Richard Baskerville, in What Design Science is Not

35

(Baskerville 2008), where they suggest that broader agreements may be achieved more easily by seeking agreement on what a theory or design science is not. It is also important to use knowledge of what a concept is not in conceptual analysis, i.e. why it is separate and distinct from everything else. “What capability is not” cases from Paper B Paper B identifies the following cases of “what capability is not”, expressed here in a condensed form for brevity. These cases relate primarily to aspects that cannot be considered essential to a general concept of capability. However, these aspects may be present in more specific kinds of capability. • Organisational construct: Although a capability may be attributed to an

organisation, other entities can possess capabilities, such as people, clouds, and machines.

• Single kind: There are innumerable kinds of capabilities, which are of interest to people in various types of work.

• Resource: Some capabilities may be considered resources, although others do not pass the resource criteria of being VRIN, such as when a machine has the capability to pollute.

• Intention: There are cases in which a capability leads to something that is not designed for or intended, such as pollution.

• Function: Some capabilities deliver a result that is not related to an intentional design, an evolutionary physical makeup, or a routine organisational activity.

• Contextual: Certain capabilities are ideal, and are defined without reference to context.

• Abstract: A capability represents a possibility; however, the elements, possessor, substantiality, source, lead-to and result may be concrete in some cases, and somewhat abstract in other cases.

• Process: In many cases, a physical process generates the results of the capability; in other cases, mathematical formulae or logic lead to these results. The concept of capability also includes two characteristics that are not included in the concepts of process - possibility and substantiality.

• Result: A capability is not defined solely as a result, and includes several other essential elements (see the general capability pattern in Section 4.2 for a description of these essential elements).

Paper B also includes a section on using the interrogatives ‘what’ and ‘how’ to characterise capabilities. • What vs. how: The what–how distinction is problematic, since these words

are polysynomous and flexible. The ‘what’ and ‘how’ do not provide unambiguous semantic definitional power or a pragmatic aid for practitioners.

36

Additional cases The following cases have not been published, but are relevant to this thesis since they occur in EAFs such as NAF (Section 2.1.1). What capability is not: Specification Some types of capabilities can be divided into two parts: a high-level specification, and something that can realise that specification. In the example of NAF given in Section 2.1.1, the specification is labelled the ‘capability’ and the realisation is labelled the ‘capability configuration’. However, there are cases in which capability represents only a possible characteristic of something. For instance, a car is capable of transporting a person 100 metres, or a computer is capable of sending 1,000 messages per second. In these cases, the capability does not include design considerations: where the capability is a specification, and something else is defined in order to realise this capability. A specification is therefore not an essential characteristic or aspect of the concept of capability. Thus, general capability patterns should not incorporate the semantics of specification–realisation, although they should allow the inclusion of specification–realisation in more specific kinds of capabilities. What capability is not: Composition Certain kinds of capability can be divided into a capability and something that contains the elements making up the source of this capability. In the example of NAF in Section 2.1.1 (NATO 2009), these two aspects are labelled the ‘capability’ and the ‘capability configuration’. A capability configuration is a combination and composition of source elements that form a capability when combined. Traditionally, more than one capability configuration can deliver a given capability. However, there are cases in which a capability represents only a characteristic of something, and does not include aspects of its design or intentional composition; for example, a cloud is capable of producing rain. Thus, being a composition of other elements is not an essential characteristic or aspect of the concept of capability. General capability patterns should therefore not incorporate the semantics of capability–composition, but should allow the inclusion of capability–composition in more specific kinds of capabilities.

3.3.3.5 Result: Demonstration cases Demonstration cases are used to inform and guide the design and development of artifacts. They also demonstrate the applicability of an artifact within a given situation. A set of demonstration cases from different domains provides a foundation for the partial evaluation of external validity, since they cover different uses, approaches and domains.

37

Demonstration cases are discussed in Section 3.3.5: Demonstration.

3.3.4 Design and development The DRSM activity entitled “Design and development” aims to design and develop the artifact to comply with the stated requirements, context and problems. This DRSM activity was directly discussed in papers B and C, and was indirectly addressed in paper D. The following artifacts were designed and developed in this work, and are reported in Chapter 4: Results:

• The general capability pattern (construct artifact) (see Section 4.2) • The base capability viewpoint (model artifact) (see Section 4.3) • The capability situating method (method artifact) (see Section 4.4)

These artifacts provide capability modellers and EAF builders with a practical way of incorporating situational capability knowledge into their products. The following diagram summarises the “design and development” activity using IDEF notation.

Figure 11: Summary of the DSRM activity ‘Design and development’

3.3.4.1 Method and foundation The main research methods used here were conceptual analysis and design methods (Olivé 2007) and the Semantics of Business Vocabulary and Business RulesTM (SBVR) (Object Management Group 2017). Conceptual analysis focuses on the identification of concepts and their parts, such as their essential, non-essential and delimiting characteristics (Object Management Group

38

2017), in order to improve the understanding of a topic or the meaning(s) behind words, signs or sentences. The shared knowledge foundations for all artifacts designed here were knowledge about capabilities and knowledge about EA and EAFs. Deconstruction and reconstruction technique: Artifact 1, the general capability pattern, was created using conceptual analysis and design methods and a deconstruction and reconstruction technique, simplifying integration (into theories, frameworks, and work practices) and allowing comparisons of various capability concepts. The deconstruction and reconstruction technique is based on the principles of the lattice of theories, in which theories are created and related using belief revisions. Specific definitions and theories of capability can be deconstructed (contracted) until the most general sense of capability is reached, i.e. nothing more can be removed. This technique enables authors of specific capability definitions to reconstruct (expand) specific concepts of capability by adding back certain propositions, assumptions, contexts, constraints, modifiers and qualifiers. The process of integrating (within theories and frameworks), comparing and relating the various definitions of capability becomes easier when authors are required to openly declare and motivate the inclusions they have made. This technique provides a foundation for addressing Requirement 3, and was used for all demonstration cases and in the service deconstruction paper D. A capability pattern poster was also created, which offers examples of added elements found through using this deconstruction and reconstruction technique on a wide range of definitions of and approaches to capability, including those in the demonstration cases. This poster and its example elements have been used in public communications and discussions about the general nature of capability. A capability template was created that simplifies and assists in the creation of specific capability constructs. The capability pattern poster and the capability template are presented in Appendices A and B.

3.3.4.2 Result: Artifact 1 – The general capability pattern The general capability pattern provides a conceptual foundation for discussions of and comparisons between the general nature of the concept of capability and the various definitions of capability. This artifact was directly discussed in papers B and C, and was indirectly addressed in paper D. The artifact was designed and developed using conceptual analysis and design methods (Olivé 2007) (Object Management Group 2017), including formal concept analyses (Stumme 2009) and the deconstruction and reconstruction technique (see the following section). The knowledge foundations were the lattice of theories and the BFO.

39

3.3.4.3 Result: Artifact 2 – The base capability viewpoint The base capability viewpoint integrates the general capability pattern with the ISO 42010 viewpoint, a standardised EA knowledge capture and documentation construct. The artifact was directly addressed in paper C, and was designed and developed using conceptual analysis and design (Olivé 2007) (Object Management Group 2017). The knowledge foundation was the ISO 4210 Standard (ISO/IECIEEE 2011).

3.3.4.4 Result: Artifact 3 - The capability situating method The capability situating method enables the creation of specific viewpoints using the base capability viewpoint that incorporate situational and work practice concerns. The artifact was directly addressed in paper C, and was designed and developed using conceptual analysis and design methods (Olivé 2007) (Object Management Group 2017) and situational method engineering (Ralyte et al. 2003) (Henderson-Sellers and Ralyte 2010) (Nehan and Deneckere 2009). The knowledge foundations were the lattice of theories (Sowa 2005), the ISO 4210 Standard (ISO/IECIEEE 2011), and practice theory (Adler and Pouliot 2011) (Brown and Duguid 2000) (Nicolini 2012).

3.3.5 Demonstration The DRSM activity ‘Demonstration’ aims to show how the artifacts can be used to solve one or more instances of the problem. This activity was directly addressed in papers B and C. Artifact 1 (the general capability pattern) was demonstrated through a number of demonstration cases. A demonstration case is one in which the general capability pattern can be extended and tailored to reconstruct a specific definition of capability. A demonstration case is primarily used to demonstrate the applicability of an artifact in a given situation, but is also used to inform and guide its design and development. Furthermore, the set of demonstration cases from different domains provides a foundation for a partial evaluation of external validity, since they cover different uses, approaches and domains. The results, information about demonstrated artifacts and knowledge about the use of artifacts were fed back into the next DSRM iteration.

40

The following diagram summarises the ‘Demonstration’ activity using the IDEF notation.

Figure 12: Summary of the ‘Demonstration’ DSRM activity

3.3.5.1 Method and foundation The research method used was conceptual analysis and integration. The knowledge foundations used were knowledge about capabilities, and knowledge about EA and EA frameworks.

3.3.5.2 Result: Demonstration cases The papers included in this thesis discuss the following demonstration cases, which are expressed here in a condensed form for brevity. During the design and development stages, further demonstration cases were used that were not reported in these papers. The demonstration cases used to examine Artifact 1 are drawn from various domains and are well-known and practiced in their fields. By using these demonstration cases, it was possible to show that the general capability pattern can be expanded to satisfy multiple definitions of capability, thus leading to coherent interpretations across domains and work practices (addressing Problems 1, 2 and 4). The general capability pattern, base capability viewpoint and capability situating method were demonstrated together by successfully applying them to the strategy map framework for strategic analysis, planning and execution by Kaplan and Norton (Kaplan and Norton 2008), as described in paper C. Demonstration Case 1: UPDM 2.0 Domain: Military Approach: UPDM 2.0 Presented in paper B: What Capability is Not Demonstration Case 2: Analysis Domain: Human development

41

Capability approach by Amartya Sen (Sen 2009) Presented in paper C: A Method for Situating Capability Viewpoints Demonstration Case 3: Business Analysis Domain: Business analysis and processes Approach drawn from A Guide to the Business Analysis Body of Knowledge (International Institute of Business Analysis 2015) Presented in paper C: A Method for Situating Capability Viewpoints Demonstration Case 4: Customer Value Domain: Customer Value Approach: The Essential Advantage: How to Win with a Capabilities-Driven Strategy (Leinwand and Mainardi 2013) Presented in paper C: A Method for Situating Capability Viewpoints Demonstration Case 5: Strategy Domain: Strategy, organisational purpose Approach: Adaptive Enterprise (Haeckel 2016) Presented in paper C: A Method for Situating Capability Viewpoints

3.3.6 Evaluation The DRSM activity ‘Evaluation’ aims to evaluate the artifact and its relevance to the problem. This activity was directly addressed in papers B and C. This work includes informed argument evaluations (Alan et al. 2004) of Artifacts 1, 2 and 3, in which a discussion and argumentation is provided, preferably using the knowledge base and of how the artifacts address the identified problem and fulfil the stated requirements. Two lightweight evaluations of Artifact 1, the general capability pattern, were performed using demonstration cases that address external validity, and “what capability is not” cases that address internal validity. Internal validity faces inwards; it involves the credibility of use and utility in work practices and internally consistent semantics in and between both general and specific constructs (Lincoln and Guba 1985). The results should be credible from the perspective of the participant in the research. External validity faces outwards; it involves transferability, that is, the generalisability of results to other contexts or situations (Lincoln and Guba 1985). The results, i.e. information about the evaluated artifacts and knowledge about the use of these artifacts, were fed back into the next DSRM iteration.

42

The following diagram summarises the ‘Evaluation’ activity using IDEF notation.

Figure 13: Summary of the ‘Evaluation’ DSRM activity

3.3.6.1 Method and foundation The research method used was informed argument, which involved “what capability is not” cases and demonstration cases. The knowledge foundations used were knowledge about capabilities, and knowledge about EA and EAFs.

3.3.6.2 Informed argumentation We analyse the benefits of the artifacts by revisiting the five requirements R1 through R5. The requirement R1, general applicability, states that artifacts should not be bound to a specific domain or overall capability analysis method. We have ensured this by defining six elements of the general capability pattern that allow us to build definitions of capability that fit a given domain, and by the explicit construction of a method chunk supporting integration with existing frameworks or methods. Moreover, we have not tied this method to a particular approach to identifying capabilities, such as a service, process or goal-based approach. In the future, general applicability can be demonstrated and evaluated by weaving the artifacts into existing capability analysis approaches. This requirements concerns all three artifacts (Artifacts 1 to 3). Requirement R2, comparability, is achieved by the construction of a general capability that can be specialised to incorporate various aspects, including concerns relating to work practices. This requirement concerns only one artifact (Artifact 1). Requirement R3, compliance with standards, is achieved by using the terminology of the ISO 42010 standard ontology as a basis for defining the base capability viewpoint and as a requirement for situated capability viewpoints. This requirement concerns two artifacts (Artifacts 2 and 3).

43

Requirement R4, efficiency, is achieved by the method that produces situated capability viewpoints in a resource-efficient way due to the underlying algorithm, since the capability situating method considers situational work aspects and factors such as job fit, performance and output expectancy, intention-to-use, and actual use of capability analysis. These are all concepts within the well-applied theory of the technology acceptance model (Venkatesh et al. 3AD). This requirement is also addressed via the inclusion of a separate step for the identification of stakeholders and work practices, and by a validation step that ensures that the results are acceptable and applicable to the stakeholders. Finally, the guidelines presented here and well-structured descriptions can also support efficiency. This requirement concerns only one artifact (Artifact 3). Requirement R5 is achieved by the conceptual design of the Artifact 1 general capability pattern, which handles all “what capability is not” cases successfully. This requirement concerns only one artifact (Artifact 1).

3.3.6.3 Demonstration cases and “what capability is not” cases The identified demonstration cases and “what capability is not” cases are used to perform a lightweight evaluation of Artifact 1. Demonstration cases address external validity and the general applicability requirement by showing that the general capability pattern can be applied to various specific capability definitions, capability uses and approaches. The “what capability is not” cases provide an evaluation of the internal validity of Artifact 1 by increasing its credibility, through identifying negative cases containing aspects that are not part of the general concept of capability. These cases provide a knowledge base with aspects that can be used for comparative analysis, such as similarity and difference comparisons between different kinds of capability concepts and approaches. The general capability pattern designed and developed here is compliant with this knowledge base.

3.3.7 Communication The DRSM activity ‘Communication’ aims to communicate the results of research to the academic research community and to practitioners. The research in this thesis has been communicated to various audiences, both academic and professional. The papers included here have been submitted, accepted and presented at peer-reviewed academic conferences and publications. See the List of Publications section for information about papers, conferences and publishers. Communication with practitioners took place through posts and interactions on the LinkedIn forum, and through a personal blog at the author’s website <www.workem.com>. The presented material included posts that were suitable for both technology-oriented and management-oriented audiences.

44

A series of open presentations was conducted during the research process to communicate current research, insights and points of view. Longer posts on the topic of capability were published at the author’s website <fia.workem.com> Furthermore, the capability pattern poster and the capability template (see Appendix) were published on the <www.slideshare.com> and <www.pinterest.com> websites for public download and use. The following diagram summarises the ‘Communication’ activity using IDEF notation.

Figure 14: Summary of the ‘Communication’ DSRM activity

3.3.7.1 Method and foundation The strategies used here were based on traditional research communication and publications, and social media outreach. The foundations were academic conferences and publications, public forums and blogs.

3.4 Contributions of papers to the research process In this section, the papers included in this thesis and their contributions to the research process and research goals are presented.

3.4.1 Paper A. Capabilities and Work Practices - A Case Study of the Practical Use and Utility This paper aims to contribute to the “Identify problems and motivate” activity of the research process with explicated problems. We studied how different work practices use and experience the utility of the concept of capability. The focus was on examining the use and utility of the concept of capability in a coherent, multi-practice and large-scale setting in which there is an explicit or implicit desire to use and align the use of the capability concept among work practices. The programme also used an EAF as part of its management. The outcome of this work was a set of identified and explicated problems involving the use of the concept of capability. It was found that there were

45

various common-sense meanings and overlaid practices of the concept of capability, and different uses and utilities between work practices in a given programme. The main research contribution of this paper is a deepened understanding of use and utility, and problems with and differences in the use and utility of the concept of capability across work practices. This paper contributed indirectly to research goals RG1 and RG2 via the explication of problems using the concept of capability. The research method used in this paper was an empirical inquiry in the form of a descriptive case study (Myers 2008). The aim of this was to inform the design science effort by characterising the overall situation and problems that occur when the concept of capability is used within several work practices. Data were gathered through semi-structured interviews with experts in five identified work practices that were using or that expected to use the concept of capability. The interview questions were focused on the participant's experiences of their own use and utility of the concept of capability. The interviewees were explicitly not asked about how they defined the term “capability” and its underlying concept. At least two individuals were interviewed from each work practice, giving a total of 11 respondents. All interviewees were assigned to the programme as senior experts. The data acquired from these interviews were analysed using thematic analysis (Myers 2008) and the process outlined by Braun and Clarke (Braun and Clarke 2006). This analysis focused on the surface and semantic meanings of what each participant said, rather than on an examination of underlying meanings (Myers 2008). The knowledge foundations used here were knowledge about capabilities, and knowledge about EA and EAFs.

3.4.2 Paper B. What Capability Is Not This paper aims to contribute to the “Design and development” activity of the research process via a conceptual analysis of what capability is and is not. The problem addressed in this paper is that there is no broad agreement on the nature of capability in the management, planning, engineering and EA literature. Definitions of the concept of capability range from the concept of a process to a loose definition as a collection of resources. The emergence of a great number of conceptualisations of capability can be noted, and this proliferation of definitions and usages shows few signs of slowing down. The many variants of the definitions/constructs of capability hinders communication between different stakeholders with different use perspectives and contexts. This makes comparisons of commonalities and differences between variants more complex. The main result is the construct of the general capability pattern. This artifact

46

was created using a deconstruction and reconstruction technique, that allows significant simplification of the integration (into capability theories, frameworks, and work practices) and comparisons of capability concepts. Moreover, a set “what capability is not” cases were identified that identify non-essential characteristics of the concept of capability and can be used in conjunction with requirements to inform and guide design. The paper also presents a “demonstration case’ that is used to show that the general capability pattern can be extended and tailored to existing domain specific capability approaches, and to allow partial evaluation of this. The main research contributions of this paper are the novel construct of a general capability pattern, and the identification of “what capability is not” cases that can be tailored to specific uses and work practices. This paper contributed directly to research goal RG1 via the identification of non-essential characteristics of the concept of capability and the designed solution, the general capability pattern. The general capability pattern can be extended to create further specific capability constructs that are suitable for inclusion in subject fields, capability frameworks and work practices. This paper contributed indirectly to research goal RG3 by creation of the general capability pattern, which can be integrated with EAFs. The research method was conceptual analysis and design and “what capability is not” analysis. Informed argument and demonstration were applied in the evaluation. The general capability pattern was extended and tailored to incorporate capability approaches in different domains. The knowledge foundations were deconstruction and reconstruction conceptual analysis and design, and the lattice of theories.

3.4.3 Paper C. A Method for Situating Capability Viewpoints This paper aimed to contribute to the “Design and development” activity of the research process via the design of a capability situating method. The problem addressed in this paper is that a single, focused definition of capability may hamper efficient use of the concept in varying situations and work practices. The risk is that a narrow, single-sided representation may fail to incorporate other essential aspects of an organisation, its people and the work they do with others. The outcome of the paper was a method for creating situated capability viewpoints. This method can also be used to clarify the different situational perspectives, why employees have different perspectives, and to show how different groups view and use the concept of capability. The paper also presents a set of ‘demonstration cases’. The main research contribution of this paper is a method that can situate an existing capability viewpoint using knowledge about work practices, in order

47

to improve the relevance and utility of the capability viewpoint to people in work they do with others. This paper contributed directly to research goals RG2 and RG3 via the design of a solution, the capability situating method, that can be integrated with EAFs. This paper contributed indirectly to research goal RG1 by enabling the creation of situated capabilities. The research method used was conceptual analysis and design. Informed argument and demonstrations were applied in the evaluation. The general capability pattern was extended and tailored to incorporate capability approaches in different domains. The knowledge foundation was situational method engineering.

3.4.4 Paper D. Interpreting Service Using an Upper-Level Ontology This paper aimed to contribute to the “Design and development” activity of the research process by exploring the adjacent concept of service, which needs to co-exist with the concept of capability in EAFs. This work addressed the question of whether it is possible to create a formulation or interpretation of the adjacent concept of service using a higher level ontology, which can be used to explain the differences in argumentation relating to service characteristics, relations between services and goods, and the practical consequences of servicing. The outcome of the paper was a formulation, interpretation and ontological grounding of the concept of service, using a higher-level BFO, the lead-to pattern and the result chain. The underlying pattern of the definition of service is analogous to the pattern of capability, which increases the level of integration of the two concepts in a single EA framework. The lead-to pattern provides an approach for informed reasoning about value creation along result chain up to service or capability horizons. The main contributions of this paper are as follows:

• A novel ontological interpretation of the concept of service, using a upper-level ontology that provides a bridge between natural and social sciences, and offers clarifications of the constituent parts of the concept of service.

• The findings that the analysed service characteristics are relevant but not determinant, and that practical implications of the service characteristics depend on specific types of services.

• The introduction of a lead-to pattern that provides a novel and flexible approach for informed reasoning about value creation along result chains up to the service or capability horizons.

This paper contributed indirectly to (i.e. informed and guided) research goal RG3 via the exploration of conceptual analysis and design techniques, and the

48

development of the analytical tools, lead-to patterns, result chain and result horizon. The paper also contributed to an understanding of how EAFs and their underlying ontologies can simultaneously accommodate multiple concepts such as capability, service, process and organisational designs. The research method was conceptual analysis and design. Informed argument was used for evaluation. The knowledge foundations used in the paper were BFO and the deconstruction and reconstruction technique.

3.5 Ethical considerations The ethical considerations of this research can be examined with respect to both the research process and to when the concepts of capability and capability-based methods are used as instruments with the aim of influencing other people. The first aspect of these ethical considerations concerns the research process. The participants in the capability case study were informed about the purpose of the research, the method used, and how the results were expected to be used. They were informed that participation was confidential and voluntary, and that personal and study information would be kept in a secure location at the researcher’s place of work. This part of the research therefore conforms to the Swedish Council of Science’s ethical principles (information about purpose, voluntary participation, confidentiality, use for research) for humanistic and social research (Forskningsrådet 1999). The second aspect of the ethical considerations concerns the use of these artifacts as instruments to influence people. An instrument is by definition something that is infused into an organisation in order to change and improve it, i.e. as a means to certain ends. The artifacts developed here relate to the discovery and codification of knowledge about capabilities; the consequences of their use depend on the situation and work practice, and may be positive, negative, intended, unintended, desired or undesired. None of the artifacts possess any inherent characteristics involving ethical consequences. Furthermore, the method in Artifact 3 includes a step in which situations using the concept of capability are identified and characterised. This step enables the identification of potential ethical considerations that can subsequently be addressed or avoided in the subsequent step in the method, ‘Tailoring’.

49

4 Results

This chapter aims to summarise the main results of this thesis. Intermediate outputs from the design science research process have been presented in Section 3.3: Research Process. The results of the case study and explicated problems are first presented. Following this, three novel artifacts are presented that can be used to increase the relevance, use and utility of the concept of capability in the different types of work people do with others. The three artifacts can briefly be described as follows: The general capability pattern provides a conceptual foundation for a description and discussion of the nature of capability, and also for comparisons between specific capability constructs. It provides essential elements of the concept of capability. Through its construction as a general pattern of the concept of capability, more specific types of capability can be defined that can incorporate aspects such as work practice concerns. The base capability viewpoint integrates the general capability pattern with enterprise architecture frameworks through the ISO 42010 international standard. The capability situating method enables the creation of specific viewpoints that incorporate situational concerns, work practice concerns and use requirements while preserving their relationships with the general concept of capability. This method can be applied at the beginning of projects when creating, adapting and tailoring an overall capability-based methodology or framework, by taking a base capability viewpoint and adapting and tailoring it to fit the needs of specific work practices, thereby creating situated capability viewpoints.

4.1 Insights into the use and utility of the concept of capability This section presents a summary of the results from the case study reported in Paper A, together with problems explicated in this study. Paper A reports on a case study of a very large European Commission programme, a research and development effort with the aim of reforming ATM. This programme used the concept of capability in various work practices, including through a use of an EAF. Data were gathered via interviews with senior experts in five different work practices that were using or expected to use the concept of capability. The programme was divided into two phases: the definition and development phases.

50

Questions were directed to the participant’s experiences of their own use and utility of the concept of capability. The interviewees were explicitly not asked about how they defined the term “capability” and its underlying concepts. Chapter 3 presents the methodological aspects of this case study and Paper A. Section 3.2.2 (Identify problem and motivate) also presents the explicated problems and motivations derived from the case study. The following sub-sections present a summary of the results and discussions of Paper A.

4.1.1 The themes of use and utility Through an analysis of the results based on thematic coding, it was shown that the participants were using the concept of capability with a variety of meanings and for differing purposes. The reported use and utility of the concept of capability were thematically coded under the following categories (for detailed information, see Section 3.1 in paper A).

• Managing change, accepting, agreeing • Creating awareness, understanding • Visualising • Communicating • Shared stakeholder points-of-view • Architecture management • Modelling • Mapping and linking • Designing and analysis • Performance management • Master planning • Investment planning • Management of programme and work • Integration with the external world

The use and utility categories in this list were spread across various areas. Some categories had been anticipated, such as modelling, linking and mapping, visualisation, communication, and architecture management, since an EAF had been used in the second phase of the programme. The category of ‘Managing change, accepting, agreeing’ was not expected to be emphasised by participants. In Phase 1, this category was seen as a success factor contributing to “manag[ing] change, acquiring of buy-in, obtain[ing] acceptance and agreements amongst participants” (Tell and Henkel 2018). The categories of ‘Performance management’, ‘Master planning’ and ‘Investment planning’ reflect that the ATM programme was oriented towards planning and

51

performance. As part of the thematic analysis with the aim of identifying the use and utility of the concept of capability, two additional themes were found: ‘Little use’ and ‘Utility not seen’. The theme of Little use relates to interviewee statements where capabilities were used little or not at all. This was the case even when there were expectations within the ATM programme that capabilities should be used. In some cases, old-fashioned concepts replaced the use of capabilities. The theme of Utility not seen relates to interviewee statements where no utility of the use of capability was identified.

4.1.2 Use and utility in work practices Using thematic analysis, the interviews were also analysed from the points of view of usage and utility with respect to the interviewees’ work practices. The work practices were selected and categorised based on the similarities of the work done by participants that used or expected to use the concept of capability. This analysis revealed that the uses and utilities varied across work practices. The following work practices were included in the case study: • Feasibility study • Strategy and planning • Architecture • Development of operational concepts • Development of technical concepts A summary of the results for each of these work practices is presented in the remainder of this section. Feasibility study work practice The interviewees in the ‘Feasibility study’ work practice were the most positive with regard to the use and utility of capability. The use of capability evolved through learning by doing. Capabilities were used as means for communication, managing change, acquiring buy-in, obtaining acceptance and agreements amongst participants, and to create a shared mental model. Thus, capabilities became important talking points. See Section 3.2.1 in paper A for detailed information. Strategy and planning work practice The interviewees in the ‘Strategy and planning’ work practice supported the use of capability, and were optimistic that the use of capabilities could be valuable, although they expressed that the expected utility had not yet been seen. For ‘Master planning’, the concept of capability was used behind the scenes as

52

a mental concept, but was not explicitly used. See Section 3.2.2 in paper A for detailed information. Architecture work practice The interviewees in the ‘Architecture’ work practice were the main advocates and users of capabilities in the programme, and positive towards the use of capabilities. They were also responsible for maintaining the programme’s EAF. The utility of capabilities lay in viewing them as a tool to interconnect the programme’s work products and deliverables. See Section 3.2.3 in paper A for detailed information. Development of operational concepts work practice The interviewees in the ‘Development of operational concepts’ work practice reported that they not did create or use capabilities; their operational activities were linked to capabilities, but not their conceptual work. This was a point of discussion, since operational concepts were strongly related to overarching performance targets through the programme’s performance framework. See Section 3.2.4 in paper A for detailed information. Development of technical concepts work practice The interviewees in the ‘Development of technical concepts’ work practice were not actively developing capabilities. However, technical capabilities were sometimes mentioned in their answers. Capabilities were primarily linked and mapped to traditional engineering artifacts such as systems, resources and services. One utility that was mentioned was that technical concepts could be linked to capabilities in order to further motivate technical concepts. See Section 3.2.5 in paper A for detailed information.

4.1.3 Additional findings The interviews created a rich set of textual material, thematic codes and findings. In this section, we present findings that are relevant to the overall research problem. Vagueness in reported use and utility A notable feature was that in several cases, interviewees were vague in their answers. It was unclear whether the use and utility they referred to were experienced, potential, perceived or expected. Furthermore, the answers and examples of use became significantly fewer and vaguer when interviewees were asked which specific problems and decisions were helped by the use of capabilities. See Section 4.1 in paper A for detailed information on these findings. Variety of definitions During these interviews, it became clear that interviewees were using the term ‘capability’ in many different senses, which were codified, although not analysed in detail. This variety of meanings is noteworthy, however.

53

Capabilities were referred to as capacities, enabling technology, infrastructure, master planning, needs, operational aspects, organisational aspects, outcomes, skilled people, systems, talking points, and technical aspects. A leading architect summarised this challenge:

“It’s also a frequently used concept, and not always used in the same way. So, you are up against people who come with it with a certain perception, and expect it to be used in a particular way, and have to work with them to try and make sure the way it’s used it fits with the framework, which you’ve adopted.”

The relationship between capability and the adjacent concept of ‘service’ was reversed in this programme. In the first phase of the programme, the feasibility study, the idea of capability played a central role. In this phase, the underlying (investment) logic was that investments lead to higher capability levels, enabling higher service levels that then satisfy performance requirements. When the EAF was introduced in the second phase of the programme, this relationship was reversed. There relation between capability and service became ‘service aims to achieve capability’. See Section 4.2 in Paper A for detailed information on these findings. Learning by doing vs. engineering approach In the first phase, capability was considered to be something important to talk about, something people wanted and to invest in. This attitude changed in the second phase, when the EAF was introduced. Here, the attitudes changed from neutral to cautiously negative, and attitudes were different across work practices. This change can be explained by the arrival of new experts in the second phase; the approach then changed to a systems engineering approach, leading to delays in uptake and in methodological maturity. Another possible explanation is that use of capability evolved in the first phase through a learning by doing process. In the second phase, a ready-made and military EAF with a definition of a single kind of capability was introduced. This created a situation where an external framework was introduced into projects with assigned tasks to be done. This framework also included a single kind of capability that did not always match with the project participants’ actual and varying needs, work practices and mental models. See Section 4.3 of paper A for detailed information on these findings. Overlaid aspects and practices on top of capability The concept of capability was a highly interlinked construct in the ATM programme. An examination of the use themes revealed a number of aspects that were overlaid on top of and embedded with the general concept of capability. The overlaid aspects identified included talking points of the most important topics, components, tools for acquiring consent, mapping to and linking

54

between underlying concept (business, operations, technical, etc.), allocation of resources and business cases, benefit realisation, performance frameworks, specification and realisation, resource configurations, influence diagrams, validation exercises, deployment solutions, master planning and change. An interesting and relevant question can be formulated: How many of these identified aspects are essential to the general concept of capability, and how many are overlaid due to the usage of the concept of capability within a particular work practice? See Section 4.4 in Paper A for detailed information on these findings. Differences between work practices The use and utility of capabilities was reported to vary across work practices. All work practices tried to use capabilities, although their attitudes and experiences ranged between positive, wait-and-see, neutral and negative. The EA approach in the second phase promised to deliver a single, coherent view of the concept of capability. The results show that the actual use and utility of this single kind of capability were manifold and varied. See Section 4.5 in Paper A for detailed information on these findings.

4.1.4 Explicated problems addressed by the artifacts The discussion and findings presented above provide a background and motivation for the explicated problems (see Section 3.3.2 for problem descriptions and motivation). These problems were as follows:

Problem 1. The kinds of the concept of capability, their use and the utility are many and varies between work practices. Problem 2. The concept of capability is expected to be used by many people, although some people use it by referring or linking to others use, do not use it themselves, or see little utility of using it. Problem 3: Using an enterprise architecture framework with a single definition of capability to integrate different kinds of work products within a project may not lead to a consistent and beneficial use of the concept of capability. Problem 4. The concept of capability is overlaid with non-essential meanings and aspects.

55

4.2 Artifact 1: General capability pattern This section presents the general capability pattern, a construct artifact. The general capability pattern was introduced and presented in Paper B, and was further discussed and refined in paper C. The general capability pattern provides a conceptual foundation for discussions about the nature of the concept of capability and for comparisons between definitions of the specific capability concepts. The general capability pattern is used to integrate the concept of capability with EAFs and viewpoints. The concept of capability is constructed as a pattern consisting of six essential elements, each playing a particular role in the pattern, as illustrated in Figure 15: possessor, possibility, source, result, lead-to, and substantiality. Simply phrased, the concept of capability can for practical purposes be considered as a means for referring to (i.e. a talking point about) that which is important and provides some potential capacity or power to cause or achieve some results.

Figure 15: Essential elements of the general capability pattern

For example, a car can and has the power to transport people home by the car’s wheels, body and electrical engine, through the conversion of electrical energy into mechanical energy. Capabilities can be expressed using a natural language pattern based on the six essential elements and their roles:

“<substantial> <possibility> of <possessor> to <result> by/with <source> through <lead-to>”

Annotating the example with the essential elements in brackets results in the following statement: A car [possessor] can [possibility] and has the power [substantiality] to transport people home [result] by the car’s wheels, body and electrical engine [source], through the conversion of electrical energy into mechanical energy [lead-to]. The general capability pattern is based on two analytical tools, the ‘Lead-to pattern’ and the ‘Result chain’, as presented in Paper D and summarised in a later section. They provide a foundation for and insights into the inner workings of the concept of capability, its relationship to aspects such as

56

causality, and the adjacent concept of ‘service’. They also provide a base for reasoning about how to select the result at the capability horizon (see Section 4.2.4 and the discussion of the result horizon). The general capability pattern is used in the base capability viewpoint (see Section 4.3) as a grounding for the development of situated capability viewpoints through the capability situating method (see Section 4.4), thus providing a foundation that centres, integrates and aligns all situated capability viewpoints around a single general pattern. The general capability pattern is a novel and original construct that is intentionally under-specified, in order to be able to bridge different meanings in domains and in the use of the concept of capability. Specificity and formalisation is intended to be added in situ to allow for specific types of capability. By enabling and facilitating authors to expand a general concept of capability by adding and motivating propositions, assumptions, contexts, constraints, modifiers and qualifiers, the process of integrating (into theories and frameworks), comparing and relating definitions of capability becomes easier. The capability pattern poster, presented in Appendix A, presents examples of capability pattern elements that were found by applying the deconstruction and reconstruction technique (see Section 3.3.4.1) to a wide range of definitions of and approaches to capability, including those in the demonstration cases. The capability template presented in Appendix B can be used in the creation of specific types of capability, while being informed and guided by the capability pattern poster.

4.2.1 Essential elements This section provides a description of the general capability pattern, and its nature, structure and elements. These descriptions are followed by a summary of the essential elements and their roles. As mentioned above, the concept of capability is constructed as a pattern consisting of six essential elements. These elements are essential and delimiting characteristics (Object Management Group 2017) that are indispensable in understanding the concept of capability, and can be also be used to distinguish the concept of capability from related concepts such as process, service and resource. Each element plays a particular role in the pattern. The “what capability is not” cases (see Section 3.3.3.4) and the use of the deconstruction and reconstruction techniques have significantly informed and guided the design of the general capability pattern by the identification of aspects that are not considered essential. One reason for viewing the general concept of capability as a pattern is that it simplifies definitions of specific kinds of capability, including those that incorporate additional aspects such as situational and work practice concerns.

57

The pattern specification of essential elements and roles simplifies the integration into different kinds of formalisations that appear in target frameworks, approaches and theories. The general capability pattern is designed to be formalised in specialisations. One example is that the underlying meaning of the ‘lead-to’ can be formalised using causality or counter-factual reasoning (Oxford University), disposition ((Stanford University)), or Bayesian inference (HORKOFF et al. 2014) (Johnson et al. 2007). Possibility At the core of the concept of capability lies the idea that capability refers to something that possibly, potentially, can, may, or could come into existence due to some power, disposition, process, natural or social law, for example, under certain circumstances. A capability can be considered in terms of a potentiality: “Having or showing the capacity to develop into something in the future” [Oxford English Dictionaries].

Example: A rifleman is capable of penetrating (can penetrate) the target using a pistol with one bullet. After a single shot, the rifleman is no longer capable of this.

Possessor In natural language, the term ‘capability’ is accompanied by the adjective ‘capable’, which is used to refer to the possessor of the capability. The capability is attributed to, owned by, accessed by, or part of a possessor. When an entity is capable, then the ‘sources’ must be related to the possessor.

Examples: organisational units, people, machines, enterprises, systems. See the capability poster in the Appendix A for more examples.

The 'to' result A capability incorporates a ‘result’ entity, which constitutes the ‘to’ in “a car is capable to drive a person to a place”, meaning the achievement, the accomplishment, the delivery, the effect, the consequence, etc. There are many ways to define a result, for example as an achieved state (“to arrive at a place”), or as a process (“to drive”).

Examples of results include: delivered goods, performed services, fulfilment of intended objectives. See the capability poster in Appendix A for more examples.

In specific types of capability, the ‘result’ element is often qualified to represent the interesting and usable aspects of particular work practices and methods. For example, intention is important in design, and an interesting ‘result’ may be defined in a qualified way as an ‘intended result’. Source A capability incorporates one or more ‘source’ elements, which refers to

58

entities that form the inputs, sources, causes or motivations for the achievement of the ‘result’. There are many ways to define a ‘source’, for example as something that exists, a routine, a conversion factor, integration, collaboration, or culture.

Examples of ‘sources’ include things, assets, facilities, resources, people, knowledge, skills, processes, machines, culture, learning processes, material, information and feedback loops. See the capability poster in Appendix A for more examples.

In an idealistic, top-down view of capabilities, the ‘sources’ are drawn from predefined categories of source elements, such as material and human resources. In a realistic, bottom-up view of capabilities, the ‘sources’ are identified as those that can significantly contribute to the ‘result’. One important group of ‘sources’ are interweaving factors such as collaboration, alignment, integration and cohesion. These factors can be missed in the analysis and specification of capabilities; however, it is easy to appreciate that a well-oiled team can perform better than a newly formed one. It is also often difficult to replace one part of a team without disrupting the whole. The ‘sources’ can be viewed through resource lenses (Cardeal and António 2012), in which the most important ‘sources’ are considered to be VRIN, and to be accessible through markets for sources. The pattern separates the ‘possessor’ from ‘sources’. This design decision arises partly from the common language phrases of an ‘organisation is capable’ and an ‘organisational capability’. However, an organisation is a complex organism that includes many parts and aspects. In an analysis of what significantly (can) contribute to some result being achieved, an organisation is a source that is too coarse-grained for detailed analysis. Lead-to A capability incorporates a ‘lead-to’ entity, which provides a directional relation between the ‘sources’ and the ‘result’. The ‘lead-to’ links the ‘sources’ and the ‘result’, and provides a way to refer to and reason about how the ‘result’ can be achieved. There exist many ways to define a ‘lead-to’. A ‘lead-to’ can be defined as a conversion, production, process, causality, mechanism or mathematical formula.

Examples of ‘lead-to’ include natural processes, prescribed or described work processes, causalities. See following section and the capability poster in Appendix A for more information and examples.

The pattern of ‘source’, ‘lead-to’ and ‘result’ is well-known. This part of the pattern is pervasive in science, theories and frameworks, and fits well with multi-factor data analysis methods. The general capability pattern can therefore be used to formulate a testable hypothesis.

59

The underlying structure of the pattern lends itself well to analysis of the values of possessing or having access to resources (Cardeal and António 2012). Here, access to resources can be viewed as a set of ‘sources’ that ‘lead to’ some valuable result, such as a competitive advantage. The ‘lead-to’ can be considered to be an organisation’s routines or processes, and the substantiality of the ‘source’ and ‘lead-to’ can be considered to be VRIN. Thus, the general capability pattern provides an integral frame for the analysis of strategic or corporate values of access to resources and their doings. Substantiality A capability incorporates a ‘substantiality’ entity, which refers to the substance, strength, or capacity of the ‘lead-to’, ‘source’, ‘result, and ‘possibility’ elements. There are many ways to define a ‘substantiality’. A ‘substantiality’ can for ‘sources’ and ‘lead-to’ be seen as a capacity, power, strength, level, or as adequate.. When viewed through resource lenses, more valuable and strong ‘sources’ are rare, inimitable, and non-substitutable. In human development, a more important substantiality of ‘possibility’ is substantial freedom. A ‘result’ may previously have been demonstrated or proven. See the capability poster in the Appendix for more examples. Grounding A capability is also a concept that depends on or is grounded in something. The ‘possessor’, ‘source’, lead-to’, ‘result’, and ‘substantiality’ elements are all grounded.

Example: A market management capability is grounded in the concept and practices of market management.

4.2.2 Kinds of capabilities Based on the general capability pattern and its six elements, we can characterise and label different kinds of capabilities.

• An indirect capability is a capability that does not specify a ‘lead-to’ element. The capability lacks something that can cause a change or can lead to the results. Examples include a table, hammer, intellectual capital or newspaper.

• An ability is a capability that does not specify ‘substantiality’. A football player may be able to kick a ball (learned psychomotor act) but not yet play a full game based on a strategy.

• A competence is a capability where the ‘substantiality’ is determined to be adequate, sufficient or demonstrated.

• A dynamic capability is a capability that operates on other capabilities in which the ‘result’ and ‘source’ are elements of other capabilities. It may also be a second-order capability that corresponds

60

to “doing the right things” and the second-order learning loop. • A processual capability is a capability where the ‘lead-to’ is specified

in terms of a ‘process’. A process typically involves intended activities, actions, or volitional doings performed by certain actors.

4.2.3 Specific kinds of capability The general capability pattern is designed to be specialised into more specific kinds of capabilities. This is done using the capability situating method (see Section 4.4) where situational factors, work-related use requirements and aspects from relevant approaches, frameworks or theories motivate and adjust the specialisation. The mechanism for the construction of more specific kinds of capability is based on Sowa’s lattice of theories approach (Sowa 2007) and its belief revisions: expansion, contraction, revision and analogy (see Section 2.2.3). A specific kind of capability is represented by a specific capability pattern, populated by extensions that modify or qualify each essential general capability element with something that is relevant and useful. For example, in strategic management work practices, “competitive advantage” is a performance measure that is considered to be relevant and important (Leiblein 2011). Here the general ‘result’ has been expanded and modified into the more specific “competitive advantage”. An even more specific ‘result’ can be defined by adding a further qualifier: “sustained competitive advantage”. Based on the specific capability pattern, a specific definition can be formulated for use as guide for the identification of instances in analysis and design. Interesting and relevant capabilities can now be identified or defined that correspond to or instantiate the specific capability pattern and the specific definition. For example, when the specific ‘lead-to’ is centred around processes and is defined as “production”, then examples of interesting specific capability instances include, “planning”, “sourcing”, “making”, “delivering”, “returning”, and “enabling” processes. Figure 16 illustrates this construction process, with examples in italic text.

61

Figure 16: The relationships between the general capability pattern and specific kinds of capability

More examples of specialisations of the general capability pattern can be found in Papers B and C.

4.2.4 Lead-to pattern and result chain The lead-to pattern and result chain are two analytical tools underpinning the general capability pattern. They provide a frame for understanding the ‘lead-to’ relationship between ’sources’ and ‘results’. The two tools were introduced and explained in Paper D, where they were used to analyse the concept of service (Tell 2014b). The semantic sharing between the concepts of capability and service increases the level of integration when the two concepts are collocated in an EAF. Furthermore, the result chain provides a tool for deciding what the result should be when constructing specific kinds of capability. Note: The name has been changed in this thesis to “result chain” from the “result ladder” defined in Paper D. This section presents a summary description of these two tools. See Paper D for more detailed information. Lead-to pattern The lead-to pattern is a three-part pattern in which ‘source’ entities ‘lead to’ ‘result’ entities; this pattern is pervasive in science, frameworks and theories. Examples include: causality (the effect from cause, means to some ends, marketing, attributes lead to consequences that lead to values) (Hughes et al. 2005); templating (Sowa); worth maps (Cockton et al. 2009); influence and

62

benefit realisation (Serra and Kunc 2015). The incorporation of the lead-to pattern into the general capability pattern increases the integration of the concept of capability within frameworks that include causality, influence diagrams and/or benefit realisation. ◦ A source entity plays the role of a source in the pattern, and can be

seen as an input to a function or process, the cause in causal relation, the influencing factor, or the means to some end.

Examples include material and immaterial entities, humans, competence, skills, knowledge, information, performers, facility, equipment, products, features.

◦ A result entity plays the role of a result in the pattern, where it can be seen as the output to a function or process, the effect of causal relation, the influenced, or the end.

Examples include values, benefits, meeting an objective, functioning that comes into being, a state-of-affairs, change or no change, or an act that is either completed or not.

◦ A lead-to entity relates source and results entities to each other. It is a directional relation from source to result, in which the results are produced, brought about, achieved, accomplished, realised, made or generated.

Examples include realisation processes, mechanisms, causality, logical entailment, counter-factual specification, probabilistic specification, and mathematical formulas.

Result chain A result chain is a set of ‘results’ that is partially ordered. These results have lead-to links between them, where a result plays the role of a source for the next lead-to in the result chain. The partial ordering forms a chain of results with intermediary results. The chain ends at a terminal result that constitutes the result horizon for the chain or the capability horizon for the terminal results of a capability (see Figure 17). A result chain provides a mechanism for describing and discussing results and a tool for determining which result should be associated with a capability.

Figure 17: The lead-to pattern in a result chain

63

There are many examples that are analogous to result chains. In the fields of marketing and services research, the means-end theory is used, in which the attributes of products (A) lead to consequences in terms of product use (C) and individuals’ values (V) (Veludo-de-Oliveira et al. 2006). Other examples include value theories (Johnston 1995), Rokeach instrumental and terminal values, and Cockton’s worth maps (Cockton et al. 2009). A result horizon specifies the characteristics of the terminal result(s). The result horizon can be viewed as analogous to an investment horizon, where the horizon represents the total length of time over which an investor expects to hold a security or a portfolio. The research reported in Paper D identifies a number of important questions relating to results, their valuation, and result chains that are relevant to analysis and design of specific kinds of capability, for example:

• Where and when are results or values observed and measured? • How many result chains exist simultaneously (e.g. customer, provider,

worker, owner, society)? • Which result or value is attributed to whom? • Are there single or multiple terminal end points? • Does the result chain terminate …

⁃ in some universal result or value space (“everything”); ⁃ in some results or values attributed to some single entity (“the”); ⁃ in societal results or values (“we”); ⁃ in experiential results or values of a sentient being (“I”); or ⁃ in some result or values that evolve over time?

For capabilities, the equivalent concept of the result horizon is the capability horizon. Selection of the capability horizon The question of which result should be associated with a capability is important. This question can be answered using result chain and capability horizon reasoning. Countless capabilities (and services) exist, since their results can be defined anywhere along a potential result chain. This is a deliberated choice in which the result chain stops at the capability horizon. For example, a car is capable to transport people various distances (1 m or across the country), but is also capable of polluting the air for a future generation of people. Capability frameworks need to specify principles for how to reason about the selection of end results at the capability horizon. The result chain tool helps in assessing potential and desired terminal results.

64

4.2.5 Artifact 1: Fulfilment of requirements The general capability pattern satisfies Requirement 1, as it is a pattern that specifies essential and delimiting elements and roles. This pattern enables more specific forms of the concept of capability to be defined based on the domain, capability approaches, and work practice use requirements. The general capability pattern satisfies Requirement 2 as it is a pattern that specifies essential and delimiting elements and roles. Through the use of the Deconstruction and Reconstruction technique, the similarities and differences between the general capability pattern and its specific variants can be analysed and documented. It also satisfies Requirement 5, since the general capability pattern conforms to the “what capability is not” cases.

4.3 Artifact 2: Base capability viewpoint This section presents the base capability viewpoint, which is a model artifact. This viewpoint was introduced and presented in paper C. The base capability viewpoint is a minimal bridge that integrates the general capability pattern with the standardised architecture framework and the knowledge capture and documentation construct ISO 42010 Viewpoint (ISO/IECIEEE 2011) (see Glossary for a definition). The concept of a viewpoint is defined in the international standard ISO 42010, which standardises existing practices of capturing and documenting architecturally relevant knowledge. The base capability viewpoint is used as an input for the capability situating method and frames the concern, the concept of capability, as represented by the general capability pattern. Thus, it enables and facilitates the capture and documentation of capability-related knowledge in architecture descriptions. The design of the base capability viewpoint is original, since it facilitates the separate and coherent management of stakeholders, concerns, situational work practice knowledge, and the creation of viewpoints that are specifically tailored to the work people do with others.

4.3.1 Design and development The base capability viewpoint is defined and designed as an ISO 42010 viewpoint. As such, it can be included in architecture frameworks and can govern descriptions of architectures through the lens of capability. The design of a viewpoint is straightforward, since this concept is defined in the standard alongside the conformance requirements. The base capability viewpoint is therefore designed to frame the concern of capability, which is defined by the general capability pattern (see the definition in the preceding

65

section). The ISO 42010 standard was chosen to contribute to research goal RG3 and to increase the likelihood that these artifacts can fit into existing and implemented EA frameworks. More precisely, the ISO 42010 standard was chosen since it codifies the existing EA documentation practices used worldwide. Furthermore, the author of this thesis participated in ISO/IEC standardisation work through the Swedish national delegation. The base capability viewpoint serves as an input to the capability situating method and as a base for the situated capability viewpoint created by the method. The base capability viewpoint is intentionally designed to be underspecified, and to fully conform with ISO 42010 through the application of the capability situating method. The capability situating method is intended to fully satisfy the requirements of ISO 42010 when merging the general concept of capability with work practices, existing frameworks, capability methods, theories and kinds of model. ISO 42010 viewpoint conformance The ISO 42010 standard requires that a viewpoint shall specify: a) one or more concerns framed by this viewpoint; b) typical stakeholders for concerns framed by this viewpoint; c) one or more model kinds used in this viewpoint; d) for each model kind identified in c), the languages, notations,

conventions, modelling techniques, analytical methods and/or other operations to be used on models of this kind;

e) references to its sources. The base capability viewpoint specifies the following: a) The framed concern is the concept of capability, as defined by the general capability pattern. Note: Although not included in this thesis, it is possible to define more specialised base capability viewpoints that incorporate particular aspects of the concept of capability, for example a taxonomy capability viewpoint that frames a taxonomy of capabilities. b) No typical stakeholders are defined. This requirement is intended to be satisfied by the application of the capability situating method, which creates a situated capability viewpoint with stakeholders, their situations and work practice. c) No kinds of model are defined. This requirement is intended to be satisfied by the application of the capability situating method, which integrates the base capability viewpoint with existing work practices, methods, theories, and kinds of model. d) All kinds of capability-situated models and corresponding meta-models

66

must include and conform to the semantics defined by the general capability pattern. e) The sources for the base capability viewpoint are Papers C and B, and the current thesis. Documentation template In Appendix C, we present a documentation template for situated capability viewpoints based on ISO 42010. The template complies with ISO 42010 requirements.

4.3.2 Artifact 2: Fulfilment of Requirements The ISO 42010 standard was chosen to contribute to research goal RG3 and to increase the likelihood that the artifacts can fit with existing and practiced EA frameworks. This is because ISO 42010 standardises existing EA documentation practices used worldwide. The base capability viewpoint satisfies Requirement 3, as it is defined as an ISO 42010 viewpoint and complies with the conformance requirements of ISO 42010. Furthermore, the base capability viewpoint satisfies Requirement 1 since it is an input to the capability situating method, and thereby provides a base for situated capability viewpoints that are specifically created to be applicable in different domains and work practices.

4.4 Artifact 3: Capability situating method This section presents the capability situating method artifact. This method was introduced and presented in Paper C, A Method for Situating Capability Viewpoints (Tell et al. 2016). The aim of this method is to generate situated capability viewpoints by tailoring the base capability viewpoint to address situational work concerns and use requirements for tools and work products. The capability situating method incorporates work practice concerns while preserving the relationships between the general concept of capability and the situated capability viewpoints. The situated capability viewpoint is a fusion between stakeholder concerns, their situations, work practices, and their capability knowledge concerns (fig 18).

67

Figure 18: Fusion of the situated method

The capability situating method is a novel method chunk (Ralyte et al. 2003) that was developed using SME techniques (Object Management Group 2012), and enables the inclusion of situational- and work-oriented knowledge into EAFs and enterprise modelling approaches.

4.4.1 The method chunk Process description The process of the method is controlled by three viewpoints (stakeholder, base capability and situation) that govern the creation of views and viewpoints. All viewpoints conform with ISO 42010, and are described in Section 4.3 and the following subsections. The process contains four steps (Figure 19) that may be performed iteratively and more than once. These steps are summarised here, and more details are given in the following sections.

1) Situate and focus: Situate and anchor the process in the overall situation of interest, problems and/or opportunities, and the focus of attention.

2) Characterise: Characterise the current situation by identifying affected individuals (stakeholders), categorise them into stakeholders, and identify situations and work practices related to stakeholders.

3) Tailor: Create a set of situated capability viewpoints by adapting and tailoring the base capability viewpoint to address situations, work practice concerns and use requirements.

4) Validate: Validate situated capability viewpoints and their fulfilment of situational and work practice concerns, and use requirements. This validation should be done according to a work quality model.

The process delivers the following results: • A stakeholder view that contains a model of the stakeholders. • A set of situational work views that contains a model of the situations

and work practices. • A set of situated capability viewpoints that frames situational

68

capability concerns including situational and work practice concerns, and use requirements aspects, and general and specific capability concerns.

The following diagram (Figure 19) illustrates this process, showing its input and output work products.

Figure 19: Overview of process with inputs, controls and outputs (Tell et al. 2016)

Figure 20 illustrates the work products and their key relationships.

Figure 20 Overview of the structure of a work product (Tell et al. 2016)

69

Stakeholder viewpoint This is a supporting viewpoint that frames stakeholder concerns and provides types of models for documenting the characteristics of individuals, groups of individual, and stakeholders. Individuals and groups of individuals may be related to one or more stakeholders, and may be categorised as stakeholders based on shared characteristics such as practice, discipline, profession, organisational job or position. The current research does not present a detailed specification and formalisation of this viewpoint and these kinds of model. Situation viewpoint The situation viewpoint is one that frames situational and work practice concerns and use requirements. It is used to tailor, frame, constrain, contextualise, configure, or regulate the construction and use of other viewpoints, views and model kinds, such as the situated capability viewpoint. The characterisation of a (work) situation includes the following aspects: • General situational aspects: Facts, conditions, circumstances and

events that affect someone or something at a particular time and in a particular place (Sowa and Zachman 1992) (Object Management Group 2015).

• Work practice aspects: Identified work practices. This is based on actual work being conducted, tasks, ways of working, ways of thinking, questions asked, objectives, results, outcomes, techniques, tools used, deliverables, work products, professions, organisational jobs or positions (Tell et al. 2016) (Venkatesh et al. 3AD).

• Use requirements (new): Requirements for the use of the capability viewpoint to be created within the frame of a work practice. Note: This type of aspects has been extracted from work practice aspects (see Paper C) into a separate group of aspects.

The characterisation of a work practice follows the description of Adler et al. (Adler and Pouliot 2011). The usage of tools and work products such as the concept of capability is added to this description, as follows:

1. It is a process of doing something; 2. It contains repetitions of actions; 3. It can be performed correctly or incorrectly; 4. It rests on accumulated knowledge; 5. It combines the use of communication and the material world; and 6. Participants use tools and work products (new).

In summary, a (work) situation includes both general situational aspects and more specific aspects related to work practices performed in such (work) situations.

70

The current research focuses on the novel situated capability viewpoint, and does not present a detailed specification and formalisation of this viewpoint and related kinds of model. Conformance of the situated capability viewpoint The situated capability viewpoint is one that is created in the tailoring step of the process. It is created by specialising the base capability viewpoint and the embedded general capability pattern through addressing situational work practice concerns and use requirements. The viewpoint can also incorporate aspects from capability-based methods, theories and models, and aspects that need to be satisfied for the viewpoint to be integrated in a larger EAF. The ISO 42010 standard requires that a viewpoint shall specify:

a) one or more concerns framed by this viewpoint; b) typical stakeholders for concerns framed by this viewpoint; c) one or more model kinds used in this viewpoint; d) for each model kind identified in c), the languages, notations,

conventions, modelling techniques, analytical methods and/or other operations to be used on models of this kind;

e) references to its sources.

All situated capability viewpoints should specify the following: a) The concerns framed by a situated capability viewpoint are:

situational, information needs, work practice and related use requirements, and capability concerns. All elements of the general capability pattern must be translated into something that fits with the target situation, work practices, methods and theories used, and kinds of models.

b) The relevant stakeholders are documented in a stakeholder view and are connected to a situated capability viewpoint through the situation, work practice and related use requirements documented in the situational view.

c) New models should be developed, or existing models should be adapted and tailored, so that specific capability concerns can be captured while being relevant to the situation, work practice and use requirements.

d) All parts of d) should be developed and specified in order for the model kinds to be used while being relevant to the situation, work practice and use-requirements.

e) The sources are Papers C and B, the current thesis, and the information used or referenced throughout the application of this method.

71

4.4.2 Steps in the method This subsection provides a description of the process involved in this method chunk. The entire section is derived from Paper C (Tell et al. 2016), and all text quoted here is taken from Section 6 of this work. Changes needed to integrate the text from Paper C into this thesis is annotated with square brackets. Step 1: Situate and focus “Description: This step provides an essential tool for framing and understanding the general situation-of-interest that surround [situations and work practices] identified at a later stage, and to allocate attention and effort to the method execution. The step provides an opportunity to identify factors that may influence subsequent steps, such as problems, objectives, challenges, opportunities, motivators, goals, experience, risks, general questions and issues to address, relevant assumptions, constraints, and beliefs system. Goal: The step aims at situating and anchoring into a situation-of-interest by describing the situation, influencing factors, and what to focus on. Activities: a. Identify, describe, and frame situation-of-interest, and focus of

interest. b. Identify, and describe influencing factors. Result: • A description of the situation-of-interest, and influencing factors.

Guidelines: a. Checklands Rich Picture technique may be used to obtain a broader

overview (Checkland 2000).”((Tell et al. 2016) Section 6.1).” Step 2: Characterise “Description: The characterise step aims at narrowing down a potentially large set of [situations and work practices], originating from each participant own world-view of the situation-of-interest, into a reasonable and practicable set of [situations and work practices] that can be used as requirements for the tailoring step. One of the most important [situations] is framed by the organized work individuals do, such as a job performed in a position or role. Stakeholder’s [situations and work practices] provides a point-of-reference, value and belief base for analysing and designing the use of a situated capability viewpoint within the frame of the situation-of-interest. The clustering of individuals into stakeholders, based on common characteristics, provides a practical [base for] subsequent steps. Goal:

72

The step aims at identifying affected individuals, categorize individuals into stakeholders, and identifying [situations and work practices] related to stakeholders, in order to provide use-requirements for the creation of situated capability viewpoints. Activities: a. Identify and describe affected individuals that participate in, are

affected by, or perceive themselves as affected by the situation-of-interest.

b. Analyse and categorize individuals into stakeholders. c. Identify and describe work-situations and use-requirements. Result: • Stakeholder view with corresponding model. • Situational work views including [identified situations and work

practices with related use-requirements]. General guidelines: a. This step can be performed using stakeholder analysis (Holland 2007). b. Real-world examples should be gathered to provide a pragmatic

grounding for discussions, debate, analysis, and evaluations in this and subsequent steps.

Use-requirements guidelines: When identifying a [situation and work practices], it is valuable to describe the needs and expectations of stakeholders on what a capability viewpoint should contain. Factors, which has an effect on intention-to-use and actual-use, can be found in the Unified Theory of Acceptance and Use of Technology (Venkatesh et al. 3AD). The following list summarise their grouping of factors, and provides a single example of a factor; Job-Fit. a. Performance expectancy: Individual’s beliefs relating to, if the use of

a capability viewpoint will help him or her to attain gains in job performance.

⁃ Job-fit: How a capability viewpoint enhances an individual’s job performance.

b. Effort expectancy: Expected ease of use of the capability viewpoint. c. Social Influence: Perception of the importance of other people’s

beliefs that a capability viewpoint should be used. d. Facilitating conditions: Perception if a value base, organizational and

technical infrastructure exists to support use of the capability viewpoint.

Other factors to consider includes: questions that can be answered through the situated model kinds (ISO/IECIEEE 2011), and factors that affect decision making.”( (Tell et al. 2016) Section 6.2).” Step 3: Tailor

73

“Description: The tailoring step creates situated capability viewpoints that weave general capability concerns, [(represented by the General Capability Pattern),] with [situational and work practice] concerns in order to improve qualities such as intention-to-use, actual-use, and to satisfy use-requirements as defined in the characterize step. Goal: The step aims at developing situated capability viewpoints by tailoring the base capability viewpoint to address situational work concerns and use-requirements. Activities: For each identified [situation and work practice]: a. Analyse [situations and work practices], use-requirements and their

relationships to other situations in order to determine relevant situated viewpoint concerns.

b. Develop a situated capability viewpoint by specialising each of the six essential elements of the base capability viewpoint [deleted reference].

c. Refine situated capability viewpoint by weaving the capability model kinds and its model elements, with related model kinds in encompassing framework or method.

d. Develop view and model examples of each situated capability viewpoints in order to increase understandability as well as comparability in the validation step.

Result: • A set of situated capability viewpoints descriptions, with

corresponding situated capability model kinds, which are ISO 42010 compliant.

((Tell et al. 2016) Section 6.3).” Step 4 Validate “Description: This step provides a real world check of the situated capability viewpoints descriptions, and aims partly at developing insights and possible ideas for improvements, and partly at providing a structured validation. This step offers a space where participation can discuss, deliberate, form intentions and commitment to-use. [The structured validation should be done according to a work quality model that contains quality characteristics which provide a quality framework for specifying quality requirements and evaluating quality [ISO/IEC 25000:2005]. Note: the preceding sentence has been added to the methods in order to strengthen the validation step.] Goal:

74

The step aims at comparing situated capability viewpoints with the perceived real world, by evaluating fulfilment of [general situational, work practice, use-requirements aspects, and general and specific capability concerns]. Activities: a. Evaluate fulfilment of [general situational, work practice, and use-

requirements aspects]. b. Record feedback from participants, findings, and ideas for

improvement c. If a situated capability viewpoint is determined to be acceptable by

stakeholders then continue, otherwise decide if it is feasible and relevant to reiterate to a previous step, if not then terminate the process.

Result: • Descriptions of evaluation results, findings, conclusions, ideas for

improvements. Guidelines: • Formal validation methods, evidence and data based methods, and

assurance case techniques can be used to increase confidence in the results and acceptability.” [(Tell et al. 2016) Section 6.4].”

4.4.3 Artifact 3: Fulfilment of Requirements The capability situating method satisfies Requirement 1, since it identifies relevant situations, work practices and use requirements that are used to adapt and tailor the base capability viewpoint to ensure that it is relevant and usable in the identified domains and work practices. The method is not bound to a specific domain or overall capability analysis method, nor to any specific method of identifying stakeholders. It also satisfies Requirement 3, since it takes a base capability viewpoint that conforms to ISO 42010 and tailors it to become an output situated capability viewpoint that conforms to ISO 42010. The capability situating method satisfies Requirement 4, since it specifically considers work practices such as job fit, performance and output expectancy, intention to use and actual use of capability analysis, and use requirements in Step 2. A separate step is used for stakeholder, situation and work practice identification, and a validation step ensures that the results are acceptable and applicable to the stakeholders, thus contributing further to the satisfaction of requirements. Guidelines and well-structured descriptions also support the efficiency requirement.

75

5 Discussion

This chapter discusses the value of the concept of capability, the quality of the research and the limitations of the current work.

5.1 What does the concept of capability really add? A question that has become increasingly relevant throughout this research is as follows: what does the concept of capability add, when so much is already known? The empirical case study reveals that the concept of capability is being annotated, embedded, overloaded, merged or combined with other existing meanings, thinking and semantics. This finding is supported by the existence of many domain-specific conceptualisations of the concept of capability (see results in Section 4.1). This can lead to problems in terms of comparison and use when these conceptualisations are not openly described and motivated. When a concept such as capability is added to existing EAFs, they need to be integrated with existing and adjacent concepts, theories and methods. Thus, the unique contribution of the concept of capability needs to be clear, and preferably not to overlap with what already exists. The following anecdotal story, shared by consultants and analysts to the author, about how the idea of capability became important to them, illustrates and motivates one aspect of the overall problem discussed in this thesis.

“Something was missing in discussions with organisations. Talking about processes was not enough. For a while, the idea of a (business) component was tried—components that were well defined, boxed, neatly organised in levels or rows and columns, and with responsible persons. However, the component idea did not gain widespread traction. Capability appeared as the missing tool, and was supported by military applications and new strategy and business theories. In many cases, the idea of capability then merged with component thinking, and sometimes capability became another way of talking about capable processes.”

However, in this story, the missing pieces already existed and were hiding in plain sight; what was missing was knowledge about the underpinning organisational, business, strategy, operational and technological concepts such as facilities and equipment. What happens when a capability model overlays, hides or replaces existing strategic, business or operational concepts? After all, an “innovation management capability” is a rather empty construct unless the underlying and grounding concepts of ‘innovation’ and ‘innovation management’ are understood. Organisational knowledge must be incorporated; otherwise,

76

capability models can paint an illusion of an organisation. In order to discuss and highlight the issues in the preceding story, a set of questions was constructed that reformulate the problem of what the essential and delimiting characteristics of the concept of capability add to a framework. The “X” in the following questions should be replaced by some organisational knowledge such as “innovation management”:

If you know “X”, then what does knowledge about “X capability” add?

If you discuss “X capability” but do not know the grounding “X”, then what are you discussing?

These questions were used in public discussions with practitioners and researchers, with varying results. In many cases, curiosity was displayed, but in others, defences were mounted such as avoiding answering the questions. One avoidance strategy was that “a (capability) modeller can make any kind of model they want, and can use any name they choose”. The capability situating method provides a way to assess such comments by the grounding and adaptation of artifacts in (work) situations. The method includes assessments of models and their correspondence and relevance to the world, and evaluations of use, intention to use and utility by the end users. These evaluations are carried out by practitioners in the context of work practices, thereby avoiding potential self-reporting problems from the persons (experts) who created a specific kind of capability. The general capability pattern developed here provides essential elements that make a unique contribution to the concept of capability. The capability situating method further improves and facilitates the integration with existing capability-based frameworks and approaches. It is the view of the author that the question of “what does the concept of capability add when so much is already known” deserves continued attention, in order to improve the utility of capability-based analysis and planning.

5.2 Research quality The underlying paradigm of this research is design science. In (Alan et al. 2004), Hevner outlined a set of guidelines for good design science research, and this section presents a discussion of the current thesis with respect to these guidelines. The quality framework is based on design science, and the creation of artifacts should be grounded in the three aspects and cycles of research (Hevner 2008):relevance, design and rigor. Relevance applies to the design of artifacts, which should be relevant within some environmental context to certain problems or opportunities. Design applies to the development and evaluation of the artifacts, while rigor applies to the grounding of the design in (scientific)

77

knowledge and experiences. Hevner formulated the following seven design science research guidelines (Alan et al. 2004). Guideline 1: Design as an artifact: “Design science research must produce a viable artifact in the form of a construct, a model, a method, or an instantiation”. This thesis presents three novel artifacts: a general capability pattern (construct), a base capability viewpoint (model), and a method for creating situated capability viewpoints (method). Guideline 2: Problem relevance: “The objective of design science research is to develop technology-based solutions to important and relevant business problems.” The problems identified and addressed in this thesis are based on an empirical case study, and the artifacts are therefore designed to address real-world problems. Through its validation step, the capability situating method provides a second way to ensure that the outcome of the method is relevant. This increases the relevance, since it adapts and tailors the base capability viewpoint to address situational work concerns and use requirements. The validation step also increases relevance via the inclusion of a second evaluation of the fulfilment of situational work concerns, capability concerns and use requirements. The overall relevance to actual work practices is therefore further strengthened. Guideline 3: Design evaluation: “The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-executed evaluation methods.” The research strategy divides the overall research process into two stages. The focus here is on the first stage, and includes evaluations using informed argument evaluations (Alan et al. 2004) in which the researchers discuss and provide argumentation using knowledge of how the artifacts address the identified problem and fulfil the stated requirements. External validity was also addressed via a lightweight evaluation using demonstration cases. Internal validity was addressed through an evaluation using ‘what capability is not’ cases. Guideline 4: Research contributions: “Effective design science research must provide clear and verifiable contributions in the areas of the design artifact, design foundations, and/or design methodologies.” The main research contributions are twofold: firstly a deepened understanding of the use and utility, problems with and differences in the use and utility of the concept of capability across work practices; and secondly, novel artifacts that can be used to increase the relevance and utility of the concept of capability in the different work people do with others. The general capability pattern provides a means of carrying out comparisons between different capability definitions and methods by exposing what has been included in a specific

78

definition and method. The capability situating method provides a means of including situational knowledge into a framework and methods. This thesis contributes to the field of EA through three artifacts, which enable EAFs to develop situated capability viewpoints that are adapted and tailored to the work practices of stakeholders. Guideline 5: Research rigor: “Design science research relies upon the application of rigorous methods in both the construction and evaluation of the design artifact.” The theoretical grounding for activities in the DRSM is presented in the research methodology chapter. For example, the empirical research work is grounded in a case study (Myers 2008) and thematic analysis methodology (Braun and Clarke 2006). The capability situating method designed here is grounded in situational method engineering and practice theory, and the general capability pattern is grounded in the lattice of theories. The base capability viewpoint and the situated capability viewpoint are pragmatically grounded in the ISO 42010 international standard. Guideline 6: Design as a search process: “The search for an effective artifact requires utilizing available means to reach desired ends while satisfying laws in the problem environment.” The research process was conducted in an iterative manner in which each iteration added to the knowledge of problems and the solution design. The research work incrementally added ‘what capability is not’ cases that provide design challenges for the general capability pattern. The demonstration cases also identified design challenges and target (specific) cases that the situated capability viewpoint should address. The capability pattern poster (see Appendix A) illustrates the iterative nature of this work, since it contains a summary of the pattern parts that were encountered and identified during the analysis, deconstruction and reconstruction of existing capability definitions and methods. Guideline 7: Communication of research: “Design science research must be presented effectively both to technology-oriented as well as management-oriented audiences.” The research process includes support for multiple audiences. The research community was reached via publication of research papers at peer-reviewed conferences, and practitioners were primarily reached through public forums such as LinkedIn and a personal blog. The material presented in this way included posts suitable for both technology-oriented and management-oriented audiences.

5.3 Limitations and possible improvements This section discusses the limitations on this research and future directions for

79

improvement. The empirical grounding of this thesis is based on data from five work practices, which is insufficient for a wide range of general conclusions. However, the study does provide sufficient empirical grounding in a range of work practices for the first stage of the overall research strategy. The second phase shifts the focus to an increase in the empirical grounding and evaluation of the artifacts with respect to work practices. The number of evaluated work practices should be increased, and the selection should include a wider range of work practices from relevant domains, in order to increase coverage. Studies of situations involving multiple work practices within a single organisation would increase the understanding of the application of situated capability viewpoints in larger collaborative environments. The general capability pattern artifact was created through conceptual analysis and design techniques based on an examination of the existing capability definitions, theories and approaches. The identified ‘what capability is not’ cases were instrumental in guiding the conceptual analysis and identification of non-essential characteristics. In future work, these cases should be clarified further, and more cases should be identified. The process of identifying demonstration cases targeting specific capability definitions, theories, and approaches should continue, in order to further strengthen the design of the general capability pattern and the ways in which this artifact can and should be situated. This should be done in future research to increase coverage, relevance and rigor. The situational concerns included in the demonstration cases presented in this thesis are documented only briefly. By improving the situational documentation of each case, they can be used to further and more deeply deeper analyse and demonstrate the relevance and usefulness of the general capability pattern and the proposed method. These cases provide an excellent vehicle for sharing and communicating knowledge about the research and the artifacts to multiple audiences, and shed further light on the foundation of and differences between specific capability approaches and theories. The number of demonstration cases presented here is small, and they are spread across domains that limit the range of generalised conclusions. However, this research was conducted based on many more cases that are not presented here. One future improvement would be to increase the number of demonstration cases and evaluate them using participatory research in order to enhance the qualities, coverage, relevance and usage of the artifacts. The evaluation was carried out in this thesis using informed reasoning (Alan et al. 2004), and was supported by two lightweight evaluations of the general capability pattern artifact: demonstration cases, which addressed the external validity, and “what capability is not” cases, which addressed the internal validity. This evaluation of the artifacts needs to be strengthened with well-executed evaluation methods, and this is the aim of the second stage of the overall research strategy. The artifacts and their use in different work practices

80

need to be studied further and in more depth, in order to understand the factors of acceptance, intention to use, situational use requirements and usage patterns. In this context, participatory action research (Myers 2008) is a natural candidate for a research method to study work practices, according to practice theory (Bourdieu 1601).

81

6 Conclusion

This thesis presents a design science research effort in which capability-based artifacts are designed and developed that can be used in and between different work practices. The driving question for this research was: How can a concept of capability be designed and made adaptable so that it can be used in different work practices, and at the same time support coherence between work practices? This question was addressed through a series of design science activities, including an empirical case study, resulting in insights into the use of the concept of capability and three novel artifacts. The artifacts developed here were grounded in results and problems explicated from a case study of an ATM programme in which individuals from multiple work practices were expected to use the concept of capability. The first artifact was a general capability pattern. This is a construct artifact that represents the concept of capability, and can be used to compare various kinds of specific capabilities. Its design enables it to be adapted and tailored to various uses, such as those required by different work practices. The second artifact was a base capability viewpoint. This is a model artifact that integrates the general capability pattern with EAFs through the use of the ISO 42010 international standard. The third artifact was a situating capability method. This is a method artifact that takes as its basis an investigation of stakeholders and the work they do with others, and uses this to adapt and tailor the base capability viewpoint to become situated capability viewpoints. The output of the method, situated capability viewpoints, incorporates situational work concerns and use requirements, aspects of capability-based methods, EAFs, theories and model kinds. EAFs such as TOGAF (The Open Group 2018) are essentially multi-stakeholder, multi-practice and multi-perspective frameworks, since they support a wide range of stakeholders and collaborations between stakeholders. Furthermore, these types of EAFs include work and work products that are based on the concept of capability, and are relevant and usable in situations with coherence between different work practices. It is therefore argued that the research reported in this thesis addresses and satisfies both the overall research goal and the research sub-goals.

6.1 Contributions The main contributions of this thesis are classified according to Gregor and

82

Hevner knowledge classification scheme (Gregor and Hevner 2013). Prescriptive knowledge was contributed by the developed artifacts, construct, model and method, while the ATM case study provided descriptive knowledge. The artifacts developed here provide a Level 2 contribution, defined as “nascent design theory—knowledge as operational principles/architecture” (Gregor and Hevner 2013). A Level 3 contribution is more “abstract, complete, and mature”; a “well-developed design theory about embedded phenomena”. A Level 1 contribution is more “specific, limited, and less mature”; a “situated implementation of an artifact” (Gregor and Hevner 2013). The contributions are also divided into practical and theoretical contributions, as presented in the following subsections. They are presented as contributions to the research focus at the intersection of the fields of EA, viewpoints, the concept of capability, and work practices.

6.1.1 Practical contributions The primary practical contribution is a method artifact called the capability situating method. This method enriches the general concept of capability and EAFs in three important ways. Firstly, the capability situating method incorporates situational work practice knowledge and related use requirements. In this way, the relevance, use and utility of the concept of capability are improved for individuals in their work practices. The capability situating method can furthermore be used as an instrument to clarify what the different work practices are, why employees have different perspectives, and to show how different groups view and use the concept of capability. Secondly, the capability situating method provides a method chunk and an addition to EAFs that enables the adaptation and tailoring of capability concerns and related EA viewpoints. Thirdly, the mechanism of situating capabilities enables a deeper understanding of and differences in the use and utility of the concept of capability in various work practices.

6.1.2 Theoretical contributions The main theoretical contribution is a novel formulation of the general concept of capability as represented by the general capability pattern, which includes the identification of both essential and non-essential elements. The general capability pattern provides a bridge between general and specific uses of the concept of capability in work practices, capability-based approaches and EA frameworks. The general capability pattern also enables comparisons of the similarities and differences between different variants of the concept of capability. The general capability pattern is designed to be adapted and tailored to fit into different work practices and EAFs.

83

6.2 Future research This thesis reports the results of the first stage of the overall research process, design theory building, and the creation of a set of artifacts that solves the identified problem and satisfies the research requirements. The primary direction of future research is to continue with the second stage of design theory justification, and to shift the focus to the evaluation of the use and usefulness of the artifacts in real-world situations and in the development of EAFs. The applied research methods should then shift to more participatory methods such as action research. A further direction would be to formalise and ontologically ground the developed general capability pattern, and to integrate it ontologically with adjacent concepts such as process, resource and service. A formalisation would need to address the question of what the concept of capability really adds. An ontological integration would shed light on the practical integration of diverse subject fields such as capability planning, service design and business process development. This can also be done as a refinement step within the first research direction. A third direction is to investigate the use of the method to situate other concepts, such as process and service, within the field of enterprise architecture. The capability situating method proposed in this thesis is tied to the concept of capability; however, the method should be generalisable to other concepts. The addition of situational and work practice knowledge has the potential to change the way enterprise modelling is conducted and how enterprise models are used by non-experts. A fourth direction would be to investigate the utility of a fusion between the general concept of capability and the general concept of a component. The capability-component approach is frequently used, especially within the fields of EA and IS. A fifth direction is to further investigate the effects of situating or adapting enterprise modelling and/or knowledge management using knowledge about stakeholders and the work they do with others. An interweaving of the work people do with their mental models and decisions, tools, and work products has the potential to unlock, realise and optimise the value of togetherness in an organisation.

84

7 Appendix

7.1 Appendix A: Capability pattern poster This appendix presents the capability pattern poster, which contains examples of the elements in the general capability pattern. This poster is intended to inform and guide analysts and developers of specific definitions of capability and capability-based methods.

85

7.2 Appendix B: Situated capability definition template This appendix presents a documentation template that can be used in the analysis and design of situated capability definitions based on the six essential elements.

Copyright © 2009-2018, Anders W. Tell, All Rights Reserved. email:<anders.w.tell@workem.com>

The Capability TemplateThis template allows you to construct a type of capability for the work you do with others

V0.9.6

Substantiality

Result

Examples:

Substantiality

Lead-To

Substantiality

Sources

Examples:

Examples:

Interested parties

Work Situation(s)

Attitudes & Roles

Possessor

Possibility

Examples:

CapabilityDefinition

86

7.3 Appendix C: Situated capability viewpoint - ISO 42010 Documentation Template This appendix presents a documentation template that enables the documentation of situated capability viewpoints based on the ISO 42010 standard. This template extends informational requirements for the viewpoint from the ISO 42010 standard (with information relevant to the situation) to situated capability concerns.

Name [42010 B.2.2]

IS 42010 Optional InformationTechniques (optional) for creation, interpretation, analysis, evaluation [42010 7., B.2.8]Correspondence rules (optional) criteria and methods for checking consistency and completeness. |42010 7., B.2.7]Examples and Guidance (optional) methods, heuristics, metrics, patterns, design rules or guidelines, best practices and examples to aid in view creation and synthesis. [42010 7., B.2.9]Notes (optional) [B.2.10]Sources (optional) [42010 7.e, B.2.11]

Capability Concerns - Knowledge Construct[42010 7.a, B.2.4]

Possessor

Source

Lead-To

Result

Substantiality

Possibility

Stakeholder ViewInterested Parties, Typical Stakeholders. [42010 7.b, B2.5]

IS 42010 Model Kind[42010 7.c, B.2.6]Meta model, languages, notations, conventions, modelling techniques, templates analytical methods and/or other operations. [42010 7.d]

IS 42010 IntroductionOverview (story) [42010 B.2.3] Logical Overview (logic)Context (library viewpoint) [42010 7.]

Situational View(s) Name: name of work situation or work practice

Situational Concern(s)

Use Requirement(s)Decisions, Questions, etc.

IS 42010 Additional InformationAnti concern (optional) [42010 B.2.4]

Work Practice Concern(s)

87

7.4 Definitions

Source: Semantics of Business Vocabulary and Business Rules, v1.4 Aspect Definition: A concept that generalizes a given concept but incorporates only those

characteristics that are relevant to a particular viewpoint. Dictionary basis: A particular way in which some thing may be considered; its

particular nature, appearance, or quality; the particular part or feature of it. [Source: The New Oxford Dictionary of English]

Characteristic Definition: An abstraction of a property of an object [thing] or of a set of objects.

[Source: ISO 1087-1] Definition Definition: The representation of a concept by a descriptive statement [expression]

which serves to differentiate it from related concepts. [Source: ISO 1087-1] Delimiting characteristic Definition: An essential characteristic used for distinguishing a concept from

related concepts. [Source: ISO 1087-1] Essential characteristic Definition: A characteristic which is indispensable to understanding a concept.

[Source: ISO 1087-1] Viewpoint Definition: A perspective from which something is considered.

Source: ISO 42010 Systems and software engineering—Architecture description Architecture Definition: Fundamental concepts or properties of a system in its environment,

embodied in its elements, relationships, and in the principles of its design and evolution. [source: ISO 42010]

Architecture description (AD) Definition: A work product used to express an architecture. [source: ISO 42010] Architecture description element (AD element) Definition: A construct in an architecture description. [source: ISO 42010] Architecture framework Definition: The conventions, principles and practices of architecture description

established within a specific domain of application or community of stakeholders. [source: ISO 42010]

Architecture model Definition: A discrete part of an architecture view consisting of AD elements.

[source: ISO 42010] Architecture view Definition: A work product expressing the architecture of a system from the

88

perspective of system concerns. [source: ISO 42010] Architecture viewpoint Definition: A work product establishing the conventions for the construction,

interpretation and use of architecture views. [source: ISO 42010] Concern Definition: Interest in a system relevant to one or more of its stakeholders. [source:

ISO 42010] Correspondence Definition: A relation between AD elements. [source: ISO 42010] Correspondence rule Definition: The definition of a relationship between AD elements expressed as a

constraint on AD correspondences. [source: ISO 42010] Model kind Definition: Conventions for one type of modelling. [source: ISO 42010] Stakeholder (of a system) Definition: An individual, team, organization, or classes thereof, having concerns

with respect to a system. [source: ISO 42010] Work product Definition: An artifact associated with the execution of a process. [source: ISO/IEC

15504-1:2004, 3.55]

Source: Basic formal ontology 2.0, June 26, 2015 Continuant Description: An entity that persists, endures, or continues to exist through time

while maintaining its identity. Disposition Description: An internally-grounded realizable entity that is a reflection of the (in-

built or acquired) physical make-up of the material entity in which it inheres. Entity Description: An entity is anything that exists, or has existed, or will exist. Function Description: A function is a disposition that exists in virtue of the bearer’s physical

make-up and this physical make-up is something the bearer possesses because it came into being either through evolution (in the case of natural biological entities) or through intentional design (in the case of artifacts), in order to realize processes of a certain sort.

Immaterial entity Description: Have no material entities as parts. Examples: surface, line or , point. Material entity Description: An independent continuant that has some portion of matter as proper

or improper continuant part. A ‘portion of matter’ is intended to encompass both mass and energy. Every material entity at any given time is localised in space at that time, and can move in space. Material entities are three-dimensional spatial entities, as contrasted with the processes in which they participate, which are four-dimensional entities. Example: a human, an aggregate of humans.

89

Object Description: A material entity manifests causal unity via physical covering

(organisms, cells), internal physical forces (portions of solid matter such as rocks and lumps of iron), or engineered assembly of components (engineered artifacts such as watches and cars). Objects can be joined to other objects and may include other objects as parts. Examples: a cell, an organism, a grain of sand.

Occurrent

Description: An entity that unfolds itself in time, or it is the instantaneous boundary of such an entity (for example a beginning or an ending), or it is a temporal or spatiotemporal region, which such an entity occupies.

Process

Description: Has temporal proper parts and for some time t, P s-depends -on some material entity at t. has-participant is an instance-level relation between a process, a continuant, and a temporal region at which the continuant participates in some way in the process. A process does not change;, it is the change itself. Examples: the life of an organism, the a process of sleeping.

Process profile

Description: A process that represents a selective cognition or abstraction of mutually dependent sub processes. Examples: a pair of rumba dancers is moving together across the dance floor form a mutually dependent process pair;, the process of temperature changes in John.

Realizable entity

Description: A specifically dependent continuant that inheres in some independent continuant which is not a spatial region and is of a type instances of which are realized in processes of a correlated type.

Source: ISO/IEC 9000: 2015, Quality management systems- Fundamentals and vocabulary Interested party

Definition: A person or organization that can affect, be affected by, or perceive themselves to be affected by a decision or activity. [source ISO 9000:2015]

90

8 References

Adler E, Pouliot V (2011) International practices: introduction and framework. CAMBRIDGE STUDIES IN INTERNATIONAL RELATIONS 119:3–35.

Alan Von RH, March ST, Park J, Ram S (2004) Design science in information systems research. MIS quarterly 28:75–105.

Aleatrati Khosroshahi P, Hauder M, Volkert S, et al (2018) Business Capability Maps: Current Practices and Use Cases for Enterprise Architecture Management. Hawaii International Conference on System Sciences, pp 1–11

Baskerville RL (2008) What design science is not. European Journal of Information Systems 17:441–443.

Beimborn D, Martin SF, Homann U (2005) Capability-oriented Modeling of the Firm. pp 1–16

Bērziša S, Bravos G, Gonzalez TC, et al (2015) Capability Driven Development: An Approach to Designing Digital Enterprises. Bus Inf Syst Eng 57:15–25. doi: 10.1007/s12599-014-0362-0

Bourdieu P (1601) OUTLINE OF A THEORY OF PRACTICE. 1–257.

Braun V, Clarke V (2006) Using thematic analysis in psychology. 3:77–101. doi: 10.1191/1478088706qp063oa

Brown JS, Duguid P (2000) Balancing Act: How to Capture Knowledge Without Killing It. 73–80.

Cardeal N, António N (2012) Valuable, rare, inimitable resources and organization (VRIO) resources or valuable, rare, inimitable resources (VRI) capabilities: What leads to competitive advantage? Afr J Bus Management. doi: 10.5897/AJBM12.295

Checkland P (2000) Soft systems methodology: a thirty year retrospective. Systems Research and Behavioral Science 17:S11–S58. doi: 10.1002/1099-1743

Cockton G, Kirk D, Sellen A, Banks R (2009) Evolving and Augmenting Worth Mapping for Family Archives. pp 329–338

Danesh MH, Yu E (2014) Modeling Enterprise Capabilities with i*: Reasoning on Alternatives. CAiSE 112–123.

Dixit A (2011) The“ IMRAD” format: a concise and clear way to present a scientific study.

Dosi G, Nelson R, Winter S (2001) The Nature and Dynamics of Organizational Capabilities. 404.

Eisenhardt KM, Martin JA (2000) Dynamic Capabilities: What Are They? Strategic Management Journal 21:1–18.

Forskningsrådet H-S (1999) Forskningsetiska principer i humanistisk-samhällsvetenskaplig forskning.

Gregor S, Hevner AR (2013) Positioning and presenting design science research for maximum impact. 37:1–26.

91

Haeckel SH (2016) Adaptive Enterprise. Harvard Business School Press

Harmon P (2011) Capabilities and Processes. In: www.bptrends.com. http://www.bptrends.com/publicationfiles/advisor20110712.pdf. Accessed 24 Apr 2016

Henderson-Sellers B, Ralyte J (2010) Situational method engineering: state-of-the-art review.

Hevner AR (2008) A Three Cycle View of Design Science Research. 1–6.

Holland J (2007) Tools for institutional, political, and social analysis of policy reform: a sourcebook for development practitioners. World Bank Publications

HORKOFF J, BARONE D, JIANG L, et al (2014) Strategic Business Modeling: Representation and Reasoning. 13:1–39.

Hughes J, Kroes P, Zwart S (2005) A Semantics for Means-End Relations. 1–15.

IDEF IDEF0 Function modeling method. In: www.idef.com. Accessed 7 May 2018

International Institute of Business Analysis (2015) A guide to the business analysis body of knowledge, 3rd edn.

ISO/IEC (2015) ISO 9000 Quality management systems — Fundamentals and vocabulary. 1–60.

ISO/IEC (2007) ISO/IEC 24707:2007 Common Logic (CL): a framework for a family of logicbased languages.

ISO/IEC, IEEE (2011) ISO/IEC 42010:2011 Systems and software engineering — Architecture description.

Javidan M (1998) Core Competence: What Does it Mean in Practice? Long range planning 31:60–71.

Johannesson P, Perjons E (2014) An Introduction to Design Science. Springer

Johannesson P, Perjons E (2017) Untangling the Web of Practices: Designing Information Systems in Context. 1–33.

Johnson P, Lagerström R, Närman P, Simonsson M (2007) Enterprise architecture analysis with extended influence diagrams. Information Systems Frontiers. doi: 10.1007/s10796-007-9030-y

Johnston CS (1995) Taylor & Francis Online :: The Rokeach Value Survey: Underlying Structure and Multidimensional Scaling - The Journal of Psychology - Volume 129, Issue 5.

Kaplan RS, Norton DP (2008) The Execution Premium: Linking Strategy to Operations for Competitive Advantage, 1st edn. Harvard Business School Press

Kusunoki K, Notiaka I, Nagata A (1998) Organizational Capabilities in Product Development of Japanese Firms: A Conceptual Framework and Empirical Findings. 9:699–718. doi: 10.1287/orsc.9.6.699

Leiblein MJ (2011) What Do Resource- and Capability-Based Theories Propose? Journal of Management 37:909–932. doi: 10.1177/0149206311408321

92

Leinwand P, Mainardi C (2013) The Essential Advantage: How to Win with a Capabilities-Driven Strategy. Harvard Business Press

Lincoln YS, Guba EG (1985) Naturalistic inquiry, 1st edn. Sage Publications, Inc

Longman Longman Dictionary of Contemporary English Online. In: Longman Dictionary. Accessed 21 Jun 2012

MAKADOK R (2000) Toward a synthesis of the resource-based and dynamic-capability views of rent creation. Strategic Management Journal 22:387–401. doi: 10.1002/smj.158

Maritan CA, Florence RE (2008) Investing in Capabilities: Bidding in Strategic Factor Markets with Costly Information. 29:227–239. doi: 10.1002/mde

McKeen JD, Smith H (2011) IT Strategy (2nd Edition), 2nd edn. Prentice Hall

Myers MD (2008) Qualitative Research in Business & Management. Sage Publications Ltd

NATO (2009) NATO Architecture Framework - NAF 3.1, 3rd edn.

Nehan Y-R, Deneckere R (2009) Component-based Situational Methods. 1–17.

Nicolini D (2012) Practice Theory, Work, and Organization : An Introduction. OUP Oxford, Oxford, pp 1–29

OASIS (2006) Reference Model for Service Oriented Architecture 1.0. OASIS

OASIS (2009) Service Oriented Architecture Reference Architecture.

Object Management Group (2012) Unified Profile for DoDAF and MODAF (UPDM).

Object Management Group (2017) Semantics of Business Vocabulary and Business Rules, v1.4.

Object Management Group (2015) Semantics of Business Vocabulary and Business Rules (SBVR) v1.3.

Olivé A (2007) Conceptual modeling of information systems. Springer Science & Business Media

Oxford University Causation in Science. In: oxfordhandbooks. http://www.oxfordhandbooks.com/. Accessed 15 May 2018

Rafati L, Poels G (2014) Capability Sourcing Modeling. 1–11.

Ralyte J, Deneckere R, ROLLAND C (2003) Towards a Generic Model for Situational Method Engineering. In: Requirements Engineering: Foundation for Software Quality. Springer Berlin Heidelberg, Berlin, Heidelberg, pp 95–110

Robeyns I (2003) The Capability Approach: An Interdisciplinary Introduction. 1–57.

Robeyns I (2005) The capability approach: a theoretical survey. Journal of human development 6:93–117. doi: 10.1080/146498805200034266

Sanchez R (2008) A scientific critique of the resource-base view (RBV) in strategy theory, with competence-based remedies for the RBV's conceptual deficiencies and logic problems. Elsevier

93

Schreyögg G, Kliesch-Eberl M (2007) How dynamic can organizational capabilities be? Towards a dual-process model of capability dynamization. Strategic Management Journal 28:913–933. doi: 10.1002/smj.613

Sen A (2009) Capability and Agency. In: Morris CW (ed). Cambridge University Press, Cambridge, pp 60–90

Sen A (2011) The idea of justice. Harvard University Press

Serra CEM, Kunc M (2015) Benefits Realisation Management and its influence on project success and on the execution of business strategies. International Journal of Project Management 33:53–66.

Smith B, Ceusters W (2010) Ontological realism: A methodology for coordinated evolution of scientific ontologies. Applied Ontology 5:139–188. doi: 10.3233/AO-2010-0079

Smith B, Grenon P Basic Formal Ontology (BFO). In: purl.obolibrary.org. http://purl.obolibrary.org/obo/bfo. Accessed 16 Aug 2013

Sollaci LB, Pereira MG (2004) The introduction, methods, results, and discussion (IMRAD) structure: a fifty-year survey.

Sowa JF (2005) Theories, Models, Reasoning, Language, and Truth. http://www.jfsowa.com/logic/theories.htm. Accessed 19 Oct 2012

Sowa JF (2007) Language Games: A Foundation for Semantics and Ontology. Game Theory and Linguistic Meaning, edited by Ahti-Veikko Pietarinen, Elsevier 17–37.

Sowa JF Relating Templates to Language and Logic. In: www.jfsowa.com. http://www.jfsowa.com/pubs/template.htm. Accessed 1 Sep 2013

Sowa JF, Zachman JA (1992) Extending and formalizing the framework for information systems architecture. IBM systems Journal 31:1–27.

Stanford University (2011) The Capability Approach. In: Stanford Plato. https://plato.stanford.edu/entries/capability-approach/. Accessed 20 May 2018

Stanford University Dispositions. In: Stanford Plato. https://plato.stanford.edu/entries/dispositions/. Accessed 15 May 2018

Stumme G (2009) Formal concept analysis.

Sutton RI, Staw BM (1995) What Theory is Not. Administrative science quarterly 371–384.

Teece DJ (2007) Explicating dynamic capabilities: the nature and microfoundations of (sustainable) enterprise performance. Strategic Management Journal 28:1319–1350. doi: 10.1002/smj.640

Tell AW (2014a) What Capability Is Not. In: Perspectives in Business Informatics Research. Springer International Publishing, Cham, pp 128–142

Tell AW (2014b) Interpreting Service using an upper-level ontology. pp 1–12

Tell AW, Henkel M (2018) Capabilities and Work Practices - A Case Study of the Practical Use and Utility. In: World Conference on Information Systems and Technologies. pp 1152–1162

Tell AW, Henkel M, Perjons E (2016) A Method for Situating Capability Viewpoints. In: Perspectives in Business Informatics Research, 2nd edn. Springer International Publishing, Cham, pp 278–293

94

The Open Group (2018) The TOGAF Standard, Version 9.2.

The Open Group (2011) SOA Reference Architecture.

Ulrich W, Rosen M (2011) THE BUSINESS CAPABILITY MAP: THE “ROSETTA STONE” OF BUSINESS/IT ALIGNMENT. In: www.cutter.com. https://www.cutter.com. Accessed 24 Apr 2016

Veludo-de-Oliveira TM, Ikeda AA, Campomar MC (2006) Laddering in the practice of marketing research: barriers and solutions. Qualitative Market Research 9:297–306. doi: 10.1108/13522750610671707

Venkatesh V, Morris MG, Davis GB, Davis FD (3AD) User Acceptance of Information Technology: Toward a Unified View. Mis Quarterly 27:425–478.

Wand Y, Weber R (1993) On the ontologrcal expressiveness of information systems analysis and design grammars. JOURNAL OF INFORMATION SYSTEMS 217–237.

Winter SG (2003) Understanding dynamic capabilities. Strategic Management Journal 24:991–995. doi: 10.1002/smj.318