Modelling Business Capabilities with Enterprise Architecture

(1)

Modelling Business Capabilities with

Enterprise Architecture

A Case Study at a Swedish Pension Managing Company

SOFIA BERGSTR ¨ OM

Master’s Degree Project

Stockholm, Sweden September 2015

(2)

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

(3)

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 meta- model 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öker hur verksamhetsförm˚agor används inom enterprisearkitektur, och vidare hur förm˚age-konceptet används p˚a det svenska pen- sionsföretaget Folksam. Baserat p˚a intervjuer med intressenter skapas en metamodell med verksamhetsförm˚agan i centrum. Metamodellen revideras och ändras sedan enligt ett fr˚age- formulär vars m˚al var att ta bort ej relevanta element, och enligt en andra omg˚ang intervjuer där en förm˚agas hälsa diskuteras. Denna andra omg˚ang intervjuer resulterade i att element som inte p˚averkade förm˚agans hälsa togs bort. Den slutgiltiga metamodellen har verk- samhetsförm˚agan och dess hälsostatus i fokus. Den best˚ar av förm˚age-elementet, med tv˚a attribut, omgärdat av nio andra element som binds ihop av totalt elva olika relationer.

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

(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].

(7)

2 MAIN OBJECTIVE

The main objective of this master’s thesis was to create an enterprise architecture meta- model 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.

(8)

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 Archi- tecture 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].

(9)

Figure 1: The TOGAF phases and their relations [18].

The Zachman Framework

To describe an existing enterprise architecture, the Zachman framework is commonly used.

This framework consists of a matrix with six columns and six rows, where each column represents a question and each row a perspective of a certain kind of employee. The official matrix can be seen in figure 2, and a simplified version can be seen in figure 3. The column labels, the questions, are ”What?”, ”How?”, ”Where?”, ”Who?”, ”When?”, and

”Why?”. These are, according to Zachman, the primitive interrogatives and therefore the fundamentals of communication. The row labels, the perspectives, are the perspectives of Executives, Business Management, Architects, Engineers, Technicians, and an overall Enterprise perspective. The 36 cells that make up the matrix would then be the different views that need to be modelled to fully describe an enterprise.

(10)

Figure 2: The official Zachman framework matrix [28].

Figure 3: A simplified version of the Zachman framework [13].

(11)

3.2 Enterprise Architecture Modelling

There are many tools that can be used when modelling an enterprise and its architecture, as well as several different modelling languages. A common modelling language is ArchiMate, developed by the Open Group. ArchiMate separates the enterprise into three different layers, the Business, Application, and Infrastructure layers. These are defined as follows:

• The Business layer, the topmost layer, models products and services delivered to external customers, as well as how they are realised within the enterprise.

• The Application layer, in the middle, shows the applications that support e.g. the different services and processes in the business layer.

• The Technology layer, at the bottom, models the infrastructure that is needed to run the applications in the application layer.

The ArchiMate language has been designed to be as small as possible while still being usable in most cases of enterprise architecture modelling. The language defines three core types of elements, as described below, which can be compared to the three grammatical parts of a regular sentence [4].

• Active structure elements are entities that can perform behaviour, compared to the subject in a sentence.

• Behaviour elements is a unit of activity that is performed by active structure elements, compared to the predicate in a sentence.

• Passive structure elements are objects on which behaviour is performed, compared to the object in a sentence.

UML, the Unified Modelling Language, is another language commonly used in enterprise architecture modelling. It is developed and maintained by OMG, the Object Management Group. The UML language also consists of three model element categories, albeit different ones from those in ArchiMate. The UML element categories are classifiers (describing a set of objects), events (describing a set of occurrences), and behaviours (describing a set of executions) [6]. UML has been standardised in ISO/IEC 19505-1 and ISO/IEC 19505-2 [2],[3].

Another framework is MODAF (the Ministry of Defence Architecture Framework), developed and maintained by the British Ministry of Defence. It consists of ”views” divided into seven categories, supporting interests for different stakeholders. The categories are:

1. Strategic views (StVs) 2. Operational views (OVs) 3. Service oriented views (SOVs) 4. Systems views (SVs)

5. Acquisition views (AcVs) 6. Technical standard views (TVs) 7. All views (AVs)

Each category corresponds to a viewpoint. The Strategic Viewpoint consists of six different StVs that together defines the capabilities needed to reach a desired business outcome, aligning capabilities with an enterprise strategy and identifying possible capability gaps.

The Operational Viewpoint has seven main views, some of which are split up into sub- views, making the total number of views for this viewpoint eleven. It provides an abstract

(12)

view of a solution, showing e.g. processes and information needed, but not what the actual solution could look like. The Service Oriented Viewpoint provides seven views and is used to specify services and their requirements for use in a Service Oriented Architecture (SOA).

The Systems Viewpoint describes the resources needed to e.g. implement a capability, and it consists of seventeen different views (including sub-views) specifying requirements for a system or solution. The Acquisition Viewpoint consists of two views that describe dependencies between projects as well as the ownership and structure of them. The Technical Standards Viewpoint is made up of two views and describes e.g. standards and policies (both technical and non-technical) that apply to different parts and aspects of the architecture.

The All Views Viewpoint is made up of two different views, and presents support and reference information for the architectural models, rather than any actual models [22].

Sparx Enterprise Architect

The tool used for enterprise architecture modelling at Folksam is called Enterprise Archi- tect, and is developed by Sparx Systems¹. This tool is based on UML 2.5, and supports several different languages and frameworks, such as ArchiMate, TOGAF, and the Zachman framework [7]. The models created as a part of this research are created in Sparx Enterprise Architect.

3.3 Business Capabilities

In Cutter Consortium’s Executive Report ”The Business Capability Map”, the business capabilities are described as the ”Rosetta stone of Business/IT alignment” [26]. Their view corresponds with Folksam’s view of business capabilities, and Cutter Consortium’s ten business capability principles have been the base for the capability work at Folksam.

The principles state that:

1. Capabilities define what a business does, not how a business does something.

2. Capabilities are nouns, not verbs.

3. Capabilities are defined in business terms, not technical terms.

4. Capabilities are stable, not volatile.

5. Capabilities are not redundant.

6. There is one capability map for a business.

7. Capabilities map to, but are not the same as, a line of business, business unit, business process, or value stream.

8. Capabilities have relationships to IT deployments and future-state IT architecture.

9. Automated capabilities are still business capabilities - not IT capabilities.

10. Capabilities are of most value when incorporated into a larger view of an enterprise’s ecosystem [26].

The first principle is a concise way to explain what a business capability is: what a company does, not how it does it. A capability could for example be ”Property management”

or ”Product development”. This definition can be compared to what a business process is:

linked procedures, collaborative activities, a series of executed steps to produce a deliverable - in essence how a company does something [25].

The second principle helps reinforce the first. By using nouns such as ”product management”, the difference between capabilities and processes or value streams is enhanced. The

1http://www.sparxsystems.com/

(13)

third principle makes it easier for people to understand a business capability map, even if they do not know many technical terms. Principle number four explains that capabilities rarely change within a company. How they are deployed might change, if for example a capability is automated, but entirely new capabilities usually only comes with changes to the business strategy or model. The fifth and sixth principles clarifies that capabilities exists only once on a map, even if it is realised at several places throughout the company, and that a company has only one capability map - no duplicate capabilities, and no duplicate maps.

A map can be decomposed into several parts, but it will still be only one capability map for the company. Principle number seven sets the capability apart from other concepts such as a process, line of business, or value stream, even if there can be similarities and correspon- dences these concepts are different abstractions of a business. The eighth principle explains that capabilities align directly to service-oriented architecture implementations, even if they may be manual. Principle number nine differs between an IT capability (a capability that the IT department has) and an automated capability (a capability implemented in an application). The tenth and last principle states that while a single capability might be good for planning and discussion, capabilities contribute the most to a company when mapped in an overall picture of the business [26].

Another explanation of what a capability is comes from the article Capability-based Busi- ness Model Transformation, where the authors describe a capability as ”the ability of an organisation to manage its resources to accomplish a task”, and says that an organisation exhibits a capability if it repeatedly can apply it [17].

[10] defines capability as ”the ability to employ resources to achieve some goal”, which is closely related to the definition used in TOGAF, the Open Group Architecture Framework, which states that a capability is ”an ability that an organisation, person, or system possesses”

[18].

MODAF has capabilities at its core, and describes a capability as ”a high level specifi- cation of the enterprise’s ability”, and adds that they do not change over time and as such can be specified even if the company does not have the capability at the moment [21].

There are several people who have investigated how to model capabilities when working with enterprise architecture [27],[12],[24], and who have also suggested that in a meta-model the capability should be connected to e.g. requirements, resources, values, services, products, roles, and processes. According to [24], a capability is ”an ability, capacity or potential that an organisation, person or system possesses”. Two examples of meta-models can be seen in figure 4.

(14)

Figure 4: Two examples of meta-models containing the (business) capability [12],[27].

In [12], seen to the left in figure 4, the author defines a Business Capability as ”the ability to execute a specified course of action, to achieve specific strategic goals and objectives”

and says that it is used to manage strategic business changes. He stresses that it is not the same thing as a Business Function, but that a capability encompasses many other elements such as Business Functions, Roles, Policies and Business Services. He connects the Business Capability to an Enterprise, a Business Value, a Product, a Business Service, and an unspecified MetaObject. [27] says that Capability could be added to ArchiMate as an aggregate of other objects from its core meta-model, and explains capability as ”the ability to produce results”. His suggested meta-model can be seen to the right in figure 4, and connects the Capability to a Product, an Artifact, a Function (be it Infrastructure, Application, or Business), a Business Process, a Node, an Application Component, and an Actor.

Working with Business Capabilities

In [17] a procedure for figuring out an organisation’s capabilities is described, where the authors suggest to start with the organisation’s ”main capability”, the capability that provides the organisation with customers. The resources needed for this main capability should then be listed, as well as the sub-capabilities needed to be able to provide those resources.

The process is then iterated for the sub-capabilities, until a desired level of abstraction is reached. This process is similar to the one in [26], but differs since it not only uses the business capabilities but includes resources as a complement as well. In [26] it is said that a decomposition down to three levels of capabilities is the most common way to work, and that using more than six levels is very uncommon but can be important when mapping business to IT architecture.

When it comes to the more widely used enterprise architecture frameworks and modelling languages, the implementations of capabilities differ. In ArchiMate 2.1² there is no exact implementation of the capability, however they suggest that their business processes or

2http://www.opengroup.org/subjectareas/enterprise/archimate

(15)

functions may be used instead [4]. There, the business process/function is connected to four entities beside itself: the business role, object, service, and event [4].

In [19], an extension to ArchiMate is proposed, with the capability connected to resources, requirements, and behavioural elements. This extension introduces resources and competences to ArchiMate, besides capabilities, and in [10] this extension is further analysed and named the Business Strategy and Valuation Concepts extension. In [19] the extension was used to align business strategy, enterprise architecture, and portfolio management.

The Swedish enterprise architecture consultancy firm IRM³ wrote about the Zachman framework in 2010, stating that even though the framework for a long time has been seen as the ”holy grail” when it comes to enterprise architecture, it is only one of several functioning models. It has its drawbacks, for example when it comes to modelling capabilities. When modelling a capability, it can be seen as a separate entity that can be analysed as an enterprise of its own, a simplification that would not be allowed within the Zachman framework [14].

Business Capabilities at Folksam

At Folksam, business capabilities were approached as a part of the work with their IT strategy. This strategy states that IT should be a support for Folksam when moving forward, be of help when coordinating important business areas, and enhance the long-term effects of advancements. To do this, they chose to start working with business capabilities, since they saw them as a way to plan strategies on a higher level, independently of what organisations or departments were involved. They state their purposes with business capabilities to be:

• Provide a coherent description of the company.

• Provide a foundation for setting goals and strategies for advancement.

• Be able to govern, measure, and do follow-ups of effects for central business areas, de- spite that the value-creating processes might be spread out over several organisations.

• Show the areas of the on-going projects and if they align with goals and strategies within the area.

• A synchronised way of analysing the scope of advancement initiatives.

They stress that it is important that the business capabilities are organisationally independent, so that it is possible to govern, measure, and follow-up regardless of responsibilities for e.g. processes or functions [16]. Since 2014, the Risk Managers at Folksam has used the Level 1 capabilities to structure their semi-annual risk reports, to in an easy way be able to show the company executives how the risks are spread over the company [9]. Today, the capabilities are also used for portfolio planning, and the capabilities on Level 2 are used to identify dependencies between projects.

At Folksam, they do not differ between ”Business Capabilities” and ”Capabilities”, and when starting the work with business capabilities, Folksam created something they called

”Capability cards”. These cards describe a capability and its implementation. They contain a description of the capability or area, and what goals, measurements, strategies, and business requirements are associated with it. They also describe its implementation, with processes, organisations, competences, and supplies of information. This card can also contain a rough estimate of how well the capability is working, shown by assigning it one of three colours: Red (Not working), Yellow (Improvements needed), or Greed (Working as it should) [16],[15].

Business capabilities were introduced at a local level at Folksam about five years ago, and two years ago on an enterprise level when the Enterprise Architects started developing a

3http://www.irm.se/

(16)

corporate capability map. In parallel with the research presented in this paper, a revision of the capability map at Folksam was carried out, and guidelines for how and when to use the capability concept were developed. A key part of these guidelines was to define a common capability meta-model.

3.4 Business Capabilities and Modelling within this Research

The definition of a business capability used within this research is the same definition as is used at Folksam, and it is the one provided by the Cutter Consortium [26] described in section 3.3. The key principle is that a capability is what a company does.

Since Folksam does not differ between ”Capabilities” and ”Business Capabilities”, this report will also use the words interchangeably.

The meta-model created in this report is a draft, and implementation of the actual meta- model was not a part of this research. The model drafts were made in Sparx Enterprise Architect, using UML structural class diagrams. The elements discussed in this report were modelled as classes, with relations and attributes.

(17)

4 METHOD

To answer the stated research question, data from several sources needed to be gathered, relating to the different aspects of the question.

• The meta-model

The meta-model drafts were made as drawings only, to identify what different elements and relations were needed for the final version. The meta-model could then later be implemented in Sparx EA⁴, the enterprise architecture tool used at Folksam.

• The business capabilities

Folksam started working with capabilities on an enterprise level about two years ago, developing a joint enterprise map. The Enterprise Architects have learnt a lot about the capabilities of the company and in which areas it could be relevant to use the business capability concept. Right now, they are revising their business capability map, and within the research in this paper, the capabilities were analysed on a more abstract and general level, which is why there was no need to delve deeper into the actual business capabilities at Folksam.

• The stakeholders

The main stakeholders of this research are the Enterprise Architects working with business capabilities at Folksam. These Enterprise Architects, and mainly the Enterprise Architect Team Leader, were consulted in the process of identifying other stakeholders that had some insight into the work with business capabilities. Some previous insight into the matter was needed, since the work with business capabilities within Folksam is still in progress and not everyone is affected by it as of today.

• The expectations and requirements

As of today, Folksam had already connected metrics to the business capabilities. To make the model complete they wished to survey what other features the stakeholders wanted to connect, and then implement this into a meta-model. This survey was done through interviews with the stakeholders.

• The thoughts on capability health status

Folksam previously had ”capability cards” showing the health status of a capability.

To be able to make these cards, and the meta-model, more relevant the respondents were asked about their thoughts on the health status of a capability, and what could affect it.

The data gathering was divided into several steps, focusing on interviews with the stakeholders at Folksam. These interviews were the basis for the meta-model of the business capability and the elements connected to it.

4.1 Step 1 - Initial Interviews

The first step was to interview the stakeholders at Folksam. The stakeholders were identified with the help of the Enterprise Architect team leader at Folksam’s Enterprise Architecture Department. The stakeholders were asked about their attitude towards the business capability concept and the use of it. Would they like to use them and, if so, how? What would they like to be able to connect to the capabilities (e.g. projects, requirements, or people)?

The interviews were recorded (with permission from the respondents) and the answers transcribed. Since Folksam is a Swedish company and all the interviewed stakeholders, as well as the author, have Swedish as their native language, the interviews were held in Swedish. The transcribed answers are therefore in Swedish as well. However, summaries,

4http://www.sparxsystems.com/products/ea/

(18)

quotes, and other excerpts from the interviews used in this report are translated to English.

The transcribed answers can be found in their entirety in the appendix, section A.1. This procedure was the same for all interviews held during this project.

The questions in table 1 were used in this first set of interviews, to help with the first part of the main objective, to create a meta-model for Folksam’s business capabilities, meeting the expectations and fulfilling the requirements set by the stakeholders In table 1 the questions are listed along with possible answers and what the answers could be used for in the analysis.

The first five questions considered the background of the respondent, and their knowledge and involvement in the work with business capabilities. These were mainly used for further analysis, for example to see if what elements a respondent wanted to connect to the capability differed with their background or their position. The last five questions concerned the business capability and what the respondent thought it could be used for, and how. These were mainly used to construct the meta-model. The question numbers Q1.1 to Q1.10 are used when referring to the different questions.

The elements listed as suggestions in Q1.8 are selected from the literature presented in section 3.3 as elements that might be relevant for the respondents, but also might be difficult for the respondents to suggest on their own (in Q1.7).

Table 1: The questions used during the first set of interviews with stakeholders at Folksam, along with possible answers, and what the answers were used for.

No. Question Possible answers Why is it asked?

Q1.1 What is your position, and how long have you been working at Folk- sam?

Business architect, IT strategist, since 2010.

To see if later answers differ between positions or time employed.

Q1.2 In short, what do you know about business capabilities?

What a company does or other specifications from the Cutter Con- sortium list of principles. If they have worked with capabilities at Folksam.

How do answers to later questions differ between people with different knowledge levels? (Will people with a more ”correct” view of what a capability is give answers that are more “correct”?) Q1.3 For how long have you

been working with (the concept of) business capabilities?

Time spans between some months and a couple of years.

To see if they have famil- iarised themselves with the concept of business capabilities for a while, or if they have seen it for the first time recently.

Q1.4 How did you first come across the concept of business capabilities?

Presented by architects, to use for analysis, in a project.

To see what manner it was introduced in, and what it was supposed to be used for, if anything.

Q1.5 Have you used business capabilities, and, if so, how?

No, for analysis, in a project.

To see what capabilities have been used for and what is needed in the meta-model in order to show this.

Q1.6 What applications can you see for the business capabilities? For yourself/your department/the company/a project.

Support when planning projects, identify flaws in process chain, manage external requirements.

To learn what they want to use the capabilities for, and to get some ideas about what could be connected to the capability in the meta-model.

(19)

Table 1: The questions used during the first set of interviews with stakeholders at Folksam, along with possible answers, and what the answers were used for.

Q1.7 To achieve this application, what elements would you like to be able to connect to a business capability?

Requirements, roles, projects, strategies.

To find elements to connect to the capability in the meta- model, according to the respondent’s own suggestions, and to see if they match the elements from the literature.

Q1.8 Which, of the following would you like to be able to connect to a business capability?

• Requirement

• Resource

• Role

• Service

• Event

Zero to all of these stated elements.

To find elements to connect to the meta-model, based on the literature.

Q1.9 Why would you like to connect these specific elements, and when do you think it would be useful?

For easy structuring of projects, when testing compliance.

Find out about the elements and attributes they could have, why they are useful, and what the relations to the capability could be called Q1.10 How do you think the

elements would affect the capability, or be affected by it, if changes occur?

Make it better/worse, increase/decrease capacity.

To help identify what the relations should be, and how the elements and relations should be structured.

4.2 Step 2 - Meta-Model Creation

With the aid of the answers from the first set of interviews, a meta-model draft was created. The meta-model was centred on the business capability. The elements added to the meta-model were the ones suggested and mentioned by the interview respondents. When a respondent described a relation between the capability and an element, that relation was added as well. If no such relation was described, a possible relation was found by searching the literature, or with the help of the Enterprise Architect Team Leader.

4.3 Step 3 - Meta-Model Evaluation

The meta-model draft was sent back to the interview respondents, along with a request for feedback. The respondents were sent a questionnaire via Google Forms⁵ where they were asked to mark all elements as relevant or not, for them in their own work. They also got another set of questions to be answered, either in an interview or via email. These questions, seen in table 2, pertained to the performance and well being of a business capability, and how the respondents felt that it was affected by the different elements connected to it.

This considered the second part of the main objective, to modify the meta-model so that

5https://www.google.com/forms/about/

(20)

it encompasses the stakeholders’ views on business capability health status. As with the previous interviews, transcripts of the interviews can be found in the appendix, section A.2.

Table 2: Questions asked to the respondents in order to find out what they think makes a business capability perform well or not, and how it could be affected by other elements.

Q2.1 How can you tell if a capability is performing well or not?

Connected processes run smoothly, output is correct.

Establishes respondents

”ideal capability”, if needed for future reference.

Q2.2 What do you think affects the well being of a capability the most?

Up time of supporting systems.

Get a notion of which elements could be involved and connected.

Q2.3 What attributes of the capability affects the well being and performance of it the most?

Information quality. Find attributes of the capability that could be affected.

Q2.4 Which of the elements connected to the capability do you think affect its well being and performance the most?

Requirements, Pro- cesses.

To know which elements should be connected to the capability.

Q2.5 What attributes of these elements do you think affect the capability, and which attributes of the capability do you think they affect?

Up time of service affects quality of capability information.

Find out which attributes should connect element and capability.

4.4 Step 4 - Meta-Model Editing and Finalisation

To optimise the meta-model, all elements that had been marked as not relevant by all of the respondents were to be removed, since the goal of this project was to create a meta- model relevant to the respondents. Elements not mentioned or described as affecting the capability and its health status were also removed, since the meta-model should encompass the stakeholders’ views on capability health status. When this was done, the remaining elements and their connections to the capability were modelled according to the answers and descriptions gained from the second set of interviews.

(21)

5 DATA

The data gathered in the four separate steps described in sections 4.1 to 4.4 is presented in the corresponding sections below.

5.1 Step 1 - Initial Interviews

Seventeen people were approached about interviews by the Enterprise Architect Team Leader, and twelve agreed to participate. In table 3 the participants’ occupations can be found, as well as how long they have been working at Folksam, and when they first came across the concept of business capabilities (the answers to Q1.1 and Q1.3).

Table 3: The occupations of the interview respondents as well as how long they have worked at Folksam and when they started working with capabilities.

Respondent ID Occupation At Folksam since Saw capabilities in

Respondent 1 Business Architect 2015 2010-2011

Respondent 2 Business Architect 2002 2013

Respondent 3 Business Architect 2013 Middle of 2013

Respondent 4 Risk Manager 2013 2013

Respondent 5 Risk Manager 2013 Middle of 2013

Respondent 6 Business Developer 2001 2012-2013

Respondent 7 Business Architect 2014 2000

Respondent 8 Business Developer 2000 2011

Respondent 9 Business Developer 2009 Middle of 2013

Respondent 10 Governance Specialist 1979 2010-2011

Respondent 11 IT Strategist 2015 2015

Respondent 12 Business Architect 2003 2011-2012

When asked to describe what they knew about capabilities, in short (Q1.2), some of the respondents were more familiar with the definition of a capability than others. Respondents 2, 3, 4, 6, 8, 11, and 12 in some way stated that a capability was what a business does, not how it does it. Respondents 1, 2, and 8 said that it was a good tool in discussions with e.g.

stakeholders, presenting a view of the whole rather than details, which made it easier for everyone to understand. Respondents 3, 5, 7 and 10 had used capabilities when mapping a business and e.g. its projects, risks, requirements, and systems. Respondent 4 thought that capabilities was a natural next step from modelling processes, and respondents 6, 8, and 9 thought capabilities to be a good way to visualise the company, and set the scope of projects while seeing which parts of the company will be affected by it.

How the respondents came across the capability concept differs (the answers to Q1.4), but respondents 3, 4, 5, 6, and 8 said that it was introduced to them by the Enterprise Architect Team Leader at Folksam. Respondents 1 and 12 discovered capabilities at their previous workplaces, when trying to describe what the companies did, and respondent 11 got an introduction to capabilities along with the introduction to Folksam when they started working there. Respondent 2 felt that processes were an out-dated way of describing a company, and discovered that capabilities were more in line with what they needed, whereas respondent 7 found that capabilities were useful when setting requirements for a proposal.

Respondent 9 was introduced to capabilities by a Business Developer colleague that had taken a course in enterprise architecture, and respondent 10 learnt it from the Enterprise Architects when they together were working with information security and immaterial assets.

The answers to Q1.7 and Q1.8 (about which elements the respondents would like to connect to the capability) were summarised in table 4 that was then used in the next step to create a draft of the meta-model.

(22)

Table 4: Elements that the interview respondents suggested to connect to the capability, which respondents suggested which elements, and how many respondents suggested each element. Elements marked with * were those suggested to the respondents in Q1.8, and x (a bold x) marks an element that was mentioned by the respondent in the answers to both questions Q1.7 and Q1.8.

Respondent no. 1 2 3 4 5 6 7 8 9 10 11 12 SUM

Application x x 2

Competence x x x 3

Cost x 1

Distribution Channel x 1

Event* x x x x x x x 7

Goal x 1

Health Status x 1

Information x x x x x 5

Input/Output x x 2

IT Support x x x 3

KPI x 1

Law/Rule/Policy x 1

Organisation x x x x x x 6

Process x x x x x x x x x x x 11

Requirement* x x x x x x x x x x x 11

Resource* x x x x x x x x x x 10

Risk x x 2

Role* x x x x x x x x x x 10

Screening x 1

Service* x x x x x x x 7

System x x x x x x x 7

Value Tree x 1

Regarding the elements, the respondents also got to answer why they wanted to connect the specific elements that they mentioned (Q1.9) and if they had any thoughts on if the elements affected the capability in some way, or if it was the other way around (Q1.10). The answers to these questions can be found in table 5.

Table 5: The answers to the interview questions Why would you like to connect these elements, and when would it be useful? (Q1.9) and How do you think these elements would affect the capability, or be affected by it, when changes occur? (Q1.10).

Resp. ID Answer to Q1.9 Answer to Q1.10

1 Capabilities with these elements connected is one important piece of the puzzle when measuring change.

The elements support the capability, but they both affect each other.

2 To describe ”What kind of business are we running?”, and to see who is responsible for what.

The elements support the capability, so rather that a good process con- tributes to a good capability, than the other way around.

3 To get a structured view of the whole company. It feels like an approach that should actually manage to finish a company-wide map.

The elements affect the capability, at least in most cases.

(23)

Table 5: The answers to the interview questions Why would you like to connect these elements, and when would it be useful? (Q1.9) and How do you think these elements would affect the capability, or be affected by it, when changes occur? (Q1.10).

4 When working with changes or when mapping the organisation.

To find where there are risks and what they are associated with.

The elements affect the capability.

The capability is a framework for the elements.

5 Important when working with changes, or optimisation.

More that the elements affect the capability, but the whole concept feels a bit abstract.

6 When you are looking at the business development process, or are in need of moving certain parts of the business somewhere else.

It could go both ways, it depends on a lot of variables. Has no clear answer to the question.

7 To be able to relate the capabilities to something, so that other people in the organisation do not deem them as too abstract.

The capability consists of the elements, it is a container for everything else, to remove the need of get- ting overly complex.

8 Useful in all sorts of resource and competence planning.

It could be both ways. When pur- chasing an IT solution, the capability is affected by the chosen solution.

On the other hand, there are criti- cal capabilities that affect whatever is inside them, such as company specific questions.

9 Good when analysing requirements, and for projects. Hard to connect it to the actual enterprise at some points, though.

The capability should be affected by other things, and it needs to adapt to what we want to do.

10 To improve the ability to govern and control, through finding out which elements connect.

If you control a capability by exam- ining the connected elements, that capability controlling will affect the elements.

11 In general, it increases your understanding of the business and why it works or not.

It depends. There is probably an as- pect of time or culture as well, which affects the other might depend on what was the point of origin, if it was the capability or e.g. a process.

12 To analyse. Knowing rules

is needed when performing changes, so you know which capabilities they affect, for example.

The capability does not change, but how it is implemented might. As long as you are not changing your business model, the other elements might change, but not the capability.

From this first set of interviews information was also gathered on what the respondents have used the business capabilities for, and if they could see any other areas where they could be useful. The answers to these questions (Q1.5-6) can be seen in table 6.

(24)

Table 6: The respondents’ answers to the questions ”Have you used the business capabilities, and, if so, how?” (Q1.5) and ”What other applications can you see for the business capabilities?” (Q1.6).

1 To map different models to one single concept, for easier analysis, for quality assurance, and to ensure that projects have the right scope.

To see the whole, and compare projects and investments. Not to measure the capabilities.

2 To describe responsibilities within the Economics area. Also trying to describe ”How well is a capability working?” by assessing the status of elements connected to it.

Almost anything you want. It is a good, neutral way to describe a company and its business.

3 When analysing new projects or initiatives, looking at which capabilities will be affected. Also to compare projects and see how the affected capabilities differ.

When needing an overview of your work, to compare departments, or looking to increase efficiency. Es- sentially, whenever working with changes or improvements.

4 To describe the business without the need for process responsibility, and to structure a risk report.

To easily find which capabilities are not performing well, and which people have some kind of responsibility for the capability and its performance. Also to see where we are performing changes.

5 For structuring the risk reports, since the last two reports.

When working with changes and IT improvements.

6 When analysing large campaigns, to see what will be affected.

Assessing how hard or complex a campaign could be. To prioritise the steps needed to maximise the outcome with regards to the resources used.

7 Mainly when mapping a business or an organisation, to find out how to organise in an efficient way, or find out how a new strategy affects the company.

Capabilities are used very widely at Folksam, but it would be nice to use it in an agile method in a better way.

8 To find which capabilities are within the scope of a project, and to find changes needed to be done to achieve a strategy or a goal.

State what an organisation does, which organisation is responsible for what. Can be used for practically anything.

9 To see which capabilities you are responsible for, how they perform, and if they can be improved. To map your own organisation.

For projects and organisations, to see what needs to be done and what is known at the moment. To see how the capabilities map to other things, and why they perform well or not.

10 When building a governance system, and seeing the connections between secure information processing, information assets, and capabilities.

When mapping risks.

Practically everything. Control and follow-up to be able to reach goals, so that it in the end can correlate with the economic follow-ups.

(25)

11 When determining the goals for our application park, since it is supposed to support the capabilities.

Map to Organisations and Systems, to understand what needs to be done e.g. to perform changes. Also good to understand which capabilities are ”yours”, and where they are and what they do.

12 To simplify when working with processes, finding out where something is affected without going through all activity flows. To identify where controls are needed when performing changes.

To identify responsibilities, and when planning initiatives.

5.2 Step 2 - Meta-Model Creation

Diagram Report Page: 4

Förmågetest 1 diagram

Class diagram in package 'Förmågetest'

Förmågetest 1 Version 1.0 FSBE25 created on 2015-07-15. Last modified 2015-07-15

Process Organisation

Resource

System

Requirement Role

Service

Event

Information

Risk

KPI IT Support

Competence

Application

Value tree Cost

Distribution Channel

Goal

Health Status

Capability

Input/Output

Law/Rule/Policy

Screening

Förmågetest 1 Figure 4:

Figure 5: The meta-model draft based on the first set of interviews.

Using the answers aggregated in table 4 as a starting point, a meta-model draft was created, see figure 5. This meta-model was centred on the business capability (here: Capa- bility), and contained all the elements suggested in the interviews. At this stage, however, it did not contain any descriptions of the relations between the elements. The draft was

(26)

then presented to the Enterprise Architect Team Leader, and edited according to her comments. The comments resulted in the following changes: the suggested elements ”Goal” and

”Health Status” were seen as attributes of the Capability rather than separate elements, and were therefore modelled in that way. Law, Rule and Policy were split up into separate elements considered specialisations of the Requirement element, and Input/Output was also split into separate elements. Distribution Channel and Screening were both removed, since they were considered capabilities of their own, rather than elements liked to one [15]. The final draft in this step can be seen in figure 6

Förmågetest diagram

Förmågetest Version 1.0 FSBE25 created on 2015-04-23. Last modified 2015-05-08

Capability - G oal: int - Health Status: int

Process Organisation

Resource

System

Requirement Role

Service

Event Information

Risk

Input

KPI IT Support

Competence

Application

Value tree

Output

Rule Law Policy

Cost

Förmågetest Figure 3:

Figure 6: The first meta-model draft, based on the initial interviews and edited according to comments from the Enterprise Architect Team Leader.

The relations between the elements were modelled as described by the respondents, as found in the literature, or as discussed with the Enterprise Architects at Folksam. The relations can be found in table 7.

(27)

Table 7: The relations between the different elements in the meta-model draft.

Element Relation to Element

Capability supports Application Capability isSupportedBy Application

Capability needs Competence

Capability isInitialisedBy Event Capability isSupportedBy IT Support

Capability uses Information

Capability uses Input

Capability isMeasuredBy KPI

Capability delivers Output

Capability isRealisedBy Process Capability isConstrictedBy Requirement

Capability needs Resource

Capability isAssociatedWith Risk Capability contributesTo Service Capability isSupportedBy System Capability contributesTo Value Tree Cost isSpecialisationOf KPI Event isAssociatedWith Process

Event has Risk

IT Support is Resource

Information is Resource

Role is Resource

Role isResponsibleFor Capability

Role has Competence

Role belongsTo Organisation

Output dependsOn Input

Law isSpecialisationOf Requirement Policy isSpecialisationOf Requirement Rule isSpecialisationOf Requirement

Organisation has Competence

Organisation isResponsibleFor Capability

5.3 Step 3 - Meta-Model Evaluation

The meta-model draft was sent to the interview respondents, along with a questionnaire that asked them to rate each element and attribute as ”Relevant” or ”Not relevant”. The answers to this questionnaire can be seen in table 8, where elements chosen as ”Relevant”

are marked with an ”x”. Unmarked elements were those chosen as ”Not relevant”. As can be inferred from table 8, respondent 8 did not complete the questionnaire, and as a result, their column was left blank. Below are listed the definitions for the different elements that were used in the questionnaire. The last two in the list, Goal and Health Status, are attributes of the Capability element rather than elements of their own, as illustrated in figure 6.

• Application (supported) An application that is supported by the capability.

• Application (supporting) An application that supports the capability and aids in its realisation.

• Competence The competence needed to perform the capability.

• Cost The costs associated with the capability.

(28)

• Event An event that will trigger the capability.

• Information The information that is needed for the capability to be able to function.

• Input What the capability uses to deliver an Output.

• IT Support The IT Support that is needed for the capability to function.

• KPI Key Performance Indicators, measurable values and variables associated with a capability.

• Law A specific kind of requirement.

• Organisation The organisation that is responsible for the capability and its realisation.

• Output The output delivered by the capability.

• Policy A specific kind of requirement.

• Process One or several processes that realise the capability.

• Requirement A requirement that limits the capability or steers it in a certain direc- tion.

• Resource What is needed for the capability to function. Can be e.g. money, competence, or information.

• Risk A risk associated with the capability. Compare to how the Risk Report has been structured based on capabilities.

• Role The role that has main responsibility for the capability and its realisation.

• Rule A specific kind of requirement.

• Service A service that the capability aids in delivering.

• System A system that helps to perform and realise the capability.

• Value Tree Shows which of Folksam’s main values the capability is related to.

• Goal (Attribute) What should or will the capability be like in the future, compared to today?

• Health Status (Attribute) How well is the capability? Does it function as it should?

(29)

Table 8: The elements marked as ”Relevant” by the different respondents, and a summary of how many respondents thought each element was relevant. The last two rows are Capa- bility element attributes rather than elements of their own, and the column for respondent 8 is intentionally left blank, since they did not complete the questionnaire.

Respondent ID 1 2 3 4 5 6 7 8 9 10 11 12 SUM

Application (supported) x 1

Application (supporting) x x x x x x x x x 9

Competence x x x x x x x x x 9

Cost x x x x x x x x 8

Event x x x x x 5

Information x x x x x x x x x x 10

Input x x x x x x 6

IT Support x x x x x x x x x 9

KPI x x x x x x x x 8

Law x x x x x x 6

Organisation x x x x x x x 7

Output x x x x x x x 7

Policy x x x x x x 6

Process x x x x x x x x x x x 11

Requirement x x x x x x x x 8

Resource x x x x x x x 7

Risk x x x x x x x 7

Role x x x x x x 6

Rule x x x x x 5

Service x x x x x x x 7

System x x x x x x x x x x 10

Value Tree x x x x x x x x x x x 11

Goal x x x x x x x x x 9

Health Status x x x x x x x x x x 10

Questionnaire Comments

Some of the respondents had comments to the questionnaire, most of them pertaining to the definitions of the elements and what they thought about them. Respondent 4 said that they had a hard time relating to the concepts, and hence marked most of the elements as

”Relevant”, whereas Respondent 5 thought that since they saw capabilities as organisation independent, all elements that were organisation dependent should be marked ”Not Rele- vant”. Respondent 1 had several comments, and thought that elements such as Information, Cost, KPI, Risk, Requirement and Resource should be connected to the Processes or Sys- tems that were connected to the capability, rather than to the Capability element, and in that case they would be relevant. This respondent also stated that Organisation and Role would be relevant if it were the ones supporting the capability, instead of the ones being responsible for it, since there can be no single entity responsible for a capability. They also said that they did not think that Resources could be allocated in that way, and that Goals only would be relevant if broken down to a lower level. Respondent 12 thought that Application and System as well as IT Support were similar, and that it therefore was hard to say which ones could be relevant or not. They also thought that a distinction was needed between Resource and the different elements connected to it, such as Role, Information, or Competence, and that Law was an external Requirement, whereas Rule and Policy were internal. Furthermore, they said that they did not like the concept of Goal and Health Status, and would prefer to instead look at analysis areas.

(30)

Follow-Up Interviews

The follow-up interviews with the questions from table 2 were conducted with 8 of the original 12 respondents, one of who chose to answer via email. Their thoughts and opinions about what and which elements might affect the well being and performance of a capability (the capability’s health status) can be found below, and a summary of these elements can be found in table 9.

Respondent 1 The first respondent thought that there was no element in particular that could be said to always affect the well being of a capability. They say that it might be possible to say in specific cases, but that it would take more information on how each element and capability is defined. They would check the performance of a capability by looking at all the different parts that connect to the capability and see how they perform and cooperate. Relating element attributes to the well being of a capability is something they personally do not do, but think it could probably be done, even if they cannot see any gains from it.

Respondent 2 Could not be reached for a second interview.

Respondent 3 Respondent 3 thinks that the well being of a capability would be affected by several things, but says that what they can use to measure it today is the current state and the business requirements of a capability. Organisation and Competence are key elements to measure it in the future, but they cannot say anything about element attributes that might affect it.

Respondent 5 The well being and performance of a capability could be measured by setting goals for it and see how well it reaches them, says the fifth respondent. Processes and Resources are the elements that affect it the most, and it is important to have a set Goal to work towards. The governance model is also important. As for element attributes that might affect a capability and its performance, they cannot say.

Respondent 6 - answered via email Says that to measure the well being of a capability you have to accumulate values for its performance and its importance to the business. It could be decreased by e.g. long lead times, faulty results, or lack of resources, and the deficiencies would be rated differently depending on the importance of the capability. They have no opinion about element attributes that might affect a capability.

Respondent 7 Respondent number seven thinks that establishing good KPIs that show what goal you have is a good way to measure the performance of a capability. They also say that the governance model will affect they way the capability functions, and therefore its performance as well, since it will play an important role for e.g. the structure of the organisation, the requirements set, or which systems you connect. Flaws in supporting systems and repeated parts of processes they say decrease the well being of a capability, something duplicate systems do as well.

(31)

Respondent 10 Thinks using KPIs to measure the capability is key when understanding its performance and well being, as well as that the concept of capabilities needs to be accepted throughout the company for it to perform well at all. Organisations with a clear structure are important for a healthy capability, as well as KPIs to measure it, but they have no opinion on element attributes and if they might affect a capability.

Respondent 11 To measure the performance of a capability, they say that one needs to measure connected elements and see if they perform well according to measurements.

Their suggested elements to measure are Information, Process, Organisation, IT Support, System, and supporting Applications. They cannot say anything about element attributes that might affect a capability, but think it is important that the people who work with it feel that the capability is performing well, and that they get the support they need.

Respondent 12 She thinks that what affects the well being of a capability depends on how you define ”well being” and what is good or not, but that nonetheless Rules and Processes are important for its performance, as well as measuring the processes connected to the capability. Outer and inner Requirements are attributes that would affect the capability, and how easy the capability is to implement would also affect its performance. They think that Competence and knowledge about the capability is key for its well being.

Table 9: A summary of which elements the different respondents thought might affect the well being of a capability.

Respondent ID Suggested elements

1 Process, System

3 Competence, Organisation, Requirement

5 Goal, Process, Resource

6 Resource

7 Goal, KPI

10 KPI, Organisation

11 Application (supporting), Information, IT Support, Organisation, Process, System

12 Process, Requirement, Rule

5.4 Step 4 - Meta-Model Editing and Finalisation

As can be seen in table 8, no element or attribute was chosen as ”Not relevant” by all of the respondents. Hence, nothing was removed from the meta-model for that reason. However, the elements not described by the respondents as affecting the capability and its performance and well being, i.e. the elements not appearing in table 9, were removed.

In parallel with this research, the Enterprise Architects at Folksam worked with defining the names and terms that should be used when working with the enterprise architecture.

They decided that the term ”Application” should be used in the cases that previously in this report have been called ”Application”, ”IT Support”, and ”System”. Hence, those three elements were combined into one element called ”Application”.

All these changes resulted in the meta-model that can be seen in figure 7.

(32)

Förmågemodell2 diagram

Förmågemodell2 Version 1.0 FSBE25 created on 2015-07-16. Last modified 2015-07-16

Capability - Goal: int - Health Status: int

P rocess

Requirement

Organisation

Competence

Resource Application

Information Rule

KPI

Förmågemodell2 Figure 2:

Figure 7: The meta-model after the removal process described in section 5.4.

As in the meta-model draft, the relations are defined as described by the respondents, as found in the literature, or as discussed with the Enterprise Architects at Folksam. The relations for the final meta-model can be found in table 10

Table 10: The relations between the elements in the final meta-model.

Element Relation to Element

Application supports Capability Competence isNeededBy Capability Competence belongsTo Organisation Information isUsedBy Capability

Information is Resource

KPI measures Capability

Organisation isResponsibleFor Capability

Process realises Capability

Requirement constricts Capability Requirement hasSpecialisation Rule Resource isNeededBy Capability

Modelling Business Capabilities with Enterprise Architecture

Modelling Business Capabilities with

Enterprise Architecture

SOFIA BERGSTR ¨ OM

Master’s Degree Project

Stockholm, Sweden September 2015

Modelling Business Capabilities with

Enterprise Architecture

A Case Study at a Swedish Pension Managing

Company

Table of Contents

1 INTRODUCTION

1.1 Folksam

2 MAIN OBJECTIVE

2.1 Scope

2.2 Delimitations

3 THEORY

3.1 Enterprise Architecture

3.2 Enterprise Architecture Modelling

3.3 Business Capabilities

3.4 Business Capabilities and Modelling within this Research

4 METHOD

4.1 Step 1 - Initial Interviews

4.2 Step 2 - Meta-Model Creation

4.3 Step 3 - Meta-Model Evaluation

4.4 Step 4 - Meta-Model Editing and Finalisation

5 DATA

5.1 Step 1 - Initial Interviews

5.2 Step 2 - Meta-Model Creation

Förmågetest 1 diagram

Förmågetest diagram

5.3 Step 3 - Meta-Model Evaluation

5.4 Step 4 - Meta-Model Editing and Finalisation

Förmågemodell2 diagram