Modelling Business Capabilities with Enterprise Architecture

Modelling Business Capabilities with Enterprise Architecture

A Case Study at a Swedish Pension Managing Company

SOFIA BERGSTRO? M

Master's Degree Project Stockholm, Sweden September 2015

TRITA-EE 2015:69

Modelling Business Capabilities with Enterprise Architecture

A Case Study at a Swedish Pension Managing Company

Sofia Bergstr?om

A Master Thesis Report written at Department of Industrial Information and Control Systems

KTH Royal Institute of Technology Stockholm, Sweden September, 2015

Abstract: This master thesis looks at the use of business capabilities within enterprise architecture, and investigates how the concept is used within the Swedish pension managing company Folksam. Based on interviews with stakeholders an enterprise architecture metamodel centred on the business capability is constructed. The meta-model is then edited and revised according to a questionnaire aimed at removing irrelevant elements, and a second set of interviews discussing a capability's health status and well being. This second set of interviews resulted in the removal of elements not affecting the well being of a capability. The final meta-model has the business capability and the capability health status at its core. It consists of the Capability element, with two attributes, surrounded by nine other elements connected by eleven relations in total.

Sammanfattning: Detta examensarbete unders?oker hur verksamhetsf?orm?agor anv?ands inom enterprisearkitektur, och vidare hur f?orm?age-konceptet anv?ands p?a det svenska pensionsf?oretaget Folksam. Baserat p?a intervjuer med intressenter skapas en metamodell med verksamhetsf?orm?agan i centrum. Metamodellen revideras och ?andras sedan enligt ett fr?ageformul?ar vars m?al var att ta bort ej relevanta element, och enligt en andra omg?ang intervjuer d?ar en f?orm?agas h?alsa diskuteras. Denna andra omg?ang intervjuer resulterade i att element som inte p?averkade f?orm?agans h?alsa togs bort. Den slutgiltiga metamodellen har verksamhetsf?orm?agan och dess h?alsostatus i fokus. Den best?ar av f?orm?age-elementet, med tv?a attribut, omg?ardat av nio andra element som binds ihop av totalt elva olika relationer.

Keywords: Enterprise Architecture, Business Capabilities, Meta-modelling, Health Status, Case Study

Table of Contents

1 INTRODUCTION

5

1.1 Folksam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 MAIN OBJECTIVE

6

2.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 THEORY

7

3.1 Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Enterprise Architecture Modelling . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Business Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Business Capabilities and Modelling within this Research . . . . . . . . . . . 15

4 METHOD

16

4.1 Step 1 - Initial Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 Step 2 - Meta-Model Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Step 3 - Meta-Model Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4 Step 4 - Meta-Model Editing and Finalisation . . . . . . . . . . . . . . . . . . 19

5 DATA

20

5.1 Step 1 - Initial Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Step 2 - Meta-Model Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3 Step 3 - Meta-Model Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.4 Step 4 - Meta-Model Editing and Finalisation . . . . . . . . . . . . . . . . . . 30

6 RESULTS

32

6.1 Element: Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 Element: Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.3 Element: Competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.4 Element: Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.5 Element: KPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.6 Element: Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.7 Element: Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.8 Element: Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.9 Element: Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.10 Attribute: Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.11 Attribute: Health Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 ANALYSIS

36

7.1 Elements Relevant to Connect to the Capability . . . . . . . . . . . . . . . . 36

7.2 Why Connect Capabilities to Other Elements? . . . . . . . . . . . . . . . . . 44

7.3 Affecting or affected? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.4 A Healthy Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8 DISCUSSION

46

8.1 Interview Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.2 Definition Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

9 CONCLUSIONS

47

9.1 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3

A Interviews

50

A.1 Interview set 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

A.2 Intervierw set 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4

1 INTRODUCTION

When working with enterprise architecture, there are several ways to describe a company. Depending on the purpose or the intended recipient, for example, three ways to describe a company can be to use the Who?, How?, or What? views. By asking Who?, one might end up with a description of who runs the company, chains of command, personal responsibilities, or an employee structure. If the question is How?, the answer could be the company's processes or production chains, showing how value is produced at the company. These are two common ways to describe companies, ways that have been used for many years and probably will be used for years to come.

To answer the question What?, companies have since the early 2000's started using a concept called Business Capabilities. These capabilities define what a company does, and each capability can be decomposed into more specific capabilities. For example, the "Procurement Management" capability could be decomposed into the capabilities "Vendor Management" and "Manage Product Acquisition", which in turn could be decomposed even further.

This report looks at the concept of business capabilities and its use within the Swedish insurance company Folksam. A study is carried out concerning what capabilities are used for at Folksam today as well as what they could be used for in the future, and an enterprise architecture meta-model is constructed based on the findings from the study.

1.1 Folksam

Folksam is a Swedish insurance company with 3900 employees and 4 million customers. The company was founded in 1908, and is now insuring every second person in Sweden. Folksam is a mutual company, which means that the customers own the company, and any profit goes back to the company and the customers, instead of being handed out to shareholders. Apart from personal risk insurance Folksam also provides pension investments and property and casualty insurance. The company is divided into three separate business areas - Private, Partner, and Collective Agreement - which operate across 11 different firms [8],[15].

5

2 MAIN OBJECTIVE

The main objective of this master's thesis was to create an enterprise architecture metamodel with regards both to the business capabilities within Folksam, and the different departmental needs within the company. The meta-model should also encompass the health status of the capability. Therefore, the main objective of this thesis consisted of two parts, seen below.

1. Create a meta-model for Folksam's business capabilities, meeting the expectations and fulfilling the requirements of identified stakeholders.

2. Modify the meta-model so that it encompasses the stakeholders' views on business capability health status.

Research was conducted through literature studies, interviews with stakeholders, and the creation and test of a meta-model. The results are documented in this report.

2.1 Scope

Folksam is currently in the process of creating a new, company-wide map of their business capabilities. As a part of the process, this report looked at what views the different stakeholders have of the business capability concept. They were asked how they would like to use the business capabilities, what they might have used them for before, and what they would like to be able to connect and relate them to in order to achieve these applications. The aim was to create a meta-model that can be of use at Folksam when creating this map, and to provide a perspective from outside the company.

2.2 Delimitations

To be able to participate in the study, the Enterprise Architect Team Leader deemed it necessary that, the respondents had to have some previous insight into the work with capabilities, since Folksam are still working with how to use capabilities. It was therefore her task to find suitable stakeholders to interview for this study.

6

3 THEORY

3.1 Enterprise Architecture

Enterprise architecture can be described as the practice of performing, among other things, enterprise analysis, planning, and design, with the goal of easing the execution of company strategies used to steer decision-making towards creating a desired architecture state [11],[5]. It has emerged since the early 2000's as an integral part of governance and transformations within a company, striving to provide a common ground for it for all the company's stakeholders [23]. In the book Enterprise Architecture: Modelling, Communication and Analysis Marc Lankhorst et al. compare the aims of enterprise architecture to the practises of architecture when it comes to buildings and construction: there you have a common framework, since everyone knows what "room", "door" or "window" refers to, which makes for efficient communication [20]. In a similar way, the ISO 42010:2011 standard pertains to systems and software engineering, and describes architecture in that context as "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution" [1]. In other words, when it comes to buildings and their architecture, most people know how to correlate a blueprint or a floor plan to an actual building, and that you need to have walls in order to be able to have windows. The ISO 42010:2011 standard strives to provide a similar working ground when mapping companies and their systems, making communication and planning easier.

TOGAF - The Open Group Architecture Framework

One way to develop an enterprise architecture is to use the TOGAF framework, developed by the Open Group. It contains methods and tools for creating an enterprise architecture through an Architecture Development Method consisting of eight basic phases enumerated A to H (seen below).

A Architecture Vision Phase defines the scope of the initiative, identifies stakeholders and other information needed to proceed with the development.

B Business Architecture Phase describes the Business Architecture needed to support the Architecture Vision.

C Information Systems Architecture Phase describes the Information Systems Architecture needed to support the Architecture Vision.

D Technology Architecture Phase describes the Technology Architecture needed to support the Architecture Vision.

E Opportunities and Solutions Phase conducts initial planning and identifies delivery vehicles (such as projects or programs) for the decided architecture.

F Migration Planning Phase describes how to move from current Baseline Architecture to future Target Architecture and finalises an Implementation and Migration Plan.

G Implementation Governance Phase provides an architectural oversight of the implementation.

H Architecture Change Management Phase establishes procedures for changing to the new architecture.

When reaching the last step the process is repeated to make sure that the enterprise architecture continues to be as up-to-date as possible. Connected to all these steps is the Requirements Management Phase that examines the process of creating architecture requirements throughout the architecture development. There is also a Preliminary Phase that describes the preparation needed to be able to create an enterprise architecture. The image used to describe TOGAF and this process can be found in figure 1 [18].

7

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download