Aligning COBIT with Enterprise

Architecture
A comparison between COBIT 2019 and TOGAF Version 9.2
Word count: 20,116

Eline Van Parijs

Student number: 01705302

Supervisor: Prof. Dr. Geert Poels

A dissertation submitted to Ghent University in partial fulfilment of the requirements for the degree of
Master of Management & IT

Academic year: 2021 - 2022

Abstract
“In the light of digital transformation, information and technology (I&T) have become
crucial in the support, sustainability and growth of enterprises”, ISACA (2018).
The management of IT guarantees the optimal utilization of IT resources within an
organization, and since the role of IT becomes more eminent, IT management
frameworks become more demanding (Samiei & Habibi, 2022).
The IT management in organizations is one of the drivers of the formation of the
COBIT 2019 framework (ISACA, 2018). Thereby, Enterprise Architecture
Frameworks (EAF) offer companies an efficient technique to manage their IT
systems aligning business requirements with effective solutions (Havaluddin, 2012).
To improve business efficiency, the world’s leading organizations use the TOGAF
Standard of The Open Group as proven Enterprise Architecture (EA) framework and
methodology (The Open Group, 2018).
In order for enterprises to reduce costs and effort when implementing those
concepts, this dissertation displays the (dis)similarities between COBIT 2019 and
TOGAF Version 9.2 so the overlap would become clear. To align COBIT with EA,
COBIT is thus chosen as framework to represent the IT governance within an
enterprise and TOGAF to represent the EA. The research is divided into three parts:
first comparisons are gathered from existing literature through WoS, SCOPUS and
Google Scholar. Then, a high-level comparison is made up by creating a concept
map for TOGAF Version 9.2 to compare its structure with that of COBIT 2019. Lastly,
a detailed comparison was made between COBIT objectives and TOGAF ADM
phases.
The research revealed that COBIT represents the most complete IT governance
reference and its principles provide several advantages, but the main disadvantage
remains the difficulty of implementation and its high cost. TOGAF on the other hand
provides better product quality and is the most capable framework regarding a gap
analysis, but its drawback is that it does not cover management processes and its
contributions are not integrated enough.
The conclusion was drawn that both frameworks maximize the IT value creation
within an enterprise, use capability and maturity models, aim to establish consistent
content, but neither of them fulfills all business and security requirements.

I
Although the COBIT management objective ‘Managed EA’ embodies nearly all ADM
phases of TOGAF, it lacks a value stream mapping, a common Repository and a
document Lessons Learned, whereas TOGAF lacks a tailoring system and a concept
around ethics, culture and behavior. Those are only a few examples of suggestions
for future research, with the ultimate goal to eventually create a mapping between
COBIT 2019 and TOGAF 9.2.

II
Preface
Reading the title of this dissertation “Aligning COBIT with Enterprise Architecture”
during Covid period, one might think a spelling error slipped into the phrase. But
nothing could be further from the truth. It states indeed COBIT and not Covid. Even
though when writing this dissertation, we are currently still living under pandemic
circumstances. This paper is, inter alia, about COBIT (20)19 and not about Covid-19.
But speaking of, it might be interesting for the reader to draw a little context. I should
mention that the Covid-19 virus continues to take over our daily lives, influencing the
social context in which this dissertation was created. Normally, students follow their
classes in an actual classroom, do research together, ask information to professors
in real time, go to the library to check a specific book or paper. Now we have been
following classes online for the past two years, doing research on our own at home
because of quarantines or lockdowns, obliged to schedule online meetings with
professors or to reserve a timeslot to be able to go to the library.

In spite of these extraordinary times, I am thankful for all that we accomplished.

Grateful for having the best family who offers me a warm home and gives me all the
support that I need. Grateful to be able to study at a high-listed university, that offers
a solid education and guidance in kicking off to the “real adult world”. Grateful for the
support of professor Geert Poels, who has given me great feedback and guidance
throughout the development of this dissertation.

In this dissertation, I will not explain every component of COBIT nor every
component of TOGAF in detail. For that I refer to the extended documentation of
ISACA regarding the COBIT framework and to the extended documentation of The
Open Group regarding the TOGAF Standard.

De Pinte, augustus 2022

Eline Van Parijs

III
Table of Contents
Inhoudsopgave
Abstract.................................................................................................................................. I
Preface ................................................................................................................................ III
Table of Contents................................................................................................................. IV
List of used abbreviations ..................................................................................................... V
List of figures ...................................................................................................................... VII
List of tables ....................................................................................................................... VIII
Intro ...................................................................................................................................... 1
Context .............................................................................................................................. 1
Problem definition .............................................................................................................. 1
Research question............................................................................................................. 2
Relevancy ......................................................................................................................... 3
Structure............................................................................................................................ 3
Background........................................................................................................................... 4
Enterprise Governance of IT.............................................................................................. 4
COBIT............................................................................................................................ 5
The use of COBIT ...................................................................................................... 5
The COBIT Core Model .............................................................................................. 6
COBIT 2019 ............................................................................................................... 7
Enterprise Architecture .................................................................................................... 19
TOGAF ........................................................................................................................ 21
The use of TOGAF ................................................................................................... 21
The TOGAF Standard .............................................................................................. 21
TOGAF Version 9.2 .................................................................................................. 23
Comparison COBIT 2019 and TOGAF 9.2 .......................................................................... 46
Methodology .................................................................................................................... 46
Part 1: Literature review .................................................................................................. 46
Part 2: High-level comparison .......................................................................................... 55
Part 3: Detailed comparison ............................................................................................ 63
Limitations & suggestions ................................................................................................ 72
Conclusions ........................................................................................................................ 74
References ........................................................................................................................... X

IV
List of used abbreviations

RQ Research Question

COBIT Control Objectives for Information and

Related Technologies

EA Enterprise Architecture

ISACA Information Systems Audit and Control

Association

IS Information System

IT Information Technology

I&T Information & Technology

EDM Evaluate, Direct and Monitor

APO Align, Plan and Organize

DSS Deliver, Service and Support

MEA Monitor, Evaluate and Assess

BAI Build, Acquire and Implement

EGIT Enterprise Governance of IT

TOGAF The Open Group Architecture

Framework

CPM COBIT Performance Management

CMMI Capability Maturity Model Integration

CPL Process Capability Level

EAF Enterprise Architecture Framework

ABB
Architecture Building Blocks
SBB
Solution Building Blocks

V
ADM
Architecture Development Method
ABB
Architecture Building Block
RFC
Request for Change

WoS Web of Science

NIST US National Institute of Standards and

Technology

VI
List of figures

Figure 1: The context of EGIT ............................................................................................... 4

Figure 2: COBIT Core Model ................................................................................................. 7
Figure 2: COBIT 2019 overview ............................................................................................ 8
Figure 4: Key concepts of COBIT 2019 ................................................................................. 9
Figure 5: COBIT Goals Cascade ......................................................................................... 10
Figure 6: Governance and management domains in COBIT 2019 ....................................... 11
Figure 7: Structure of the objectives in COBIT 2019 ............................................................ 12
Figure 8: COBIT components of an objective/governance system ....................................... 13
Figure 9: Design process for a governance system in COBIT.............................................. 14
Figure 10: Design factors in COBIT 2019 ............................................................................ 15
Figure 11: Impact of design factors on a governance and management system .................. 16
Figure 12: Capability levels for processes in COBIT ............................................................ 17
Figure 13: Maturity levels for focus areas in COBIT ............................................................. 18
Figure 14: Structure and content of the TOGAF Standard ................................................... 24
Figure 15: The ADM cycle of TOGAF .................................................................................. 27
Figure 16: Relationship between deliverables, artifacts and building blocks in TOGAF ....... 41
Figure 17: The content metamodel of TOGAF ..................................................................... 42
Figure 18: An overall structure for the Architecture Capability Framework of TOGAF .......... 45
Figure 19a: Concept map of COBIT 2019............................................................................ 57
Figure 19b: Concept map of COBIT 2019............................................................................ 58
Figure 20: Concept map of TOGAF 9.2 ............................................................................... 59

VII
List of tables

Table 1: COBIT and TOGAF search queries (literature review) ........................................... 47

Table 2: Comparison COBIT 2019 vs TOGAF 9.2 from useful literature .............................. 53
Table 3: High-level comparison COBIT 2019 and TOGAF 9.2 ............................................. 60
Table 4: Content comparison COBIT 2019 and TOGAF 9.2: APO03 ................................... 64
Table 5: Content comparison COBIT 2019 and TOGAF 9.2: EDM04, APO02, APO04, BAI02
and BAI03 ........................................................................................................................... 69

VIII
Intro

Context
Information technology (IT) is a vital part of every organization today. Not only the
products and services are based on it, but it is also necessary for supporting the
processes of an organization (Samiei & Habibi, 2022). “The key to success with
technology is not technology per se, but the ability to manage it well”, stated Tshinu et.
al (2008). The management of IT guarantees the optimal utilization of IT resources
within an organization, and since the role of IT becomes more eminent, IT management
frameworks become more demanding (Samiei & Habibi, 2022).
The IT management in organizations who are required to be more agile, faster and
supporting existing innovations, is one of the drivers of the formation of the COBIT 2019
framework (ISACA, 2018a). COBIT is one of the most crucial frameworks for IT
governance, because it offers organizations useful guidelines for evaluating their IT
governance systems (Al-Turkistani et al., 2021). Ensuring this effective governance over
I&T is critical to business success (ISACA, 2018a).
On the other hand, Enterprise Architecture Frameworks (EAF) offer companies an
efficient technique to manage their IT systems aligning their business requirements with
effective solutions. As a result, experts have developed multiple EAF’s such as TOGAF
to help organizations achieve their objectives by reducing the costs and complexity
(Havaluddin, 2012).
To improve business efficiency, the world’s leading organizations use the TOGAF
Standard of The Open Group as proven Enterprise Architecture (EA) framework and
methodology (The Open Group, 2018). It offers excellent alignment between business
and IT and simple implementation measures, providing group of models, strategies,
methodologies and tools for developing a holistic EA (Al-Turkistani et al., 2021).

Problem definition
Since each IT management framework covers a certain area of IT-related resources
and processes, it requires separate projects for deploying each of them in an
organization (Samiei & Habibi, 2022). The separate implementation of those

1
frameworks increases the required cost and time to achieve the results, as there are
many processes, resources, and artifacts that are shared among the projects and could
cause waste, redundancy and duplications. The separate implementation also leads to
the creation of incompatible or duplicated products, since the outputs, the frameworks’
components and the steps of the projects are in many cases similar or complementary
to each other (Harani et al., 2018). That is why this dissertation aims to give a clear
overview of the differences and similarities between the COBIT 2019 framework and the
TOGAF Standard Version 9.2, in order for future research to integrate and/or map the
two frameworks so costs and time could be reduced when implementing a tailored IT
management framework. Furthermore, ISACA has made mappings between previous
versions of the two frameworks (ISACA, 2011), but mappings for the recent versions
have not been made up yet. So this dissertation also aims to give a clear overview of
the structural and (some) content differences and similarities between COBIT 2019 and
TOGAF Version 9.2 to enable the creation of mappings in the future.

Research question
As Samiei and Habibi (2022) recently stated, the efforts made in studying EA-COBIT
relations are limited and are in need for further development. Multiple research papers
also indicate that there is only limited academic research that leverages or explores
COBIT (De Haes et al., 2013). ISACA itself, as developing institute of the COBIT
framework, has made major investments over the years in mapping COBIT to other
frameworks such as TOGAF versus COBIT 4 (ISACA, 2011). However, there is no
academic research (yet) about the inter-operation of these relationships. One of their
major questions include: “How does an enterprise manage multiple frameworks and
standards?” (De Haes et al., 2013). In response, Samiei and Habibi (2022) already
created a comprehensive IT management methodology that makes use of the concepts
of different IT management frameworks (such as COBIT and EA) in order to provide
organizations with the same outputs and artifacts at lower cost and effort. Unfortunately,
this was performed with the previous version of COBIT.

Due to these given gaps, I would like to draw a detailed descriptive comparison
between the COBIT 2019 framework and the TOGAF Version 9.2 (representing the EA
concept since COBIT refers to TOGAF for establishing EA objectives and also because
TOGAF is used by the world’s leading organizations to improve business efficiency),

2
giving a clear overview in order to extend the academic research regarding these
frameworks.

The main research will be about describing the (dis)similarities between COBIT 2019
and TOGAF 9.2. Thus the main research question (RQ) states: “What are the
similarities and dissimilarities between COBIT 2019 and TOGAF 9.2?”. The answer to
this question will be firstly looked for in existing literature, trying to find any existing
comparisons between the two most recent versions of the COBIT and TOGAF
framework. Secondly, a high-level comparison will be drawn regarding their structure,
based upon concept maps made of the key components of each framework. Lastly, a
detailed comparison between some specific content of the frameworks will be
performed.

Relevancy
With this dissertation I hope to bring a contribution of societal relevance by providing a
clear overview of the overlap between the two frameworks, which should benefit both
enterprise and society: organizations are to become more efficient, less costly and so
more sustainable in the long run. The goal for aligning COBIT with EA is to draw a clear
vision of the differences and similarities between both concepts in order for enterprises
to avoid making double costs.

Structure
In this dissertation about how to align COBIT with EA, I will firstly introduce the broader
concepts of IT governance and EA, wherein COBIT is used as framework for IT
governance and TOGAF as framework for EA. For this background provision, the most
recent versions are chosen, namely COBIT 2019 and TOGAF Version 9.2. After
providing a neutral explanation on the working of these frameworks, I will dive deeper
by identifying the similarities and differences between them. This descriptive
comparison, elaborated into a literature review, a high-level comparison and a limited
detailed comparison, should give a clear overview of which parts have an overlap.
Lastly, some gaps and possibilities for future research will be drawn by discussing the
results of the comparison.

3
Background
In order to align COBIT with EA, TOGAF is chosen as framework to approach EA, partly
because COBIT refers to TOGAF as guided reference for establishing EA, but also
because it is one of the most common used EA frameworks (Al-Turkistani et al., 2021)
and is used by the world’s leading organizations to improve business efficiency (The
Open Group, 2018). “It is the most prominent and reliable EA standard, ensuring
consistent standards, methods, and communication among EA professionals.”, states
The Open Group (2018). Before comparing COBIT and TOGAF, it should be clear what
each framework stands for and in which context they are being used. Explanation of
these concepts are given in this section.

Enterprise Governance of IT
Enterprise governance of IT (EGIT), as integral part of enterprise governance,
addresses the definition and implementation of processes, structures, and relational
mechanisms in the organization (Van Grembergen & De Haes, 2009). A specific focus
on EGIT has arisen over the last three decades given the centrality of I&T for enterprise
risk management and value generation (ISACA, 2018a).

EGIT is complex and multifaceted, with no ideal way to design, implement and maintain
it within an organization. As such, members of the governing boards and senior
management typically need to tailor their EGIT measures and implementation to the
specific context and needs. EGIT should enable both business and IT people for
executing their responsibilities in support of business/IT alignment and the creation of
business value from I&T-enabled business investments, as shown in figure 1 (ISACA,
2018a).

Figure 1: The context of EGIT

4
“The implementation of IT governance is important to lead and evolve the information
system in agreement with stakeholders” (Ibrahim & Abdessamad, 2019). In support of
enterprises increasingly making tangible and intangible investments to improve EGIT,
they are drawing upon the practical relevance of generally accepted good-practice
frameworks such as COBIT (ISACA, 2009). Choosing an IT governance framework is a
very important task before implementation, since a good choice will lead to a better
results, as explained in the paper of Ibrahim and Abdessamad (2019). They further boil
down IT goverance into five issues, as defined by ISACA:
- IT Strategic Alignment
- IT Value Delivery
- IT Risk Management
- Performance Measurement
- IT Resource Management

COBIT

The use of COBIT

COBIT is a framework in information governance and management of enterprise I&T
that leads to the entire company (Ikhsan et al., 2021). It defines design factors and
components to build and maintain a governance system that best fits the needs of
organizations and companies (Ikhsan et al., 2021). COBIT is implemented in
organizations as a tool to measure the achievement of the objectives of improving
process quality, as well as standardizing the activities with regard to the improvement of
governance initiatives (Machado & Carvalho, 2021).

ISACA (2018a), founder of the framework, summarizes COBIT as follows: “COBIT is

considered one of the most used models to manage, control, and guarantee the best
practices of IT, incorporating standards – such as TOGAF - and aligning with models, in
addition to being an important determining factor for the disclosure of information on IT
governance in annual reports.” ISACA is a global association that helps individuals and
enterprises to achieve the potential of technology by leveraging the expertise of
engaged professionals in information and cyber security, governance, assurance, risk
and innovation to help advance innovation through technology.

5
The latest version of COBIT, namely COBIT 2019, is used in evaluating IT governance
and management. It has a role in controlling, maximizing the value of I&T with the aim
of helping organizations earn profits and achieve resource- and risk optimization
(ISACA, 2018a). According to ISACA (2022), this newest COBIT release further
cements the continuing role of COBIT as an important driver of innovation and business
transformation. Steuperaert (2019) describes that adding interesting features and
developments such as design factors, governance components, governance and
management objectives, as well as focus areas, makes COBIT 2019 an attractive
choice for companies to use and take advantage of.

The COBIT Core Model

ISACA (2012) describes COBIT as an IT governance, management and audit
framework well-known in IS practitioners’ communities. According to professor Jan
Devos and Kevin Van de Ginste (2015), COBIT analyzes the complete Information
System (IS) function and offers descriptive and normative support to manage, govern
and audit IT in organizations.

As ISACA (2012) explains, the framework “supports enterprises in achieving their

objectives for the governance and management of enterprise IT” and “is based on five
key principles that embodies these objectives and enables the enterprise to build an
effective governance and management framework that optimizes IT investments and
use for the benefit of stakeholders.” Those five principles are:

- Meeting stakeholder needs

- Covering the enterprise end-to-end

- Applying a single, integrated framework

- Enabling a holistic approach

- Separating governance from management

The COBIT Core Model has five domains, divided into two main parts, namely (IT)
governance and (IT) management (ISACA, 2018a). These five domains embody 40
management and governance objectives in total; five objectives regarding the
governance domain and 35 objectives dispersed over the four management domains
(see figure 2).

6
Figure 2: COBIT Core Model

Each objective represents a process, for which practices are summed up with activities
(at a certain capability level) to achieve the objective.
COBIT defines a process as ‘a collection of practices influenced by the enterprise’s
policies and procedures that takes inputs from a number of sources (including other
processes), manipulates those and produces outputs (e.g. products, services)’ (ISACA,
2012). Practices, as part of a particular process, group activities with metrics to
measure the achievement of the practice (Proper et al., 2021).

COBIT 2019
Aimed at the whole enterprise, COBIT is a framework for the governance and
management of enterprise IT, which represents all the technology and information
processing the enterprise puts in place to achieve its goals, regardless of where this
happens in the enterprise (ISACA, 2018a). “In other words, enterprise IT is not limited to
an organization’s IT department, but certainly includes it.” COBIT does not make or
prescribe any IT-related decisions, it will not decide the best IT strategy, the best
architecture, nor the best cost. COBIT rather defines all the components describing

7
which and how decisions should be taken and by whom. COBIT is not a framework for
organizing business processes, but defines the components to build and sustain a
governance system, including processes, organizational structures, policies and
procedures, information flows, culture and behaviors, skills, and infrastructure. It also
defines design factors to be considered by the enterprise for building a best-fit
governance system (ISACA, 2018a).

The COBIT framework makes a clear distinction between governance and

management, which encompasses different activities, requires different organizational
structures and serves different purposes. This way it addresses governance issues by
grouping relevant governance components into governance and management
objectives, manageable to the required capability levels.
Following image (figure 3) gives an overview of COBIT 2019 (ISACA, 2018a):

Figure 1: COBIT 2019 overview

The following sub-sections will explain the key concepts embedded in COBIT 2019
(figure 4).

8
Figure 4: Key concepts of COBIT 2019

Goals Cascade
In the updated Goals Cascade (where enterprise and alignment goals have been
consolidated, reduced, updated and clarified where necessary), firstly the needs of
stakeholders should be transformed into an actionable strategy for the enterprise. The
goals cascade (see figure 5) supports enterprise goals - one of the key design factors
for a governance system - and also supports the translation of those goals into
priorities for alignment goals. The alignment goals emphasize the alignment of all IT
efforts with business objectives a

9
Figure 5: COBIT Goals Cascade

Objectives
In order for IT to contribute to enterprise goals, a number of governance and
management objectives should be achieved. Basic concepts relating the objectives are
(ISACA, 2018a):
- A governance or management objective always relates to one process (with an
identical or similar name) and a series of related components of other types to
help achieve the objective.
- A governance objective relates to a governance process, while a management
objective relates to a management process. Typically, boards and executive
management are accountable for governance processes, while management
processes are the domain of senior and middle management.
- The governance and management objectives in COBIT are grouped into five
domains (as shown in figure 6), having names with verbs that express the key
purpose and areas of activity of the objective contained in them:
o Governance objectives are grouped in the Evaluate, Direct and Monitor
(EDM) domain. In this domain, the governing body evaluates strategic
options, directs senior management on the chosen strategic options and
monitors the achievement of the strategy.
o Management objectives are grouped in four domains:
▪ Align, Plan and Organize (APO) addresses the overall organization,
strategy and supporting activities for IT.

10
 ▪ Build, Acquire and Implement (BAI) treats the definition, acquisition
and implementation of IT solutions and their integration in business
processes.
▪ Deliver, Service and Support (DSS) addresses the operational
delivery and support of IT services, including security.
▪ Monitor, Evaluate and Assess (MEA) addresses performance
monitoring and conformance of IT with internal performance
targets, internal control objectives and external requirements.

Figure 6: Governance and management domains in COBIT 2019

COBIT 2019 has 40 core governance and management objectives defined through the
COBIT Core Model (ISACA, 2018a). There are five governance objectives and 35
management objectives. Each objective provides – as high-level information - which
domain and focus area it belongs to as well as a description and a purpose statement.
Secondly, it follows a goals cascade concerning the alignment goals and enterprise
goals, given with example metrics. As related components in an objective are given:
processes, practices and activities, organizational structures, information flows and
items, people, skills and competencies, policies and frameworks, culture, ethics and
behavior and services, infrastructure and applications. Additionally, related guidance to
other standards and frameworks is provided for each of the governance components
within each objective (see figure 7).

11
Figure 7: Structure of the objectives in COBIT 2019

Components
“To satisfy governance and management objectives, each enterprise needs to establish,
tailor and sustain a governance system built from a number of components.
Components are factors that, individually and collectively, contribute to the good
operations of the enterprise’s governance system over I&T” (ISACA, 2018a). They
interact with each other, to result in a holistic IT governance system. Different types of
components of a governance system exist, and can be generic components (applying to
any situation) or variants of generic components (tailored within a focus area) (ISACA,
2018a). Following components are present within each objective (see figure 8):
- Processes: describing an organized set of practices and activities for achieving
certain objectives.
- Organizational structures: are the key decision-making entities in an enterprise.
- Principles, policies and frameworks: for translating desired behavior into practical
guidance for day-to-day management.
- Information: all information produced and used by the enterprise. COBIT focuses
on that required for the effective functioning of an enterprise’s governance
system.
- Culture, ethics and behavior: both of individuals and of the enterprise, as success
factors in activities.
- People, skills and competencies: required for good decisions, execution of
corrective action and successful completion of all activities.

12
 - Services, infrastructure and applications: providing the enterprise with the
governance system for IT processing.

Figure 8: COBIT components of an objective/governance system

Design process
The design process as shown below (figure 9), composes of a flow of steps, which will
realize a governance system that is tailored to their needs, if an enterprise follows it.
The different stages and steps in the design process, will result in recommendations for
prioritizing objectives or related components, for target capability levels, or for adopting
specific variants of a component (ISACA, 2018a). That way, design factors and focus
areas can be established to achieve a tailored governance and management
framework.

13
Figure 9: Design process for a governance system in COBIT

Focus areas
“A focus area describes a certain governance topic, domain or issue that can be
addressed by a collection of governance and management objectives and their
components. Examples of focus areas include: small and medium enterprises,
cybersecurity, the COBIT Core Model, digital transformation, cloud computing, privacy,
and DevOps.” These areas may contain a combination of generic governance
components and variants. The number of focus areas is virtually unlimited and can be
added when required (ISACA, 2018a).

The five domains that distribute the 40 objectives of the two dimensions (governance
and management), integrate design factors and focus areas as indicated in the COBIT
guidelines, created by ISACA (2018a). “These design factors and focus areas help
enterprises with the implementation of the 40 generic processes (and to make a
selection)”, dixit professor Geert Poels (personal communication, 2nd of May 2022).

Design factors
“Design factors are factors that can influence the design of an enterprise’s governance
system and position it for success in the use of I&T.” They include any combination of
the following elements in figure 10 (ISACA, 2018a):

14
Figure 10: Design factors in COBIT 2019

In the COBIT 2019 Design Guide, there is a detailed description of the design factors,
which influence in different ways the tailoring of the governance system of an
enterprise. The publication distinguishes three different types of impact of the design
factors, shown in the image below (figure 11) (ISACA, 2018a):
1. Management objective priority/selection: “The COBIT core model contains 40
governance and management objectives, each consisting of the process and a
number of related components. They are intrinsically equivalent; there is no
natural order of priority among them. However, design factors can influence this
equivalence and make some governance and management objectives more
important than others, sometimes to the extent that some governance and
management objectives may become negligible. In practice, this higher
importance translates into setting higher target capability levels for important
governance and management objectives.”
2. Components variation: “Components are required to achieve governance and
management objectives. Some design factors can influence the importance of
one or more components or can require specific variations.”
3. Need for specific focus areas: Some design factors will drive the need for
variation of the content of the core model to a specific context.

15
Figure 11: Impact of design factors on a governance and management system

Performance Management
The COBIT Performance Management (CPM) expresses how well the governance and
management system and all the enterprise’s components work, and how they can be
improved to achieve the required level. As integral part of the COBIT framework, COBIT
uses the term COBIT Performance Management (CPM) to describe the activities,
including concepts and methods such as capability and maturity levels (ISACA, 2018a).

The CPM should enable managing the performance of all types of components and
should support different types of assessment, providing reliable, repeatable and
relevant results. It must be flexible to support the requirements of different organizations
with different priorities and needs. The CPM model largely aligns to and extends CMMI
Development V2.0201 concepts: process activities are associated to capability levels,
whereas maturity levels are associated with focus areas and will be achieved if all
required capability levels are achieved (ISACA, 2018a).

Regarding the performance management of processes, the process within each

objective can operate at various capability levels, ranging from 0 to 5. The Process

16
Capability Level (CPL), as shown in figure 12, is a measure of how well a process is
implemented and performing. A level can be achieved to varying degrees, expressed by
a set of ratings depending on the context of the performance assessment. “The COBIT
Core Model assigns capability levels to all process activities, enabling clear definition of
the processes and required activities for achieving the different capability levels”
(ISACA, 2018a).

Figure 12: Capability levels for processes in COBIT

For the purpose of expressing performance at a higher level without needing the
granularity of individual process capability ratings, maturity levels can be used (see
figure 13). These maturity levels measure performance at the focus area level, whereby
a certain maturity level is achieved if all the processes contained in the focus area
achieve that particular capability level (ISACA, 2018a).

17
Figure 13: Maturity levels for focus areas in COBIT

Related standards
Thanks to its easy integration, COBIT 2019 is specifically designed to play well with
others. Guidance is provided for helping to integrate the industry standards, guidelines,
regulations and best practices unique to the enterprise into the governance solution
using COBIT (ISACA, 2022).

“One of the guiding principles applied throughout the development of COBIT 2019 was
to maintain the positioning of COBIT as an umbrella framework. This means that COBIT
continues to align with a number of relevant standards, frameworks and/or regulations.
In this context, alignment means that COBIT does not contradict any guidance in the
related standards.” Standards and guidance used during the development of COBIT
2019 include - among others - TOGAF Version 9.2 (ISACA, 2018a).

18
Enterprise Architecture
“EA is a discipline in worldwide expansion”, said Moscoso-Zea et al. in 2019. IT caused
changes in many organizations that are not aligned with business strategies and
resulting in wastage of resources, which caused that many organizations have turned to
Enterprise Architecture Frameworks (EAF) (Al-Turkistani et al., 2021). These offer the
control and holistic structure needed to align a corporation’s ITs and business
operations to support its strategies and business goals (Alshammari, 2017).

EA allows companies to model an organization's current situation and the desired future
scenarios and to establish road maps to enable adequate transformations (Moscoso-
Zea et al., 2019). It thus describes the current state of the organization and brings
forward the best alternative to achieve desired results. Moscoso-Zea et al. (2019) state
that EA provides a long-lasting view of the processes, systems and technologies used
in an enterprise. The Open Group (2018) describes that a good EA enables to achieve
the right balance between business transformation and continuous operational
efficiency, allowing individual business units to innovate safely in their pursuit of
evolving business goals and competitive advantage.

The term ‘enterprise’ in the context of ‘Enterprise Architecture’ can be applied to either
an entire enterprise – which encompasses all of its business activities and capabilities,
information, and technology, making up the enterprise’s entire infrastructure and
governance - or to one or more specific areas of interest within the enterprise (The
Open Group, 2018). The meaning of ‘architecture’ within the context of The Open Group
Architecture Framework (TOGAF), is defined by The Open Group (2018) as follows:
"The structure of components, their inter-relationships, and the principles and guidelines
governing their design and evolution over time."

There are four architecture domains, commonly accepted as subsets of an overall EA

(The Open Group, 2018):
- Business Architecture; defining the business strategy, governance, organization,
and key business processes.
- Data Architecture; describing the structure of an organization’s logical and
physical data assets and data management resources.

19
 - Application Architecture; providing a blueprint for the individual applications to be
deployed, their interactions, and their relationships to the core business
processes of the organization.
- Technology Architecture; describing the logical software and hardware
capabilities required for supporting the deployment of business, data, and
application services, including IT infrastructure, middleware, networks,
communications, processing, standards, etc.

According to Lankhorst (2013), EA entails the set of principles, methods and models
used to design, produce and maintain the business and technology architecture,
organizational structure and Information Systems (IS). It is stated that a well-established
EA helps to accomplish the perfect balance between IT efficiency and business
innovation and that EA’s main goal is to optimize the organization process in a cohesive
environment ready to support incoming changes and business strategies (The Open
Group, 2018).

Enterprise Architecture Frameworks (EAF) could be considered as a tool in a context

which facilitates utilizing a holistic architecture of the enterprise system as fundamental
infrastructure, providing the basis of software, hardware and networks. It enables
enterprise to manage and collaborate multifaceted systems within an enterprise and
helps aligning enterprise systems and business to decrease the general cost of system
deployment and maintenance by reducing complexity (Havaluddin, 2012).

As a proven EA methodology and framework, there is the TOGAF Standard of the Open
Group, used by the world’s leading organizations to improve business efficiency (The
Open Group, 2018). The Standard provides a best practice framework to add value and
it enables the organization to build workable and economic solutions that address their
business issues and needs. Using TOGAF results in an EA giving due consideration
both to current requirements and perceived future needs of the business (The Open
Group, 2018).

20
TOGAF

The use of TOGAF

TOGAF is a trusted, vendor-neutral, globally recognized and portable credential,
resulting in greater industry credibility, job effectiveness and career opportunities for
those professionals who are fluent in the TOGAF approach. It helps practitioners to
avoid being locked into proprietary methods, utilize resources more efficiently and
effectively and realize a greater return on investment (The Open Group, 2018). The
Standard may be used freely by any organization who wishes to develop an EA to use
within that organization (The Open Group, 2018).

Adapting the Standard for configuring EA practice, is done together with universal
concepts, best practice guidance and emerging ideas. Due to the greatly expanded
guidance and how-to material, TOGAF enables organizations to operate in an efficient
and effective way across a broad range of use-cases (The Open Group, 2018).
“Although all of the TOGAF documentation works together as a whole, it is expected
that organizations will customize it during adoption, and deliberately choose some
elements, customize some, exclude some, and create others” (The Open Group, 2018).

As a result of the delivered work by the members of the Open Group Architecture
Forum, the standard is constantly evolving. Due to this constant evolution, an update to
the standard got released in 2018: The TOGAF Standard, Version 9.2. This version has
been redesigned and restructured into a smaller publication, including separate guides
(The Open Group, 2018). The latest release at the moment has just recently (June,
2022) been reached: the 10th version of TOGAF. For practical reasons, it is decided that
this dissertation will handle TOGAF Version 9.2, since there has been no research/use
cases available so far for the 10th version.

The TOGAF Standard

“The TOGAF standard is a framework for Enterprise Architecture”, providing methods
and tools to assist in the acceptance, production, use and maintenance of an EA. “It is
based on an iterative process model supported by best practices and re-usable set of
existing architecture assets” (The Open Group, 2018).

21
The TOGAF Standard is divided into the TOGAF Fundamental Content and the TOGAF
Series Guides: The Fundamental Content provides the core concepts and practices and
the Series Guides give advice on configuring the Fundamental Content (The Open
Group, 2018).
Regarding the core concepts in the TOGAF Fundamental Content, a division of the
Standard into six parts is made (The Open Group, 2018):
1) A high-level introduction to the key concepts of EA and in particular of the
TOGAF approach, containing the definitions of terms used throughout the
standard.
2) Description of the Architecture Development Method (ADM), being the core of
the TOGAF framework. This approach develops an EA step-by-step.
3) Collection of ADM Guidelines and Techniques. “Additional guidelines and
techniques are also available in the TOGAF Library.”
4) Description of the Architecture Content Framework, including a structured
metamodel for architectural artifacts, the use of reusable architecture building
blocks and an overview of typical architecture deliverables.
5) Enterprise Continuum and Tools for discussing appropriate taxonomies and tools
for categorizing and storing the outputs of architecture activity within an
enterprise.
6) The Architecture Capability Framework, discussing the organization, processes,
skills, roles and responsibilities needed for establishing and operating an
architecture practice within an enterprise.
This division will be discussed more in detail in the following sections, regarding version
9.2 of the Standard.

Concerning the supporting documentation in form of the TOGAF Series Guides, they
contain detailed guidance on how to use the framework and is expected to be the most
rapidly developing part of the TOGAF documentation. This guidance can be industry,
architectural style, purpose, and problem-specific, while the TOGAF framework itself is
expected to be long-lived and stable (The Open Group, 2018).
As the TOGAF standard provides a framework for effective delivery of EA, it is
supported by a set of documents providing specific guidance about how to use and
adapt it for supporting new trends. This set resides in the TOGAF Library and
represents an extensive new body of knowledge that EA practitioners can use for

22
supporting development of EAs. This reference library contains guidelines, templates,
patterns and other forms of reference material to accelerate the creation of new EAs
(The Open Group, 2018).

TOGAF Version 9.2

Building on previous versions of the standard, version 9.2 of the TOGAF Standard - the
one that will be analyzed in this dissertation - is an update of the standard, providing
additional guidance, correcting errors, removing obsolote content and introducing
structural changes to support the TOGAF Library (The Open Group, 2018). This version
provides industry, architecture style, and purpose-specific tools, techniques, and
guidance (The Open Group, 2018).

Although the core of the standard remains the same – the same division in six parts - ,
this new version includes more on Business Architecture, Security Architecture,
mappings to other industry reference models and practical implementation guides. It
also focuses more on digital trends and business transformation beyond IT (The Open
Group, 2018).

Following subsections will explain the six core parts of Version 9.2:
Part 1: High-level introduction
Part 2: Description of the ADM
Part 3: ADM Guidelines and Techniques
Part 4: Architecture Content Framework
Part 5: Enterprise Continuum and Tools
Part 6: Architecture Capability Framework

Figure 14 reflects the structure and content of the TOGAF Standard (The Open Group,
2018):

23
Figure 14: Structure and content of the TOGAF Standard

Part 1: Introduction
The TOGAF standard is a generic framework, intended to be used in a wide variety of
environments and it provides a flexible and extensible content framework, underpinning
a set of generic architecture deliverables. As a result, the framework may be used either
in its own right – describing the generic deliverables - or else these deliverables may be
replaced or extended by a more specific set, defined in any other framework that the
architect considers relevant (The Open Group, 2018).

It is expected that the architect adapts and builds on the TOGAF framework to define a
tailored method integrated into the enterprise’s processes and organization structures.
This tailoring may include adopting elements from other architecture frameworks, or
integrating TOGAF methods with other standard frameworks or best practices such as
COBIT. The TOGAF standard thus provides the capability and collaborative
environment to integrate with other frameworks (The Open Group, 2018).

24
Part 2: Architecture Development Method (ADM)
“The TOGAF ADM defines a recommended sequence for the various phases and steps
involved in developing an architecture. It provides a tested and repeatable process for
developing architectures” (The Open Group, 2018). The ADM includes establishing an
architecture framework, developing architecture content, transitioning, and governing
the realization of architectures (The Open Group, 2018). These activities are carried out
within an iterative cycle of continuous architecture definition and realization, allowing
organizations to transform their enterprises in a controlled manner in response to
business goals and opportunities (The Open Group, 2018). “The ADM is iterative over
the whole process, between phases, and within phases.” Each iteration adds resources
to the Architecture Repository of the organization and for each iteration, fresh decisions
must be taken concerning (The Open Group, 2018):
- The breadth of coverage of the enterprise; what part of the enterprise’s extent will
the architecting effort deal with
- The depth; the level of detail of the effort
- The extend of the time period, including the number and extent of any
intermediate time periods
- The architectural assets to be leveraged, including those created in previous
iterations as well as those available elsewhere in the industry. A complete EA
description should contain all four architecture domains (business, data,
application, technology), but in reality there is often not enough time, funding, or
resources!

Figure 15 shows the ADM cycle with the sequence of phases, which are (The Open
Group, 2018):
- Preliminary Phase: Description of the preparation and initiation of activities
required to create an Architecture Capability including customization of the
TOGAF framework and definition of architecture principles.
- Phase A: Architecture Vision, describing the initial phase of an architecture
development cycle, including information about defining the scope of the
architecture development initiative, identifying the stakeholders, creating the

25
 Architecture Vision, and obtaining approval to proceed with the architecture
development.
- Phase B: Business Architecture, describing the development of a Business
Architecture to support the agreed Architecture Vision.
- Phase C: Information Systems Architectures, describing the development of
Information Systems Architectures to support the agreed Architecture Vision.
- Phase D: Technology Architecture, describing the development of the
Technology Architecture to support the agreed Architecture Vision.
- Phase E: Opportunities & Solutions, conducting initial implementation planning
and the identification of delivery vehicles for the architecture defined in the
previous phases.
- Phase F: Migration Planning, addressing how to move from the baseline to the
target architectures by finalizing a detailed Implementation and Migration Plan.
- Phase G: Implementation Governance, providing an architectural oversight of the
implementation.
- Phase H: Architecture Change Management, establishing procedures to manage
change to the new architecture.
- Requirements Management, examining the process of managing architecture
requirements throughout the ADM.

These phases will be elaborated in the next sub-sections. Each phase of the ADM cycle
provides a purpose, inputs (architectural, non-architectural and external material
references), outputs and is further divided into steps. The level of detail (in most of the
phases) will depend on the scope and goals of the overall architecture effort, whereas
the order of the steps as well as the start- and completion time should be adapted to the
situation at hand in accordance with the established Architecture Governance (The
Open Group, 2018).

26
Figure 15: The ADM cycle of TOGAF

Based on research using the TOGAF ADM, it is stated that companies do not always
have to use all the phases when implementing ADM. ADM must be applied sequentially
between phases and the entire process when designing EA (Rika & Budi, 2011). The
ADM may be – but not necessarily – tailored to the specific needs of the enterprise.

Preliminary Phase

This “pre-phase” describes the preparation and initiation activities needed to meet the
business directive for a new EA. This includes the definition of principles and of an
organization-specific architecture framework (The Open Group, 2018). It is about
defining where, what, why, who and how to do architecture in the enterprise. The
purpose of this phase is to determine the desired Architecture Capability and to
establish this (The Open Group, 2018).

27
The Preliminary Phase involves doing any necessary work to initiate and adapt the
ADM for defining an organization-specific framework, since the ADM is a generic
method and intended for a wide and variated use with other frameworks (The Open
Group, 2018). The steps within the Preliminary Phase are as follows:

1) Scope the enterprise organizations impacted

2) Confirm governance and support frameworks
3) Define and establish EA team and organization
4) Identify and establish architecture principles
5) Tailor the TOGAF framework and, if any, other selected architecture
framework(s)
6) Develop a strategy and implementation plan for tools and techniques

As mentioned above, this phase defines the architecture principles that will form part of
the constraints on any undertaken architecture work (The Open Group, 2018). The
definition of these principles is fundamental to develop an EA. Architecture work is
informed by both business principles as well as architecture principles, who themselves
are also normally based in part on business principles (The Open Group, 2018).

“The Preliminary Phase may be revisited, from the Architecture Vision phase, in order to
ensure that the organization's Architecture Capability is suitable to address a specific
architecture problem” (The Open Group, 2018).

Phase A: Architecture Vision

The Architecture Vision phase is the initial phase of the ADM, including information
about defining the scope, identifying the stakeholders, creating the Architecture Vision
and obtaining approvals (The Open Group, 2018). The objectives of this phase are to
develop a high-level aspirational vision of the capabilities and business value to be
delivered as a result of the proposed EA. It also aims to obtain approval for a Statement
of Architecture Work defining a program of works to develop and to deploy the
architecture outlined in the Architecture Vision (The Open Group, 2018).

In this phase, the level of detail will depend on the scope and goals of the Request for
Architecture Work, or the subset of scope and goals associated with this iteration of
architecture development. The steps in Phase A are as follows:

28
 1) Establish the Architecture Project
2) Identify stakeholders, concerns and business requirements
3) Confirm and elaborate business goals, business drivers and constraints
4) Evaluate capabilities
5) Assess readiness for business transformation
6) Define scope
7) Confirm and elaborate architecture principles, including business principles
8) Develop Architecture Vision
9) Define the target architecture Value Proposition and KPIs
10) Identify the business transformation risks and mitigation activities
11) Develop Statement of Architecture Work; secure approval

“Phase A starts with the receipt of a Request for Architecture Work from the sponsoring
organization to the architecture organization” (The Open Group, 2018).

This phase defines what is in and outside the scope of the architecture effort and the
constraints that must be dealt with. If the business principles, business goals and
strategic drivers of the organization are already defined in the enterprise, the activity in
Phase A involves ensuring that existing definitions are current and involves clarifying
any areas of ambiguity (The Open Group, 2018). If not, it involves defining these
essential items for the first time. This is the same concerning the architectural principles
– defined in the Preliminary Phase - which form part of the constraints on architecture
work.

“The Architecture Vision describes how the new capability will meet the business goals
and strategic objectives and address the stakeholder concerns when implemented”
(The Open Group, 2018). One of the key parts in this phase is to clarify and agree the
purpose of the architecture effort, clearly reflected in the created vision. The whole point
of the Architecture Vision is to demonstrate how the purpose will be achieved by the
proposed architecture development. As a step in the development of the Architecture
Vision, applying business models show how the organization intends to deliver value to
its customers and stakeholders (The Open Group, 2018).

“The Architecture Vision provides a first-cut, high-level description of the Baseline and
Target Architectures, covering the business, data, application, and technology domains.

29
These outline descriptions are developed in subsequent phases” (The Open Group,
2018).

Phase B: Business Architecture

The development of a Business Architecture supports an agreed Architecture Vision. It

relates business elements to business goals and elements of other domains (The Open
Group, 2018). “Business Architecture is a representation of holistic, multi-dimensional
business views of: capabilities, end-to-end value delivery, information, and
organizational structure; and the relationships among these business views and
strategies, products, policies, initiatives, and stakeholders” (The Open Group, 2018). It
has the objective to develop the target Business Architecture describing how the
enterprise needs to operate to achieve the business goals and to respond to strategic
drivers set out in the Architecture Vision. The second objective of Phase B is to identify
candidate architecture road map components based upon gaps between the baseline
and target Business Architectures (The Open Group, 2018). The Business Architecture
is the first architecture activity that needs to be undertaken, as knowledge of this
architecture is a prerequisite for architecture work in any other domain (Data,
Application, Technology).

Existing business artifacts can be carried over and supported in the target environment
when defined in previous architectural work, if not they will need to be defined in this
phase (The Open Group, 2018) . To characterize the business needs, new models will
also need to be defined in detail. As part of this phase, the architecture team needs to
consider what relevant Business Architecture sources are available from the
Architecture Repository, namely relevant industry reference models, enterprise-specific
Business Architecture views, enterprise-specific building blocks and applicable
standards(The Open Group, 2018).

The work scope is primarily determined by the Architecture Vision set out in Phase A.
The steps in Phase B are (The Open Group, 2018):

1) Select reference models, viewpoints and tools

2) Develop baseline Business Architecture description
3) Develop target Business Architecture description
4) Perform gap analysis
30
 5) Define candidate road map components
6) Resolve impacts across the architecture landscape
7) Conduct formal stakeholder review
8) Finalize the Business Architecture
9) Create the architecture definition document

All activities initiated in the above mentioned steps should be closed during the ‘Finalize
the Business Architecture’ step and the generated documentation must be formally
published in the last step (The Open Group, 2018).

An organization map is a key element of the Business Architecture since it provides the
organizational context for the whole EA effort. While capability mapping exposes what a
business does and value stream mapping exposes how it delivers value to specific
stakeholders, the organization map identifies the business units or third parties that
possess or use those capabilities and which participate in the value streams. It provides
– taken together with the methods around business capabilities and value streams - an
understanding of which business units to involve in the architecture effort, who and
when to talk about a given requirement, and how to measure the impact of various
decisions (The Open Group, 2018).

As extensions to implementing the business capabilities, value streams and

organization maps into the business practices, there are modeling and mapping
techniques provided in this phase (The Open Group, 2018).

Phase C: Information Systems Architectures

The Information Systems Architectures for an architecture project include developing
Data Architectures and Application Architectures (The Open Group, 2018). Phase C
thus involves some combination of Data and Application Architecture, in either order.
The objectives of this phase are to develop the target Information Systems
Architectures, which describe how those will enable the Business Architecture and the
Architecture Vision, so that it addresses the Statement of Architecture Work and
stakeholder concerns. Furthermore the purpose of Phase C is to identify candidate
architecture road map components based upon gaps between the baseline and target
Information Systems (Data and Application) Architectures (The Open Group, 2018).

31
Data Architecture
“As part of this phase, the architecture team will need to consider what relevant Data
Architecture resources are available in the organization's Architecture Repository, in
particular, generic data models relevant to the organization's industry "vertical" sector”
(The Open Group, 2018).

As part of this effort, newly introduced data building blocks will need to be defined in
detail, whereas existing data building blocks are carried over and supported in the target
environment and have already been defined in previous architectural work (or not, and
needs to be defined in this phase then) (The Open Group, 2018).

It should be determined whether it is appropriate to conduct baseline description or

target architecture development first. The steps for Data Architecture are (The Open
Group, 2018):
1) Select reference models, viewpoints and tools
2) Develop baseline Data Architecture description
3) Develop target Data Architecture description
4) Perform gap analysis
5) Define candidate road map components
6) Resolve impacts across the architecture landscape
7) Conduct formal stakeholder review
8) Finalize the Data Architecture
9) Create the architecture definition document

All activities in these steps should be closed during the ‘Finalize the Data Architecture’
step and the generated documentation must be formally published in the last step.

Furthermore, the Data Architecture requires some key considerations concerning data
management, data migration and data governance and should ensure that an
enterprise-wide common data definition is established to support transformation (The
Open Group, 2018).

32
Applications Architecture
This sub-phase uses the same inputs as the Data Architecture sub-phase, but with
Application principles instead of Data principles (if existing) and can also use business
and data architecture components of an architecture roadmap if they are available (The
Open Group, 2018). Relevant Application Architecture resources available in the
Architecture Repository should be considered, in particular generic business models
relevant to the organization's industry "vertical" sector and application models relevant
to common high-level business functions, such as electronic commerce, supply chain
management, etc (The Open Group, 2018).

The steps in this sub-phase are the same as for Data Architecture, but applicable to
Application Architecture instead of Data Architecture.

Phase D: Technology Architecture

The development of the Technology Architecture for an architecture project, sets forth
following objectives (The Open Group, 2018):
- Development of the target Technology Architecture enabling the Architecture
Vision, target business, data, and application building blocks to be delivered
through technology components and technology services, addressing the
Statement of Architecture Work and stakeholder concerns.
- Identifying candidate architecture road map components based upon gaps
between the baseline and target Technology Architectures.

As is customary, the architecture team needs to consider what relevant Technology

Architecture resources are available in the Architecture Repository, in particular
regarding existing IT services, technology models relevant to common systems
architectures, generic technology models relevant to the organization’s industry
“vertical” sector and regarding the adopted technical reference model – if applicable
(The Open Group, 2018).

Newly introduced technology building blocks need to be defined in detail during this
phase, whereas existing technology building blocks may need to be redefined to ensure
interoperability and fit-for-purpose within this specific Technology Architecture (The
Open Group, 2018).

33
It should be determined whether in this situation it is appropriate to conduct baseline
description or target architecture development first. The steps to follow during this
phase are the same as in the previous phase, applied now to the Technology
Architecture.

Important to consider during this phase is to capture the available transformation

opportunities through the adoption of new technology (The Open Group, 2018).

Phase E: Opportunities and Solutions

Phase E describes the process of identifying delivery vehicles (projects, programs, or
portfolios) which effectively deliver the target architecture identified in previous phases
(The Open Group, 2018). Contrary to the objectives of the previous phases, the
objectives in this phase are to generate the initial complete version of the Architecture
Road map bases upon the gap analysis and candidate architecture road map
components from phases B, C and D, and to determine whether an incremental
approach is required, and if so to identify Transition Architectures to deliver continuous
business value. Furthermore, Phase E also aims to define the overall solution building
blocks to finalize the target architecture based on the Architecture Building Blocks
(ABBs) (The Open Group, 2018).

Regarding the architectural inputs, the candidate architecture road map components
from phases B, C and D are being used as additional inputs, together with change
requests for existing business programs and projects and governance models.

The steps in this phase are different from those of the previous phases:

1) Determine/Confirm key corporate change attributes

2) Determine business constraints for implementation
3) Review and consolidate gap analysis results from phases B to D
4) Review consolidated requirements across related business functions
5) Consolidate and reconcile interoperability requirements
6) Refine and validate dependencies
7) Confirm readiness and risk for business transformation
8) Formulate implementation and migration strategy
9) Identify and group major work packages

34
 10) Identify Transition Architectures
11) Create the Architecture Road map & implementation and migration plan

All initiated activities must be closed during the last step. Phase E is the initial step on
the creation of the implementation and migration plan - which is completed in Phase F -
and provides the basis of a well-considered plan that is integrated into the enterprise's
portfolio in the next phase (The Open Group, 2018).

This phase concentrates on how to deliver the architecture, taking into account the
complete set of gaps between the target and baseline architectures in all architecture
domains, and it logically groups changes into work packages within the portfolios of the
enterprise (The Open Group, 2018). “This is an effort to build a best-fit road map that is
based upon the stakeholder requirements, the enterprise's business transformation
readiness, identified opportunities and solutions, and identified implementation
constraints. The key is to focus on the final target while realizing incremental business
value.” A work package identifies a logical group of changes necessary to realize the
target architecture (The Open Group, 2018). To list individual work packages in a
timeline - which will realize the target architecture - , the Architecture Road map is used.
“The implementation and migration plan provides a schedule of the projects that will
realize the target architecture. A Transition Architecture describes the enterprise at an
architecturally significant state between the baseline and target architectures” (The
Open Group, 2018).

Phase F: Migration Planning

Migration planning is how to move from the baseline to the target architectures by
finalizing a detailed implementation and migration plan(The Open Group, 2018). The
objectives to do so, are to finalize the Architecture Road map and the supporting
implementation and migration plan and to ensure that that plan is coordinated with the
enterprise’s approach to managing and implementing change in the overall change
portfolio (The Open Group, 2018). Lastly, this phase has also the purpose to ensure
that the business value and cost of work packages and Transition Architectures is
understood by key stakeholders.

Also in this phase, the steps differ from previous phases:

35
 1) Confirm management framework interactions for the implementation and
migration plan
2) Assign a business value to each work package
3) Estimate resource requirements, project timings, and availability/delivery vehicle
4) Prioritize the migration projects through the conduct of a cost/benefit assessment
and risk validation
5) Confirm Architecture Road map and update architecture definition document
6) Complete the implementation and migration plan
7) Complete the Architecture Development Cycle and document lessons learned

All initiated activities must be closed during the last step.

The focus of this phase is the creation of an implementation and migration plan in co-
operation with the project and portfolio managers, while the previous phase provided an
incomplete Architecture Road map and implementation and migration plan, addressing
the Statement of Architecture Work (The Open Group, 2018). This phase integrates the
road map and the plan with the other change activities of the enterprise, including
assessment of the dependencies, costs, and benefits of the various migration projects.
The first version of the road map and the plan from phase E forms the basis of the final
plan that will include portfolio and project-level detail. “The Architecture Development
Cycle should then be completed and lessons learned documented to enable continuous
process improvement” (The Open Group, 2018).

Phase G: Implementation Governance

The implementation governance is closely allied to the overall architecture governance.

The objectives to achieve the implementation are to ensure conformance with the target
architecture by implementation projects and to perform appropriate architecture
governance functions for the solution and any implementation-driven architecture
change requests (The Open Group, 2018).

The steps during the Implementation Phase are:

1) Confirm scope and priorities for deployment with Development Management

2) Identify deployment resources and skills
3) Guide development of solutions deployment

36
 4) Perform EA compliance reviews
5) Implement business and IT operations
6) Perform post-implementation review and close the implementation

In this phase, all information for successful management of the various implementation
projects is brought together. Parallel with this phase, there is the execution of an
organizational-specific development process, where the actual development happens
(The Open Group, 2018).

The favored approach to enable early realization of business value and benefits, and to
minimize the risk in the transformation and migration program, is to deploy the target
architecture as a series of transitions. “Each transition represents an incremental step
towards the target, and each delivers business benefit in its own right” (The Open
Group, 2018).

Through the Architecture Contract, this phase establishes the connection between
architecture and implementation in the organization. The project details are being
developed, concerning the name, objectives, scope, deliverables, risks, effectiveness
measures, … .

Phase H: Architecture Change Management

This phase looks at establishing procedures to manage change to the new architecture.
The objectives are to ensure that the architecture lifecycle is maintained and that the
architecture governance framework is executed. Phase H has also the purpose to
ensure that the EA capability meets current requirements (The Open Group, 2018).

The steps in Phase H are:

1) Establish value realization process
2) Deploy monitoring tools
3) Manage risks
4) Provide analysis for Architecture Change Management
5) Develop change requirements to meet performance targets
6) Manage governance process
7) Activate the process to implement change

37
The goal of an architecture change management process is to ensure that the
architecture achieves its original target business value, including managing changes to
the architecture in a cohesive and architected way. “This process will typically provide
for the continual monitoring of such things as governance requests, new developments
in technology, and changes in the business environment. When changes are identified,
change management will determine whether to formally initiate a new architecture
evolution cycle” (The Open Group, 2018). Additionally, the process aims to establish
and support the implemented EA as a dynamic architecture, meaning having the
flexibility to evolve rapidly in response to changes in the technology and business
environment.

“While the architecture has been built to deliver a steady state Business Architecture
with agreed capacity during the lifecycle of the EA, the growth or decline in usage needs
to be continually assessed to ensure that maximum business value is achieved ” (The
Open Group, 2018).

The value and change management process will determine the circumstances under
which the EA - or parts of it - will be permitted to change after deployment, and the
process by which that will happen and will also determine the circumstances under
which the architecture development cycle will be initiated again to develop a new
architecture. It is critical that the governance body establishes criteria to judge whether
a change request warrants just an architecture update or whether it warrants starting a
new ADM cycle (The Open Group, 2018) .

Regarding the drivers for change, there are many technology-related drivers and
business drivers for architecture change requests. Change requests for technology
drivers are normally manageable primarily through an enterprise’s change management
and architecture governance processes. The Requests for Change (RFC) regarding
business drivers often results in a complete re-development of the architecture, or at
least in an iteration of a part of the architecture development cycle. Governance has to
handle the RFCs and there needs to be a lessons learned process, which ensures that
mistakes are made once and not repeated. The Architecture Board then assesses and
approves the RFCs (The Open Group, 2018).

38
The EA change management process needs to determine how changes are to be
managed, what techniques are to be applied, and what methodologies used and also
needs a filtering function that determines which phases of the architecture development
process are impacted by requirements. “There are many valid approaches to change
management, and various management techniques and methodologies that can be
used to manage change” (The Open Group, 2018).

Furthermore in this last phase, guidelines for maintenance are given, or for redesign of
the architecture if a refreshment cycle (partial or complete) is required. “If there is need
for a refreshment cycle, then a new Request for Architecture Work must be issued (to
move to another cycle)” (The Open Group, 2018).

Requirements Management

This phase - being the center of the ADM cycle - is a continuous phase, ensuring that
any changes to requirements are handled through appropriate governance processes
and reflected in all other phases.

“An enterprise may choose to record all new requirements, including those which are in
scope of the current Statement of Architecture Work through a single Requirements
Repository” (The Open Group, 2018).

Part 3: ADM Guidelines & Techniques

Guidelines regarding the use of different process styles and specific specialist
architectures throughout the ADM cycle include (The Open Group, 2018):

- Applying iteration to the ADM and showing potential strategies for applying it
- Applying the ADM across the Architecture Landscape, discussing the different
types of architecture engagement at different enterprise levels

The following techniques are described to support specific tasks within the ADM:

- Architecture principles for the use and deployment of IT resources across the
enterprise, setting up general rules and guidelines for the architecture being
developed

39
 - Stakeholder management, to win support for the projects of successful
architecture practitioners
- Architecture patterns guidance
- Gap analysis, widely used in ADM to validate an architecture being developed
- Migration planning techniques for phases E and F
- Interoperability requirements determination
- Business transformation readiness assessment, to identify business
transformation issues
- Risk management during an architecture/business transformation project
- Capability-based planning technique

Part 4: Architecture Content Framework

While executing the ADM, architects will produce outputs as a result of their efforts. The
Architecture Content Framework provides a structural model for architectural content,
allowing major work products to be consistently defined, structured and presented (The
Open Group, 2018).

“The Architecture Content Framework uses the following three categories to describe
the type of architectural work product within the context of use:

- A deliverable is a work product that is contractually specified and in turn formally

reviewed, agreed, and signed off by the stakeholders. Deliverables represent the
output of projects and those deliverables that are in documentation form will
typically be archived at completion of a project, or transitioned into an
Architecture Repository as a reference model, standard, or snapshot of the
Architecture Landscape at a point in time.
- An artifact is an architectural work product that describes an aspect of the
architecture. Artifacts are generally classified as catalogs (lists of things),
matrices (showing relationships between things), and diagrams (pictures of
things). An architectural deliverable may contain many artifacts and artifacts will
form the content of the Architecture Repository.
- A building block represents a (potentially re-usable) component of enterprise
capability that can be combined with other building blocks to deliver architectures
40
 and solutions. Building blocks can be defined at various levels of detail,
depending on what stage of architecture development has been reached.
Building blocks can relate to "architectures" or "solutions".
o Architecture Building Blocks (ABBs) typically describe required capability
and shape the specification of Solution Building Blocks (SBBs).
o Solution Building Blocks (SBBs) represent components that will be used to
implement the required capability.”

The relationships between deliverables, artifacts, and building blocks are shown in
figure 16 (The Open Group, 2018):

Figure 16: Relationship between deliverables, artifacts and building blocks in TOGAF

A definition of all the possible types of building blocks within an architecture, is provided
through the content metamodel, showing how these building blocks can be described
and related to one another (The Open Group, 2018). The content metamodel identifies
the concerns regarding application, data entity, technology, actor, and business service,
shows the relationships that are possible between them, and finally identifies artifacts
that can be used to represent them (The Open Group, 2018). The content metamodel is
shown below in figure 17:

41
Figure 17: The content metamodel of TOGAF

The ADM describes the process of moving from a baseline state of the enterprise to a
target state of the enterprise by addressing a business need through a process of
visioning, architecture definition, transformation planning and Architecture Governance.
At each stage in the process, ADM requires information as inputs, and creates outputs
as a result of the execution of a number of steps. The content framework provides an
underlying structure for the ADM that defines the inputs and outputs in more detail and
puts each deliverable into the context of the enterprise’s holistic architecture view.
Therefore, the content framework should be used as a companion to the ADM, whereas
the ADM describes what needs to be done to create an architecture and the content
framework describes what the architecture should look like once it is done (The Open
Group, 2018).

The TOGAF Standard includes thus a content framework to drive greater consistency in
the outputs created when following the ADM. This Content Framework provides a
42
detailed model of architectural work products. It also provides guidance on a process
that can be followed for identifying and establishing an appropriate architecture
capability (The Open Group, 2018).

Part 5: Enterprise Continuum & Tools

As an enterprise needs to deal with many related EAs in order to meet all stakeholders
requirements, the Enterprise Continuum provides a view of the Architecture Repository,
showing the evolution of these related architectures from generic to specific, from
abstract to concrete and from logical to physical. This view provides methods for
classifying architecture and solution artifacts, showing the evolution of the different
types of artifacts and how they can be leveraged and re-used (The Open Group, 2018).

“The Enterprise Continuum provides a framework and context to support the leverage of
relevant architecture assets in executing the ADM. These assets may include
architecture descriptions, models, and patterns taken from a variety of sources” (The
Open Group, 2018). It categorizes architectural source material – the contents of the
organization’s own enterprise repositories as well as the set of relevant, available
reference models and industry standards.

The Enterprise Continuum includes the Architecture Continuum and the Solutions
Continuum, and describes how architectures can be partitioned and organized within a
repository. The Architecture partitioning describes the various characteristics being
applicable to classify and to then partition architectures. Finally the Enterprise
Continuum also describes tools for developing architecture, providing guidelines to
select a toolset for creating and managing architectural artifacts (The Open Group,
2018).

The practical implementation of the Enterprise Continuum typically takes the form of an
Architecture Repository, including reference architectures, models, and patterns
accepted for use within the enterprise, and actual architectural work done previously
within the enterprise. This can be used for storing different classes of architectural
output at different levels of abstraction, which is created by the ADM (The Open Group,
2018).

43
At relevant places throughout the ADM, there are reminders to consider which - if any -
architecture assets from the Architecture Repository should be used. During the use of
ADM, at particular points in time, the architect develops a snapshot of the decisions of
the enterprise and their implications. Each ADM-iteration will populate an organization-
specific landscape, identified with all the architecture assets and leveraged through the
process, including the final organization-specific architecture delivered. Since
architecture development is a continuous, cyclical process and since the ADM gets
executed repeatedly over time, the architect gradually adds more and more content to
the Architecture Repository. Although the primary focus of ADM is on the development
of the enterprise-specific architecture, the ADM can – in this wider context - also be
seen as the process of populating the enterprise’s own Architecture Repository with
relevant re-usable building blocks taken from the more generic side of the Enterprise
Continuum (The Open Group, 2018).

Part 6: Architecture Capability Framework

“In order to successfully operate an architecture function within an enterprise, it is

necessary to put in place appropriate organization structures, processes, roles,
responsibilities, and skills to realize the Architecture Capability. The Architecture
Capability Framework provides a set of reference materials for how to establish such an
architecture function.” This framework includes an elaboration of Architecture
Compliance, Architecture Contracts, Architecture Governance, Architecture Board,
Architecture Maturity Models and Architecture Skills Framework (The Open Group,
2018).

An overall structure for the Architecture Capability Framework is shown in figure 18:

44
Figure 18: An overall structure for the Architecture Capability Framework of TOGAF

45
Comparison COBIT 2019 and TOGAF 9.2

Methodology
The purpose of this dissertation is to try to align COBIT with EA. As EA is a broad
concept, TOGAF has been chosen as framework within EA, whereas COBIT is a
framework regarding the IT governance of an enterprise. Since COBIT refers to TOGAF
as reference for establishing EAs and since TOGAF is used by the world’s leading
organizations to improve business efficiency (The Open Group, 2018), TOGAF has
been chosen as framework to represent EA.

In order to answer the research question “What are the similarities and dissimilarities
between COBIT 2019 and TOGAF 9.2?” a comparison will be made between the two
frameworks, each representing another concept of the enterprise (EA versus IT
governance). For both frameworks, the most recent version is used, namely TOGAF
Version 9.2 and COBIT 2019. It should be mentioned that the results from this
comparison are only applicable to these two frameworks specifically, and are not
generalizable to EA and IT Governance as general concepts. Both EA and IT
Governance encompass many frameworks, which means that quite different results can
be obtained when comparing other frameworks.

The research is divided into three parts: firstly, I will look for existing comparisons in the
literature, then I will draw a concept map for TOGAF 9.2 (since there has already been
drawn one for COBIT 2019) to compare the high-level components of COBIT 2019 and
TOGAF 9.2. After explaining and comparing the high-level structure of both frameworks,
I will made a more detailed comparison of some specific content.

Part 1: Literature review

First, existing comparisons between COBIT 2019 and TOGAF Version 9.2 were looked
for in the literature. While performing this literature review to seek for (dis)similarities,
not much existing literature has been found. Three scientific search engines were used,
namely Web of Science (WoS), SCOPUS and Google Scholar.

46
Firstly, each digital library was queried with the most specific keywords, namely “COBIT
2019” AND “TOGAF 9.2”. Unfortunately, both WoS and SCOPUS came with no results.
Google Scholar on the other hand, gave 181 results, which had been reduced to 74
results after refining to papers dating since 2018 and written in English (since both
COBIT 2019 and TOGAF 9.2 were developed in 2018, only results dating starting from
that time period will be considered valid).

The second search entry was performed with the keywords “COBIT 2019” AND “ADM”:
WoS gave 2 results, but one was using COBIT 5 instead of COBIT 2019 and the other
had no free availability. SCOPUS gave no match for the terms. Again Google Scholar
came out with 187 results since 2018, written in English.

Furthermore, a lot of combinations were made using indexes such as “COBIT 2019”
AND “TOGAF”, “COBIT” AND “TOGAF 9.2”, “COBIT” AND “ADM”, “COBIT processes”
AND “ADM”, “COBIT domains” AND “TOGAF 9.2”, “COBIT objectives” AND “TOGAF
9.2”, etc., but either there were no matches found, or the publication was made on a
previous version of COBIT or TOGAF, or the results were outdated (since COBIT 2019
and TOGAF 9.2 were both developed in 2018, only results starting from that date were
considered valid) or no freely available edition was found. Nevertheless, results were
found in SCOPUS using the index “COBIT” AND “TOGAF”, “COBIT processes” AND
“TOGAF” and ”COBIT objectives” AND “TOGAF”. All queries and results are gathered in
table 1.

Table 1: COBIT and TOGAF search queries (literature review)

Search entry Search Refinement Results Useful papers

engine
COBIT 2019 WoS / None None
AND TOGAF
9.2
SCOPUS / None None
Google Since 2018 74 - “A built-in criteria
Scholar AND English analysis for best IT
governance framework”
- “Enterprise Architecture
Frameworks

47
 Assessment:
Capabilities, Cyber
Security and Resiliency
Review”
- “Toward a
comprehensive IT
management
methodology”
- …

COBIT 2019 WoS / 2 None

AND ADM
SCOPUS / None None
Google Since 2018 187 - “Toward a
Scholar AND English comprehensive IT
management
methodology”
- …

COBIT 2019 WoS / 2 None

AND TOGAF
SCOPUS / 1 None
COBIT AND WoS / None None
TOGAF 9.2
SCOPUS / None None
COBIT AND WoS Publication 2 None
TOGAF year 2019
SCOPUS Publication 6 - “A built-in criteria
year 2019 OR analysis for best IT
2020 OR 2021 governance framework”
- “Enterprise Architecture
Frameworks
Assessment:
Capabilities, Cyber

48
 Security and Resiliency
Review”
COBIT AND WoS Publication 6 None
ADM year 2018 OR
2019 OR 2021
SCOPUS / 3 None
COBIT WoS Publication 4 none
processes year 2019 OR
AND ADM 2021
SCOPUS / 1 none
COBIT WoS Publication 1 None
processes year 2019
AND TOGAF
SCOPUS Publication 4 “Enterprise Architecture
year 2019 OR Frameworks Assessment:
2021 Capabilities, Cyber Security
and Resiliency Review”
COBIT WoS / None None
processes
AND TOGAF
9.2
SCOPUS / None None
COBIT WoS Publication 1 None
domains year 2019
AND TOGAF
SCOPUS Publication 1 None
year 2019
COBIT WoS / None None
domains
AND TOGAF
9.2
SCOPUS / None None
COBIT WoS / 1 None

49
domains
AND ADM
SCOPUS / None None
COBIT WoS Publication 1 None
objectives year 2019
AND TOGAF
SCOPUS Publication 4 - “A built-in criteria
year 2019 OR analysis for best IT
2020 OR 2021 governance framework”
- “Enterprise Architecture
Frameworks
Assessment:
Capabilities, Cyber
Security and Resiliency
Review”
COBIT WoS / None None
objectives
AND TOGAF
9.2
SCOPUS / None None
COBIT WoS Publication 3 None
objectives year 2019 OR
AND ADM 2021
SCOPUS / 1 None

In the cross-section of useful papers found with the above mentioned queries in the
three digital libraries, three papers were gathered giving significant results regarding a
comparison between COBIT 2019 and TOGAF 9.2.

Paper “A Built-in Criteria Analysis for Best IT Governance Framework” (Ibrahim and
Abdessamad, 2019)
This useful paper aimed to provide a decision-making system that allows professionals
to choose the IT governance framework suitable to desired criteria. They tried to build
an integrated meta-model for a better approach of IT Governance. The goal was to

50
provide this approach based on existing models and to complement this with other best
practices in several IT domains. The decision system is based on a multi-criteria
analysis method that weighs the criteria so companies can choose the framework based
on their needs. The multi-criteria analysis between the frameworks showed that there is
no governance framework which meets all governance criteria, but COBIT is the most
completed (Ibrahim & Abdessamad, 2019). Although this paper is also based on COBIT
5, results are considered valid since recent updates improve the framework, so if the
previous version already covers 65% of the foundations of a good governance (Ibrahim
& Abdessamad, 2019), the most recent version must at least reach this level to be an
improvement. The authors found that regarding the governance components, COBIT
responds best to strategic alignment, given its commitment to corporate values with a
clear definition of the processes, so allowing a comprehensible vision by the
management of what is done by the company (Ibrahim & Abdessamad, 2019).
Furthermore, value creation as governance component is present in each framework,
since it is the essence of the implementation of IT in the company whatever the chosen
framework (Ibrahim & Abdessamad, 2019).
It is conducted of this research that there is no complete repository of IT governance,
however the most complete reference is COBIT given the positions it takes on each of
the components (Ibrahim & Abdessamad, 2019).

Even before the analysis, a comparative study was performed between the different
frameworks specifying their strengths and weaknesses.
Although the authors used COBIT 5 for this paper, the advantages they summed up
concern the COBIT principles, which remain the same for the recent version. The
disadvantages are the difficulty of the implementation and the fact that the management
guide is unknown in the framework.
The advantages of TOGAF 9.2 involve the achievement of a better product quality, the
use of a common framework to facilitate the search for skills, the strength of the IS, the
maximization of IT value and the fact that TOGAF provides a common language within
the company (Ibrahim & Abdessamad, 2019). Similarly, COBIT provides also a common
single framework - but for governing IT in the enterprise – and also maximizes IT value.
The drawback of TOGAF 9.2 is that it does not cover management processes (Ibrahim
& Abdessamad, 2019), whereas COBIT 2019 does.

51
Paper “Enterprise Architecture Frameworks Assessment: Capabilities, Cyber Security
and Resiliency Review” (Al-Turkistani et al., 2021)
This similar research aimed to perform a comparison in order for enterprise architects to
choose the best suitable EA framework (or combination of frameworks). Business
capabilities in – among others – TOGAF 9.2 and COBIT 2019 were selected and
evaluated, and essential security requirements were identified by comparing their
resiliency processes.
After review of a number of existing EA frameworks (EAFs), the study suggests that
there is no ideal framework that can totally fulfil all business and security requirements.
Enterprises need to choose a framework which is flexible to tailor according to the
business needs, security requirements and cyber resiliency, and at the same time
having maximize return on investment, optimize risk and resources (Al-Turkistani et al.,
2021).

Although TOGAF clearly addresses security procedures in ADM, it does not create
security architecture, which results in absence of complete security guidelines. TOGAF
considers security as a secondary action which is merged with data architecture,
highlighting that data security should be planned at the beginning of system
development and could not be added later (Al-Turkistani et al., 2021) . Furthermore,
TOGAF does not develop a cyber resistance approach, being the most important
compound of EAF that enables to fight successfully against cyberattacks(Al-Turkistani
et al., 2021).
COBIT on the other hand, groups its managerial objectives into four domains which
satisfies several security requirements (ISACA, 2018b):
- APO13 ‘Managed security risks’ to keep the impact and occurrence of
information security incidents within the enterprise’s risk appetite levels.
- DSS05 ‘Managed security services’ to minimize the business impact of
operational information security vulnerabilities and incidents.
- DSS06 ‘Managed business process controls’ to maintain information integrity and
the security of information assets handled within business processes in the
enterprise or its outsourced operation.

Furthermore, to ensure compliance with security standards, COBIT implements ‘US

National Institute of Standards and Technology’ (NIST) standards. But despite COBIT’s

52
comprehensive framework, it does not provide an information security resilience
approach, neither mentions it in its documentation (Al-Turkistani et al., 2021) . So
COBIT 2019 also does not fulfil all information security requirements criteria (Although
COBIT does provide a publication about the focus area ‘IT risk’ and ‘Information
security’!).

The evaluation of the EAF’s showed that EAF’s are not perfect and have also their
weaknesses. TOGAF for example is considered loose in that the contributions are not
integrated tight enough and that the nonessentials often cloud the essentials. On the
other hand, the COBIT framework is majorly limited by its high cost, since it needs a lot
of knowledge and skills to be implemented, which may not be feasible for many
organizations (Al-Turkistani et al., 2021).
If organizations decide to implement EAF in their environment by focusing to fulfil a gap
analysis, TOGAF is the most capable framework, whereas COBIT can satisfy the
requirement of enhancing the Data Architecture (Al-Turkistani et al., 2021).

Table 2: Comparison COBIT 2019 vs TOGAF 9.2 from useful literature

Paper COBIT 2019 TOGAF 9.2

A Built-in Covers at least 65% of the Governance components:
Criteria foundations of good - Value creation
Analysis for governance.
Best IT Governance components: Advantages:
Governance - Value creation - Better product quality
Framework - Strategic alignment - Common framework to
(Ibrahim and (COBIT responds best facilitate the search for skills
Abdessamad, to this) - Maximize IT value
2019)  Most complete - Common company
reference concerning IT language
governance - Strength of the IS

Advantages: ‘principles’ Disadvantages:

- Meeting stakeholder’s - Does not cover
needs management processes
- Covering the entire

53
 company from end to
end
- A single framework
- Holistic approach to
business decision-
making
- Separating
management from
governance

Disadvantages:
- Difficulty of
implementation
- Unknown management
guide in the framework.
Enterprise Advantages: Disadvantages:
Architecture - Management objectives - No complete security
Frameworks concerning security guidelines because no
Assessment: requirements: creation of technology
Capabilities, ➔ APO13 ‘managed architecture
Cyber security risks’ ➔ Security as ‘secondary’
Security and ➔ DSS05 ‘managed action, merged with data
Resiliency security services’ architecture
Review (Al- ➔ DSS06 ‘managed - No development of a cyber
Turkistani et business process resistance approach
al., 2021) controls’ - No integrated contributions
- NIST standards for (nonessentials often cloud
compliance with the essentials)
security standards

Disadvantages:
- No information security
resilience approach

54
 - High cost due to lots of
skills and knowledge

Paper “Toward a Comprehensive IT Management Methodology” (Samiei and Habibi,

2022)
This research paper tried to answer if a comprehensive IT management methodology
could be proposed to make use of the concepts of different IT management frameworks
in order to provide organizations with the same outputs and artifacts at lower cost and
effort. This to avoid redundancies and costs of implementing each framework
separately. Among others, EA and COBIT were chosen as samples of most acclaimed
and adopted IT management frameworks (Suryawan & Veronica, 2018). A comparison
between the components was made, but since this paper still used the previous version
of COBIT, namely COBIT 5, and changes were made to some components in the recent
version, this paper is considered invalid. Especially because “COBIT 2019 resembles
more to COBIT 4 than to COBIT 5” (dixit professor Geert Poels, personal
communication, 25th of February 2022), the results from this research would not be
relevant in the comparison. This paper highlights again that almost no research has
been done regarding a comparison of the most recent versions of the COBIT and
TOGAF framework.

Due to this limited literature review, I tried to make a contribution by performing a high-
level structural comparison and a more detailed content comparison in the following
sections.

Part 2: High-level comparison

Because of this lack of useful papers concerning a comparison between the two latest
versions of COBIT and TOGAF, I made a high-level comparison of the key components
myself, based on the official documentation of both frameworks.
As the paper of Proper et al. (2021) already made a concept map of COBIT 2019 (see
figure 19), I tried making one for TOGAF 9.2 as you can see in figure 20.

55
Figure 19 contains the concepts of COBIT’s main guidance towards IT governance
practitioners with the key concepts concerning governance components, governance
and management objective, governance and management domain, focus area,
processes, governance and management practice, and activity (Proper et al., 2021).
Figure 20 contains the concepts of TOGAF’s main guidance towards EA architects with
the key concepts concerning the 6 parts, the ADM instances, the Architecture Content,
the Architecture Capabilities and the Architecture Repository.

56
Figure 19a: Concept map of COBIT 2019

57
Figure 19b: Concept map of COBIT 2019

58
Figure 20: Concept map of TOGAF 9.2

59
Putting the two concept maps next to each other, the high-level structure of both
frameworks become clear. Table 3 gives the comparison between COBIT 2019 and
TOGAF Version 9.2, regarding their high-level structure and components.

Table 3: High-level comparison COBIT 2019 and TOGAF 9.2

COBIT 2019 TOGAF 9.2

Core: governance and management Core: Part 2 – ADM phases
objectives ➔ Description + purpose
➔ Description + purpose ➔ “Components”:
➔ Components: - Objectives
- Process - Inputs
- Organizational structure - Outputs
- Information flow and items - Steps
- Policies and procedures - Approach
- Services, infrastructure and
applications
- People, skills and
competencies
- Culture, ethics and behavior

The COBIT Framework consists of the The TOGAF Standard consists of the
Introduction & Methodology publication, TOGAF Series Guides, the TOGAF
the COBIT Design Guide, the COBIT Library and the TOGAF Fundamental
Implementation Guide and the COBIT Content. The latter is divided in 6 parts,
Core Model publication, which in which the second part represent the
represents 40 objectives divided over 5 ADM, being the core of the standard.
domains.
TOGAF does not work with “focus
This Core Model is an instance of a areas”, although it must be mentioned
focus area. The configuration of an EA that enterprises are not required to
(for which TOGAF is used), could be perform the whole ADM cycle, but can
seen as a (future) focus area in COBIT cherry pick the phases they need. That
(see discussion and limitations section). could be seen as a form of ‘focus area’.
The objectives support the alignment No explicit goals cascade.

60
goals, which support the enterprise
goals (a clear goals cascade is drawn
and followed in COBIT).
The COBIT objectives refer to related The TOGAF Reference Models from the
guidance, which can be other TOGAF Library refer to other models,
frameworks, standards (such as frameworks (such as COBIT) and
TOGAF) or compliance requirements. standards to be used while executing
the ADM.
The components ‘People, skills and Part 6 of the TOGAF Fundamental
competencies’ and ‘Organizational Content represents the Architecture
structures’ in COBIT explain what and Capability Framework, explaining the
who are needed to develop the skills, roles, responsibilities and
activities/practices. processes needed to develop an EA.
The components ‘Ethics, culture and Not found in the TOGAF Standard,
behavior’ and ‘Services, infrastructure although these are important things to
and applications’. consider when developing an EA! This
is another suggestion to implement in a
future TOGAF release.
Example metrics are provided for each No metrics are given with the
practice. phases/steps.
COBIT provides a management Part 5 – Enterprise Continuum and
objective regarding ‘Managed EA’ within Tools provides an Architecture
the APO domain and the objective Repository to manage related EAs and
‘Managed assets’ regarding the BAI inputs and outputs. This Architecture
domain, to ensure the management of Repository embodies sources and
multiple EAs and assets (inputs and outputs from anywhere, so also from
outputs). another framework like COBIT.
The ‘Managed requirements definition’ Part 4 – the Architecture Content
(BAI) objective and the ‘Managed Framework, in which TOGAF content is
solutions identification and build’ (BAI) categorized as deliverables, artifacts
objective in COBIT try to achieve what and/or building blocks. This ensures the
the Architecture Content Framework is consistent definitions and structure of
meant for in TOGAF, namely ensuring the inputs and outputs.

61
consistent definitions.
On of COBIT’s core publications: Part 1 – high level introduction of the
Introduction and Methodology key concepts and definitions of the
terms
Tailoring is done through design factors, Tailoring by taking elements from other
defined by the design process (COBIT frameworks such as COBIT
Design Guide). (ADM can, but does not necessary need
to be tailored!)
Performance management through TOGAF also uses the concept of
capability and maturity levels for the maturity levels to assess the EA
activities and focus areas. processes and provides Capability
Maturity Models in the ‘Architecture
Maturity Models’ - part of the
Architecture Capability Framework
Suggestion for COBIT: value stream Part 2 – ADM Phase B Business
mapping Architecture → represents
multidimensional views of capabilities,
info, organizational structures, policies,
…
➔ Organizational mapping
➔ Value stream mapping
➔ Capability mapping
COBIT Implementation Guide; Part 3 - ADM Guidelines and
describing techniques and a road map Techniques providing the gap analysis,
for governance improvement + COBIT migration planning, risk management,
focus area ‘IT risk’ for risk management road map for EA development, …
Integrates standards, such as TOGAF. “ADM can be regarded as a description
of a process lifecycle operating within a
holistic governance framework”, such as
COBIT.

You can compare certain COBIT objectives with TOGAF ADM phases (see the next
section regarding the content comparison), since both concepts represent certain goals
to reach, explained by a description, a purpose and components to achieve that goal.

62
The objectives, inputs, outputs, steps and approach which is stated in each phase of the
ADM cycle in TOGAF, can be seen as what are called “components” in COBIT. The
objectives for each TOGAF phase can be seen as an objective elaborated in COBIT,
whereas the inputs and outputs can be compared to the ‘Information flow and items’-
component in COBIT. This component gives also inputs (also external input) and
outputs to be used to reach the objective. In each ADM phase, steps are summed up to
walk through to reach the objectives of the phase. This can be compared to the
activities and/or practices summed up for each process to reach the COBIT objective.
Furthermore, the approach explained in each TOGAF phase on how to proceed to
reach the purpose of the phase, is comparable to the processes belonging to each
objective, also explaining how to reach the purpose of the objective.

The research of Moscoso-Zea et al. in 2019 about the role of EA as a management tool,
concluded that EA can support most of the existing management tools and techniques,
stating that EA represents the foundations on which other practices can be designed
and implemented. COBIT can be seen as the holistic governance approach that
integrates other frameworks and standards, such as TOGAF.

In the next section, a detailed comparison will be made between the TOGAF phases
and some COBIT objectives, especially the ‘Managed EA’ objective from the APO
domain.

Part 3: Detailed comparison

Now, to dive a little deeper, a more detailed comparison has been made regarding
some specific content of the frameworks. As the high-level comparison shows how
certain COBIT objectives (or processes within an objective) are woven into certain
TOGAF phases, I will now elaborate on some of those. This dissertation will not explain
every (dis)similarity between COBIT 2019 and TOGAF 9.2 in detail, but will elaborate
these processes who specifically refer to TOGAF 9.2 as related guidance.

63
Table 4: Content comparison COBIT 2019 and TOGAF 9.2: APO03

COBIT 2019 IS REFERRED TO TOGAF 9.2

Domain Objective Practice Phase
APO 03 - 01 – Develop A – Architecture
Managed EA the EA vision Vision
02 – Define B – Business
reference Architecture; C –
architectures Information
Systems
Architectures; D –
Technology
Architecture
03 – Selection E – Opportunities
of opportunities and solutions
and solutions
04 – Define F – Migration
architecture planning
implementation
05 – EA G–
services Implementation
governance; H –
Architecture
change
management

It appeared that only the third objective (APO03 – Managed EA) within the Align, Plan
and Organize (APO) domain explicitly refers to TOGAF 9.2. This management objective
aims to establish a ‘managed EA’, which means establishing a common architecture
that consists of business process, information, data, application and technology
architecture layers. It aims to create key models and practices that describe the
baseline and target architectures, in line with the enterprise and I&T strategy. The
purpose of this objective is to represent the different building blocks that make up the
enterprise and its interrelationships as well as the principles guiding their design and
evolution over time (ISACA, 2018b).

64
The first component of this management objective, namely the process for achieving the
objective, is based on management practices. The first practice (APO03.01) is to
develop the EA vision, which provides a first-cut, high-level description of the baseline
and target architectures, covering the business, information, data, application and
technology domains. The architecture vision describes how the new capabilities will
meet enterprise goals and strategic objectives and address stakeholder concerns when
implemented (ISACA, 2018b) .

To execute this practice, multiple activities are given to achieve the development of the
EA vision: regarding the second capability level, there is among others the activity to
understand current enterprise strategic goals and objectives and to work within the
strategic planning process to ensure that I&T-related EA opportunities are leveraged in
the development of the strategic plan. To reach the higher capability level (level 3), an
EA concept business case and outline plans and statement of architecture work should
be developed. The approval to initiate a project aligned and integrated with the
enterprise strategy should be secured. For this practice, related guidance from TOGAF
9.2 is provided, more detailed in phase A Architecture Vision.
When compared to what TOGAF explains in Phase A, the similarity is not neglectable.
Phase A also has the purpose to develop an Architecture Vision, being a first-cut, high-
level description of the baseline and target architectures. One of the steps described in
Phase A is also to understand current enterprise strategic goals and objectives. The
statement of architecture work is a milestone to develop in this phase.

The second management practice (APO03.02) to achieve the third APO objective, aims
to define reference architectures, so describing the current and target architectures for
the business, information, data, application and technology domains(ISACA, 2018b) .
This can be done by – among others – performing a gap analysis between baseline and
target for capability level 3. The related guidance from TOGAF 9.2, describes this
process in detail in Phase B Business Architecture, Phase C Information Systems
Architectures (Data and Application Architecture) and Phase D Technology
Architecture.
The gap analysis technique between baseline and target architecture, is a technique
well-described and well-used in TOGAF, for (at least) the above-mentioned phases,

65
regarding the development of the different architectures. Although COBIT mentions this
technique in several activities throughout the objectives, it does not explain how the gap
analysis is to be performed, whereas TOGAF does describe how to execute the
analysis.

The third management practice (APO03.03) represents the selection of opportunities

and solutions, which aims to rationalize the gaps between baseline and target
architectures, and to logically group them into project work packages(ISACA, 2018b) .
One of the activities for capability level 3 is to identify any enterprise drivers that would
constrain the sequence of implementation and to include a review of enterprise and line-
of-business strategic and business plans.
This is in line with the related TOGAF guidance about Phase E Opportunities and
solutions, regarding the consolidation of the gap analysis’ between baseline and target
architectures and grouping them into work packages. Also the formulating activity/step
of the implementation and migration strategy and the development of transition
architectures is similar. But Phase E in TOGAF is even more extensive than this
practice, creating the initial complete version of the architecture road map and defining
the overall solution building blocks.

The fourth practice (APO03.04) is to define architecture implementation, which means

creating a viable implementation and migration plan(ISACA, 2018b).
The activity to reach capability level 3 is to update the architecture definition document.
This activity is explained in detail in TOGAF 9.2, and Phase F Migration planning is the
detailed reference given in COBIT. Again, this phase is more elaborated in the TOGAF
documentation, adding that the business value and cost of work packages and
transition architectures should be understood by key stakeholders. One of the steps
mentioned is to assign a business value to each work package and to prioritize the
migration projects through the conduct of a cost/benefit assessment and risk validation.
Also here (in TOGAF) it is mentioned to update the architecture definition document.
Differently to this practice in COBIT, in phase F it is also described to complete a
document Lessons Learned, which I think would be a valuable addition to the COBIT
documentation.

The fifth management practice (APO03.05) provides EA services, including guidance to

and monitoring of implementation projects, formalizing ways of working through
66
architecture contracts, and measuring and communicating architecture’s value and
compliance monitoring (ISACA, 2018b).
Starting from capability level 3, EA requirements should be managed and business and
IT should be supported with advice and expertise on architectural principles, models
and building blocks. It should be guaranteed that new implementations (as well as
changes to current architecture) align with EA principles and requirements. Also the
portfolio of EA services should be managed and the alignment with strategic objectives
and solution development should be ensured. To reach the higher capability level (level
4), EA priorities should be identified and aligned to value drivers (similarly described in
Phase G). Defining and collecting value metrics and measuring and communicating the
value of EA is also an activity in this regard. Phase G Implementation governance and
Phase H Architecture change management are listed as related guidance here.
Although this practice refers again to some specific TOGAF phases, it forgets the
metrics-part. Where can value metrics be found in TOGAF and how to communicate the
value of EA? TOGAF does not include any of those metrics, but it does show the value
stream of EA, something that is not present in COBIT. So TOGAF lacks metrics,
whereas COBIT lacks value stream mapping.

Although this detailed comparison is based on a comparison between the COBIT

component processes within certain objectives (together with some practices and
activities) and the TOGAF ADM phases, the other components of this specific objective
also refer to TOGAF concepts.

One of those concepts concern the function of the Architecture Board, used in COBIT
for the second component of this objective, namely the organizational structures. This
Architecture Board, as part of the roles and organizational structures in COBIT, is
described as “A group of stakeholders and experts accountable for guiding enterprise
architecture-related matters and decisions and for setting architectural policies and
standards”. Strangely enough, TOGAF 9.2 does not include this term in its list of
definitions, but devotes a whole chapter to this concept in part 6 regarding the
Architecture Capability Framework.

The third component ‘Information flows and items’ gives inputs for the practices, in order
to reach certain outputs. For example for the first management practice, it takes the
67
guiding principles for EA as inputs coming from EDM04.01, to reach the architecture
concept business case and value proposition as outputs (APO02.05 and APO05.02).
For this component can be looked into the inputs and outputs from Phase A to Phase H
in TOGAF.

The fourth component regarding policies and procedures, mentions the architecture
principles as relevant policy, and refers directly to the architecture principles of TOGAF
9.2. These principles ensure the alignment of current and target architecture with
enterprise objectives and strategy.

The culture, ethics and behavior component states that effective practice of EA should
be driven throughout the organization, and not only by enterprise architects (ISACA,
2018b). That statement represents the key culture element of this objective.
As mentioned earlier, I did not find any resemblance of a culture/ethics/behavior part in
TOGAF, although I think this is an important issue in enterprises and society in general!

The last component ‘Services, infrastructure and applications’ refers to the Architecture
Repository, directly referring to the Architecture Repository developed in TOGAF, since
COBIT does not foresee an Architecture Repository to gather the inputs and outputs.

Summarized, this third management objective within APO, contains all phases of the
TOGAF ADM cycle, but does not explicitly refer to the Preliminary Phase and the
Requirements Management phase. Nonetheless, the 7 phases of the COBIT
Implementation Approach mention to define and monitor the drivers at any time in the
process and to ‘keep the momentum going’ by reviewing and providing checkpoints at
each phase to ensure performance (ISACA, 2018a). But regarding the preparation of
the processes, COBIT refers many times to another standard.
Besides the fact that this single objective embodies nearly the whole core of the TOGAF
Standard, it also uses other concepts of TOGAF, namely the (re-)use of building blocks,
the use of an architecture definition document, architecture principles, the Architecture
Board, the Architecture Repository and the Statement of Architecture Work.
It is astonishing to see how one single objective contains almost a whole standard! This
makes it obvious that COBIT acts as the overarching governance/management

68
framework wherein other frameworks and standards can be used/elaborated, such as
TOGAF.

Although the APO objective ‘managed EA’ is the only objective which explicitly refers to
TOGAF 9.2, there are other objectives who refer to EA in general, for which a mapping
to TOGAF 9.2 might be possible and interesting for future research.

Table 5: Content comparison COBIT 2019 and TOGAF 9.2: EDM04, APO02, APO04, BAI02 and BAI03

COBIT 2019 CAN BE TOGAF 9.2

COMPARED TO
Domain Objective Practice Concepts
EDM 04 – 01 – Evaluate Business and
Ensured resource architecture principles
resource management
optimization
APO 02 – 04 – Conduct a Phase E
Managed gap analysis Opportunities and
strategy solutions; gap
analysis technique
05 – Define the Phase F Migration
strategic plan and planning; roadmap
roadmap technique
04 – 06 – Monitor the Phase H Architecture
Managed implementation Change Management
innovation and use of
innovation
technologies
BAI 02 – 01 – Define and Requirements
Managed maintain Management;
requirement business Preliminary Phase
s definition functional and
technical
requirements
03 – 01 – Design high- Requirements
Managed level solutions Management;

69
 solutions and align them Preliminary Phase
identification with the IT
and build strategy and EA

Within the EDM domain for example, the fourth governance objective ‘ensured resource
optimization’ provides a governance practice (EDM04.01) to evaluate resource
management by – among others – defining principles for the management and control
of the EA (capability level 3). To help defining these principles, the TOGAF
documentation regarding the architecture and business principles could be useful.

The second APO objective ‘managed strategy’ is to provide a holistic view of the current
environment, the future direction and initiatives to migrate to the desired future
environment. It is also about assessing current digital maturity and developing a road
map to close the gaps and leveraging EA building blocks, governance components and
the organization’s ecosystem (ISACA, 2018b) .
The fourth management practice (APO02.04) is to conduct a gap analysis, so identifying
gaps between current and target environments and describing the high-level changes in
the EA. Activities to perform that practice, are describing the high-level changes in EA
(capability level 3) and considering the value of potential changes to business and IT
capabilities, I&T services and EA, and the implications if no changes are realized
(capability level 4).
The fifth management practice is to then define the strategic plan and road map, which
defines the incremental steps required to achieve the goals and objectives (ISACA,
2018b).
Similarly as the third APO objective ‘managed EA’, this objective could also be guided
by TOGAF Phase E Opportunities and solutions and F Migration planning and by the
TOGAF principles regarding the development of a road map and performing a gap
analysis.

The fourth APO objective thrives for ‘managed innovation’ to influence strategic
planning and EA decisions (ISACA, 2018b). Practice 6 ‘monitor the implementation and
use of innovation’ can be reached by – among others – assessing new technology or IT
innovations implemented as part of IT strategy and EA development (capability level 4).
This could be guided by Phase H regarding Architecture Change Management,

70
ensuring to establish a dynamic architecture so that changes in for example technology
fall into line.

Also the BAI domain has some references to the maintenance/establishment of EA: the
second management objective ‘managed requirements definition’ is to identify solutions
and analyze requirements before acquisition or creation to align with enterprise strategic
requirements. The first practice is to define and maintain business functional and
technical requirements by ensuring requirements meet enterprise policies and
standards, EA, strategic and tactical IT plans, in-house and outsourced business and IT
processes, security requirements, people competencies, organizational structure,
business case, and enabling technology (capability level 3). Another activity for this
capability level is to track and control scope, requirements and changes through the life
cycle of the solution as understanding of the solution evolves. This objective could be
seen as a combination of the continuous Requirements Management Phase and the
Preliminary Phase in TOGAF, so defining the requirements at the beginning of a cycle
and maintaining/adapting the changes in requirements throughout the whole cycle.

The third BAI objective ‘managed solutions identification and build’ is about establishing
and maintaining identified products and services in line with enterprise requirements.
Configuration, test preparation, testing, requirements management and maintenance of
business processes, applications, information/data, infrastructure and services should
all be managed (ISACA, 2018b). The first given practice to achieve the objective, is to
design high-level solutions and align them with the IT strategy and EA. It also states to
reassess and update the designs when significant issues occur during detailed design
or building phases, or as the solution evolves. This is done by – among others –
establishing and creating a design that meets/is consistent with business and EA
requirements (capability level 2). This practice/objective – even more than the previous
one – could also be seen as the combination of Requirements Management and the
Preliminary Phase of TOGAF.

71
Limitations & suggestions
As De Haes et al. already stated in 2013, the COBIT approach is only partial sampling
of real-world conditions, so there is research needed to understand the relationship
between prescriptions of COBIT and real world conditions. Up until now, still little
research has been done regarding real-life studies to develop some use cases of both
the COBIT and the TOGAF framework, in order to write down guidelines or best
practices for implementation. Samiei and Habibi (2022) recently confirmed this issue,
stating that “research in this area is mostly theory-based and less empirical.” Mappings
between the frameworks are based on abstract concepts and lack references to actual
observations and experiences.

Furthermore as literature shows, both frameworks offer a lack of security, so the content
of COBIT 2019 and TOGAF 9.2 should focus more on building a resilient cyber
approach beyond protecting, detecting and preventing, since security risk are rapidly
increasing.
More suggestions to study in future research, could be to model an explicit goals
cascade in TOGAF, similarly as the one provided in COBIT. Whereas a document
Lessons Learned as in TOGAF should be provided in COBIT.
Furthermore, the design process for COBIT could be related to the ADM of TOGAF, so
a comparison between the COBIT design process and the TOGAF ADM phases could
be developed, since the purpose of TOGAF is to develop and establish an effective EA,
whereas the purpose of COBIT could be seen as the development of an effective IT
governance system.

During the research, I noticed that COBIT does not mention how to use the related
guidance it refers to. Since TOGAF provides a useful reference and starting point to be
mapped to other content frameworks (The Open Group, 2018) it would be interesting to
create a mapping between the two frameworks. That way, the COBIT framework could
be extended and so enterprises could use COBIT as ‘all-in-one’ package, containing a
full overview of how to implement the processes. The problem for enterprises making
double costs when implementing IT governance and establishing EA, would be solved
by integrating the two frameworks into one model.

72
To align COBIT and TOGAF more in detail, there are – in my opinion – multiple options:
Up until now, the alignment stops by just referring to the other framework as
“framework/standard with which you can comply with, which you can integrate with”
(The Open Group, 2018). COBIT goes a little further, and also gives a detailed
reference to which specific part of TOGAF (mostly a specific phase of the ADM) can be
helpful to use. COBIT tells WHERE to look, but not HOW to look. That is why I think it
would be interesting to make the mapping between COBIT 2019 and TOGAF 9.2, to
make a direct connection between the two frameworks, so COBIT and TOGAF could be
implemented coming from the same source/basis. Not only would this be cost-saving,
but also time-saving, since it would avoid the overlap (as shown in this dissertation)
between the two frameworks. Creating the mapping and maybe eventually developing
one framework which contains both COBIT and TOGAF, would be the ultimate goal for
a better alignment.

Seeing this as end game, we could first make some incremental adjustments to the
frameworks. Right now, COBIT has an objective specifically designed for
implementing/establishing EA, but it would be an idea to set EA (and maybe more
specific TOGAF and its ADM) as a focus area in COBIT, since all the above mentioned
objectives are set for the COBIT Core Model as focus area. Since “the number of focus
areas is virtually unlimited and can be added when required” (ISACA, 2019), this seems
a valid trail to blaze.
Furthermore, the comparison performed in this dissertation, was between COBIT
objectives and TOGAF phases, but another comparison could be made regarding the
COBIT content (inputs, outputs, …) and the Architecture Content Framework in TOGAF
(catalogs, matrices, diagrams).

Besides developing a model that would integrate COBIT 2019 and TOGAF 9.2, it would
also be useful to create a model that assesses the IT governance maturity and
capabilities of an enterprise. That would allow the evaluation of the performance of the
IT governance system.

73
Conclusions
In order to align COBIT with EA – so that enterprises could reduce their cost of
implementation –, TOGAF was chosen as framework to represent the broader EA
concept and COBIT as framework to represent the IT governance of an enterprise.
Since barely no comparisons has been made up yet between the most recent versions
of the frameworks, this dissertation aimed to answer the research question “What are
the similarities and dissimilarities between COBIT 2019 and TOGAF 9.2?”. The
research was divided into three parts: first comparisons were gathered from existing
literature, found through three online libraries, namely WoS, SCOPUS and Google
Scholar. Then, a high-level comparison was made up by creating a concept map for
TOGAF Version 9.2 to compare the structure of COBIT 2019 and TOGAF 9.2. Lastly, a
more detailed comparison was made between some COBIT objectives and TOGAF
ADM phases.

Results from literature state that COBIT represents the most complete reference of IT
governance regarding the governance components, wherein COBIT responds best to
strategic alignment. Although the governance component present in each framework is
value creation, neither frameworks fulfill all business and security requirements. In
future research, establishing resilient cyber approaches should be a priority!
Furthermore, the advantages of COBIT are its principles, namely meeting stakeholder’s
needs, covering the entire company from end to end, providing a single framework and
a holistic approach to business decision-making, while separating management from
governance. Its disadvantages are the difficulty of implementation and the unknown
management guide in the framework. The biggest disadvantage remains the high cost
of implementation, that is why further research is mandatory, to be able to really reduce
the costs for enterprises.
TOGAF on the other hand, provides better product quality, a common company
language, maximizes the value of IT by the strength of the IS, while providing a
common framework to facilitate the search for skills. But the drawback is that TOGAF
does not cover management processes and does not provide complete security
guidelines, which is a crucial element in today’s dangerous environment regarding
cyberattacks. Furthermore, results conclude that TOGAF is considered loose in that the

74
contributions are not integrated tight enough and that the nonessentials often cloud the
essentials.

Results coming from the high-level comparison, conclude that the COBIT objectives can
be compared to the TOGAF ADM phases, wherein the COBIT components resemble to
the purpose, inputs, outputs, steps and approach used in the phases of TOGAF. Other
similarities were found in the performance management of both frameworks; both use
capability and maturity levels/models. Also a resemblance can be seen between
TOGAF’s Enterprise Continuum and some specific COBIT objectives, aiming to gather
and establish consistent inputs and outputs. Regarding the dissimilarities, no ‘ethics,
culture and behavior’- component can be found in TOGAF, nor a ‘services,
infrastructure and applications’ components. COBIT on the other hand does not provide
a mapping for the value stream, but does contain several (example) metrics, which
TOGAF does not provide. Some other differences involve the absence of an
Architecture Repository in COBIT, the absence of an explicit goals cascade, focus
areas and design process (tailoring process) in TOGAF.

The detailed content comparison between the COBIT APO objective ‘Managed EA’ and
the TOGAF ADM phases, conclude that all five practices of this objective explicitly refer
and resemble to almost all ADM phases. Although this single objective embodies nearly
the whole core of the TOGAF Standard, some crucial parts are missing: the gap
analysis is not explained in COBIT documentation. Also a document for learned lessons
does not exist in COBIT, whereas TOGAF refers to it. Furthermore, more
mappings/references could be made up between other COBIT objectives and TOGAF
concepts.

To summarize: neither framework is perfect. Both frameworks has its advantages and
disadvantages, and in order to obtain the best of both worlds, they should be mapped to
each other. With this dissertation, I hope to make a contribution to the basis for a future
integration/model of COBIT 2019 and TOGAF Version 9.2.

75
References

Alshammari, B. M. (2017). “Enterprise Architecture Frameworks: A Critique Review from

a Security Perspective,” International Journal of Computer Applications, 174(5),
9-10.
Al-Turkistani, H. F., Aldobaian, S., & Latif, R. (2021, april). Enterprise Architecture
Frameworks Assessment: Capabilities, Cyber Security and Resiliency Review.
2021 1st International Conference on Artificial Intelligence and Data Analytics
(CAIDA). https://doi.org/10.1109/caida51941.2021.9425343
COBIT | Control Objectives for Information Technologies. (2022). ISACA. Consulted on
13th of May 2022, from https://www.isaca.org/resources/cobit
De Haes, S., Van Grembergen, W., & Debreceny, R. S. (2013). COBIT 5 and Enterprise
Governance of Information Technology: Building Blocks and Research
Opportunities. JOURNAL OF INFORMATION SYSTEMS, 27(1), 307–324.
https://doi.org/10.2308/isys-50422
Devos J. and Van de Ginste K. (2015), “Towards a Theoretical Foundation of IT
Governance – The COBIT 5 case” The Electronic Journal Information Systems
Evaluation, 18(2), 95-103.
Harani, N. H., Arman, A. A., & Awangga, R. M. (2018). Improving TOGAF ADM 9.1
migration planning phase by ITIL V3 service transition. Journal of Physics:
Conference Series, 1007, 12036.
Havaluddin, P. A. (2012). “Exploring COBIT Framework for Information Technology
Governance (ITG) at Mulawarman University, Samarinda, East Kalimantan,
Indonesia: A Descriptive Study,” in 2012 - BIMP - EAGA CONFERENCE:
"Enhancing Sustainability, Competitiveness & Innovation".
Ibrahim, H., & Abdessamad, B. (2019). A Built-in Criteria Analysis for Best IT
Governance Framework. International Journal of Advanced Computer Science
and Applications, 10(10). https://doi.org/10.14569/ijacsa.2019.0101026
Ikhsan, M., Widodo, A. P., & Adi, K. (2021). Systematic Literature Review on Corporate
Information Technology Governance in Indonesia using Cobit 2019. Prisma

X
 Sains : Jurnal Pengkajian Ilmu dan Pembelajaran Matematika dan IPA IKIP
Mataram, 9(2), 354–364. https://doi.org/10.33394/j-ps.v9i2.4370
ISACA. COBIT® 2019 Framework: Introduction & Methodology; ISACA: Schaumburg,
IL, USA, 2018a; ISBN 978-1-60420-763-7.
ISACA. COBIT® 2019 Framework: Governance & Management Objectives; ISACA:
Schaumburg, IL, USA, 2018b; ISBN 978-1-60420-764-4.
ISACA. 2009. Building the Business Case for COBITt and Val ITe: Executive Briefing.
Rolling Meadows, IL: ISACA.
ISACA. 2011. COBIT Mapping: Overview of International IT Guidance. Rolling
Meadows, IL: ISACA.
ISACA (2012) COBIT 5 - A Business Framework for the Governance and Management
of Enterprise IT, Rolling Meadows, IL, USA: ISACA.
Lankhorst, M. (2013). Enterprise Architecture at Work - Enterprise Modelling,
Communication and Analysis - Second Edition. Springer (Vol. 36). Springer.
https://doi.org/10.1016/B978-0-12-387667-6.00013-0
Machado, M. C., & Carvalho, T. C. M. D. B. (2021). Maturity Models and Sustainable
Indicators—A New Relationship. Sustainability, 13(23), 13247.
https://doi.org/10.3390/su132313247
Moscoso-Zea, O., Paredes-Gualtor, J., & Luján-Mora, S. (2019). Enterprise
Architecture, an enabler of change and knowledge management. Enfoque UTE,
10(1), 247–257. https://doi.org/10.29019/enfoqueute.v10n1.459
Proper, H. A., Bork, D., & Poels, G. (Reds.). (2021). Towards an Ontology-Driven
Approach for Digital Twin Enabled Governed IT Management (Vol. 2941, Paper
18). CEUR-WS.
Rika Y., & R. Budi R. (2011). Designing enterprise architecture for mining by using
TOGAF framework. Magister Thesis of Informatics, Institut Teknologi Bandung
Samiei, E., & Habibi, J. (2022). Toward a Comprehensive IT Management Methodology.
IEEE Engineering Management Review, 50(1), 168–185.
https://doi.org/10.1109/emr.2021.3133804
Steuperaert, D. (2019). COBIT 2019: A SIGNIFICANT UPDATE. EDPACS, 59(1), 14–
18. https://doi.org/10.1080/07366981.2019.1578474
Suryawan, A. D., & Veronica. (2018). Information technology service performance
management using COBIT and ITIL frameworks: A case study. International
Conference on Information Management and Technology (ICIMTech), 223–228.

XI
The Open Group. The TOGAF® Standard, Version 9.2; The Open Group: USA, 2018;
ISBN 1-947754-11-9.
Tshinu, S. M., Botha, G., & Herselman, M. (2008). An integrated ICT management
framework for commercial banking organisations in South Africa. Interdisciplinary
Journal of Information, Knowledge, and Management, 3, 39–53.
Van Grembergen, W., and S. De Haes. 2009. Enterprise Governance of Information
Technology: Achieving Strategic Alignment and Value. New York, NY: Springer.

XII