Enterprise Architecture - PDF by xld14276

VIEWS: 1,126 PAGES: 206

More Info
									Successful Enterprise Architecture

       Enterprise Architecture
 - how to establish and sustain a successful EA

A Master Thesis from the IT University Copenhagen

Author: Vibeke Trolle Hansen

Supervisor: John Gøtze

March 2006
Successful Enterprise Architecture                                                       ii

Enterprise architecture aims to establish business and IT alignment. EA is often
applied to ensure a more central business driven IT portfolio, and make the
organisation more agile in managing change. Having analysed the EA discipline
including the EA definition, EA frameworks, governance, change management and
EA maturity and business value measures from a theoretical perspective, I aim at
defining a set of guidelines that will inspire organisations in practice to create a
successful EA in a structured manner.

After I have defined the set of guidelines, I apply them on two cases, SKAT and
ATP. The case analyses show that the organisations have established many of the
relevant processes necessary to implement and sustain a business driven IT
portfolio, but also that both organisations still have a long way to go to fully reach
their objectives. SKAT has a very strong project model that already takes the new
IT architectures into account and ensure compliance with their IT modernisation
project. The main obstacle, however, is that SKAT does not fully appreciate the
value EA can generate for them, and even though they are working in the right
direction, the approach seems ad hoc. SKAT claims that they are not interested in
establishing an EA although this is partly what they are doing. To me this implies
lack of structures, which the EA discipline may provide when implementing and
sustaining a business driven IT portfolio. ATP, on the other hand, is deliberately
conducting an EA. They have thoroughly performed many of the initial EA
investigations and are ready to seize the challenge in implementing their EA in the
organisation. My main obstacle in this analysis is, however, that ATP ought to put
more focus on EA governance as opposed to mainly focussing on IT governance at
the top level in their EA. This could ensure more coherent governance structures of
the entire framework.

The theoretical framework and best practise conclusions, thus, lead me to define a
set of guidelines that proved very useful in my case analyses. The guidelines
consist of four stages:

        1. EA foundation stage

        2. EA approach stage

        3. EA governance and management stage

        4. EA maturity and measurement stage
Successful Enterprise Architecture                                                iii

The guidelines should be useful in bridging the gap between theory and practise
within the EA field, and may, hopefully, assist organisations in creating and
sustaining a successful EA.
Successful Enterprise Architecture                                                                                                  iv


1.     Introduction ....................................................................................... 1
     1.1.     My contributions and structure of the thesis .................................................... 2

2.     Methodology ....................................................................................... 4
     2.1.     Theory........................................................................................................ 4
     2.2.     Case studies ................................................................................................ 5

3.     Enterprise Architecture Prerequisites.................................................. 7
     3.1.     Scope of EA................................................................................................. 7
     3.2.     Zachman’s EA framework.............................................................................. 9
     3.3.     Bernard’s EA Cube Framework ..................................................................... 10
       3.3.1.         The three dimensions in the EA Cube ................................................................ 12
   The five functional levels .............................................................................      12
   The multiple sub-cubes ...............................................................................        13
   Distinct activity areas (LOBs) .......................................................................        13
       3.3.2.      The planning threads ......................................................................................     13
     3.4.     Evaluation of Zachman’s framework and Bernard’s EA Cube ............................ 14
     3.5.     EA methodology......................................................................................... 14
     3.6.     Conclusion ................................................................................................ 17

4.     Governance and Decision Structures from an IT Perspective ............. 18
     4.1.     Governance scope ...................................................................................... 18
     4.2.     An IT governance arrangements matrix ........................................................ 20
       4.2.1.         Examples of governance decision structure set-ups ............................................. 24
       4.2.2.         The Glocalisation model .................................................................................. 26
     4.3.     Conclusion and evaluation of IT governance in an EA respect .......................... 27

5.     EA Governance and Management ...................................................... 29
     5.1.     EA scope ................................................................................................... 29
     5.2.     EA governance processes ............................................................................ 29
       5.2.1.         Ensuring compliance and vitality....................................................................... 30
    Governance and management of the EA components and artifacts..................... 30
    An EA exception process ............................................................................. 32
       5.2.2.      EA roles ........................................................................................................ 32
    The necessary competences and knowledge ................................................... 32
    Senior management buy-in.......................................................................... 33
       5.2.3.      EA organisation.............................................................................................. 33
       5.2.4.         Communication .............................................................................................. 34
     5.3.     Conclusion ................................................................................................ 35

6.     EA Implementation and Change Management ................................... 36
     6.1.     Implementing change ................................................................................. 36
     6.2.     The importance of leadership....................................................................... 39
     6.3.     Conclusion ................................................................................................ 40

7.     EA Maturity and EA Measurement...................................................... 42
     7.1.     GAO’s EA maturity model ............................................................................ 42
     7.2.     Herzum’s EA maturity model ....................................................................... 44
     7.3.     Evaluation of the EA results......................................................................... 47
Successful Enterprise Architecture                                                                                                      v

     7.4.       Economic evaluation of EA .......................................................................... 49
     7.5.       Conclusion ................................................................................................ 51

8.     EA implementation guidelines ........................................................... 53
     8.1.       Stage 1: EA foundation ............................................................................... 55
     8.2.       Stage 2: EA approach ................................................................................. 56
     8.3.       Stage 3: EA governance and management .................................................... 57
     8.4.       Stage 4: EA maturity and measurement ....................................................... 60
     8.5.       Conclusion ................................................................................................ 61

9.     Case 1: SKAT..................................................................................... 63
     9.1.       Introduction to SKAT .................................................................................. 63
       9.1.1.           The municipal reform from an IT perspective ...................................................... 64
     9.2.       IT modernisation (stage 1 – EA foundation)................................................... 65
       9.2.1.           Top management buy-in ................................................................................. 66
       9.2.2.           EA needs analysis........................................................................................... 66
       9.2.3.           High-level governance structure ....................................................................... 67
     9.3.       Stage 1 evaluation ..................................................................................... 69
     9.4.       EA approach – (stage 2) ............................................................................. 71
       9.4.1.           EA organisation and executive board ................................................................. 71
       9.4.2.           Competences................................................................................................. 72
       9.4.3.           EA framework and EA methodology................................................................... 73
     9.5.       Stage 2 evaluation ..................................................................................... 75
     9.6.       EA/(IT) governance and management - ensure compliance and vitality (stage 3)77
       9.6.1.           IT decision structures...................................................................................... 77
       9.6.2.           IT principles .................................................................................................. 79
       9.6.3.           Establish the EA framework content .................................................................. 80
       9.6.4.           Project model ................................................................................................ 81
       9.6.5.           Maintenance of the architecture........................................................................ 83
       9.6.6.           Process owners .............................................................................................. 84
       9.6.7.           Escalation structure ........................................................................................ 85
       9.6.8.           Communication .............................................................................................. 85
         Stakeholders ............................................................................................. 86
     9.7.       Stage 3 evaluation ..................................................................................... 87
     9.8.       Maturity and measurement (stage 4)............................................................ 92
         Measuring SKAT’s ‘EA’ performance .............................................................. 93
     9.9.       Stage 4 evaluation ..................................................................................... 94
     9.10.      Conclusion ................................................................................................ 96

10. Case 2: ATP....................................................................................... 98
     10.1.      Introduction to ATP .................................................................................... 98
     10.2.      The IT architecture department.................................................................... 99
     10.3.      The NAFS Project (stage 1 – EA foundation) .................................................100
       10.3.1.          ATP’s domain landscape .................................................................................101
       10.3.2.          EA needs analysis..........................................................................................103
       10.3.3.          Top management buy-in ................................................................................104
       10.3.4.          High–level governance structure......................................................................104
     10.4.      Stage 1 – evaluation .................................................................................106
     10.5.      EA approach – (stage 2) ............................................................................107
       10.5.1.          EA organisation and executive board ................................................................107
       10.5.2.          Competences and knowledge ..........................................................................108
Successful Enterprise Architecture                                                                                                vi

      10.5.3.      EA framework and methodology ......................................................................109
   10.6.     Stage 2 evaluation ....................................................................................110
   10.7.     EA/(IT) governance and management – ensure compliance and vitality (stage 3)
      10.7.1.      IT decision structures.....................................................................................112
      10.7.2.      IT Principles .................................................................................................115
      10.7.3.      Establishing the EA framework content .............................................................116
      10.7.4.      Development model.......................................................................................118
      10.7.5.      EA maintenance ............................................................................................118
      10.7.6.      Artifact owners .............................................................................................119
      10.7.7.      Escalation structure .......................................................................................120
      10.7.8.      Communication and stakeholders ....................................................................120
   10.8.     Stage 3 evaluation ....................................................................................121
   10.9.     Maturity and measurement (stage 4)...........................................................125
       Measuring ATP’s ‘EA’ performance ...........................................................126
   10.10. Stage 4 evaluation ....................................................................................126
   10.11. Conclusion ...............................................................................................128

11. Comparing the two cases ................................................................ 129
   11.1.     Stage 1: EA foundation ..............................................................................130
   11.2.     Stage 2: EA approach ................................................................................131
   11.3.     Stage 3: EA governance and management ...................................................132
   11.4.     Stage 4: EA maturity and measurement ......................................................134
   11.5.     Conclusion ...............................................................................................134

12. Conclusion ...................................................................................... 136

13. Reflection ....................................................................................... 139
   13.1.     Applied theory, best practices and models....................................................139
      13.1.1.      Frameworks .................................................................................................140
      13.1.2.      Governance ..................................................................................................140
      13.1.3.      Change management .....................................................................................141
      13.1.4.      Maturity.......................................................................................................141
      13.1.5.      The case studies ...........................................................................................142
      13.1.6.      Conclusion ...................................................................................................143
   13.2.     The purpose of my guidelines and the thesis in general..................................144
   13.3.     Further research .......................................................................................145
      13.3.1.      EA governance versus IT governance ...............................................................145
      13.3.2.      EA measurements .........................................................................................145
      13.3.3.      The public / private aspect..............................................................................146
   13.4.     Conclusion ...............................................................................................146

Glossary ................................................................................................ 148

Appendix A: Interviews and interview summaries with SKAT................. 150

Appendix B: Interviews and interview summaries with ATP................... 167

Appendix C: Interview and interview summary with Gartner Group,
Denmark ............................................................................................... 180

Appendix D: Interview and interview summary with IBM, Denmark....... 183
Successful Enterprise Architecture                                                                      vii

Appendix E: Zachman’s EA framework ................................................... 186

Appendix F: SKAT’s map of their organisation........................................ 187

Appendix G: ATP’s overall organisational diagram ................................. 188

Appendix H: IT departments in ATP ....................................................... 189

Appendix I: ATP’s domain landscape ..................................................... 190

Appendix J: Establishing EA in ATP ........................................................ 191

Appendix K: ATP’s EA ............................................................................ 192

Bibliography .......................................................................................... 193
Successful Enterprise Architecture                                                                                                viii


Figure 1 The focus of EA ............................................................................................................ 8

Figure 2 Zachman’s Framework for Enterprise Architecture (for full size see appendix E) ..................... 9

Figure 3 Bernard’s EA Cube Framework...................................................................................... 11

Figure 4 Enterprise Architecture Approach .................................................................................. 15

Figure 5 Governance structure .................................................................................................. 17

Figure 6 The IT governance arrangements matrix ........................................................................ 21

Figure 7 Domain comparisons between the ITG matrix and the EA Cube ......................................... 22

Figure 8 The Glocalisation Model ............................................................................................... 26

Figure 9 RACI matrix ............................................................................................................... 31

Figure 10 Kotter’s eight change management stages.................................................................... 37

Figure 11 EA benefits .............................................................................................................. 50

Figure 12 Enterprise architecture value model ............................................................................. 50

Figure 13 Illustration of my EA guidelines necessary to establish a successful EA.............................. 54

Figure 14 SKAT’s organisational set-up (in Danish) ...................................................................... 63

Figure 15 SKAT’s old and new (desired) high-level IT governance structures.................................... 68

Figure: 16 A simplification of SKAT’s new (desired) more central IT decision structures ..................... 78

Figure 17 SKAT’s map of their organisation (in Danish) (for full size see appendix F) ........................ 80

Figure 18 ATP’s overall organisation diagram (in Danish) (for full size see appendix G) ..................... 98

Figure 19 IT-related departments in ATP (in Danish) (for full size see appendix H)...........................100

Figure 20 ATP’s Domain Landscape (in Danish) (for full size see appendix I) ...................................102

Figure 21 ATP’s old and new (desired) high-level IT governance structure ......................................105

Figure 22 Establishing EA in ATP (in Danish) (for full size see appendix J) ......................................110

Figure 23 A simplification of ATP’s new (desired) more central IT decision structures .......................114
Successful Enterprise Architecture                                                                                       ix

Figure 24 ATP’s EA framework (in Danish) (for full size see appendix K).........................................117

Figure 25 SKAT’s scores based on my guidelines ........................................................................129

Figure 26 ATP’s scores based on my guidelines ..........................................................................130

Figure 27 Illustration of business and IT architectures .................................................................148
Successful Enterprise Architecture                                                       1

1. Introduction
Enterprise Architecture (EA) as a discipline1 is increasingly being applied where
organisations aim to make their IT portfolios business driven rather than operated
in isolation from the business (Bernard, 2004; Kaisler, Armour and Valivullah,
2005; Infosys, 2005). The importance of EA is clearly established in a study made
by the Institute For Enterprise Architecture Developments (IFEAD), which showed
that EA was ranked near the top of the list of most important issues considered by
CEOs and CIOs in 2004 (Schekkerman, 2005). Despite the growing interest, EA is
still not broadly implemented in full and when implemented, this is often with a low
success rate (Scott, 2004). Thus, the question is what is required by a given
organisation to implement an EA that generates business value?

The aim of an EA is to improve the alignment between IT and business and
consequently being better to control IT-related changes to support the overall
business strategy (Bernard, 2004; Mayo and Tiemann, 2005; IFEAD, 2004). To do
this, the organisation is required to map its current and future (desired) EA states
of the organisation in relation to the business and IT perspectives and consequently
prepare a transition plan that closes the gap between the two states - in other
words, a blueprint for the organisation’s IT (Bernard, 2004; Nascio, 2003). In this
process, it is necessary to acknowledge that the EA content may evolve over time
to allow the organisation to adapt to changes in the business environment (Nascio,
2003). Therefore, it is necessary to establish processes to ensure that the EA is
continuously complied by and updated, and consequently supports the overall
business strategy (Spurway and Patterson, 2005).

Through my exposure to EA, it seems that a significant number of organisations are
beginning to focus on optimising their IT portfolios from a business perspective. It
is generally no longer assumed that the IT department controls the organisation’s
IT independent from all other departments, but, rather, they have become strategic
partners in carrying out the business strategy. The result appears to be more agile
organisations that are better equipped to manage change in relation to making
their IT portfolios business driven. The process of arriving at this realisation seems
to be complex and requires a long-term commitment and continuity.

    For my definition of discipline, see Glossary
Successful Enterprise Architecture                                                       2

On this basis, this thesis aims to investigate:

            “How an organisation can establish and sustain a successful EA”

1.1.         My contributions and structure of the thesis
According to Scott (2004), too many EA programmes are stuck in an out-of-date
paradigm that will never deliver value in today’s environment. He believes the EA
approach must change to focus on how organisations should approach technology
rather than on technology itself to be more successful. Paras (2005) gives his view
to why EA has not fully achieved its potential. He believes that the shortcomings
are partly because of the absence of high-level direction to orchestrate
collaboration between programme management offices and EA groups. These are
just two of the incredible many suggestions, ideas, and views that prevail in today’s
magazines, journals etc. on how organisations can create better EAs.

Based on this thesis’s theoretical framework, I aim to define a set of minimum
requirements that I believe are necessary to establish a successful EA. These
requirements or guidelines will form the basic structure of the case analyses and
thus will be tested on the two cases.

This thesis consists of two parts: a theoretical framework and some empirical
research. First, the methodology is explained used in relation to both. The EA
discipline forms the basis of the theoretical framework, which will include sections
on EA prerequisites, including EA frameworks; governance, specifically focusing on
EA governance (EAG); an introduction to Change Management (CM) from an EA
perspective and EA maturity evaluation. The theoretical framework concludes with a
section describing the above-mentioned EA guidelines based on the theoretical

The empirical research consists of two case studies from two large Danish
organisations (ATP and SKAT) that have worked with EA for a period. The cases are
analysed separately based on the guidelines that I derive from the theoretical part
of the thesis. In addition, the empirical work in itself gives insights into how EA is
practically approached, and how entities work with EA to streamline their IT
portfolios in order to make them business driven. Subsequently, the two cases are
compared, and a set of overall conclusions and reflections are provided.
Successful Enterprise Architecture                                                  3

The practical and the empirical work are supported by best practise as indicated by
leading consultants that I have interviewed. This should put some light on the
bridge between theory2 and practice, and secure that my empirical findings in the
two cases are not too idiosyncratic.

    For my definition of theory, see Glossary
Successful Enterprise Architecture                                                                4

2. Methodology
2.1.            Theory
This thesis focuses on Enterprise Architecture (EA) and, more specifically, on how
to approach, implement, and anchor an EA in an organisation3 with the aim of
making an IT portfolio business driven, and thereby create long-term business

A definition of the EA scope together with a description of two different EA
frameworks will constitute the basis of the first section. The concept of EA is being
defined and discussed variously (Malhotra, 1996; Schekkerman, 2005) for which
reason, I find it important to initially define the EA scope that will form the basis of
this thesis’s theoretical framework. According to Orr (2003) and Spurway and
Patterson (2005) planning EA is impossible without maps. As such, EA frameworks
provide the means for an organisation to draw a map that establish their current
and future states of their organisation which function as the basis for a transitions
plan in reaching their desired state (Orr, 2003; Spurway and Patterson, 2005).

EA encompasses a range of disciplines4. On meta level one of the most significant
ones is governance due to this discipline being particularly instrumental in
consciously operationalise an EA in an organisation (Scott, 2004), and the analysis
of governance - from the terms origin to the use in relation to an EA - comprises
thus a main part of the theoretical framework. Furthermore, one of the
cornerstones of implementing an EA is to manage the challenge of change that
faces today’s organisations (Zachman, 1995; IFEAD, 2004) for which reason
Change Management (CM) requires attention when analysing EA. The CM section in
this thesis aims to illustrate the importance of this area in relation to implementing
and anchoring an EA and takes a practical perspective. To determine an
organisation’s EA maturity and thereby help them to advance in this field and
improve the EA value, maturity and assessment models may help establish areas
that need improvement and further attention (GAO, 2002).

    For my definition of organisation, see Glossary

    For example: IT governance, EA governance, change management, portfolio management, project
management and strategic management.
Successful Enterprise Architecture                                                         5

Often, an organisation’s intention to create a service-oriented architecture5 (SOA) is
the reason why they start focussing on EA. However, this is not this thesis’
approach. I do believe that it is relevant to examine how organisations can create
an EA whether the objective is to establish a SOA or not. Thus, SOA is not part of
this thesis, even though I recognise it as being closely related to EA.

The theoretical framework for EA including governance, CM, and EA maturity and
measurement evaluation is established through a thorough review of the
contemporary literature on these topics. Following this review, the theory is
analysed, explained, and tested by the means of two case studies.

2.2.            Case studies
According to Yin (2003) “case studies are the preferred strategy when ‘how’ or
‘why’ questions are being posed, when the investigator has little control over
events, and when the focus is on a contemporary phenomenon within some real-life
context” (p. 1). These three factors match this thesis research question, and further
“the case study method allows investigators to retain the holistic and meaningful
characteristics of real-life events - such as individual life cycles, organisational and
managerial processes, neighbourhood change, international relations, and the
maturation of industries” (Yin, 2003, p. 2).

The case studies were conducted in collaboration with two large organisations: one
public sector organisation (SKAT) and one public-private organisation (ATP). The
objective of the case studies is to provide an insight into how EA is approached,
implemented, and anchored in practice and thereby testing the theory. This is done
with due acknowledgement that empirical research does not necessarily provide a
firm foundation for drawing universal conclusions (Yin, 2003). However, I believe
that the two cases selected (micro level) together with interviews of various leading
consultants to control for best practise trends (macro level) are representative to
an extent that allows for the identification of indicative developments in general,
and provides sufficient data to enable an informed discussion on this topic and
insight into the practical application of EA theory. The two particular cases were
selected on the basis that the organisations in question have reached a certain
degree of maturity in relation to EA.

    For my definition of architecture, see Glossary
Successful Enterprise Architecture                                                       6

According to Sarantakos (1998), the various types of social researches are not
mutually exclusive and thus, this thesis’s case studies are primarily conducted as
exploratory case studies’ (Yin, 2003; Sarantakos, 1998) with the goal to investigate
how the EA discipline successfully can assist organisations in controlling their IT to
support their business strategy. Exploratory research is “a process that, according
to some writers, is useful for developing an accurate picture of the research object,
is a central element of qualitative research and can offer assistance not only in
formulating hypotheses and theories but also in modifying and testing hypotheses
and theories” (Sarantakos, 1998, p. 7). The aim of this thesis is to analyse the EA
discipline and thereby explore what it takes to create a successful EA by defining
guidelines based on the theoretical framework’s conclusions and subsequently test
these guidelines on the cases. Here I am to test both whether the guidelines are
useful in practise, and how well the organisations in the empirical research perform
according to the guidelines.

This thesis’s research question and the following theoretical framework is analysed
and tested through qualitative interviews and analysis of available and relevant
documentation from the two organisations (e.g. organisational charts, documents
describing the organisations’ strategies and architectures, web sites etc.). The use
of multiple sources of evidence including interviews with leading EA consultants
helps in clarifying meaning and avoiding any misunderstandings as more views are
covered to different areas of interest (Yin, 2003). The interviews are qualitative
(Sarantakos, 1998) and is thus undertaken in order to gain the interviewee’s
“experiences, understanding, meaning, thoughts, feelings, motivations and
intentions” (Launsø and Rieper, 2000, p. 122) on various topics relating to the
organisations’ work with EA including governance, CM, and EA maturity and
measurement. On micro level the thesis question forms the foundation for the data
collection, and, therefore, the interview guides for each interview are created to
ensure that relevant areas are covered and documented (see appendices A - D).
Successful Enterprise Architecture                                                    7

3. Enterprise Architecture Prerequisites
In this section, the EA term will be defined to provide the scope that lays the
ground for this thesis EA analysis. Subsequently, two frameworks will be analysed:
Zachman’s EA framework and Bernard’s EA Cube including his EA methodology.
Zachman has been selected due to his framework being the most used in defining a
map of the organisation including current and target states (Orr, 2003). Further,
most EA frameworks that have evolved the last many years are almost always a bit
Zachman as it is most often his way of thinking that forms the basis (Zangenberg,
interview, 2005). Bernard’s EA Cube has been selected to show a framework that is
different than Zachman’s, yet based upon his earlier work (Bernard, 2004).
According to Pavlak (2005), “the EA Cube is interesting because it is simultaneously
a data description and a functional description of the enterprise” (p. 3). Thus, I find
the EA Cube and Bernard’s EA methodology an interesting counterpart that show an
extended EA framework that also includes dynamic work processes as opposed to
Zachman’s framework.

3.1.         Scope of EA
To understand the EA discipline, it is important to understand its heritage (Hjort-
Madsen, 2005). EA as such is not a new discipline as it replaces the systems-level
approaches to IT resource development that have dominated the last several
decades and has left many organisations with stovepipe and duplicative IT systems
(Bernard, 2004). The EA literature today takes a more holistic perspective on the
management of IT than have previously been seen, but many of the concepts used
today are based on ideas and concepts developed in the earlier system-level
approach (Hjort-Madsen, 2005). As below figure shows, the essence of an EA is
that it focuses equally on business, technology, and their interrelationship.
Successful Enterprise Architecture                                                    8

Figure 1 The focus of EA

                                           Business              Enterprise
                   Business Focus         Architecture          Architecture

                                              No                Architecture

                                    Low                                        High
                                                  Technical Focus

Source: Own contribution based on Schekkerman (2005) and Hjort-Madsen (2005).

The contemporary literature does not offer a single definition of EA. However, as is
illustrated with the definitions below some consensus can be detected in that the
various authors all centre their definitions on creating an overview of the
organisation showing the alignment of the business and technology with the aim to
make the IT more business driven. Further, some definitions include processes in
relation to management and governance, which will assist the organisation in
creating a dynamic EA.

Spewak (1992) refers to EA as ‘Enterprise Architecture Planning’ and define it as
“the process of defining architectures for the use of information in support of the
business and the plan for implementing those architectures” (p. 1).

Bernard (2004) applies a more detailed definition: “Enterprise Architecture is both a
management programme and a documentation method that together provides an
actionable, coordinated view of an enterprise’s strategic direction, business
processes, information flows, and resource utilization” (p. 33).

Schekkerman (2005) sees EA from a holistic point of view: “Enterprise Architecture
is a complete expression of the enterprise; a master plan which ‘acts as a
collaboration force’ between aspects of business planning such as goals, visions,
strategies and governance principles; aspects of business operations such as
business terms, organisation structures, processes and data; aspects of automation
such as information systems and databases; and the enabling technological
infrastructure of the business such as computers, operating systems and networks”
(p. 18).
Successful Enterprise Architecture                                                     9

Based on above definitions, I define the purpose of an EA programme as
“dynamically guiding an organisation’s IT to support the business thus reaching for
a common goal in which business, information, data, and technology are
integrated” (Bernard, 2004; Spewak, 1992; Zachman, 1989). In this respect, the
EA framework is defining what the EA programme will document (Bernard, 2004)
and can thus be viewed as a logical structure for classifying, organising and
managing complex information (Gao, 2003).

3.2.         Zachman’s EA framework
Zachman (1987 and 1992) is the originator of the ‘Zachman Framework for
Enterprise Architecture’ (hereafter referred to as Zachman’s EA framework).

The purpose of Zachman’s EA framework is to document how information systems
relate to an organisation and its surroundings. It is an elaboration of the metaphor
that compares the construction of a computer system to the construction of a house
(Sowa and Zachman, 1992). It is a schema that helps an organisation systematise
the elements of an organisation and the relationships between them including how
a change in one element may affect another element (Zachman, 2005). The
framework is a basic two-dimensional diagram (see figure 2 below).

Figure 2 Zachman’s Framework for Enterprise Architecture (for full size
see appendix E)

Source: www.zifa.com
Successful Enterprise Architecture                                                     10

The diagram outlines five levels of abstraction (the rows) in relation to the
architecture descriptions: The Planner’s view (scope); The Owner’s view (business
model); The Designer’s view (system model); The Builder’s view (technology
model); and The Subcontractor’s view (detailed representations). The six columns
describe different focus on each of the five rows: What (data); How (function);
Where (network); Who (people); When (time); and Why (motivation). The
framework thus provides a way of viewing a system from 30 different perspectives
and illustrates how they are interrelated (Sowa and Zachman, 1992; the US
Department of Veteran Affairs, USA, 2005).

Zachman’s EA documentation framework can be viewed as a ‘bookshelf’ in which
the organisation may organise its data and information. However, it does not
include any processes or methodologies for how to ‘fill in the cells’ or how to
approach and create a dynamic EA, and, therefore, Zachman leaves it up to the
individual organisation to define these processes. To alleviate this challenge,
particularly to novice organisations in terms of EA, the next section introduces
Bernard’s EA Cube Framework, which includes examples of suggested EA

3.3.         Bernard’s EA Cube Framework
Bernard’s EA Cube Framework (hereafter referred to as the EA Cube) assists the
organisation in defining the scope of their EA documentation process and organising
the documentation data (Bernard, 2004). It is an expansion of a data
documentation framework as it includes both a data and a high-level functional
description of the organisation (Pavlak, 2005). It includes hierarchical levels that
relate the different functional areas of the organisation logically to each other by
positioning high-level strategic initiatives at the top, general business processes
and information flows in the middle, and supporting systems, services and the
technological infrastructure at the bottom. The EA Cube (see figure 3 below)
includes three dimensions that relate to the different functional areas of the
organisation (Bernard, 2004).
Successful Enterprise Architecture                                                                        11

Figure 3 Bernard’s EA Cube Framework

Source: Bernard, 20056

The three dimensional Cube makes it possible to illustrate multiple vertical levels as
various EA documentation areas (functional descriptions of the organisation, e.g.
‘Goals and Initiatives’). Furthermore, the multiple sub-cubes at each level represent
plug-and-play EA components, e.g. ‘strategic plan’ at the ‘Goals and Initiatives’

    It has recently come to my attention that during the work with this thesis, Bernard has published a
new version of his Enterprise Architecture book in 2005. The content seems, however, to be more or less
the same. To illustrate his progress, I have, however, chosen to illustrate his EA Cube with his updated
2005 terms. These terms will be used throughout the thesis, even though my description of his cube and
methodology is based on his 2004 book.
Successful Enterprise Architecture                                                                       12

level7, and multiple layers of depth that are distinct activity areas. These are
referred to as Lines-of-Business (LOBs). According to Bernard (2004), LOBs make it
easier for an organisation to conduct phased EA implementation as each LOB has a
complete sub-architecture including all the five hierarchical levels and can as such
stand alone architecturally in the organisation. However, this would not decrease
any duplication in data, application, network functions, and other inefficiencies, and
they should instead be handled as segments of the overall EA and be integrated in
the documentation framework when they are included in the EA programme
(Bernard, 2004).

3.3.1.          The three dimensions in the EA Cube
Below is a short introduction to the three dimensions in the EA Cube.          The five functional levels
The five functional levels in the EA Cube represent various functional
documentation areas in the organisation:

Level 1: Goals and initiatives (old term: Strategic initiatives): The driving
force behind the enterprise architecture. It identifies the organisation’s strategic
direction, goals, and initiatives, and it provides a clear description of the
contribution that IT will make in achieving these goals (Bernard, 2004).

Level 2: Products and services (old term: Business Processes): Identifies the
business lines and processes of the organisation and shows the IT contribution to
those processes. Strategic planning helps to direct and prioritise the various
business processes and activities to ensure that they are collectively moving the
organisation in the strategic direction that is set out in the strategic plan (Bernard,

Level 3: Data and information (old term: Information Flows): Documents
how information is currently being used by the organisation and how future

    EA components are replaceable elements in the framework that will vary with changes in the five
areas. The components are thus plug-and-play goals, processes, measures, projects, data, services and
IT resources (Bernard, 2004).

“An EA artifact is a documentation product, such as a text document, system specification, application
interface information, diagram, spreadsheet, briefing slides, and/or video clip” (Bernard, 2004, p.87)
Successful Enterprise Architecture                                                     13

information flows should look. For example, the design and functioning of
databases throughout the organisation and standards and formats for data, data
dictionaries, and repositories for reusable information objects is described at this
level (Bernard, 2004).

Level 4: Systems and applications (old term: Systems and Services):
Documents the current group of information systems and application services,
which the organisation uses to deliver IT capabilities (Bernard, 2004).

Level 5: Networks and infrastructures (old term: Technology
infrastructure): The backbone of the architecture. Here, the organisation
organises and documents current and future views of the voice, data and video
networks which the organisation uses to host systems, applications, websites and
databases (Bernard, 2004).        The multiple sub-cubes
The multiple sub-cubes consist of artifacts that document the various components.
Examples of components are business processes. In this respect, Bernard (2004)
defines artifacts as those elements that describe the business processes.        Distinct activity areas (LOBs)
Distinct activity areas are also referred to as LOBs. These may involve the
manufacturing of certain products, the provision of services or internal
administrative functions (Bernard, 2004).

3.3.2.        The planning threads
The EA Cube framework also consists of three threads: Security, Standards, and
Workforce (Bernard, 2004).

IT Security: IT Security should work across all levels of the EA framework and
within all of the EA components.

IT Standards: One of the most important functions of the EA is to provide
technology-related standards at all levels of the EA framework.

IT Workforce: It is a necessity having the right staff at all levels of the EA.

These threads can actually be viewed as a fourth dimension. In this respect, it is
important to note that a thread is a permanent feature of the framework that
occurs at all levels of the framework, whereas components including artifacts are
Successful Enterprise Architecture                                                    14

changeable elements that change as a result in, for example, new goals (Bernard,
2004; Gøtze, 2005).

3.4.      Evaluation of Zachman’s framework and Bernard’s
       EA Cube
Bernard’s EA Cube framework provides the means to map the organisation’s ‘as is’
and ‘to be’ perspectives in five hierarchical functional levels which allows for an
integrated holistic and detailed view of the organisation (Bernard, 2004). Creating
present and future perspectives is also a cornerstone in Zachman’s framework
where the framework includes business perspectives at the top and more technical
perspectives at the bottom. Even though, Zachman’s framework, in practise, is
often seen as being very advanced and comprehensive, it is broadly applied in
organisations, however, often in a scaled-down version. Zangenberg (interview,
2005) comments that “it is mostly Zachman’s way of thinking that lays behind
[other EA frameworks] typically scaled down, as Zachman’s [framework] is way too
comprehensive” (0:51:39), further, Dreyer (interview, 2005) points out in relation
to choosing a framework that “they [organisations] can use Zachman’s [framework]
even though it is very complex to approach” (0:10:00). Bernard (2004) introduces
the EA Cube to primarily “help move business and technology planning from a
systems and process-level view to a more strategy-driven enterprise-level view” (p.
13). With this, he implies that he saw a need for a cubic-shaped framework as his
EA Cube including an EA methodology in assisting organisation applying EA
programmes successfully in their organisations. However, whether an organisation
ought to select one framework over another depends on the individual
organisation’s needs, requirements and not least experiences and ambitions with
EA, as will be proven in this thesis’s analysis.

3.5.         EA methodology
According to Bernard (2004), the EA Cube is only part of the EA process which
includes both a documentation methodology and management programme (see
figure 4 below). Therefore, it seems prudent to include a brief introduction to the
other aspects that Bernard mentions when discussing how to implement an EA

Bernard (2004) emphasises that in order to be able to provide an informed
foundation for management decision-making, an organisation must apply a
documentation methodology that entails:
Successful Enterprise Architecture                                               15

        EA approach: A modelling framework (e.g. the EA Cube) and
        implementation methodology.

        Current architecture: View of ‘as-is’ strategies, processes, and resources.

        Future architecture: Views of ‘to-be’ strategies, processes, and resources.

        EA management plan: A plan to move from the current to the future view.

Figure 4 Enterprise Architecture Approach

                    Enterprise Architecture Approach

  Documentation of                                    Documentation of
                           EA Management Plan
     the current                                          the future
                          (standards, sequencing
      Enterprise                                          Enterprise
     Architecture                                        Architecture

Source: Overview of EA Documentation, Bernard, 2004 (p. 34)

The precise, high-quality information an EA provides makes it much easier for the
organisation to respond to the forces of change and should improve decision
making in relation to various areas (Schekkerman, 2004). Working as a
management programme, EA provides a strategy and business driven approach to
the following four areas:

        Resource alignment: Resource planning and standard setting

        Standardised policy: Resource governance and implementation.

        Decision support: Financial control and configuration management.

        Resource oversight: Lifecycle approach to development and management
        (Bernard, 2004).

This, however, entails that the EA must be part of an overall governance structure
that includes management policies and processes to be effective (Bernard, 2004) as
illustrated in figure 5 below.
Successful Enterprise Architecture   16
Successful Enterprise Architecture                                                   17

Figure 5 Governance structure


                                     Workforce                  Enterprise
                                     Planning                  Architecture


                                  Program                        Capital
                                 Management                     Planning


Source: Bernard, 2004 (p. 33)

With the EA Cube framework and the EA methodology, Bernard (2004) both
simplifies and augments different processes for an organisation to consider when
approaching an EA programme. Thus, he also defines other processes to be aware
of above the completion of an EA framework when an organisation commences on
an EA programme.

3.6.         Conclusion
As discussed above, the basis of an EA framework is to provide means to describe
the organisations’ ‘as is’ and ‘to be’ architectures aiming at improving the alignment
between business and IT. The various EA definitions, however, clearly recognise
that these architectures are only part of the entire EA process that also includes
methodologies as to how to get from the current to the desired state, the
management of the EA and not least the governance of the EA which will be the
subject of discussion in the next section.
Successful Enterprise Architecture                                                    18

4. Governance and Decision Structures from an IT
A governance process is crucial to ensure effectiveness in an organisation’s EA
(Giga Research, 2003). EA governance (EAG) centres around creating and making
sure that the EA processes and structures are followed and EAG is thus a key
aspect of ensuring positive EA performance (Cutter Consortium, 2003; Brundage
and Gøtze, 2004).

In the following, I will examine definitions of the term ‘governance’ and look into
the IT Governance (ITG) discipline. Specifically, I will describe and analyse a well-
known IT governance decision structure model from an EA perspective. I will
conclude with an evaluation of the relevance of ITG in relation to governing an EA.

4.1.         Governance scope
Webster’s dictionary of the English language defines governance as “the act of
governing; exercising authority” and “the persons (or committees or departments
etc.) who make up a governing body and who administer something”. Wikipedia,
the free encyclopaedia on the internet defines governance as “dealing with the
processes and systems by which an organisation or society operate”. The essence
of governance is thus to enforce the systems, structures, and processes by which
something is operated.

In recent years, corporate governance (CG) has attracted much attention not least
due the Enron and other organisation scandals (Harris and Kramer, 2002). As is
clear from the following two definitions, CG is the high-level governance body in
organisations that defines the structures, systems, policies, and responsibilities,
among others, within which an organisation must operate.

OECD defines CG as “the system by which business corporations are directed and
controlled. The corporate governance structure specifies the distribution of rights
and responsibilities among different participants in the corporation, such as, the
board, managers, shareholders and other stakeholders, and spells out the rules and
procedures for making decisions on corporate affairs. By doing this, it also provides
the structure through which the company objectives are set and the means of
attaining those objectives and monitoring performance” (OECD April 1999).
Successful Enterprise Architecture                                                                       19

The Danish ‘Nørby Committee’8 defines Corporate Governance as “the goals an
organisation is governed after and the high-level principles and structures that
regulate the cooperation between the governing bodies in the organisation, the
owners and others that are directly affected by the organisation’s transactions and
company (referred to as the organisation’s ‘stakeholders’). The stakeholders
comprise, among others, employees, creditors, suppliers, customers, and the local
community”9 (www.corportegovernance.dk).

The intensified focus and importance of CG has undoubtedly influenced the
development of IT governance (ITG) in recent years (Kühn Pedersen and Holm
Larsen, 2005). This is not least because IT is becoming a more strategic asset in
the organisations in their aim at generating business value. However, many
organisations have significant problems in the IT area, e.g. as has been seen in the
National Labour Market Authority’s Amanda IT project. The reason why this is a
much bigger problem with a higher focus today than 15-20 years ago is because IT
today involves much more money. The IT budgets are growing and as a result, it is
not indifferent which decisions are made and who makes them (Zangenberg,
interview, 2005).

ITG Expert Committee's10 Mission Statement and Yvonne Balzer, IBM, DK adopts
the IT Governance Institute’s ITG definition: “ITG is an integral part of enterprise
governance and consists of the leadership and organisational structures and
processes that ensure that the organisation’s IT sustains and extends the
organisations strategies and objectives. IT Governance is the responsibility of the
board of directors and executive management”.

    On November 5, 2005, Copenhagen stock exchange published the constitution of a committee looking
into ‘proper corporate management’. The task of the committee is to improve corporate management
and governance of Danish companies listed on the exchange. The committee has the following
members; Lars Nørby Johansen (chairman), Mads Øvlisen, Sten Scheibye, Peter Ravn, Henrik
Stenbjerre, Finn L. Meyer and Lars Rohde

    Translated from: ”De mål, et selskab styres efter, og de overordnede principper og strukturer, der
regulerer samspillet mellem ledelsesorganerne i selskabet, ejerne samt andre, der direkte berøres af
selskabets dispositioner og virksomhed (her kollektivt benævnt selskabets ”interessenter”).
Interessenter omfatter bl.a. medarbejdere, kreditorer, leverandører, kunder og lokalsamfund”.

     Part of Dansk IT
Successful Enterprise Architecture                                                      20

Ross and Weill, MIT (2004) define ITG as “specifying the decision rights and
accountability framework to encourage desirable behaviour in using IT. IT
governance is not about making specific decisions –management does that - but
rather determines who systematically makes and contributes to those decisions” (p.

As these two definitions show, there is no clear consensus around what exactly ITG
contains. However, the basic idea seems to be to control an organisation’s IT
aiming at supporting the high-level business strategy. The disagreement of the two
definitions lies in who holds the responsibility. The first definition clearly states that
the top management is responsible whereas Ross and Weill (2004) do not proclaim
any particular party to be in charge of ITG. As we will see below, Ross and Weill
(2004) define different domains in relation to IT and based on these domains, the
organisation must evaluate who are to take the decisions (is responsible).

In the following, a well-known ITG arrangements matrix developed by MIT Sloan
School Center for Information Systems Research (CISR) (2003) will be described.
Gartner Group uses the model and its implications will thus be analysed based on
an interview with Henrik Zangenberg, Gartner Group. I will look at different ITG
decision structure set-ups based on the arrangements matrix and following this, I
include a model (‘the Glocalisation model’) that helps establish an organisation’s
general governance set-up which can be used as an indicator of which ITG set-up
would be most relevant. Further, I will explore the arrangements matrix’s
relationship to EA. I have chosen this specific model as I find it useful in defining
governance decision structures in relation to an organisation’s EA.

4.2.         An IT governance arrangements matrix
In every organisation in which IT plays even a marginal role to the business, it is
important that the organisation has completely well-defined roles of who makes
which decision and who provides input in relation to IT (Ross and Weill, 2004). The
ITG model assists organisations in defining these roles and it consists of five
decision domains and six archetypes.
Successful Enterprise Architecture                                                                           21

Figure 6 The IT governance arrangements matrix

                        IT                 IT                 IT              Business             IT
                    Principles        Architecture      Infrastructure       Application       Investment
                                                          Strategies           Needs
                 Input   Decision    Input   Decision   Input   Decision   Input   Decision   Input   Decision

 A   Business
 C   IT
 H   Monarchy
 T   Feudal
 P   Federal



Source: MIT Sloan School Center for Information Systems Research (CISR), 2003 in Ross and Weill,
2004, p. 11.

The five decision domains:

IT Principles: IT principles are maxims directly arisen from the business strategy
that set the strategic role for IT and consequently guide the organisation’s use of IT
(Ross and Weill, 2004).

It can be a rather complex task to define IT principles and to distinguish between
when a statement is a principle or an architecture decision. For example, an
organisation could choose SAP to be their strategic technology and SAP is thus the
system they will use whenever possible. However, SAP could also simply be a
choice of architecture (Zangenberg, interview, 2005).

IT Architecture: IT architecture translates the IT principles into requirements for
integration and standardisation and following define a technical road map for
providing needed capabilities (Ross and Weill, 2004). The IT architecture domain is
very comprehensive. In this domain, the organisation does not make decisions
about the business processes but only technology related decisions.

IT Infrastructure: IT infrastructure is the foundation of planned IT capability
available throughout the business as shared and reliable services are used by
multiple applications. The aim is to establish an agile infrastructure that enables
Successful Enterprise Architecture                                                             22

rapid implementation of future electronically enabled business initiatives (Ross and
Weill, 2004).

Business Applications: Business applications are the functional design of the
organisation’s business systems. In addition, to reinforce the organisation’s core
processes, decisions about business application needs are important for responding
to market changes (Ross and Weill, 2004).

IT Investment and Prioritisation: IT investment and prioritisation is dealing with
prioritising the IT budgets in which principles are converted into systems (Ross and
Weill, 2004).

Each of the five decision domains require individual attention but at the same time
it is important that none of them is made in isolation as all the domains are
dependent on each other as there exist many inter-dependencies (Ross and Weill,

Comparing the ITG matrix to the EA Cube Framework shows that there exist
domain similarities and differences:

Figure 7 Domain comparisons between the ITG matrix and the EA Cube

                              ITG matrix                    Relating to the EA Cube
                           decision domains                     domains/levels

                   IT Principles                      ≈ Goals and initiatives (IT part)

                   IT Architecture                    ≈ System and application

                   IT Infrastructure                  ≈ Networks and infrastructures

                   Business Applications              ≈ Products and services (IT part)

                   IT Investment and Prioritisation

                                                      ≈ Data and information

                                                      ≈ Products and services (business
                                                      ≈ Goal and initiatives (business part)

Source: Own contribution

As the figure above shows, the ITG matrix decision domains cover some of the EA
Cube framework. However, to be fully applicable with the EA Cube, I miss a domain
dealing specifically with ‘Data and information’ and an organisation’s business
processes arisen directly from the business strategy – that is the part of ‘product
Successful Enterprise Architecture                                                      23

                                                                                             Kommentar [A1]:
and services’ that is purely business related. From an EA perspective, which is to
improve the IT and business alignment, the ITG model must be extended to cover
the business perspectives as well. Zangenberg (interview, 2005) also comments
that a governance set-up without an architecture covering both business and
technology that will help the organisation achieving their goals, will result in sub-
optimisation with wrong decisions at different levels. Thus, the ITG model seems to
only have an IT focus that does not take the business architectures into account. I
will get back to this point in my guidelines in section 8. Looking at the EA
framework’s domains, one could argue that the EA framework miss an area relating
to the ‘IT Investment and Prioritisation’ compared to the ITG matrix. However, the
EA framework, as a whole, serves as the basis on which to make relevant IT

The ITG model also consists of six archetypes. These archetypes refer to who
makes the decisions within the five domains and who provides input to the
decisions. Some people have input rights and some people are required to deliver
input (Ross and Weill, 2004). A set-up could be that the IT department must
provide input to the decisions regarding the infrastructure strategies but it is the
management that makes the decisions.

The six ITG archetypes:

Business Monarchy: This archetype consists of a group of business executives or
individual executives that could include committees of senior business executives.
This archetype excludes IT executives acting independently (Ross and Weill, 2004).

IT Monarchy: The IT monarchy archetype comprises individual IT executives or
groups of IT executives (Ross and Weill, 2004).

Feudal: This archetype refers to business unit leaders, key process owners or their
delegates (Ross and Weill, 2004).

Federal: The federal archetype consists of corporate level executives and business
groups. The archetype may also include IT executives as additional participants
(Ross and Weill, 2004).

IT Duopoly: IT duopoly comprises IT executives including one other group (Ross
and Weill, 2004).
Successful Enterprise Architecture                                                  24

Anarchy: The anarchy archetype is referring to each individual user (Ross and
Weill, 2004).

These governance archetypes could serve as inspiration for establishing the
governance decision structures for an EA in different domains. They may assist in
defining the best set-up in relation to which persons should take which decisions in
specific areas.

Mapping an organisation’s current decision structures into the ITG model extended
with the business perspective will show who takes which decisions in the EA
domains. The model will display any advantages and disadvantages and be a guide
to the organisation in developing a governance decision structure that will aim
directly at achieving their business goals supported by their IT portfolio.

4.2.1.        Examples of governance decision structure set-ups
Ross and Weill (2004) have analysed about 250 organisations and examined
whether there is some governance decision set-up that works better than other do.
They mapped the 250 organisations’ governance set-ups into their ITG model and
asked the management in these organisations whether they believe that their IT is
supporting their business in a satisfying way and whether their governance model
supports their goals and consequently is not a barrier to how they wish to run their
business. The results indicate that there are set-ups that work better than other do
based on the specific organisation in question.

One of the preferred governance set-ups is a construction in which the IT
department makes architecture decisions. Such a set-up applies to those
organisations in which IT plays a marginal role and thus only holds a supporting
function. Zangenberg (interview, 2005) points at the Danish organisation ‘Jysk’
(Dyne Larsen) as an example of an organisation that runs such a set-up. Here, the
management board states that IT is not important to them. Their core business is
to buy quilts cheaper than they are able to sell them. Consequently, they need
systems that helps them carry out this business model and which is easily scalable
as they opens up new stores on a regular basis. Their choice could easily be a
standard system and they have chosen a SAP strategy. In this set-up, the
management board does not have to focus their attention too much on their IT but
they can instead concentrate on the business in general. They have communicated
to their IT department that they must be able to support a strategy in which the
Successful Enterprise Architecture                                                     25

organisation opens up two new stores a week. This is laid out in a set of IT
principles that are very clear and extremely simple.

This example illustrates that governance is much about executing strategic
management decisions. The top management must establish principles upon and
within which employees act. However, it is important to note that one of the pitfalls
in letting the IT department make decisions about the IT architecture is that the
organisation presumes that the department understands the business to such an
extend that they can build an architecture that match the business wishes in two to
three years. This could easily be a gamble and I certainly would view this as a very
defensive way of working with IT strategy.

The above set-up would obviously not work in all organisations. For example, in
banks or the public sector the interrelation between the business strategy and the
IT strategy is much more complex (Zangenberg, interview 2005). Here there are
typically interactions between the business and IT strategies and not just from the
business strategy to the IT strategy. This could occur in situations in which IT
creates new opportunities for the organisation, which they ought to take into
account. This, of course, has implications, as an existing static architecture can be
an obstacle in implementing these new ideas. As a result, these organisations have
to adopt a dynamic view to architecturing, which requires capital and investments.
Making such investments is a top management decision as they hold the
responsibility for prioritising capital usage to best meet the overall goals for the
organisation. This should not be delegated as an independent decision to various IT
executives based on their beliefs about what is most efficient at their level. In such
an organisation, the architecture decisions should be placed where the strategic
management is involved.

Zangenberg (interview, 2005) comments that the ITG set-up also depends on how
the organisation’s governance decision structures works in general. If the
organisation is very much top-down and hierarchical controlled, then top
management or alternatively an IT steering committee will most often control and
directly manage the IT decisions. On the other hand, if the organisation is very
much division controlled, the organisation could choose a model in which the
individual divisions themselves determine their own architecture (Zangenberg,
interview, 2005). Implementing such a set-up indicates that the organisation has
accepted that it might be harder to built or use systems across the entire
organisation. The organisation could also choose to control some of the architecture
Successful Enterprise Architecture                                                                26

centrally and decentralises only parts of the architecture. This would result in a
federal governance model.

Many different governance structures have both pros and cons and the right
solution dependent on the specific organisation. “If there is too big a disconnect
between the general decision model and the way IT decisions are made, problems
will occur” (Zangenberg, interview, 2005, 0:30:44). Therefore, the first step in
defining the ITG structure is to examine how the organisation makes the general
decisions. Based on these results and the organisation’s goals, the ITG structure
should be defined.

4.2.2.        The Glocalisation model
The Glocalisation model is a model that operates with four controlling archetypes.

Figure 8 The Glocalisation Model


                                        Central            Federal

                                        Parental            Local

                                  Low                                High

                                         Local Responsiveness

Source: Own contribution based on Zangenberg, interview, 2005; ‘Midtjylland Rapporten’, 2005, p. 39

The Pure Central Model: The organisation makes all decision centrally and in
principle, all departments in the organisation are obliged to follow them. This set-up
has a very top-down driven structure. An example of a Danish organisation that has
such a set-up is Danske Bank. To a great extend they have a very centrally driven
IT decision structure in which the departments are told what to do. In relation to IT,
this set-up will include a large central system, which all employees have to use, and
there will be manuals that explain what the employees must do from A to Z
(Zangenberg, interview, 2005).

The Federal Model: In this set-up, some decisions are made centrally. Beyond
that, there exists complete freedom to how they wish to run their business locally.
Successful Enterprise Architecture                                                    27

Here there will be a manual that explains some of the things the employees must
do, e.g. a security manual that includes procedures in relation to the organisation’s
security in general (Zangenberg, interview, 2005). The A.P. Moller - Maersk Group
is a very complex organisation with some federal structures. Some decisions are
made centrally but there also exist local freedom to a great extend.

The Multi Local Model: Nothing is decided centrally. The organisation is run
individually in small units (Zangenberg, interview, 2005).

The Parental Model: The organisation distributes best practices in that the
organisation communicates to its units what works best. In principle, the units can
decide themselves (Zangenberg, interview, 2005).

The Glocalisation model shows that if the organisation wishes to have local
responsiveness (the ability to adapt the local organisation to the local conditions),
the multi local or federal models are to be preferred compared to the very parent
led or centrally controlled models. In this way, the decisions will be made closer to
the market needs, which they try to meet (Zangenberg, interview, 2005).

Mapping an organisation’s general decision structures into the Glocalisation model
gives background knowledge as to how the organisation is governed and how this
will influence their governance of their IT (Zangenberg, 2005). Based on the
specific organisation, the Gartner Group typically creates archetype scenarios of
how the ITG decision structures could look in future. This provides the organisation
with a clear understanding of the different possible scenarios and their implications.
Disagreement between an organisation’s general decision structures and how they
make IT decisions is possible, but it should be a conscious choice. It is thus all
about being aware of and decide who are to take which decisions.

4.3.      Conclusion and evaluation of IT governance in an
       EA respect
There is no doubt that ITG is important in relation to governing EA, as the core of
EA is to govern and manage IT in line with the business strategy. The above ITG
matrix and the Glocalisation model are useful tools in establishing the best IT
decision structures based on an organisation’s general governance model. However,
in relation to governing the entire EA, I believe that we need to focus more directly
on the specific processes and structures in an EA, which I find is not fully apparent
in the ITG discipline.
Successful Enterprise Architecture                                                   28

Jeanne Ross, MIT (2005) says that there are “two things IT and business must get

Enterprise Architecture: The organising logic for IT applications, data, and
infrastructure captured in policies and technology choices to achieve the
standardisation and integration requirements of the organisation’s operating model.

IT Governance: The decision rights and accountability framework to encourage
desirable behaviour in the management and use of IT.

From the above statement, it seems that adopting these two disciplines will give
the organisation the possibility to make their IT support their business. However,
seen from an EA perspective, I believe that an organisation must look specifically at
EA governance (EAG) as opposed to ITG. As we saw above, there are definitely
many relevant perspectives in the ITG discipline when seeking to govern an EA, but
aiming at governing an EA including all its systems, processes and structures, EAG
is, as the term implies, directly focusing on governing an EA that provides business

With this thesis, I do not seek to define the specific relationship between IT
governance and EA governance, merely, I aim at establishing the specific
governance mechanisms that will help an organisation implement a dynamic EA
that is anchored in the organisation and that creates business value. Thus, in the
next section, the EA governance discipline will be analysed aspiring to define
governance mechanisms that are necessary above the IT governance decision
matrix and the Glocalisation model in creating a successful EA.
Successful Enterprise Architecture                                                   29

5. EA Governance and Management
In this section, I will first explore the scope of EA and following analyse the EA
governance processes necessary to establish a dynamic EA.

5.1.         EA scope
Scott, Cutter Consortium (2004) defines EA Governance as a process that: ”focuses
on internal IT stakeholders, mainly development and infrastructure project teams,
and it defines the set of roles, responsibilities, and practices by which all EA
processes are managed and maintained” (p. 1).

IBM, Canada defines EAG as a process that: “defines the principles, processes and
roles required to manage, use and update the EA” (Spurway and Patterson, 2005,
p. 25).

A third EAG definition states that “EA governance is the critical management
oversight, guidance, and control framework essential for the success of an EA
programme and the long-term success of the enterprise” (Brundage and Gøtze,
2004, p. 3).

Based on the above definitions, I conclude that the essence of EAG is to ‘define the
roles, principles and control framework focussing specifically on creating and
managing a dynamic EA’. In the following, I will explore what this specifically

5.2.         EA governance processes
Spurway and Patterson (2005) describe EAG as existing of two main processes
referred to as ‘compliance’ and ‘vitality’.

Compliance: The process by which the EA will be used and enforced in the day-to-
day decision-making by the organisation.

Vitality: The process by which new business needs are assessed and the EA
enhanced to enable them, and by which new technologies are incorporated into the

This illustrates that there are two important aspects in relation to establishing the
EA in the organisation. There must be established processes that ensure that the
EA is followed and that the content of the EA is always updated.
Successful Enterprise Architecture                                                     30

5.2.1.        Ensuring compliance and vitality
There are three main areas in relation to governing and managing an EA (Dreyer,
interview, 2005):

Establishing the EA model (complete the EA framework): The organisation
creates the ‘as is’ and ‘to be’ states of the organisation and then prepare a
transitions plan in accordance with the principles established based on the high-
level business strategy to get to the ‘to be’ state.

Project Review: The project review process is external to the EA model. The aim
is to integrate the EA into the project review process to secure that the organisation
only develop in accordance with the business and technology plans defined in the
EA model. In IBM’s project management model, one of the prerequisites to receive
funds to continue a project is to receive an acceptance from the EA group. Further,
any project reviewed is used to update the EA model, as the EA organisation is
automatically informed of all new IT-related initiatives that come into the
organisation (at least via projects) (Dreyer, interview, 2005).

Maintenance: Maintenance is dealing with the low-level governance of the
organisation’s existing IT applications, e.g., minor improvements of existing
applications. This process is part of the daily operation and is often included in what
is often referred to as application portfolio management (Dreyer, 2005).

There is also maintenance in relation to keeping the EA up-to-day. These processes
must, for example, be enabled in relation to new business and IT possibilities that
the organisation might find valuable to them and which they therefore incorporate
into their ‘to be’ views.        Governance and management of the EA components and
To sustain compliance and vitality in above three aspects at the EA components and
artifacts level requires structure. In my interview with Peter Dreyer, IBM, he
showed me the ‘RACI’ model (for definition, see figure 9). The model is a powerful
yet simple tool for identifying roles and responsibilities on a cross-organisational
basis (Value Based Management.net and Time to Market). Thus, I find it very useful
when defining governance structures at the component and artifact level.
Successful Enterprise Architecture                                                             31

Figure 9 RACI matrix

             R     Responsible:          The person/s that do the work
             A     Accountable:          The person that holds the decision authority
             C     Consulted:            The person/s that must be involved
             I     Informed:             The person/s that must be informed

Source: Own contribution based on Dreyer, interview, 2005; Value Based Management.net and Time to

The RACI model states that there must be one person who is accountable, whereas
there may be more responsible persons (Dreyer, interview, 2005 and Value Based
Management.net and Time to Market). However, whether the accountable part is
one person or a department, board, committee or other, I believe must depend on
what is most feasible in the particular situation. Further, when using the RACI
matrix in relation to the EA components and artifacts, it is important to be aware of
the limitations the higher levels of an EA framework puts on the lower levels. For
example, Dreyer (interview, 2005) finds that it is important to take into account the
situations in which it is necessary to receive a specific person’s sign off (e.g. from
top management). For example, if an artifact accountable person knows that a
suggested specific change to his/her artifact will affect some of the IT principles,
the sign off should be escalated upwards to the relevant executives as the
appointed accountable is not empowered in this situation. Thus, the accountable
person must ensure that their components/artifacts comply with the EA content.

In my opinion, the ITG decision structure matrix could be used to extend the RACI
model. The idea with different decision domains and archetypes indicates that there
are different possible archetype constructions necessary dependent on the domain.
For example, in the top level of an EA framework, the organisation would often map
their IT principles and any change to these principles would most definitely require
another decision structure including executives compared to a change to the
business application level. This is possible to illustrate in the ITG matrix compared
to the RACI model that defines only one person holding the decision authority.
However, the RACI model is simpler as it does not operate with different archetypes
or domains but simply state the roles that must be apparent in more detail. Using
both models could assist and inspire an organisation in defining the roles and
responsibilities necessary in the different EA domains – possible at an artifact level.
However, both models ought to be extended with an exception process in case of
Successful Enterprise Architecture                                                  32

disagreement or implications to the high-level strategies or principles as according
to Ross and Weill (2004) “Without a viable exception process, business units ignore
the enterprise-wide standards and implement exceptions with no approval” (p. 99).        An EA exception process
A practical exception process is necessary to motivate the business units to comply
with organisational standards and not implement autonomous exceptions with no
approval (Ross and Weill, 2004; Scott, 2004). Such an exception process gets even
more complicated if the organisation is outsourcing some of their processes and
functions (Dreyer, interview, 2005). In this case, the organisation and the external
supplier must together find out who has which responsibilities and who possesses
which competences (Dreyer, interview 2005). Thus, a viable exception process is
necessary in order for structures not to dominate practical flexibility. Governed
flexibility still maintain ad hoc solutions within the governance process, while
structures with no exceptions might imply lack of flexibility that ultimately may put
pressure on business managers to circumvent the governance processes.

5.2.2.        EA roles
There may be many different committees, boards, projects, programmes etc. that
are involved and responsible for part of the EA. Below is an example of three
groups at different levels that could relate to different aspects of the EA:

EA Executive board (mixture of IT and business executives): High-level
governance and decision-making.

EA Office/Organisation (including architects): Daily compliance and vitality
and lower level governance.

Others involved: Typically EA clients e.g. projects, committees, and user groups
(Ross and Weill, 2005; Dreyer, interview, 2005; Brundage and Gøtze, 2004).

The IT governance arrangement matrix could also be used in this respect to map
the various roles responsibility domains.        The necessary competences and knowledge
Implementing and running successful EA requires the right people with the right
knowledge and competences. The organisation needs to involve architects that are
able to translate the strategy into an executable form including understanding the
EA discipline and the EA content and bring this back into the business strategy
Successful Enterprise Architecture                                                    33

(Dreyer, interview, 2005). In this respect, Dreyer (interview, 2005) emphasises
that “there must exist [the necessary] knowledge and competences” (0:20:39).
The architects also need to dynamically maintain the EA and update contents taking
in bottom-up information from individuals and groups as well as interacting with
management to ensure continuous compliance with the overall strategy (Dreyer,
interview, 2004). For example, if the EA group receives a project involving a new
kind of technology then the EA group (architect) must be able to understand this
new initiative and the new technology and subsequently be able to translate it into
the structures in a relationship with the other content in the EA (Dreyer, interview,
2005; Bredemeyer and Malan, 2004). The architects need to evaluate the impact to
rest of the business and involve executive management if necessary.

This shows how important it is for the organisation to involve staff that possesses
the right kind of knowledge and competence. Without these people, it can be
difficult and rather complex to keep the EA alive and updated and hence useful for
the entire organisation.        Senior management buy-in
Succeeding in implementing effective EA requires a significant amount of
management time, attention and resources. Involving executive management is
imperative as they make EA transparent and, thereby, a driver for making
everyone understand and follow the processes for developing, implementing, and
using IT in accordance with the EA (Ross and Weill, 2004; Dreyer, interview, 2005).

It is imperative not to underestimate the importance of an EA champion. Human
capital is the driving force behind the EA processes and therefore critical to
establish an EA and make it work. Executive management is involved in many
initiatives and must prioritise time. Therefore, it is necessary with at least one
person that keeps bringing EA on the agenda in a convincing way, as this will more
likely result in the support and involvement from executive management (Dreyer,
interview, 2005).

5.2.3.        EA organisation
To create and run an EA including achieving compliance and vitality, the
organisation must establish an EA organisation. The EA organisation should (among
other things) be responsible for facilitation of the overall EA governance processes
(Scott, 2004). The EA organisation may consist of both a passive and active part
(Dreyer, interview, 2005).
Successful Enterprise Architecture                                                     34

The passive part relates to the internal maintenance of the EA in which the EA
organisation awaits that people come to them to ask for their service – mainly
through a project model review. The EA organisation has the daily ownership and
responsibility of the EA and they must appoint staff that is responsible for the EA
information (e.g. at the components and artifacts level). They must also ensure the
EA organisation has the right competence and knowledge to be able to maintain
compliance and vitality.

The active part is to look for inspiration (also from outside) and use this to keep
the EA model up-to-date and in the forefront of general EA processes. This can
partly be done by e.g. reading specialist journals, taking part in conferences and
courses, joining ERFA groups and not least making sure that the organisation has a
network in the organisation. The organisation should create a small EA community
with people from different places within the organisation that have special interest
in new business initiatives and technology. If such a community is established
including the EA staff’s own initiatives, this will collect ideas bottom-up and as a
result, the EA organisation can carry the most valuable ideas to the strategy group.

How an organisation establishes such an EA organisation depends on how large it is
and how many resources the organisation is willing to spend on this area. However,
Dreyer (interview, 2005) emphasises that “it is necessary with an [EA] organisation
that includes the competences that match what the organisation intends to control”
(0:22:33). Further, according to Dreyer (interview, 2005), EA works best if it is
controlled form one place. This is in contrast to controlling the EA from different
departments, which is often seen in practice. Often, applications and data are
controlled from one department and the infrastructure from a completely other
department. Typically, the organisation has an application development department
and an operation department (Dreyer, interview, 2005). The danger is that this
makes decisions very disperse which goes against the basic idea of EA - namely to
govern and manage the organisation’s IT portfolio from a holistic perspective where
the aim is that the IT should dynamically interact with the general business.

5.2.4.        Communication
The communication process is also very important - both in relation to implement
knowledge and perceived value about EA in general and thereby influence
behaviour throughout the organisation, but also in relation to any EA change (Ross
and Weill, 2004; and Dreyer, interview 2005). For example, an introducing of a new
valuable technology must be communicated to the relevant stakeholders and the
Successful Enterprise Architecture                                                   35

organisation in general. It is important to set up a structure that ensures fast,
thorough and reliable communication and one of the elements in this process
involves documenting EA in an accessible way (Dreyer, interview, 2005). If there
are no communication structures, the organisation can end up having an EA that
never really is implemented. Visibility and openness around the EA is important to
make things work and to this end, communication is key. The initial implementation
of EA relates closely to change management, which will be introduced in the next

5.3.         Conclusion
EA governance focuses directly on establishing and implementing an EA in an
organisation as well as focus on setting the policy for how EA subsequently should
be run. EAG defines the systems, structures and responsibilities within which the EA
and affected people must operate. There are many mechanisms that must be in
place to be able to achieve a dynamic EA that is part of the organisation’s daily
work, and I have tried to emphasise some of the most important ones to sustain
compliance and vitality in the organisation’s EA. I believe that EAG is a critical
factor in managing EA in a way that induces employees to comply with the EA

To implement EA as an integrated part of the organisation’s culture, I find it useful
to look at change management. The implementation of EA, of course, potentially
generates significant changes throughout the organisation – changes that must be
managed carefully.
Successful Enterprise Architecture                                                   36

6. EA Implementation and Change Management
Change management (CM) is a planned and systematic approach to implement
changes in an organisation in which the organisational and people perspectives of
the change are brought together aiming at achieving the same goals (Wikipedia,
2006; Lamarsh, 2006).

Enterprise architecture is referred to as ‘transformation enablement’ (Gøtze, 2005).
Thus, one basic idea with EA is to operate dynamic changes to the organisation
better by determining the impact between specified EA domains. Consequently, CM
is closely related to EA as many changes will probably be evaluated and operated
through an EA programme. The initial implementation of EA is, of course, also
related to CM itself. In both ways, significant changes affect the way that many
employees carry out their work, and, therefore, it is important to consider how to
manage such changes and how the responsibility for change is anchored in the
organisation. Here, I will focus on how CM relates to both the initial part of EA
implementation, and how CM as a theory can support EA as a change facilitator.

CM is a broad area with many different perspectives. The following section is only
meant as a practical introduction with focus on elements that I consider important
in relation to implementing EA. I will relate CM to the EA implementation discipline
and in this way show how the CM discipline can help anchor the EA in an

6.1.         Implementing change
In his book ‘Leading Change’, John P. Kotter (1996) introduces eight stages that an
organisation needs to consider and realise when introducing larger changes.
Successful Enterprise Architecture                                                   37

Figure 10 Kotter’s eight change management stages

                                         Kotter’s Eight Stage Process

                                a.   Establish a sense of urgency
                                b.   Create a guiding coalition
                                c.   Develop a vision and strategy
                                d.   Communicate the change vision
                                e.   Empower employees for broad-based action
                                f.   Generate short-term wins
                                g.   Consolidate gains and produce more changes
                                h.   Anchor new approaches in the culture

Source: Own contribution based on Kotter, 1996.

a. Establish a sense of urgency
Urgency among managers and employees is important in ensuring the change is
treated seriously. If the change is not motivated transparent and open, the
employees will not understand why change is necessary, and, consequently, the
employees might not work in the right direction (Kotter, 1996). These aspects and
implied costs should be included in the business plan before initiating an EA
programme. It could be useful to communicate results from the Glocalisation model
and ITG extended matrix to employees, as this would clarify to the organisation
how IT-related decisions are taken and probably point to gaps between business
driven decisions and IT investments, which has imperative economic consequences.
Such an analysis should motivate a need for better IT and business alignment, and
this is key to employees in accepting the need of an EA programme.

b. Create a guiding coalition
One person alone cannot implement significant changes in a large organisation.
This will take a professional team with a clear mandate. The team must have
responsibility, expertise, credibility, leadership and management skills. Further, the
team must understand and work towards the same goals (Kotter, 1996). A clear
parallel can be drawn from CM to the EA organisation including that of roles,
responsibilities, and relevant competences.

c. Develop a vision and strategy
A sound and clear vision and strategy is, of course, necessary to steer the changes
in the right direction. There has to be a clear plan that will also help employees
understand why the changes are necessary and why they might have to change
Successful Enterprise Architecture                                                    38

their way of working (Kotter, 1996). The IT principles governing the EA content
must reflect the vision and strategy.

d. Communicate the change vision
Communication is a key aspect in implementing changes. The communication of the
vision should be simple, consist of examples creating a verbal picture, use multiple
forums, be repetitive, and use ‘leadership by example’. Two-way communication
should be prioritised to make employees take ownership and the process should be
dynamically evaluated to meet inconsistencies. Further, it is important that the
entire organisation (specifically the management) act according to the vision (‘walk
the talk’), otherwise the changes will be undermined (Kotter, 1996). Thus,
communication is a very important tool in making EA visible and part of the
employees’ daily work.

e. Empower employees for broad-based action
Obstacles that block the new vision must be removed or changed. Elements to be
aware of in relation to empowerment of the employees during the change
management process include: formal structures that makes change difficult, lack of
skills that support the process, personnel and information systems that make it
difficult to act and reluctant managers that discourage actions aimed at
implementing the new vision (Kotter, 1996). To remove obstacles (top)
management must buy-in and the exception process must exist. If the top
management is not supporting the idea, there is no reason for the employees to do
so. As discussed in the last section, establishing an EA is a significant task that will
not survive without the top management involvement and investments. In addition,
a practical exception process allows for conscious and necessary deviations.
Further, ensuring that an organisation has the right EA competences and
knowledge will also ease the EA establishment and implementation.

f. Generate short-term wins
It is important to produce short-term results in the change management process.
This will show that the organisation is on the right track, that it is advantageous to
continue the transformation, and it will help build positive momentum among top
management and employees. The short-term results must be visible, unambiguous
and clearly related to the change process (Kotter, 1996). EA short-term results
should prove why the organisation wants to establish such working processes, and
should quickly make clear the advantages of such a programme. Further, it will
Successful Enterprise Architecture                                                      39

show and increase the individual employee’s understanding of why changes to their
daily work is necessary

g. Consolidate gains and produce more changes
The organisation should be careful not to declare victory too soon. It is important to
keep employees working on the transformation even after the first results, as there
is still a long way to the actual goal (Kotter, 1996). It requires hard work and takes
a long time before an EA is established in the organisations. Therefore, the quick
wins are necessary, but they are not signs of the EA being anchored in the
organisation yet.

h. Anchor new approaches in the culture
It is vital to anchor the changes in the organisation before letting go of the process.
If this is not done, the ownership is lost and the changes might disappear.
Anchoring change requires all the eight steps and usually in the above sequence,
even though it is very common that an organisation often works at more stages at
the same time (Kotter, 1996). As previously described, EA is a long-term and
resources intensive programme that often trigger large organisational changes, and
establishing those changes in the organisation is a complex and long-term process.

6.2.         The importance of leadership
As suggested earlier, top management plays an important role in anchoring EA and
consequently manage change. In this respect, leadership is very important.
Leadership involves a relationship in which leaders motivate followers to perform by
providing challenges and support and by rewarding people fairly for their efforts
(Chemers, 2003). Kotter (1996) distinguishes between management and
leadership. Leadership is dealing with a vision for the future and strategy in relation
to how to achieve the vision. Management, on the other hand, is dealing with plans
containing specific steps and timetables to implement the strategy, supported by
budgets, financial projections and goals (Kotter, 1996). Both leadership and
management are important factors in relation to CM, but it is the leaders’ task to
create the visions that will bring positive results to the organisation. Further, the
leader must motivate the employees to act according to the changes.

The leader must create responsiveness towards changes in the organisation and
consider them as opportunities instead of threats. Too many organisations focus on
problem solving but this undermines the ability to create something new. Accepting
changes in the organisation will help the organisation meeting the future by being
Successful Enterprise Architecture                                                     40

proactive instead of reactive (Drucker and Senge, 2001). As EA is about handling
change, it is important to involve those leaders that view changes as opportunities,
as these will ease the EA anchoring in the organisation.

The organisations should implement ‘organised phase-outs’ into the systems on a
regular basis in which the organisation asks itself whether a product, service or
system is still relevant. If the answer is negative, the product, service, or system
must be stopped right away (Drucker and Senge, 2001). This is a process that is
highly relevant in relation to EA, as the basic idea is to improve the alignment
between IT and business, which will undoubtedly require that some old systems are
to be rendered obsolete. However, it can be very difficult to give up on existing
processes, as the employees are emotional involved in their work. Still it is
sometimes necessary to give up on the old systems to implement and control
change (Drucker and Senge, 2001). Drucker and Senge (2001) point to three
important strategic principles that may assist this process:

        Problem solving is not to create

        Effective leaders must be open to surprises

        Changes start with the few that are enthusiastic and not the larger majority.

It is difficult to work with the majority of employees and convince all of them to
work in line with the changes. Instead, the leader should work with the key
employees, guide them, and, subsequently, the rest will follow (Drucker and Senge,
2001). Thus, preparing a stakeholder analysis focussing on those that deliver
results and are enthusiastic about the change makes it easier to achieve success in
managing changes, whereas trying to convince everybody at the same time is far
too complex and almost always impossible.

6.3.         Conclusion
Chemers (2003), Kotter (1996), Drucker and Senge (2001) agree that leadership is
important to manage change. This emphasises that the architects that lead the EA
programme implementation must be able to look beyond status quo, beyond
problem solving and seize opportunities as inspiration for new goals that will
support the overall visions and strategies. Afterwards the architects must
implement the changes in the organisation with the help of managers and other
employees. Here Kotter’s (1996) eight steps are relevant and can be used as a
Successful Enterprise Architecture                                                  41

practical guide. In this process, both the organisation and its employees must be
involved for the adoption process to work, and for the changes to take effect in the
organisation by ultimately changing the daily behaviour of individual employees.
Successful Enterprise Architecture                                                                   42

7. EA Maturity and EA Measurement
Even though EA is being implemented, this is no guarantee that it performs. An
organisation needs to measure continuously the value added of the EA and thereby
evaluate its justification (Schekkerman, 2005). Good intentions and a good start
are not measures of success. What matters in the end is completion that delivers
performance and results (Office of Management and Budget (OMB), USA).

This section will focus on evaluating an EA, which will be analysed from two
perspectives. First, I will analyse the maturity of the EA itself in relation to
establishing the EA. I will use two models to show the generic content of such
models that, however, also do entail some differences. Secondly, I will briefly touch
upon the analysis of measuring the business value that the EA generates.

7.1.           GAO’s EA maturity model
In USA, many organisations have worked seriously with EA for a number of years,
which places USA among the top performing EA countries in the world (IFEAD cited
in Schekkerman, 2005). This naturally implies that many organisations in other
countries look to the US for input and advice on how to approach an EA
programme. The Government Accountability Office11, USA (GAO) has published a
report including an EA maturity model. This maturity model is highly relevant for
organisations attempting to establish and implement an EA, as it explicitly states in
practical terms which activities are necessary to reach a certain EA maturity state in
which EA generates business value.

The model is a practical framework for assessing and improving EA management. It
defines activities to assist an organisation in achieving a stable and mature process
for managing the development, maintenance and implementation of EA. It includes
five stages that are cumulative which means that each activity builds on lower
maturity levels that in this way must be completed before moving to the next
maturity level. GAO has created the model to provide federal agencies in the US
with a benchmarking tool for planning and measuring their EA efforts. Using the
same tool will make comparison between the offices easier (GAO, 2003). However,

     GAO is an agency that works for the US Congress and the American people. Congress asks GAO to
study the programmes and expenditures of the federal government and thus GAO evaluates federal
programmes, audits federal expenditures and issues legal opinions.
Successful Enterprise Architecture                                                 43

many of the activities are of a generic nature, and I believe the model could be
useful for other organisations worldwide as well.

The five stages in GAO’s EA maturity model follows below:

Stage 1 Creating EA awareness: The organisation may have initiated some EA
activities. They are, however, ad hoc and unstructured and they lack organisational
leadership and direction.

Stage 2 Building the EA management foundation: The organisation recognises
that EA is a corporate asset benefiting the entire organisation. The organisation has
appointed a chief architect and established a programme office (EA organisation)
responsible for EA development and maintenance. In addition, the organisation has
established a group (often a steering committee representing both business and IT
managers) that is responsible for the EA governance (i.e. directing, overseeing and
approving architecture development and maintenance). An EA framework and
methodology have been selected, and the organisation has plans for or has started
developing some EA products. Further, awareness of the value of an EA and its
intended use in managing an organisation’s IT investment has been communicated
to the entire organisation.

Stage 3 Developing the EA: Scope of the architecture has been defined to include
the entire organisation. The focus is on developing architecture products according
to the selected EA framework, EA methodology and management plans. The
products are to describe the ‘as is’ and ‘to be’ states and the transition plan
between the two. The organisation is measuring its progress against plans,
identifying and addressing gaps.

Stage 4 Completing the EA: The EA products (the ‘as is’ and ‘to be’ states and
the transition plan between the two) have been completed and approved by the EA
steering committee or some other board.

Stage 5 Leveraging the EA to manage change: Senior leadership approval of
the EA products is secured and IT investments must comply with the architecture
unless exception is specifically granted. Further, the organisation tracks and
Successful Enterprise Architecture                                                                 44

measures EA benefits. Finally, adjustments are continuously made to both the EA
and management process and the EA products to keep them updated.12

It is important to note that the above maturity guidelines describe what needs to be
done and not how it is done (GAO, 2003). It is a guide an organisation can use to
measure its progress in creating an EA programme. However, how they approach
specific activities is left to the individual organisations. The model may be used as a
guiding tool, emphasising which activities are necessary to establish an EA that
assist the organisation in align IT investments with the business, and,
consequently, improve the management of change.

7.2.         Herzum’s EA maturity model
Peter Herzum, Senior Consultant, Cutter Consortium (2003) has also described five
maturity stages in relation to establishing an EA. Whereas GAO provides a very
comprehensive report describing the entire content in the various maturity stages
(see note 8), Herzum describes the maturity stages from a more theoretical
perspective without the same level of detail. Herzum also identifies the first phase
at an earlier stage compared to GAO. Thus, the two models will show both
similarities and differences. Based on this, I believe that the models together
provide an insight into the necessary steps in creating an EA, and as such may
serve as inspiration for individual organisations when they evaluate their EA
maturity. This evaluation will show which areas they need to improve to climb the
EA maturity latter to improve the business value of their EA.

The five maturity levels:

Phase 1 ‘Inception’:

        There is no explicit process behind the definition of the IT strategy.

        The need for an explicit EA activity has not been recognised.

        The organisation believes that interoperability and integration problems can
        be resolved simply through technology.

12 See http://www.gao.gov/new.items/d03584g.pdf to view the specific content in the different stages.
Successful Enterprise Architecture                                                  45

        No identification of project synergies.

Phase 2 ‘Classification’:

        An EA team has been established.

        The organisation considers existing architectural EA frameworks.

        There is often a tendency to believe that a ‘tool’ will resolve an EA problem

        There may be some creation of an inventory of all existing systems in the
        organisation but this diagram typically has no relationship to other diagrams
        or deliverables.

        Some cross-organisational programmes may be initiated, but in this phase,
        the organisation and the IT management do not have the right architectural
        and governance support to properly address these programmes.

        IT strategic decisions are still ad hoc.

Phase 3 ‘Blueprinting’:

        The organisation develops a common conceptual framework for the various
        organisation-wide activities from all perspectives.

        The ‘as is’ and ‘to be’ states of the IT portfolio are defined.

        The EA effort is explicitly managed as a strategic programme with cross-
        organisational teams that reports to top management.

        Governance processes define how and when to use the EA objectives.

        The EA deliverables can now be used to make informed and ongoing
        decisions about overall directions, strategic programmes, tactical decisions,
        and specific projects architectures.

        The organisation starts to provide organisation services or components but
        they are not yet widely used within the organisation and must still mature.

Phase 4 ‘Integration’:
Successful Enterprise Architecture                                                     46

        There is a strategy for incrementally increasing the level of overall IT and
        business integration.

        The organisation is able to drive a given architectural direction strategically.

        All significant new programmes, purchases, and outsourcing are performed
        to align to a specific IT strategy and reference architecture and the
        governance processes are in place to enforce this.

        There is a shift in focus from the interoperability architecture to the
        integration architecture (the first, focuses on exchanges between systems as
        black boxes whereas the latter focuses on flow of information and building
        systems out of common parts).

Phase 5 ‘Optimization’ (EA nirvana – ‘ideal’ state):

        The IT organisation has all the architectural support, governance support
        and tooling required to manage IT.

        New business strategy objectives can be traced into IT strategy objectives,
        all the way down to the way individual projects are budgeted, managed,
        architected, and executed.

        IT is managed as a business.

        The organisation has reached significant levels of integration.

        The organisation has reached a significant level of agility.

        The reference architecture is realised in the actual IT portfolio and is no
        longer just an ideal future.

        The complexity of the IT portfolio has been significantly reduced

        The whole IT organisation is a learning organisation.

        There are metrics to evaluate the performance of the various aspects of IT
        and these metrics can be directly mapped into business metrics.

        The power of IT is fully realised.
Successful Enterprise Architecture                                                                        47

EA is used to align business and IT strategies. In this respect, it is important to
notice that an EA effort is not to have a wonderfully described EA, but rather to
accomplish a number of business or IT strategy objectives through EA. EA is a
mean to reach an end, not the end itself (Herzum, 2003).

Both maturity models emphasise that there are several stages that an organisation
needs to go through to achieve an EA that is integrated in the organisation and that
generates positive results. There is no easy short cut. All maturity activities must
be completed to achieve an ideal state. I believe that these two models could easily
serve as inspiration for public and private organisations in Denmark. Maybe they
could even be adopted to define benchmarks to stimulate competition and create
best practices.

7.3.            Evaluation of the EA results
The Office of Management and Budget (OMB), USA13 has created a document
‘Enterprise Architecture Assessment Framework, version 1.5’ to specifically
measure how an EA performs within four specific areas and with scores ranging
from 0 (no evidence presented) – 5 (IT planning is optimised through the EA). This
measurement framework can help an organisation continuously improve their EA by
identifying its weaknesses and assisting the EA organisation assessing the achieved
results. Scorecards that employ a simple ‘traffic light’ grading system, which are
common today in well-run businesses (green for success, yellow for mixed results,
and red for unsatisfactory) is applied to the individual organisation based on their
EA assessment results (OMB).

Even though the OMB framework like the GAO EA maturity model has been made
specifically for the US governmental agencies, it can easily be used by other
organisations, at least as an inspiration. The framework looks at two capability
facets of an EA programme:

Maturity of the EA, including:

     “OMB's predominant mission is to assist the President in overseeing the preparation of the federal
budget and to supervise its administration in Executive Branch agencies. In helping to formulate the
President's spending plans, OMB evaluates the effectiveness of agency programs, policies, and
procedures, assesses competing funding demands among agencies, and sets funding priorities. OMB
ensures that agency reports, rules, testimony, and proposed legislation are consistent with the
President's Budget and with Administration policies”.
Successful Enterprise Architecture                                                                      48

           EA product development

           Capability of the EA programme to provide specific investment

Degree of alignment, defined as:

           Alignment with an organisation’s strategic mission, direction and plan

           Reflection of the FEA14 reference models and principles of good architecture.
           This is specifically related to the US agencies but again it could easily serve
           as inspiration for organisations in establishing organisational wide reference
           models, which would ease the streamlining of technical development and
           provide a baseline for assessment.

The four main capability assessment categories are:

Change: Assesses how well EA facilitates change management.

Integration: Assesses how well the EA ensures the standardisation of interfaces,
interoperation, information and connectivity.

Convergence: Assesses how well the EA integrates an organisation’s IT as defined
by the Technical Reference Model15 (TRM) (A FEA reference model).

Business Alignment: Assesses how well the EA ensures alignment with the
organisation’s mission, direction and plan16.

     Federal Enterprise Architecture (FEA), a business-based framework for government-wide improvement
developed by OMB. The FEA is being constructed through a collection of interrelated ‘reference models’
designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and
opportunities for collaboration within and across Federal Agencies.

     The Technical Reference Model (TRM) provides a foundation to categorise the standards,
specifications, and technologies to support the construction, delivery, and exchange of business and
application components (Service Components) that may be used and leveraged in a Component-Based
or Service-Oriented Architecture.

     Assessment schema can be downloaded from OMB’s web site:
Successful Enterprise Architecture                                                    49

Assessing an organisation’s EA will make the EA justification visible. Therefore, it is
important to continuously keep track of the EA work itself, but also of the results, it
creates. EA in isolation counts for little. The value comes from how an organisation
uses the EA, and the results EA generates. It is vital to demonstrate the difference
EA makes in the specific organisation (Federal Computer Week, Sep. 2005).

EA should prevent IT investments that result in duplicative systems that cannot be
well integrated or are unnecessarily costly to maintain. This requires that IT
investments should be defined in the context of defined architectures, and, hence,
its value can be measured and communicated to the organisation (OMB, 2005).

7.4.         Economic evaluation of EA
There is also the economic aspects of evaluating an EA (Schekkerman, 2005).
However, being able to clearly measure the economic benefits requires that an
organisation has a certain level of EA maturity. Still, it is important to think of
evaluation metrics right from the beginning of the EA work, as this will help
establish the EA’s continuation and help the organisation being focused on the
results they expect from their EA work (Schekkerman, 2005). The British physicist
Lord Kelvin wrote in 1981 “When you can measure what you are speaking about,
and express it in numbers, you know something about it” (Schekkerman, 2005).
This quote indicates that when an organisation defines what and how they want to
measure the value of their EA, they most likely have a clear idea of what they wish
to gain from the EA, and how this is achieved.

It requires some considerations establishing the measurement process and metrics.
To achieve success, an organisation must establish and implement an iterative
measurement process that is flexible, pragmatic, and simple and that addresses
both immediate and long-term requirements of the EA stakeholders. (Meta Group,
2004). IT investment evaluation methods are a critical issue because the difference
between the ‘right’ decision and the ‘wrong’ decision is dramatic for many IT
investments. EA can be of great assistance in this respect as many senior
executives are no longer able or willing to make significant investments based
merely on gut feeling. They require a disciplined EA approach and framework to
determine and evaluate investment options and to measure these initiatives as they
proceed (Schekkerman, 2005).

The idea with EA is to create a holistic view of an organisation. As the figure below
shows, this will help reduce duplication and improve synergies, and consequently
Successful Enterprise Architecture                                                                     50

help the organisation improve their return on information while reducing complexity
and costs.

Figure 11 EA benefits

               Return on Information

                                                    Business Architecture

                                                      No Architecture

                                              Low                   Technology                  High

                                                       Reduction of Complexity & Costs
Source: Schekkerman, 2005, p. 20.

EA benefits can be realised in any of these four different categories:

Figure 12 Enterprise architecture value model
                                                          Business                Business
                                                        Effectiveness            Innovation

                                                         Technology              Technology
                                                          Efficiency              Enabling
                        Current                                                         Future

Source: Schekkerman, 2005, p. 67.

The first step is to align the above EA value model with an EA framework model to
determine possible areas of value improvement in relation to the current and / or
future states. Having defined the focus areas, the next step is to identify and
analyse the methods to introduce and implement measurement of economic
benefits inside these focus areas (Schekkerman, 2005).

It is important to keep in mind the existing measurement techniques the
organisation uses (Schekkerman, 2005). It will probably ease the understanding of
the EA value and ease the comparison between the EA programme and other
programmes if the evaluations are based on more or less the same measurements.

Schekkerman (2005) emphasises two areas of measuring EA economic benefits.
Successful Enterprise Architecture                                                  51

Costs of the EA itself: a general equation for the cost of an EA is:

EA Lifecycle Cost = EA Initiation/Definition Cost + EA Development Cost + EA
Implementation Cost + EA Maintenance Cost.

Costs and benefits of EA programmes: the performance measurement of costs
and benefits related to the execution of EA guided transformation programmes. The
best performance and value measurement method is a performance budgeting
approach. This is an integrated annual performance plan and annual budget that
shows the relationship between EA programme funding levels and expected results.
This requires the investment process ‘select, control and evaluate’ of all the
programmes within the EA. Select: all costs and benefits of all EA programmes are
assessed. Control: the selected programmes are monitored. Evaluate: all the
selected programmes are evaluated to check whether they produced what was
expected (Schekkerman, 2005).

Being world-class requires that an organisation’s performance measurement system
encourages behaviour that maximizes corporate results, both currently and in the
future. To be effective, the system must be part of the strategic plan, and each
measurement should be traceable and supportive of corporate purpose. Further,
the performance management system must constantly be re-evaluated to avoid
showing results that are of no interest to the stakeholders (Schekkerman, 2005). It
is also important to keep in mind that today’s human capital is often the most
important asset for value creation whereas capital is becoming more of a
commodity that, at least, is easier to measure. In a people driven business model,
information is a critical resource, and, consequently, effective management of
information should be visible in the measurement results.

7.5.         Conclusion
GAO and Herzum’s EA maturity models are very useful when organisations wish to
measure how mature their EA is. Further, it can make visible which areas the
specific organisation needs to focus on to be able to reach a higher maturity stage
and get more value from their EA. It is important to show the value of the EA both
in relation to specified categories but in the end also with hard figures - otherwise
EA will probably not remain as the benefits might lack transparency. Being aware of
the EA measurements from the beginning will benefit the basis for EA as an
integrated and irreplaceable part of the organisation. In particular, this should
Successful Enterprise Architecture                                             52

strengthen EA as basis for optimising IT investments aligned to the business
strategy, which is the core of an EA.
Successful Enterprise Architecture                                                     53

8. EA implementation guidelines
In this section, I will sum up the theoretical work by defining guidelines for
implementation of EA solutions. The guidelines are a result of the discussions in the
previous chapters, and, as such, sum up the main theoretical and best practise
contributions of this thesis and my evaluation of those. My guidelines are different
to both GAO and Herzum’s EA maturity stages in both approach and content. GAO’s
maturity model is focussing on providing specific tools targeted directly towards US
agencies, and Herzum’s guidelines may be viewed rather theoretical. As pointed out
in the theoretical framework, those models may well serve as an inspiration at each
side of practical and theoretical discussions. My guidelines are a different and
important contribution to EA exactly because of the apparent distance between
theory and practise. Indeed, to me it seems that EA is no exception to the general
challenge of linking academic work to business. It appears that practitioners, in
general, appreciate the importance of EA but also find it very difficult to approach
an EA programme, from creating a map of the organisation to govern and manage
it in future. As such, I hope these guidelines can assist the organisations in their EA
work, and, thus, be a step in the direction of reducing the gap between theory and

The guidelines are a result of approaching the EA discipline from various angles
such as EA frameworks, EA methodology, IT governance, EA governance, change
management, EA maturity and assessment models and best practice evaluation
from two leading consultants on EA implementation (IBM & Gartner Group). My aim
is that the broad theoretical approach evaluated against best practises should lead
to better EA implementation that is different from what I have seen elsewhere in
the literature. Thus, it facilitates my own approach to evaluating the two case
studies below. Further, the guidelines will not only test my empirical work but will
also shed some light on applicability of theory.

The figure below illustrated by four stages - Stage 1: EA foundation, Stage 2: EA
approach, Stage 3: EA governance and management and Stage 4: EA maturity and
measurement (continuously) - will be used in the case comparison section to show
differences and similarities in the two cases.
Successful Enterprise Architecture                                                       54

Figure 13 Illustration of my EA guidelines necessary to establish a
successful EA

                             EA NEEDS ANALYSIS
                                                                       E   E   E
                        TOP MANAGEMENT BUY-IN                          V   V   V
                                                             STAGE 1   A   A   A
                        COMMOM EA DEFINITION                           L   L   L
                                                                       U   U   U
    C                   GOVERNANCE STRUCTURES                          A   A   A
    H                                                                  T   T   T
                   EA ORGANISATION, EXECUTIVE BOARD                    E   E   E
                 RELEVANT COMPETENCES AND KNOWLEDGE                    E   E   I
    N                                                        STAGE 2                 S
                                                                       A   A   T
    G            SELECT EA FRAMEWORK AND METHODOLOGY                                 T
                                                                       M   R   I     A
    E                         DEFINE EA SCOPE
                                                                       A   E   N     G
                                                                       T   S   V     E
             I      I    E      P    M   P       E   U   C             U   U   E
    M                                                                                4
             T      T    S      R    A   R       S   S   O             R   L   S
    A                    T      O    I   O       C   E   M             I   T   T
                         A      J    N   C       A   R   M             T   S   M
    N        D      P
                         B      E    T   E       L       U             Y       E
             E      R
                         L      C    E   S       A       N                     T
    A        C      I                                G
             I      N    I      T    N   S       T   R   I
    G                    S           A           I       C                     S
             S      C                                O
             I      I    H      M    N   O       O   U   A
    E                                C           N       T   STAGE 3
             O      P           O        W           P
    M        N      L    E      D    E   N           S   I
                    E    A      E        E       S       O
    E        S      S           L        R       T       N
             T                           S       R
             R                                   U
             U                                   C
             C                                   T
             T                                   U
             U                                   R
             R                                   E

Source: Own contribution

As indicated, the guidelines are split into four main stages. Each stage points to
certain processes and mechanisms, which are necessary to establish a successful
EA. Further, inside the stages, I will suggest which tools or models can be helpful
and which change management steps ought to be taken into consideration to
complete a certain level of EA. The change management steps are an integrated
part in many of the processes, however, my aim is to draw attention to the most
obvious ones.
Successful Enterprise Architecture                                                        55

Below the stages are illustrated using four schemas. This is done to ease reading
and to provide a clear overview of all the processes, models and Kotter’s eight
change management steps.

8.1.         Stage 1: EA foundation
Stage 1 is the foundation stage. Here, the organisation must perform a needs
analysis and EA cost benefit analysis. This should help them establish to what
extent an EA will assist them in solving any problems and/or assist them in
achieving their goals. It is important that the organisation specifically define why
they intent to implement an EA and as such establish how an EA would create
benefit to them. Based on these conclusions, it will be an advantage to obtain the
top management’s buy-in already at this early stage given indications from a
business case. The sooner the top management acknowledges sizable problems,
the more focussed and direct problem solving can be. This should, in turn, imply a
quicker and less costly EA programme in terms of getting the initial project
established, getting the EA structures implemented and getting the EA organisation

It is clear from the theoretical part of this thesis that various EA definitions exist.
Therefore it is important to have a common understanding of what an EA
programme entails. Often, organisations consider implementing an EA if they wish
to practise more central control of their IT portfolio in order to improve their
business and IT alignment. In this context, I recommend that the organisation uses
the Glocalisation model to map their current high-level IT governance structures in
relation to their general governance structure. This will help them evaluate whether
they are actually satisfied with their IT structure or whether they should aim for
another more appropriate structure in relation to their goals. As was shown in the
theoretical framework, too large disconnects between the general and IT
governance structures might give problems.
Successful Enterprise Architecture                                                       56

                                     Stage 1- EA foundation

           Processes                  Change management processes            Models

Needs analysis and a cost             Establish a sense of urgency       Schekkerman’s
                                                                         EA cost benefit
benefit analysis to establish
the need for an EA

Top management buy-in                 Develop a vision and strategy

                                      Empower employees for broad-
                                      based action

Establish common EA
definition and ensure
common understanding of
the EA programme

Establish current and desired                                            Glocalisation
high-level governance                                                    model

8.2.         Stage 2: EA approach
If an organisation decides to commence on an EA programme based on conclusions
from stage 1, the top management should set-up the project sponsor and an
executive body for the EA organisation. In this way, top management is involved in
the high-level decisions that need to be taken.

It must be ensured that the right competences and knowledge are included in the
EA organisation responsible for establishing the EA. I believe, that consultants
brought in at an early stage will have an incentive to ‘just get started’ along their
lines. Further, the capability of a given organisation to evaluate itself at this stage
is often limited due to lack of necessary skills. Therefore, it is preferred that the
organisation includes competent employees from ‘inside’ the organisation and not
only leaves the EA establishment to consultants. It is also important to involve role
Successful Enterprise Architecture                                                   57

model team leaders into the EA programme to inspire many other employees. This
will strengthen complex implementation and anchoring processes of the EA.

When the EA organisation has been established, they must select an EA framework
and EA methodology that will guide them through the EA implementation. Even if
no EA framework explicitly fits the organisation, there probably exist various
frameworks that can serve as inspiration for a more specific design. The
framework, among other things, assists the organisation in defining the EA scope.
This is needed in order to map the ‘as is’ and ‘to be’ states in the organisation,
assign necessary resources and not least to create a realistic timeframe for the next

                                     Stage 2 – EA approach

           Processes                    Change management processes          Models

EA organisation and EA                Create a guiding coalition
executive board
                                      Key employees


Ensure relevant                       Empower employees for broad-based
competences and knowledge             action

Select EA framework and EA                                                 EA
methodology                                                                framework

Define EA scope                                                            EA

8.3.         Stage 3: EA governance and management
To ensure and maintain compliance and vitality in the EA content, the organisation
must establish governance processes with which management and staff must
comply. To make sure the right decisions are taken by the right persons and to
ensure compliance, the organisation could use the IT governance decision structure
matrix augmented with a business process domain (or other domains dependent on
the organisation in question’s needs – their specific EA domains), as pointed out in
Successful Enterprise Architecture                                                     58

the theoretical section. This will help the organisation determine which groups etc.
are necessary to involve to implement the best decision structures and show who
are empowered to take which decisions in the various EA domains (roles and
levels). Further, such a model including both IT and business domains will provide
an overview of the decision structures in the organisation, which will give the
organisation an understanding of the necessary cooperation between the business
and IT domains. Thus, the model will assist the organisation in avoiding random
and complex decision-making in which business and IT are treated as completely
separate domains.

When the IT decision structures are in place, the organisation must establish the IT
principles based on their business and IT strategies. These IT principles will govern
the desired IT architectures. Based on these principles and the defined scope, the
current and future EA states are mapped and a transition plan is prepared that
establishes how the organisation intends to move from the ‘as is’ state to the ‘to be’

To ensure compliance and vitality in the EA content, the organisation must align
their general project model(s) with the EA content by integrating EA structures into
the general project templates. In this way, the project model helps to control that
any new project comply with the EA content and, further, informs the EA
organisation of new initiatives. In addition, maintenance routines and processes
must be aligned with EA structures. Maintenance, in general, is minor changes and
updates in relation to new technology or business opportunities that are not
covered by the project model.

The EA organisation must also secure ownership in relation to the content in the EA
framework (components and artifacts). Here, the organisation may use the RACI
model and/or the ITG extended matrix to cover all the roles performed by the right
people or groups. Further, to incorporate flexibility, the organisation must establish
escalation structures (exception possibilities). In case of disagreement, it should be
able to escalate the decision. If this is not possible, the danger could be that
departments do not apply EA at all, as they see it as too much of a constraint to
their business development possibilities.

To anchor the EA in the organisation and ensure vitality, the organisation should
establish user groups and committees. This will incorporate the staff’s ‘voice’ into
the EA programme, as their ideas and comments are to be considered by the EA
Successful Enterprise Architecture                                                   59

organisation, specifically in relation to important business and technological needs
and possibilities. This will further broaden the ownership of the entire programme.

Information and communication is important when implementing and anchoring the
EA programme in the organisation. In this respect, the organisation should map the
stakeholders to analyse the need for information flow throughout the organisation
and choose the right communication form to different parts of the organisation. It is
important not to underestimate this process, as without communication, no one will
understand the importance of the EA in the organisation. It is much easier to make
the staff comply with EA if they learn about it at an early stage and possible get
involved e.g. through a user group.

                      Stage 3 – EA governance and management

            Processes                    Change management                Models

Establish future IT decision                                          ITG matrix,
structures                                                            extended

Establish governing principles       Develop a vision and strategy

Establish the EA                                                      EA framework

      Map the organisation’s
      ‘as is’ state

      Map the organisation’s
      ‘to be’ state

      Prepare transition plan

Adjust general project               Anchor new approaches in the
model(s) to contain EA

Adjust maintenance to be in          Anchor new approaches in the
line with the EA content

Map process owners and               Empower employees for broad-     RACI and ITG
Successful Enterprise Architecture                                                 60

responsibility roles                 based action                     matrix,
                                     Key employees

Define escalation structures         Empower employees for broad-
                                     based action

User groups, committees              Empower employees for broad-
                                     based action

                                     Anchor new approaches in the

Map stakeholder and prepare          Communicate the change vision
communication plan
                                     Key employees

8.4.         Stage 4: EA maturity and measurement
To evaluate whether the organisation is on the right EA track, the organisation
should measure their EA maturity. This will clarify in which areas there is a need to
intensify focus and improve performance. Further, the organisation should define
measures that point to how well EA helps facilitate change and, from a more direct
economic angle, how EA has helped the organisation to improve its IT investment
decisions. The value added by EA should be communicated to the organisation to
show EA’s justification.

Even though stage 4 is the last stage, it is, of course, important that EA
performance measures are set up right from the beginning of the EA work, so that
the EA implementation and results continuously can be evaluated against the set
Successful Enterprise Architecture                                                  61

                        Stage 4 – EA maturity and measurement

           Processes                     Change management               Models

Evaluate EA maturity                                                 GAO and

Evaluate the EA results as           Generate short-term wins        OMB
regard facilitation of change,
                                     Consolidate gains and produce   Schekkerman’s
integration and business
                                     more changes                    EA cost benefit

Evaluate better IT                   Generate short-term wins        Schekkerman’s
Investments – economic                                               EA cost benefit
                                     Consolidate gains and produce
evaluation                                                           models.
                                     more changes
                                                                     Set shadow cost
                                                                     accounts for
                                                                     synergies in

8.5.         Conclusion
The four stages above will be used to structure and measure my case studies. In
this way, the guidelines have a dual function – first as guidelines for creating an EA,
but also as a framework for evaluating and measuring EA success. In a sense, this
makes my guidelines a maturity and measurement model of its own. I conclude
each stage in the case analyses by plotting the organisations’ performance in
relation to the various processes into the stage schemas defined in this section.
This will give a clear link between the guidelines and the case analyses.
Successful Enterprise Architecture                                                     62

I have set up scorecards using a simple ‘traffic light’ grading system in my
evaluation of the individual organisations. Traffic lights are widely applied across
organisations and regulators. As OMB, my grading for the different lights is defined
as green for success, yellow for mixed results, and red for unsatisfactory results.
When applying the scores to my two case studies, I take into account that they are
in the implementation process and, consequently, have not worked with EA in many
Successful Enterprise Architecture                                                    63

9. Case 1: SKAT
The focus in this case study is on SKAT’s IT, specifically how they plan to govern
their IT portfolio to support their business in the best way possible. Morten Hass,
Office Manager of the IT Architecture, Security, and Strategy department (ITASS)
in SKAT is my main contact person, and consequently, a majority of the information
gathered for this case study represents his point of view. I have, however, also
conducted an interview with a member of SKAT’s ‘Project Organisation’ (responsible
for SKAT’s project model) discussing the integration of SKAT’s new IT architectures
into this model. The ITASS department belongs to the ‘IT Services’ function, which
is a form of cross-organisational entity (administrative function) that has both
operational and strategic tasks. Below figure shows ‘IT Services’ organisational
positioning in SKAT (in Danish).

Figure 14 SKAT’s organisational set-up (in Danish)

Source: SKAT

9.1.         Introduction to SKAT
SKAT (which translates into ‘tax’) is part of the Danish Ministry of Taxation. Some
of their main responsibilities are tax assessments, collection of income tax,
business tax, labour market contribution, VAT, and customs duty in relation to
Danish citizens and organisations.

On 1 November 2005, the old ‘Told og Skat’ (now SKAT) was changed to a ‘one
entity administration’, which imply that the individual citizen or organisation, in
Successful Enterprise Architecture                                                     64

principle, can contact any of 30 newly established tax centres around the country
for assistance. This is a completely new way of thinking, as the individual is no
longer dependent on the previously local tax office nearby, but may freely use any
centre in Denmark. In addition, specialisation of some tax centres as high
competence centres responsible for knowledge-intensive functions are planned.
This will undoubtedly put high requirements on SKAT’s IT platform, which must be
able to deal with cross-centre data and knowledge sharing.

SKAT’s vision for 2006 is:

        To be an organisation based on services, openness, and digital solutions

        To be the most effective tax collection authority (‘opkrævningsmyndighed’)

        To guarantee process of law (‘retssikkerhed’) for the individual citizen and

        To be the best public workplace in Denmark

One of their main tasks relating to the vision is to create a fast-paced, simple, and
competent administration that will place as little strain on SKAT’s customers as
possible. Consequently, SKAT must focus on the citizens’ and organisations’
individual needs when they develop and implement service systems.

9.1.1.        The municipal reform from an IT perspective
Many of the individual municipalities’ systems are already operated and developed
centrally by SKAT. However, to meet the objective of being able to service each
citizen from any tax centre, SKAT needs to develop a citizens portal. The tax
centres must be able to access each other’s systems to be able to share data and
digital knowledge. This is a significant architectural challenge, as the entire tax
sector must have well-defined interfaces and develop one common public model.
This requires that the individual agency (tax centre) is aware of their existing IT
portfolios and this is often not the case as, according to Morten Hass “generally, the
organisations in Denmark do not know the content of their business IT systems.
The organisations do not know what information they actually work with” (interview
1, 2005, 0:26:11). Consequently, this is an area the tax centres will have to
improve during the coming years.
Successful Enterprise Architecture                                                    65

9.2.         IT modernisation (stage 1 – EA foundation)
SKAT has focused on IT for 30 years and they are used to viewing their systems as
technical installations. This approach will not work today where their systems are
considered more as strategic assets supporting the business, and the organisation
has thus worked on redefining their IT set-up for a number of years. SKAT aims to
be able to share development assignments, and maintenance and operation of the
products between many different suppliers by putting more defined tasks through
public tenders. This is not easy with the existing set-up as all systems are built as
one large system (80% of their IT portfolio is one large system). According to
Morten Hass, “it is very complex to work on this set-up as it is so comprehensive
that it can be difficult for any new supplier to get an overview” (interview 1, 2005,

In 2004, in a dialogue with the Danish Government and the Danish Ministry of
Finance concerning SKAT’s IT portfolio, they concluded that if SKAT was to
modernise their IT portfolio, SKAT ought to look at their business to identify the
areas where they could achieve advantages in closer aligning their IT platform with
their business goals. Consequently, in the 2004 budget, the Danish Ministry of
Finance allocated funds to SKAT to thoroughly modernise their system portfolio.
The objectives for this IT modernisation plan are:


                 To make a number of the central work processes more effective.

                 To provide the citizens and organisations with better digital services.

        IT Development and Operation

                 To make SKAT’s system portfolio more flexible to changes.

                 To create and maintain competition in relation to IT tenders.

In other words, the goal of the IT modernisation is to make IT-driven services
faster and cheaper, and make it easier to change SKAT’s system portfolio when
optimising and improving business processes. Ultimately, this will improve
customer servicing. According to Hass (interview 1, 2005), this also means that
SKAT no longer makes IT investments without preparing a business case explaining
the benefits. The modernisation is not a number of technical projects, but rather a
Successful Enterprise Architecture                                                     66

number of workflow projects that changes SKAT’s processes and thereby drive the
IT modernisation.

Thus, there clearly exists a need and urgency for modernising SKAT’s highly
complex IT systems to make their IT portfolio more business driven and,
consequently, improve their level of services to citizens and organisations. Based
on this, I believe that establishing an EA will make the IT and business alignment
easier to implement and maintain. I will elaborate on this in section 9.2.2.

9.2.1.        Top management buy-in
The IT modernisation is not a requirement from inside the organisation. Rather, it is
a requirement put on the organisation through demand for improved services and
citizen portability from top management (needs analysis by the politicians). This
means that SKAT by definition has top management buy-in at the initial stage. How
much time they subsequently will have to spend on keeping the buy-in from the top
management is unclear and as such probably depends on the perception of success.
As will be illustrated later in section 9.4.1., an executive board in SKAT is highly
involved in the modernisation process, but to what extend it represents the top
management in the SKAT organisation is rather unclear to me. I believe there
ought to be a process between the ITASS department and the top management in
SKAT that continuously shows the value-added the IT modernisation is generating.
If there are not any positive results, the ITASS department and SKAT’s top
management should consider whether they are approaching the modernisation in
the best way.

9.2.2.        EA needs analysis
“SKAT is not specifically interested in EA”, says Hass (interview 2, 2005, 0:01:40).
He comments that they are interested in creating an effective tax administration in
which the IT systems support the business.

SKAT is running a programme approved and financed by the government. The
objectives of the programme state that almost all processes are to be changed.
According to Hass (interview 2, 2005), if this is not tightly controlled it may go
terrible wrong, and, consequently, SKAT has three objectives:

    1. SKAT wants to make the organisation technologically effective and they try
        to achieve this by basing their infrastructure on SOA.

    2. SKAT wants to avoid IT catastrophes.
Successful Enterprise Architecture                                                     67

    3. SKAT wants to keep all other projects informed about the planned IT
        architecture and make sure that other projects fit into the overall picture.

Hass (interview 2, 2005) emphasises that these are the reasons why they had to
look at first how the organisation is actually working with business processes and IT
today, and how these areas are interrelated.

According to Hass (interview 1, 2005) based on the new architectures, SKAT’s goal
is to create an efficient tax administration meeting the objectives while cutting the
cost significantly. This means that the work processes must be created so they only
cost half of what they cost today. In this way, SKAT tries to extract synergies by
being lean in the way they operate their processes. More specifically, they try to do
this by creating a flexible and leveraged structure where IT processes are broken
into smaller pieces, simplified, and consolidated. According to Hass (interview 2,
2005), the ITASS department’s objective is not specifically to create an EA but
technically to facilitate the above.

Hass emphasises that their mission is to implement an IT modernisation that
includes particular defined objectives, and not specifically to create an EA.
However, I believe, that it would benefit SKAT to acknowledge that the EA discipline
would have and still will assist them in achieving and even defining their IT
modernisation objectives. The purpose of an EA is to create a holistic view of the
organisation that includes both technology and business and not least their
interrelationships to improve and sustain IT and business alignment now and in
future. Many EA methodologies identify processes that are necessary to create this
view and define how to govern and manage the processes in future. In my view,
this is exactly what SKAT wants to do. With such a complex problem at hand (the
IT modernisation), an organisation needs all the experience and assistance it can
get. Trying to invent working processes and governance disciplines twice is what
could lead to redundant and value-destroying focus. In my opinion, SKAT could be
at risk of not getting enough out of the experience EA has created for others even
though EA theory and EA practice, admittedly, do lack clear success stories and
‘recipes’ for achieving such. The fact that SKAT does not perceive themselves as
dealing with EA is a point that I extensively will point to throughout in the analysis.

9.2.3.        High-level governance structure
As a part of stage 1, it is interesting to map SKAT’s current and desired high-level
IT governance structures into the Glocalisation model to examine whether this
Successful Enterprise Architecture                                                 68

supports their general governance structure. As became apparent in the theoretical
part, similarities between the organisation’s general governance structure and their
IT governance structure is preferred. Large discrepancies should only be result of a
conscious choice. The Glocalisation model below shows the old and new high-level
IT governance structure that SKAT is heading towards.

Figure 15 SKAT’s old and new (desired) high-level IT governance


                                      Central          Federal



                                      Parental         Local

                                Low                              High

                                          Local Responsiveness

Source: Own contribution based on Gartner Group (2005)

Zangenberg (interview, Gartner Group, 2005) and Hass (interview 2, 2005) agree
that both the general governance models and IT governance models in SKAT are
heading towards being more central.

As the above model shows, the new set-up will allow for a strong governance of the
processes and restrict the organisation to a limited number of local variants of the
IT systems, not least due to the new established principle of ‘one tax
administration, one service level, and one phone number’ in which streamlining of
processes and systems are necessary. According to Hass (interview 1, 2005), many
of the IT systems have, however, always been driven from the Ministry of Taxation
because the management and process owners are placed here, and, consequently,
many of the systems are coordinated by the ministry. According to Hass (interview
2, 2005), there is, however, much more centralisation in relation to the new
principles that SKAT’s IT portfolio must comply with (will be elaborated on later in
section 9.6.2.), and in addition comes the central principle that the new
architecture must be driven by the business. Furthermore, the new corporate
Successful Enterprise Architecture                                                   69

functions (e.g. the ITASS department), which are set up to streamline processes
and achieve synergies organisation-wide, is a sign of a more central governance.

Previously, each business in SKAT worked in a silo set-up in which the departments
found their own system vendors and build their framework on an ad hoc basis. With
IT being more complex, with more focus on costs, with increased efficiency
demands, and with increased service requirements, SKAT had to change this
approach. The society’s requirements to public agencies have changed, and the
decentralised approach cannot deliver the required solution. “For example, it is
impossible to harmonise the entire collection of money cross-organisational if they
[each business department] have their own [system] models,” says Hass (interview
2, 2005, 0:43:55).

It is worth reiterating that when heading towards a more central model, an
organisation loses local flexibility. As mentioned in the theoretical part, choosing a
central governance structure means that local responsiveness is downgraded at the
expense of a more centralised integration. This, for example, implies that
implementing business development from the local competence agencies where the
business knowledge exists can be tricky. Which governance model to select
depends on the individual organisation’s vision and needs. However, with the
current set-up, SKAT views it as impossible to deliver savings and service
improvements if there is no control from a central level. In my view, this is exactly
the reason why an EA would help SKAT, that is, assist them in creating, governing
and managing this central structure.

9.3.         Stage 1 evaluation
Below, I evaluate SKAT in stage 1 based on my guidelines.

                           Stage 1 Scorecard: EA foundation

         Processes                          SKAT’s performance            Score

Needs analysis and a                 SKAT is very aware that they need    Yellow
cost benefit analysis to             to modernise their IT to achieve
establish the need for               both their business and IT
an EA                                objectives. However, they are not
                                     commencing on an EA programme
(CM: Establish a sense of
                                     even though such a programme
Successful Enterprise Architecture                                                     70

urgency)                             would assist them in the process.

(Model: Schekkerman’s EA             They have defined urgency in
cost benefit models)                 relation to investigating how the
                                     organisation is put together in terms
                                     of processes and IT, and how these
                                     areas are interrelated.
                                     Unfortunately, it seems that they
                                     are not aware of how an EA would
                                     provide them with such an overview
                                     including processes in relation to
                                     govern and manage ‘their EA’ now
                                     and in future.

Top management buy-                  The IT modernisation is defined and      Green
in                                   funded in the annual budget by the
                                     Danish Ministry of Finance in 2004.
(CM: Develop a vision and
                                     Further, SKAT has an executive
                                     board that is highly involved in the
                                     IT modernisation (see section
(CM: Empower employees
                                     9.4.1). This clearly shows top
for broad-based action)
                                     management buy-in.

                                     It is, however, unclear how dynamic
                                     the management buy-in is and how
                                     the information flows back to the

Establish common EA                  SKAT has not defined a common EA         Red
definition and ensure                definition, as they are not
common understanding                 specifically interested in creating an
of the EA programme                  EA. Since they seem to be doing
                                     exactly that anyway, they risk losing
                                     the experience from other

Establish current and                I have analysed SKAT’s old and new       Yellow
desired high-level                   (desired) high-level IT structures
Successful Enterprise Architecture                                                   71

governance structures                using the Glocalisation model. The
                                     result shows that they are heading
(Model: Glocalisation
                                     to be more central. This is
                                     consistent with SKAT’s general
                                     governance model, which is also
                                     heading towards more centralism.

                                     EA is a programme that would have
                                     assisted SKAT in reaching and
                                     governing this more central
                                     structure as it provides them with
                                     means to establish more IT central
                                     governance and following ensure
                                     compliance and vitality.

9.4.         EA approach – (stage 2)
Even though SKAT is not directly establishing an EA, many of their initiatives are
very similar to those involved in an EA, as will be analysed below.

9.4.1.        EA organisation and executive board
SKAT has established the ITASS department who is in charge of the IT
modernisation work technologically. Further, SKAT has a special executive board
forum, which is involved in the modernisation work. This board, Hass (interview 1
and 2, 2005) comments, is used to work with IT projects and this is an advantage,
as they understand how IT can support the business, and they also know how
complex IT projects can be and how easy it may go wrong if not governed tightly.
This understanding is contrary to other Danish agencies that must struggle to
receive attention from top management in relation to IT matters.

Thus, “three important factors exist that make it all [the system modernisation in
SKAT] possible”, says Hass (interview 1, 2005, 0:18:00):

         The fact that the executive board is used to IT projects.

         The savings requirements generally for the Tax Administration.
Successful Enterprise Architecture                                                    72

        The Government’s decision that SKAT is to govern their IT according to an
        architecture that is based on SKAT’s business.

These are excellent conditions and definitely important drivers in realising the
modernisation goals. Further, the above shows that SKAT has established a team in
charge of establishing the IT modernisation, and that they have an executive board
that is highly involved in the work – who exactly is represented in this board is
unclear to me. This department and board are, of course, not referred to as an EA
organisation or an EA executive board as SKAT does not want to specifically
conduct an EA.

9.4.2.        Competences
According to Hass (interview 1, 2005), there are three specific competences that
individuals must have to work at the ITASS department:

        Communication and sales skills.

        An understanding of the business and business modelling.

        High understanding of platforms and development experience.

Hass (interview 2, 2005) states that it is a challenge to find people that meet all
three requirements as these people are in demand. However, these people are
necessary and SKAT has a few of them, and they inspire and pull the others in the
right direction. Hass (interview 1, 2005) explains, however, that one of the most
significant challenges has actually been the lack of competences. He finds it difficult
to find staff that master both the business and the technology aspects and who
understands the inter-relationships. He comments that there exists “a big gap
between the desire to make the IT architecture business driven and the business’s
own modelling capacity” (interview 1, 2005, 0:52:07). In relation to the large
projects SKAT has started up, “it has gone incredible well, but there are still 200
employees left in the organisation that are unable to model the business,” says
Hass (interview 1, 2005, 0:52:18). With the new set-up, SKAT cannot leave it to
the suppliers to decide the business processes, and it would thus be much easier if
the business could easily model their business processes themselves.

According to Hass (interview 2, 2005), the overall vision is not so complicated.
SKAT aims at having a technical layer that mirrors how the business works. To
succeed, SKAT needs key people that know how to model the business and at the
Successful Enterprise Architecture                                                                           73

same time knows enough about large-scale technical development that they can
advice the organisation on the best and most effective solutions. SKAT’s modelling
tool is ‘System Architect’, which best builds the road from processes down to the
information level. There is no coherence between the business modelling tools and
the tools that support solutions development. “Nobody has built that bridge yet,”
says Hass (interview 1, 2005, 0:54:29).

Creating new architectures is a long and complicated process, which Hass is very
well aware of. He acknowledges that it is very hard to find the staff that possesses
the right knowledge and competences, which probably makes the process even
more complex. Thus SKAT dares to acknowledge both their strength and
weaknesses, which enable them to put more focus on areas where it is needed.

9.4.3.          EA framework and EA methodology
Even though SKAT is not commencing on an EA, they did investigate whether an EA
framework would assist them in mapping their organisation. “We were surprised to
find out how few methodologies there existed in this area. It was a chock to
discover that no one could tell us how we should do this [create a map of the
organisation showing the business and IT and their interrelationships],” says Hass
(interview 1, 2005, 0:48:40). They found, for example, “that Zachman only
consists of some boxes and no methodologies that explain how to do it [map the
current and future states of their business and technological processes and their
interrelationships]” (0:49:10). Further, Hass (interview 1, 2005) comments that
Zachman as such cannot do anything for SKAT or say anything about their map as
it is SKAT’s processes. Also, ‘Hvidbogen’ [the Ministry of Science, Technology, and
Innovation’s White Paper] is a general model for how a system is created and does
not assist an organisation in establishing an EA,” comments Hass, (interview 1,
2005, 0:49:25). As a result, SKAT concluded that it would not provide them with
any productivity using an EA framework.

Consultants from Devoteam and Deloitte17 assisted them at the strategy level.
According to Hass (interview 1, 2005) neither of these two was able to point at an

     Devoteam Group is a consultancy and engineering company in information technologies in Europe,
specialising in information system infrastructures.

Deloitte is a global organisation that offers services in auditing, tax, consulting and corporate finance.
Successful Enterprise Architecture                                                    74

EA methodology that explained how SKAT should approach the mapping of their
organisation either. Consequently, SKAT worked out themselves how to map their
organisation. The basis for this has been their strategy. They found that the
challenge is not how to change COBOL code to web services, nor to gather data
about the various IT processes. The challenge has been to find out how to create an
overview of SKAT’s business and technology and their interrelationships. In
addition, SKAT found that it was a complex task to define how the business and
technology should be interrelated in the future in order to achieve maximum
benefit. Hass (interview 1, 2005) states that “it is impossible to govern after
something that is complex. Governance must happen based on something that is
immense simple otherwise there is no strategy and thus no conscious exclusion”
(0:56:20). He comments that the danger in EA models lies with their overly
complex nature. “It is about finding out how the business is to be broken down into
pieces and how this is supported optimally by technology” (Hass, interview 1, 2005,

I agree that EA frameworks can seem very complex, but complex problems do not
just become simple that easy. Structuring architectures into locally simpler pieces
or shelves is exactly EA. Thus, I believe that EA frameworks and EA methodologies
can be very useful when organisations aim to define their business and IT including
their interrelationships. Naturally, an organisation should not use a framework if it
does not bring any value to the organisation. However, the danger in not using a
recognised framework or EA methodology when mapping an organisation’s business
and technology is that SKAT might miss important aspects or they are actually
reinventing the wheel, which is a waste of valuable resources and time. I believe
that, for example, Bernard’s EA Cube and methodology could have assisted SKAT -
or at least served as inspiration. This framework and methodology actually helps an
organisation break their organisation down into five functional areas including
showing their interrelationships. Also, it is important to understand that an EA
framework is only part of an EA programme that also consists of various processes
that assist the organisation in defining their ‘as is’ and ‘to be’ states, how to reach
their desired state and ensure future compliance and vitality. Of course, Hass might
very well have found the exact EA approaches presented by the consultants too
weak. This brings back my earlier point about consultants trying to fit client
organisations into the ‘specific consultancy house EA framework’ instead of fitting
the EA approach to the client. By doing this instead, I believe other approaches to
EA would assist SKAT in modernising their IT. This would have inspired them to
Successful Enterprise Architecture                                                     75

which processes are necessary to map their business and IT processes and their
interrelationships and to establish and ensure continuity in their IT portfolio that are
to be business driven now and in future.

9.5.         Stage 2 evaluation
Below, I evaluate SKAT in stage 2 based on my guidelines.

                            Stage 2 Scorecard: EA approach

        Processes                         SKAT’s performance                  Score

EA organisation and              As SKAT is not deliberately working on       Yellow
EA executive board               an EA, they have not specifically
                                 established EA roles. However, SKAT
(CM: Create a guiding
                                 has established the ITASS department
                                 to streamline processes to achieve
                                 process synergies throughout the
(CM: Key employees)
                                 organisation technologically based on
(CM: Leadership)                 their business strategy. Further, SKAT
                                 has an executive board that is very
                                 much involved in the IT modernisation

                                 In relation to the IT-modernisation, the
                                 responsibility of this department and
                                 an executive board will be elaborated
                                 in section 9.6.1.

Ensure relevant                  Morten Hass is aware of the ITASS            Yellow
Competences and                  department’s needs as regards
knowledge                        competences and knowledge. It is,
                                 however, very difficult to find staff that
(CM: Empower
                                 possess all their requirements at a
employees for broad-
                                 necessary level.
based action)
                                 This can actually be an annoying and
                                 significant obstacle in achieving SKAT’s
                                 objectives in time, because without the
Successful Enterprise Architecture                                                    76

                                 right competence and knowledge, it is
                                 very difficult to complete such a
                                 complex process as SKAT’s IT
                                 modernisation is.

Select EA framework              SKAT believes that the existing EA           Red
and EA methodology               frameworks are too complex and
                                 unsuitable for their needs. Further,
(Model: EA framework)
                                 they seem to define an EA as only
                                 assisting of an EA framework.

                                 Thus, they have not specifically
                                 selected an EA framework or EA
                                 methodology. Based on this, I believe
                                 that SKAT’s IT modernising process
                                 becomes more complex than it has to
                                 be. I find it curious that consulting
                                 firms have not been able to come up
                                 with satisfactory EA initiatives. Of
                                 course, it is a very complex process
                                 but using e.g. Bernard’s EA Cube and
                                 EA methodology as inspiration and
                                 assistance would have given them an
                                 overview of the necessary processes in
                                 relation to how to map their ‘as is’ and
                                 ‘to be’ states and controlling this in

                                 In my opinion, this would have saved
                                 SKAT from reinventing the wheel and
                                 making more ad hoc decisions.

Define EA scope                  The scope of the IT modernisation is         Green
                                 defined in the annual budget. Even
(Model: EA framework)
                                 though this is not specifically related to
                                 EA, they seem to have a precise defi-
                                 nition of the IT modernisation scope.
Successful Enterprise Architecture                                                77

9.6.      EA/(IT) governance and management - ensure
       compliance and vitality (stage 3)
According to Hass (interview 2, 2005), ITG is very important to SKAT. They have
spent a large amount of money on analysing how to create their project model and
how to establish the governing functions, one of them being the ITASS department.
These functions and the project model should govern cross-organisational
assignments. Further, in the executive board representing the IT modernisation 80
per cent of the executive management is used to discuss large IT projects and large
IT governing issues. This is a clear sign of the importance of ITG in SKAT.

9.6.1.        IT decision structures
According to Hass, (interview 1, 2005), the ITASS department is responsible for the
IT architecture work, and the executive board responsible for the IT modernisation
is involved in high-level IT decision-making.

Based on this, I find it interesting to map SKAT’s new (desired) IT decision
structures in the extended ITG matrix. This is not meant as an in-depth analysis of
SKAT’s decision structures, but merely as an illustration of the more central
governance structures that SKAT wants to operate in the various domains.
Successful Enterprise Architecture                                                                          78

Figure: 16 A simplification of SKAT’s new (desired) more central IT
decision structures


                 IT               IT              IT               Business         IT              Business
                 Principles       Architecture    Infrastructure   Application      Investment      Processes
                                                  Strategies       Needs

                 Input    Deci-   Input   Deci-   Input    Deci-   Input    Deci-   Input   Deci-   Input   Deci-
                          sion            sion             sion             sion            sion            sion

     Business             EB


     IT          ITASS            ITASS           ITASS                             ITASS

     Federal                              EB               EB               EB              EB      PO          BEB

                                          ITASS            ITASS            ITASS           ITASS   *            *

     Duopoly                                                       PO



Source: Based on MIT as cited in Ross & Weill, 2004 including own contribution

Executive board: EB (the board mentioned above)

BEB: Business executive board

Process owners: PO

*: Other unknown

Here, I consider the executive board as a business monarchy constituting business
executives (may include CIO). I refer to the ITASS department as an IT Monarchy
constituting IT professionals and an IT executive (Morten Hass), (Ross and Weill,
2004). The executive board makes the high-level decisions in relation to ‘IT
principles’ based on input from the ITASS department. Further, the executive board
is involved in high-level decisions in relation to all other domains except for the
‘business processes’ domain. The ITASS department also makes decision in relation
to the ‘IT architecture’, ‘IT strategies’, ‘business application needs’ and ‘IT
investments domains’. In addition, they provide input in the ‘IT architecture’, ‘IT
infrastructure’, ‘IT investments domains’ and ‘business application needs’ - that is
when they are not empowered to take the decisions themselves. The process
Successful Enterprise Architecture                                                  79

owners also provide input in the domain ‘business application needs’. As written in
the theoretical part of this thesis, I believe that the above model should be
extended with a ‘Business Process’ domain. This domain origins from the business
strategy, and I claim that extending the model with such a domain illustrates the IT
and business alignment, which is the core of SKAT’s IT modernisation. In relation to
SKAT, a business executive board and probably some other business groups will
make the decisions regarding this business domain based on input from different
business units, process owners and management.

The analysis above emphasises the earlier mentioned more central governance
structure in SKAT. The ITASS department and the executive board play very central
roles in all IT-related decisions that are no longer delegated to the individual
departments. It demonstrates the ITASS department’s highly central role in
defining the new IT architectures based on the business needs. Thus, it is very
important that the ITASS department documents their plans - otherwise the
success of the IT modernisation would depend too much on one department –
ITASS, or one person – Morten Hass. Again, the EA discipline could help with this
documentation, which would also be a structured way to communicate the new
architectures to the organisation showing the business and IT alignment.

9.6.2.        IT principles
To be able to create a drawing of SKAT’s business and IT processes, ITASS read all
SKAT’s business strategies and came up with five statements representing the
overall vision for the IT modernisation. These statements reflect SKAT’s goals in
prioritised order, and have been approved by the executive board as being the five
principles that govern the IT modernisation:

    1. Adaptability

    2. Effective processes

    3. Simplicity when dealing with the citizens and organisations

    4. Overview of the individual customers

    5. Market prices on the IT systems

Thus, these five statements (principles) will form the basis governing SKAT’s
architectures. “The essence of architecture is about saving money and therefore
Successful Enterprise Architecture                                                                                                                                                                                                                                                                                                                                                        80

avoid making things that are ineffective, for example developing the same
functionality twice, invest in a platform that will be very expensive to operate in the
long run, and to avoid continuous development of systems that are being closed
down soon because of obsolescence,” says Hass (interview 1, 2005, 0:15:30).
Thus, in defining SKAT’s ‘to be’ state, ITASS has looked at the ‘as is’ map plotting
both business and IT to evaluate how to make the relationship between the two
areas less complex and more effective in accordance with the five statements.

9.6.3.                     Establish the EA framework content
Creating an overview of their business, SKAT drew a map that shows both the
business and its functionality. Having done this they broke their extensive system
into smaller pieces again and mapped them into the drawing, as well. “This is EA,”
says Hass “drawing a map of the organisation that makes it possible to see how an
organisation is structured in overall terms” (interview 2, 2005, 0:05:05).

Figure 17 SKAT’s map of their organisation (in Danish) (for full size see
appendix F)

    Version d. 27 maj 2005. SAS-kontoret - IT-services
                                                                                                                                                                                                     Offentlige processer
                                                                       Portaler                          Registrering                                                           Produkter                                                          Fordeling                                          Afregning.                                                      Sikkerhed
                                                                    - Virk.DK
                                                                                                   - Virk. reg.                                                                                                                                                                                                                                                       - Politi
      Kundeprocesser         Serviceudbyder                         - Kommunale                                                                                                                                                                                                       - Statens
                                                                                                   - Person reg.                                                                                                                                                                                                                                                      - Beredskab
                                                                    kvikskranker                                                                                                                                                          - Kontanthjælp                              KoncernBetalinger
        Virk. etablering            Revisor                         - SU-styrelsen                 - Tinglysning                                               - Produktstøtte                                                            - Dagpenge                                  - NemKonto
                                                                    - Netbanker                    - Byggesag                                                  - Produktilladelse                                                         - Boligstøtte
                                                                                                   - Motorregistrering                                         - Produktkvoter                                                            - Friplads

         Virk. økonomi                Bank
         Økonomisystem                                                                                                                                                                                       Skatteprocesser
                                                                  Kundekontakt                           Registrering                                                            Angivelse                                                          Opgørelse                                           Afregning                                            NP 4 Kontrol med illegal
        Virk. medarbej.           Lønservice                      TastSelv Erhverv                                             ES
            Lønsystem                                                                                                                                                                                                                                                                                                                                        GPP    PC-SURVEIL              AFIS
                                                                  Nyt TastSelv                                                 SE
                                                                                                                                                                                               DR                                                                                                                DR
                                                                                                                                                                                                                                                                                                                                                                    Transit (NCTS)          SCENT/CIS
                                                                  LetLøn                                              Ny Registrering
                                                                                                                                                                     Spil.dk                                                                                                               LetLøn        PC-           Ny Debitor
         Virk. produkt              Importør                               TStele                                                                                                     Intrastat                                                                                            SAP38

                                                                       Ny Portal
                                                                                                                                                              Import          e-Export      Nyt Liste         Nyt YM-
                                                                                                                                                           E-handel            Eksport     YM-syst        Liste
                                                                     Din Skattes
          Virk. logistik            Speditør                                                                   Slutmandtal

                                                                                                                                                              PAF              PAL       EIS          EROS

                                                                  TastSelv Borger KMD                                        CSR-P                                                                                                  Forskud                   ABS
                                                                                                                                                                                                                                                                                      TURS        KOBRA         KR-L       BYS            OLVER

                                                                  TastSelv Borger                                                                                      COR               MIA                         SA              SP       Uddata                         EVS
             Flytning         Ejendomsmægler
                                                                                                                                                                       RKO: AKFA           AKSA ANPA BHO CPS                                  Gammel SLUT 1988 - 1991
                                                                       Gennemstilling 3 I                                                                                                   GI        L
                                                                                                                                                                                FINK            KTR  IFPA IRTE

                                                                                                                                                                                                                                                Gammel SLUT 1992 - ?
                                                                       Gennemstilling 3 II
                                                                                                                                                                        SVUR           SVUR IGS                    VUR
                                                                                                                                                                                                                                                                               SLUT          (kontrol, beregning,
           Transport             Bilforhandler                                                                                                                               Ny Ejendomsvurdering
                                                                                                                                                                                                                                                                                         KMD Debit
                                                                                                                                                                    StaPri            Modep         Motor                                                                                                                                                                  Arbejdsmiljø
                                 Trafikselskab                                                                                                                                                                                      MT-fil          VSO/VBO
                                                                   Et nummer                                   Nyt Motorsystem
                                                                                                                                                                                                                                                                                         CKR-K        Fordelingssys
        Person familier             Advokat                                                                                  CKR-A

                                                                                                                                                                                     Kontrol                                                                                          KMD Debit         Inddrivelse
                                                                                                                                                                                                                                                                                                                                                             Skatteanke-             Landskatte-
                                                                                             Træskoregistret                                  KINFO            DIPSY            Kvalipro            VK                      SLS-E            RAP        LS/SLS-S                                  RUF            Bøde         Ny Inddrivelse                 nævn                    retten
           Person job                                                                                                                                                                                                                                                                                         beregning
                                                                  Skattecenter                     LUP                  ELO
                                                                                                                                                  Nye udsøgninger                                                         HARPUN             SEES           SLS-P                        DFLS           CFR         FAS/RES         FAS/STU
                                   A-kasse                                                                                                                                                                                                                                                                                                                           Økonomistyring
                                                                                                                                                                                                             Sagsbehandling                                                                                                                                          Personale
                                                                                                                                                                                                                                                                    RegAfg                        Bevillinger
                                      Bank                                                                                                                                                                                                                                                                                                                           IT
       Person økonomi                                                                                    Captia -              Remedy               Scanjou         KOM*IT              KMD                                                                                                                                                                          Rigsrevisionen

                                                         SP 1: Økonomistyring                      SP 2: Personale                                                                    SP 3: IT                                               SP 4: Intern                             SP 5:                               SP 6: Interne                                    SP 7:
                                                                                                                                                              Fælles         Ny ENS         BRAS            INKO          FROC
                                                                                             MUS       UAS        LUKAS        TiRe/LISY
                                                                                                                                                              server                                                                           Revision                        Ministerbetjening                            aktiviteter                            Ledelsesinformation
                                                                                                                                                          Telefoni             DAP             BR        Intermedi        PRINT                                                                                                                                     TiRe/LISY
                                                           SAP9                              PAI         SAPHR          REKS            Idébank                                                                                                     Elrev
                                                                                                                                                                                                                                                                                                                              Bibliotek           Registre
                                                                                                                                                                  Dist.               Std. klient        Driftplan        Nyt DW
                                                                                                                                                              servermiljø               prog.

     Omlægning af grænseflader                   Større funktionelændring                           Lukkes eller                                                                     Ændres ikke                                                                    Nyudvikling                                                           Ikke vurderet
     mv.<= 25%                                   25-75%                                             reimplementeres

Source: SKAT PowerPoint show

The drawing shows the business processes and the systems. The colours illustrate
which systems that must be changed, closed down, stay as they are etc. Clearly,
Successful Enterprise Architecture                                                      81

there are many systems that must be changed in some way. To realise this, SKAT
is working according to a strategy called ‘Connect Strategy’. This strategy divides
the IT modernisation into several phases in which, for example, phase one is
dealing with establishing SKAT’s basic IT infrastructure called ‘ENS’ (Enterprise
Nervous System). The aim with SKAT’s new established ‘ENS’ is to enable the
system portfolio to easier handle future business changes. SKAT’s objective is thus
to make their IT portfolio more agile.

The main idea is to keep the existing functionality if usable in the new set-up. “Only
in the areas where there will be completely new ways of doing things, we will close
the old systems and build completely new,” comments Hass (interview 1, 2005,
0:08:16). SKAT will no longer have one large complex system. Rather they will split
out their IT portfolio into minor areas to establish flexibility. The key is to reuse
services. To achieve this requires that SKAT knows their own system portfolio well
and is able to work with it to make the required changes. Hass (interview 1, 2005)
believes that an organisation should only create an architecture if the need exists.
At SKAT, they had to do it. They needed an overview of the systems in relation to
the business to analyse how they can break their extensive systems into smaller
pieces in a way that support the business in the best possible way.

The analysis above shows that SKAT has, in fact, managed to create a map of their
current and future business and technological processes. They claim, however, that
they are not deliberate working on an EA, even though drawing a map of the
organisation is EA, according to Hass (interview 1, 2005). This clearly shows that
SKAT is working in an EA direction, but, as previously mentioned, it also indicates
some confusion by SKAT, as they interpret EA as just being a map or framework.
An EA framework is obviously only part of an EA programme, and I believe that a
broad understanding of what EA is would have given the ITASS department more
tools to work with, other than the map. Again, realising that an EA would actually
assist SKAT in establishing, implementing and anchoring the IT modernisation
changes would thus probably give some more help to the entire process.

9.6.4.        Project model
“Without an incredible strong project organisation, it is impossible to govern
architecture,” says Hass (interview 1, 2005, 0:29:05). Hass (interview 1, 2005)
points out that every project and every change in SKAT must pass the new project
model structure. This is only possible with a strong project model and commitment
to police it. The changes have already been implemented for the large IT-related
Successful Enterprise Architecture                                                      82

projects that include invitations to submit to a public tender. The plan now is to
extend the model to also include the many larger or smaller IT-related projects and
changes in relation to legislation, probably by this year. It is incredibly important
governing all projects and their changes in line with the new IT structure,
otherwise, the directions laid out in the new architectures will not be followed. Hass
(interview 1, 2005) points out that many of the IT changes SKAT has carried out on
the existing (old) IT system has been ordered ad hoc, and, subsequently, the
suppliers have made a project. This will change drastically as SKAT will now
themselves control the system changes.

At the moment, the projects (often of a legislative nature) that are not covered by
the project model must, in principle, be approved by the ITASS department to
make sure they follow the new architectures. This has been communicated to the
organisation. “Any solution has some interfaces, some processes, some functions
and some information,” says Hass (interview 1, 2005, 0:31:18). Consequently,
according to Hass (interview 1, 2005), the ITASS department would indeed like the
employees to follow the architectures defined for these areas. Thus, if someone
wants to change the old systems, the ITASS department asks them also to prepare
the change for the new integrations platform – given that ITASS, of course, hear
about the changes in the first place.

This, however, is clearly not a strict enough structure in the long run. It is
imperative that the project model is extended to comprise all projects to secure
compliance. Especially when dealing with an extensive system as SKAT’s and with
little room for errors, strict structure is necessary. Further, the executive board
expects the ITASS department to have control of the IT portfolio and to keep an
overview of all the systems and their interrelationships. This again requires strict
structure and governance. However, according to Hass (interview 2, 2005),
integrating the legislative projects will not be difficult as much of the work already
exist. “The difficulty exists in making the business people competent in being able
to express their needs in this specific way [business modelling] this they are not
used to,” Hass (interview, 2005, 0:22:24).

The above analysis shows, that SKAT has a very strong project model that is the
central element in implementing and establishing changes. The project organisation
and the ITASS department are working on integrating compliance and vitality into
the project model with respect to ensuring alignment to the new architectures. This
Successful Enterprise Architecture                                                      83

is a long process as regards all projects and maintenance, but the ITASS is aware
of the necessity in incorporating all changes into the model to secure compliance.

The model is also a tool that will ensure new initiatives in a bottom-up structure.
According to Larsen from SKAT’s project organisation (interview, 2005), they intend
to implement the project model in the various tax centres in a light version to allow
for new ideas to prosper bottom-up in an otherwise very central top-down
structure. This again indicates this models’ very central role in a governance

9.6.5.        Maintenance of the architecture
Updating SKAT’s architecture in relation to the general technological trends is
second to SKAT. Hass (interview 2, 2005) emphasises that it is the business
initiatives that control the development. The way they work is that in connection
with a new project, the ITASS department ask the project group to create services
in a way that allows them also be used in other projects. The ITASS department
tries mapping the components of any new large project and its technical
specifications. Then they investigate if there are other possible projects that might
find the same components useful. They establish a workshop and define the non-
negotiable requirements. Hass (interview 2, 2005) says that they never commence
on a project due to new technology, however, they cannot exclude the possibility
that it might happen if a new technology yields new important business
opportunities. Thus, it seems the architecture is up-dated in line with the business
but not so much in line with technological development.

According to Hass (interview 2, 2005), departments in SKAT can affect the system
architecture by small ‘think tanks’ that exist in SKAT. When a ‘think tank’ has come
up with a business idea, they prepare a proposal that will be reviewed through the
project model. Likewise if a law is passed which might generate system changes
this should also be embraced in the project model. The business organisation in
SKAT also has a development department. This department and the ITASS
department are in close contact. The contact is established even prior to the project
phase already in the ‘idea phase’. However, “in relation to our prioritisation of the
office’s resources, it is much more urgent to deliver those components that are
actually to be bought – we have enough projects,” says Hass (interview 2, 2005,
Successful Enterprise Architecture                                                    84

The discussion clearly shows that the business is the driver for any change in SKAT.
Further, it seems clear that Hass believes that all changes will be caught in the
project model, at least on a longer term when the legislative part has been
integrated. However, it might be wise to consider alternative maintenance
structures than only the project model. In relation to legislative changes that
require fast implementation, for example, it might be too cumbersome to go
through the project model.

9.6.6.        Process owners
SKAT has defined ownership at the process level (activity owners). However, the
processes are often person dependent which is rather negative and, consequently,
SKAT aims to change this when formalising it more. They are not an organisation in
which the systems belong to the IT department (except, mail, Word, Excel etc.)
because much of their information and processes are digitalised, and, thus, system
ownership is defined and incorporated into the business already. Further, Hass
(interview 2, 2005) says that if a change requires communication, this is also
integrated into the project model.

The technical process owners seem to be positive towards the changes, the IT
modernisation requires. Hass (interview 2, 2005) says that the technical process
owners do understand that they need to describe their processes if the business
processes are to be more flexible even though they are not used to it. They are
used to speak about codes and fields but need now to understand the business
aspect. “New ideas are only realised if there exist advantages for those that are to
use them and those that must finance the ideas,” says Hass (interview 2, 2005,
0:53:38). In connection to architecture, he comments that the technical process
owners are getting more control of their systems at the costs of having to model
and be responsible for their systems and processes which is no longer the suppliers.

However, a dilemma is that quite a few of SKAT’s technical process owners are
soon to retire and SKAT has almost a freeze on hiring. Thus, one of their main
challenges is how they retract knowledge from those that understand the new
architecture before they retire and clarify who will be able to drive the modern IT
structure in future.

It seems that there are many good intentions and much work has already been
done. However, SKAT needs to specifically state ownership and responsibilities at
the desired level for all processes, the ITASS department appears to be responsible
Successful Enterprise Architecture                                                     85

for defining ownership for only the IT processes. It seems that SKAT is aware of the
various governance structures as regards owner, input and communication
processes. This is, however, not the ITASS department’s responsibility but the
project organisation’s responsibility as this is build into the project model. This is a
sign of the ITASS department not being responsible for creating an entire EA
programme including all its processes and structures, but being in charge of
establishing an IT architecture that comply with the five statements mentioned
earlier. This unclear structure could be a result of not having directly focussed on
EA. I believe that, at least, the ITASS department must establish the necessary
structures to ensure compliance and vitality in respect of this new IT architecture.
This makes it necessary for ITASS to have a very close cooperation with the project
organisations as many of the necessary governance structures are built into this
model. It is therefore vital that the ITASS department influence the development of
the general project model, which they also seem to be doing.

9.6.7.        Escalation structure
According to Hass (interview 2, 2005), the involvement of the top management is
as previous mentioned not a problem for SKAT at all. Consequently, an escalation
structure is built into their project model, which means that in any architecture
disputes, the project models escalation structure will become effective.

9.6.8.        Communication
The ITASS department holds lectures explaining the purpose of the new
architectures. Further, they hold courses, for example, in business modelling. The
courses are not compulsory but when needed by the staff, they automatically
attend. For example, whenever there are new, large-scale projects that involve
many people, the ITASS department establishes a course specifically for this target
group because it is relevant. Hass (interview 2, 2005) says that these attendees
will talk about it to their colleagues and, consequently, more staff sees that they
can also use some of the established IT components and services.

This is a good way to communicate about the architecture in the organisation as it
will have a positive ripple effect in the organisation and create role models. Further,
it shows that the ITASS department is very aware of the necessity and importance
of communication in implementing and anchoring the changes in the organisation.
However, it is an open question whether this form of communication reach a broad
enough audience in the organisation. Often, different types of communications are
preferred by different individuals. Additional information templates through staff
Successful Enterprise Architecture                                                       86

letters or an intranet news portal could be a relevant supplement – even though,
this might already exist to some extend on their intranet, otherwise, this media
would be obvious to exploit in this respect.        Stakeholders
Establishing and implementing the changes in SKAT only happens when the staff
discovers their advantages and that they have a stake in accepting and
participating in the changes. According to Hass (interview 2, 2005), some of the
employees see the advantages immediately whereas others do not think it works.

According to Hass (interview 1, 2005), it is critical that a staff function solves the
problem the business has in order to survive and hence they must position
themselves in relation to the business needs. Hass (interview 2, 2005) says that in
the case of the ITASS department, they must focus all their strengths on convincing
the business of IT’s advantages and show results. They know in which offices they
have buy-in because they have helped them and created value. However, there are
also a couple of projects in which they have small issues. Hass says, “we know our
stakeholders and this is very important to us as our department is nothing in itself
but only exists due to our assistance and problem solving for other offices”
(interview 2, 2005, 01:22:20). Thus, the top management’s understanding of what
SKAT may accomplish if they establish an architecture is conclusive, and the right
sponsors are critical.

According to Hass (interview 2, 2005), they do not have an EA champion in SKAT.
He comments that champions of areas that are of no need makes no sense and
therefore champions must be working on the issues that are important to SKAT.
Hass (interview 2, 2005) emphasises that the trick is to assist in the areas that are
of importance to the organisation and the decision makers. In this connection it is
also important to communicate and position oneself in relation to the decisions that
are to be made. The ITASS department spent much time on marketing themselves
and try to demonstrate why their work is important and how it assists SKAT. They
never talk about the technical infrastructure in relation to the decision makers but
only about the goals, they have set. Hass (interview 2, 2005) says that the goals
are very important to those people and not the specific technical details.

Not being specifically interested in EA champions is, of course, due to the ITASS
department claiming to not specifically work on an EA. Hass (interview 2, 2005)
says that it makes no sense to have champions of areas that are of no need. This
Successful Enterprise Architecture                                                     87

implies that he finds EA in itself invaluable. As stated earlier, I clearly disagree with
this, as I believe that SKAT is actually establishing part of an EA. Realising this
would help them define the necessary processes to implement their IT
modernisation. Hass is very much aware of focusing on key-employees in relation
to implementing and establishing changes in the SKAT organisation, as these
employees will inspire the co-workers. This will, consequently, make the compliance
aspect easier for SKAT.

9.7.         Stage 3 evaluation
Below, I evaluate SKAT in stage 3 based on my guidelines.

                Stage 3 Scorecard: EA governance and management

           Processes                          SKAT’s performance                  Scores

Establish future IT                  I believe that SKAT could use the            Yellow
decision structures                  extended ITG matrix analysis to ensure
                                     that the desired decision structures are
(Model: The extended ITG
                                     in place in the various domains. My
                                     analysis indicates the decision structures
                                     to a somewhat large extent is aligned
                                     with SKAT’s goals, but using the
                                     extended ITG model will put alignment
                                     on more firm ground.

                                     My ITG analysis indicates that the ITASS
                                     department and the executive board, at
                                     the moment, run the entire IT
                                     modernisation. Involvement of others
                                     are secured top-down and bottom-up
                                     through the project model (ITASS
                                     department is in charge of this
                                     integration).It thus seems that the
                                     information / business development
                                     from the local units is secured through a
                                     light version of the project model. This
                                     is definitely important for the local
Successful Enterprise Architecture                                                     88

                                     commitment to the change management

Establish governing                  SKAT has established five statements         Green
principles                           based on their business strategies.
                                     These five statements are to govern
(CM: develop a vision and
                                     their IT architecture.

Establish the EA                     SKAT has mapped their ‘as is’ and ‘to        Yellow
                                     be’ states and has prepared a transition
    Map the organisation’s
                                     plan including various phases (e.g.
    ‘as is’ state
                                     phase 1 is dealing with establishing their
                                     IT infrastructure).
    Map the organisations
    ‘to be’ state
                                     SKAT has, however, not used an
                                     established EA framework (not even as
    Prepare transition
                                     inspiration), which I believe is a
                                     mistake. I find that e.g. Bernard’s EA
(Model: EA framework)                Cube and methodology would have
                                     assisted them in their mapping of the
                                     two states. This would most likely have
                                     made a very complex process less

Adjust general project               SKAT has a very strong project model.        Yellow
model to contain EA                  The model is very central to SKAT’s aim
                                     of integrating the new IT architectures
(CM: Anchor new
                                     into any new IT-related project. Even
approaches in the culture)
                                     though the model is very impressive, it
                                     is still very important that the model
                                     embraces all changes including those
                                     that refer to the legislation.

Adjust maintenance to be             Again, the project model must,               Yellow
in line with the EA                  according to Hass, be adjusted to
content                              embrace all changes – at least the
                                     changes the ITASS department seeks to
Successful Enterprise Architecture                                                     89

(CM: Anchor new                      control. I believe, however, that there is
approaches in the culture)           a risk that some of the minor, though
                                     important, changes will never be
                                     included in the project model and
                                     thereby all changes might not be
                                     captured by the new IT architecture.
                                     The ITASS department must define how
                                     they will handle such maintenance or
                                     acknowledge that they cannot control all
                                     changes and relate clearly to that.

                                     In relation to general updates, SKAT
                                     made very clear that it is the business
                                     that controls the architecture, and only
                                     rarely would technology initiate
                                     changes. This is of course an ad hoc and
                                     debatable conclusion.

Map process owners and               The ITASS department has defined             Yellow
responsibility roles                 processes owners as regard their system
                                     processes. Unfortunately, some of the
(CM: Empower employees
                                     processes seem dependent on individual
for broad-based action)
                                     persons, some of whom will soon retire.
                                     It is critical for SKAT to figure out how
(CM: Key employees)
                                     they maintain all necessary knowledge
(Model: RACI)                        and experience in the organisation.
                                     Further, SKAT ought to make sure that
(Model: The extended ITG
                                     process owners are defined also as
                                     regards the business processes, and not
                                     only the IT-related processes.

                                     As regards communication, this was
                                     included in the project model. I find the
                                     application of other communication
                                     forms (e.g. staff letters) advantageous
                                     to secure the change management
Successful Enterprise Architecture                                                      90

                                     process better.

                                     The analysis here again shows the
                                     project model’s central role in governing
                                     and maintaining the new architectures.
                                     However, I believe that the ITASS
                                     department can be more conscious of
                                     their needs in relation to the process
                                     owners’ responsibilities and thus define
                                     their requirements to the project
                                     organisation. The ITASS department
                                     could use the RACI and extended ITG
                                     matrix to assist them in defining these
                                     requirements. This would also make
                                     SKAT aware of needed cooperation
                                     between business and IT domains.

Define escalation                    SKAT has an escalation structure build      Yellow
structures                           into their project model. Since the
                                     project model is very central to all IT-
(CM: empower employees
                                     related changes, the escalation structure
for broad-based action)
                                     is generally in place disregarding the
                                     problems around maintenance and
                                     legislative changes mention earlier.

User groups, committees              There exist ‘Think Tanks’ and business       Red
                                     development departments looking into
(CM: Empower employees
                                     new business initiatives in SKAT.
for broad-based action)
                                     However, there does not seem to exist
(CM: Anchor new
                                     any user groups or special committees
approaches in the culture)
                                     that help keeping the IT architectures
                                     up-to-date technically. I believe it is
                                     important to set up such groups or
                                     committees where staff is invited in.
                                     This will strengthen vitality, knowledge
                                     sharing and input generation. The ITASS
Successful Enterprise Architecture                                                      91

                                     department does not currently have
                                     resources to spend on this area, as they
                                     focus on completing their current
                                     projects. This is consistent with
                                     generating ‘quick wins’, which is
                                     important for the establishment process.
                                     But still, I believe, SKAT needs to
                                     establish user groups to leverage
                                     resources and knowledge better.

                                     Even though the technology in itself
                                     must not take control of changes to IT
                                     strategy, I believe that it is important to
                                     be aware of any technologies that might
                                     improve existing business processes and
                                     could affect the IT scope through new
                                     business opportunities or improved
                                     services. Information technology
                                     advances too fast to be only at the

Map stakeholder and                  SKAT is aware of the importance to            Yellow
prepare communication                communicate their IT modernisation to
plan                                 their stakeholders.

(CM: Communicate the                 Some of the employees resist the IT
change vision)                       modernisation. This must be expected in
                                     an organisation going through a
(CM: Key employees)
                                     dramatic change and designing new
                                     workflows. Consequently, the ITASS
                                     department must focus on solving the
                                     problems applying a clear
                                     communication strategy and by trying to
                                     create role models throughout the
                                     organisation. As mentioned earlier, I
                                     believe the communication plan could be
                                     carried out in a more diverse way. In
Successful Enterprise Architecture                                                  92

                                     addition, it might be useful to prioritise
                                     the user groups mentioned above to
                                     create role models.

9.8.         Maturity and measurement (stage 4)
According to Hass (interview 1, 2005), the modernisation work takes a very long
time. SKAT has a high turnover of functionality in relation to the legislation and in
this area, they have implemented some IT modernisation projects. As regards the
projects they have been involved in so far, the business response was very positive.
For example, the ‘TastSelv Erhverv’ digital solution is about to be completely
rewritten. The solution consists of around 200 technical services where potentially
all can be reused. If the ITASS department finds out that someone in another
project is building a system where some of the services from the ‘TastSelv Erhverv’
can be reused, ITASS can already now ask this other project to wait until the
‘TastSelv Erhverv’ solution has been completed, or at least ask them to built in
accordance with this project. This shows that SKAT is on the right track. However,
as was illustrated in SKAT’s map of their processes, SKAT has to rebuild many
systems. Thus, there is a long way before all benefits from the entire desired IT
architectures are realised. Before the modernisation programme, it was CSC (an IT
supplier) that had the big overview. Now SKAT themselves know their systems,
and, consequently, they make many more system-related decisions than earlier.
Clearly, this large-scale IT modernisation takes a long time to implement and
anchor in the organisation.

The ITASS department believes that EA (or rather the need to have an overview of
the business according to ITASS) and ITG have come to stay in SKAT not least due
to the requirements to cut costs. According to Hass (interview 2, 2005), ITG is very
important as SKAT is and will be a big building place the next 10 – 15 years which
requires high governance to stay on track. Today ITG has become an integrated
part of the organisation, which was not the case two years ago. Earlier, governance
existed in the separate departments and not on an enterprise cross-organisation
level and also not in a project organisation, which is necessary and apparent today.

SKAT is, of course, not specifically interested in EA maturity. However, in the
current year, the ITASS department plans to measure the maturity of their
architectures. They wish to establish measurements that reflect their goals. They
Successful Enterprise Architecture                                                     93

are interested in evaluation those specific technological areas that are necessary to
assist the business in achieving the overall goals, e.g. how much have been
modeld, how much have been service-enabled. According to Hass (interview 2,
2005), they are more interested in some SOA maturity as their ‘EA’ overview map
is only a small part of their work, and, therefore, he believes that they are not
specifically interested in evaluating this drawing. Hass (interview 2, 2005)
emphasises that they are to deliver a more flexible business system, and,
consequently, this is the centre of their attention.

Again, the above discussion shows that Hass sees the map of the organisation as
being the EA. However, as this is all too narrow, I actually believe that measuring
their achievements according to GAO and Herzum as defined in my guidelines could
serve as inspiration an potentially point to areas where they need to put more focus
in order to move ahead with their IT modernisation and sustain a business driven IT
portfolio in future.        Measuring SKAT’s ‘EA’ performance
Even though SKAT is not intentionally establishing an EA, I would assess SKAT as
being in stage 3 – Developing the EA – in GAO’s maturity model, and in the
beginning of the ‘Blueprinting’ state according to Herzum’s maturity model. This is
due to the fact that they are actually implementing many of the EA processes, e.g.
their IT modernisation is strategically driven, and SKAT has defined scope to
include more or less the entire organisation, which is to be implemented in phases.
They have described their ‘as is’ and ‘to be’ states and have started the transition
between the two states. They are defining governance processes in relation to
incorporating the new architectures into the project model’s milestones. Further,
their new architectures are used as a basis upon which to make ongoing decisions.
SKAT is not measuring their progress yet, but this is an area they will focus more
on in the current year. Thus, if disregarding the fact that SKAT does not
acknowledges that an EA would ease the IT modernisation and sustain a business
perspective in their IT portfolio in future, they are a somewhat mature organisation
but do not measure it yet.

Beyond recognising the value an EA would bring to SKAT, climbing the next
maturity levels in both GAO’s and Herzum’s models, SKAT must, among other
things, realise more projects in their future state, incorporate all their projects and
changes (including the legislative part) into their project model. Further, SKAT must
be working on how to evaluate both in relation to the maturity level of their
Successful Enterprise Architecture                                                      94

architecture itself but also in relation to guide the organisation in making informed
IT investments. The ITASS department has spent the current year working on
infrastructure tender offers. It was critical for them to establish an infrastructure
they can build upon and measurements are a naturally extension to this. According
to Hass (interview 2, 2005), the projects have their own business goals which are
somewhat irrelevant to the ITASS department, as their responsibility is to make
sure the technical parts are build correctly and in accordance with their defined

It might be interesting, though, for the ITASS department to measure whether their
new architectures are supporting the departments in reaching their goals. Here, I
believe SKAT could get inspiration from OMB to assess whether the new
architectures eases the general IT investment decisions and whether it has become
easier to facilitate change. Further, SKAT could use Schekkerman (2005) as
inspiration when defining more specific economic measurements that will be
necessary in the long run to demonstrate and measure the value added of EA
(SKATS’ dynamic architectures that aim at sustaining SKAT’s visions).

9.9.         Stage 4 evaluation
Below, I evaluate SKAT in stage 4 based on my guidelines.
Successful Enterprise Architecture                                                         95

               Stage 4 Scorecard: EA maturity and measurement

           Processes                           SKAT’s performance                 Scores

Evaluate EA maturity                 SKAT is not specifically interested in EA     Red
                                     maturity. However, I believe that using
(Model: GAO)
                                     GAO or Herzum’s EA maturity models will
                                     emphasise areas in which SKAT ought to
(Model: Herzum)
                                     put more focus to improve their IT
                                     modernisation as they are, in fact,
                                     conducting an EA. Directly establishing
                                     and measuring an EA, would ease their IT
                                     modernisation implementation and secure
                                     a business focus in their IT portfolio in

                                     SKAT, however, is interested in
                                     evaluating their IT architecture maturity,
                                     but has not started measuring anything

Evaluate the EA results              I believe that SKAT should begin to look      Red
as regard facilitation               at measurements that evaluate how (or
of change, integration               whether) the new IT architectures have
and business                         improved the business’s facilitation of
alignment                            change, improved IT and business
                                     alignment etc. Doing this at an early
(CM: Generate short-
                                     stage would justify and measure the
term wins)
                                     ‘quick wins’. Further, it would show the
                                     specific goals they wish to achieve with
(CM: Consolidate gains
                                     the new IT architecture.
and produce more

(Model: OMB)

(Model: Schekkerman’s
Successful Enterprise Architecture                                                      96

EA cost benefit models)

Evaluate better IT                   Again, I believe that SKAT ought to          Red
Investments –                        establish measurements that establish
economic evaluation                  whether the IT architectures have led to
                                     better IT investment decision making.
(CM: Generate short-
term wins)                           A shadow cost accounting principle can be
                                     used to directly evaluate the economic
(CM: Consolidate gains
                                     synergies created by the IT architectures.
and produce more
                                     For example, in the case of TastSelv
                                     Erhverv, SKAT could measure the
                                     development cost of the different parts of
(Model: Schekkerman’s
                                     the flexible components. Measuring the
EA cost benefit models
                                     cost of each component will exactly give a
(Model: Set shadow cost              measure of the value added in terms of
of internal synergies in             saved costs by not having to develop the
open architecture)                   particular component again.

9.10.        Conclusion
Even though SKAT is not recognising that they are in fact creating an EA, they have
come far. They have established the current and future states of their business and
technological processes and have prepared a transition plan consisting of various
phases. They know the IT modernisation is a very complex process to implement as
it consists of immense changes. The changes reflect the entire organisation, and as
such require governance structures in relation to both top management and the
daily projects. Thus, as I have mentioned several times, using an EA framework
and methodology (e.g. Bernard) would inspire and assist them in this process and
save them for ad hoc developments and decision-making.

SKAT is very focused on governance and is heading towards a more centralised set-
up. The ITASS department, the executive board and SKAT’s project model are very
important factors in this new structure. The ITASS department is in charge of the IT
modernisation from a technological perspective, and even though being defined as
Successful Enterprise Architecture                                                      97

an IT department they, currently, seem to have a strong business focus due to the
business driving the system changes as stated in the annual budget 2004. The
ITASS department and executive board are currently having a large responsibility,
which is a sign of SKAT being in the start up phase. To secure the implementation
of the various decision structures in the organisation to make the architectures part
of the staff’s daily behaviour, SKAT could use the extended ITG matrix. This will
help them establish who are to be responsible for the various domains.

As regards the project model, it seems very strong and structured, but it must be
extended to cover all projects including the legislative part. Further, the ITASS
department needs to define how they will handle minor changes external to the
project model. In addition, the ITASS department ought to define measurements in
relation to how they measure the value the new architectures generate. Of course,
the results are limited at this early stage, but it shows that they have clear goals.
Further, quick wins would justify all the changes the new architectures causes.

SKAT has come far but they still have a very long way to go. To improve the IT and
business alignment, to ensure agility in the business when making IT investment
decisions and implementing changes in future all requires constant compliance and
vitality. They do have some very strong governance processes including their
project model. Unfortunately, SKAT sees EA as only an EA framework, which they
found was of no use to them. I find that if they view EA correctly, it would and still
will help them establish the new architectures and ensure compliance and vitality in
anchoring the changes in their organisation. SKAT is heading towards more
centralism and this is exactly where an EA prove its worth. Further, it would ensure
and sustain a business driven IT portfolio in future – also after the IT
Successful Enterprise Architecture                                                   98

10. Case 2: ATP
This section about ATP is based on two interviews. Jytte Bertelsen, group manager
for three groups in the IT Architecture department in ATP, has been my main
contact for the interviews. Additional information is received mainly from their web
site and other online sites.

10.1.         Introduction to ATP
ATP (‘Arbejdsmarkedets tillægspension’ / ‘the Danish Labour Market Supplementary
Pension Scheme’) is a public-private organisation. ATP has a board of directors and
a board of representatives consisting of 15 representatives from the employers’
side and 15 representatives from the employee side. The board of representatives
is appointed according to law of the National Labour Market Supplementary Pension
Fund. The two boards carry ultimate responsibility for all ATP activities and Lars
Rohde, chief executive, runs the daily management at ATP.

Figure 18 ATP’s overall organisation diagram (in Danish) (for full size see
appendix G)

Source: ATP

ATP was established in 1964 through a law passed by the Danish Parliament. The
purpose was to supplement the state pension with a separate pension scheme to
reduce the risk of the state pension becoming a too large part of the state budget
Successful Enterprise Architecture                                                   99

while at the same maintaining the state’s intention to keep a certain level of
support of the elderly in Denmark in future. Thus, ATP’s main business is to offer
pension and insurance solutions to the labour market. ATP’s main products are ‘ATP
Livslang Pension’ (‘ATP life annuity pension scheme’) and ATP Ratepension’ (‘ATP
fixed annuity pension scheme’). The ‘ATP Livslang Pension’ is required by law and
secures that the working population save for their retirement above the state
pension. ‘SP / ATP Ratepension’ was established as a compulsory pension in 1999
but has now been put on hold by the government. The ATP organisation is required
by law to manage the ‘ATP Livslang Pension’ funds but the SP Pension is different.
Here, it is up to the citizens to decide whether their own bank, ATP or maybe a
third party manage their savings. Consequently, ATP is competing on asset
management with private entities, and in that sense has had to prepare themselves
for competition from the private sector over the last years.

ATP is a very interesting case as they are operating on both the private and public
market. As such, some of their business could be viewed as a kind of a non-profit
monopoly. As a working citizen, it is compulsory to pay ATP contributions, which
implies that ATP does not have to fight for the customers - they arrive
automatically. Regarding the SP contributions, however, the citizens have been
given the freedom to choose who should manage their savings.

ATP is a very interesting case due to its nature but, of course, also because the
organisation has initiated an EA programme to be able to control their large system
portfolio. The latter is the centre of attention in this thesis.

10.2.        The IT architecture department
Richard Haagensen is director of the ‘IT Architecture Department’ (ITAD) and ‘Nyt
Administrations og Forsikringssystem’ (NAFS) (‘New Administration and Insurance
System’ in English).
Successful Enterprise Architecture                                                  100

Figure 19 IT-related departments in ATP (in Danish) (for full size see
appendix H)

Source: ATP

The ITAD is divided into three groups: ‘Method and Enterprise Architecture’, ‘Test
Method, Tools and Quality Assurance’ and ‘Solutions Infrastructure’, all headed by
Jytte Bertelsen. The three groups employ 18 persons in total and are highly
integrated, and networking between the groups will be even more intensified in
future. The ITAD department is responsible for ATP’s EA.

As mentioned above, Richard Haagensen is also head of their NAFS project. The
purpose of this project is to modernise ATP’s entire system portfolio. Jytte Bertelsen
also has a big stake in the NAFS project, in fact, half of the 18 employees spend
much of their working time on this project.

10.3.         The NAFS Project (stage 1 – EA foundation)
NAFS is a large project where ATP is changing their entire system portfolio. The
goal is to be more service-oriented by running on a new platform. Previously, ATP
administered 11 different business lines with each line running their own systems.
Consequently, there could be a lot of systems supporting almost the same kind of
jobs. According to Bertelsen (interview 1, 2005), this has resulted in a very
complex system portfolio being very expensive and complex to operate.
Consequently, ATP is moving away from operating 11 business lines to ‘one
organisation, one process, one system’ and their goal is to reuse functionality
wherever possible.
Successful Enterprise Architecture                                                    101

To execute this project, ATP has analysed their entire business. They have mapped
their current business processes across the ATP organisation and defined which
functionality is necessary to support them. “Our goal is to have 80% general
functionality [services] and 20% specific functionality [services],” says Bertelsen
(interview 1, 2005, 0:11:17). Around 120 employees work on the NAFS project
including developers, people from the business side, architects, people from the
production side etc. This clearly indicates the importance and scope of this project.

ATP aims to be organised according to their business processes. In this way, they
hope to increase cross-organisational interoperability and focus on applying
functionality to be more efficient. “It is not in place yet everywhere but the thought
exists and is deeply anchored in the top management minds, and this is ATP’s
survival,” says Bertelsen (interview 1, 2005, 0:13:24).

There is no doubt that this new structure will make ATP much more agile. ATP will
not only improve their understanding of their business and technology but also
understand how they are interrelated. This will ease implementation of changes to
the business model and IT architectures in the future.

10.3.1. ATP’s domain landscape
ATP approaches the NAFS project by looking at ATP’s business. The NAFS team has
drawn a domain landscape mapping ATP’s information and services. Based on the
philosophy ‘single best home’, ATP has then defined the best domain or ‘home’ for
each single information and service. The goal of this philosophy is to avoid having
the same services in more places. The people working in the individual domains are
also responsible for developing the services in the desired direction. Bertelsen
(interview 1, 2005) comments that the domain landscape assists ATP in creating
Successful Enterprise Architecture                                                   102

Figure 20 ATP’s Domain Landscape (in Danish) (for full size see appendix

Source: ATP

‘Fonds (Funds)’ and ‘CRM’ are not included in the project initially. The two areas
are, however, integrated in the domain landscape to prepare an overall map of
ATP’s ‘as is’ information and services to be able to view which changes are
necessary to support the ‘one organisation, one process, one system’ strategy.
Bertelsen (interview 1, 2005) says that the domain landscape can be viewed as
Lego building blocks. As ATP creates new business solutions, they will use existing
services and information from the entire domain landscape to try to support new
business as generic as possible.

This structure provides flexibility. The domain landscape visualises ATP’s existing
services, and, thus, creates a general view of which services ATP has and which
they lack to start up on a new business initiative, in the future. This will ensure that
ATP does not build services that already exists, and in this way help cutting costs
and leverage growth. According to Bertelsen (interview 2, 2005), ATP is, however,
not used to work with such structures. Consequently, it will naturally be a big
Successful Enterprise Architecture                                                  103

challenge for ATP to implement and anchor this new way of working for the

10.3.2. EA needs analysis
Working with the NAFS project, ATP discovered that they needed a methodology
that would help them align their working processes with their new system portfolio.
According to Bertelsen (interview 1, 2005), ATP needed something that would help
them sustain and improve the business and IT alignment. Consequently, ATP chose
to establish an EA to enable the domain landscape in a structured way. Bertelsen
(interview 1, 2005) emphasises that they needed to be able to see the organisation
from a holistic perspective telling them how the strategy affects the technical
solutions across the entire organisation. The EA framework was a natural
instrument to help them achieving this. According to Bertelsen (interview 2, 2005),
most of the information produced in NAFS ends up in their EA. As a consequence, it
is not possible to alter NAFS’s domains without controlling it via their EA.

ATP is conscious that an EA including an EA framework would help them control this
new way of working. In a document ‘Etablering af Enterprise Arkitektur i ATP’
(‘Establishing an Enterprise Architecture in ATP’), the ITAD department has defined
what an EA programme entails and how this would benefit ATP. This document has
been produced to the board of directors. In the document, the ITAD department
defines EA as a framework including its content and guidelines in relation to how to
use the content. Further, they define IT governance as an important part of their
EA in which the IT principles will build the overall direction for the EA content. They
see EA as a tool that will ensure agility in ATP helping them to establish a holistic
map of ATP’s business and technology and help them understand how this

It seems that ATP has conducted an extensive EA preparation and investigation
process. In my opinion, this is extremely important when ATP aims at implementing
such a complex EA programme. As emphasised in the theoretical framework, there
is no single EA definition and therefore it is important to make sure that the
individual organisation understands what an EA means in respect to their own
organisation. In my view, ATP has done that. However, I do believe that ATP views
the EA compliance and vitality processes (governance and management) too
narrow and as such ought to focus specifically on EA governance (see section
Successful Enterprise Architecture                                                  104

10.3.3. Top management buy-in
As mentioned above, ATP has set up a structure to inform and involve top
management in high-level EA decisions. They approve ITAD’s EA plans before the
ITAD implements them. According to Bertelsen (interview 2, 2005), in October
2005 the board of directors approved that ATP could initiate an EA programme. The
programme approved will allow ATP to use the framework and EA principles
suggested by the ITAD (see sections 10.7.2. and 10.7.3.). This implies that ATP
with top management’s commitment can prepare a transition plan describing which
projects will be implemented in order to reach the goals based on ATP’s ‘as is’ and
‘to be’ states.

10.3.4. High–level governance structure
According to Bertelsen (interview 2, 2005), ATP used to be driven by consensus
decision-making. In many ways, there has been a tendency to involve several
people with possibly different opinions in decision-makings. Bertelsen (interview 2,
2005) says that many decisions were up for discussions, which resulted in lengthy
decision-makings, and, consequently, in the end somebody enforced a conclusion
that nobody actually cared about anyway. ATP had their different business lines and
each of those had their own way of doing things and their own systems. ATP is now
moving away from this silo structure heading towards a more top-down decision-
making process. According to Bertelsen (interview 2, 2005), a more central
structure is necessary to implement the new more streamlined way of controlling
ATP’s IT portfolio.

I find it interesting to map ATP’s old and new (desired) high-level IT governance
structures using the Glocalisation model. The analysis should indicate whether this
support their general governance structure and their goals.
Successful Enterprise Architecture                                                  105

Figure 21 ATP’s old and new (desired) high-level IT governance structure


                             Central           Federal



                             Parental          Local

                       Low                               High

                                  Local Responsiveness
Source: Own contribution based on Gartner Group (2005)

As pointed out in the SKAT case analysis, a more central governance structure
supports high cross-organisational integration. This is, however, at the expense of
local responsiveness. ATP seems to be aware of these pros and cons, as their goal
is to streamline their IT portfolio to support their business from a central point of
view. For example, ATP did not previously have a central development model but
applied many different methods. Bertelsen (interview 2, 2005) comments that this
is not feasible if ATP aims to work with service-oriented architecture. Here,
consistency must be prioritised as everything is interrelated. Consequently, the
ITAD has initiated a project called ‘from ‘IT development model’ to ‘development
model’’. The goal of the project is to create a model that accommodates all
development needs including business development, organisational development,
IT development etc. Currently, the various projects in ATP must deal with the new
development techniques, which the ITAD is preparing at the same time as the
actual projects need them. This has both positive and negative consequences. On
the positive side, the ITAD knows whether their suggestions are useful. On the
other hand, it is negative because it may confuse the employees and meet
resistance, as project managers must change their way of working. Bertelsen
(interview 2, 2005) thinks that this balance must be managed centrally.

In conclusion, ATP is heading towards a more central decision-making structure,
both in relation to their general business and their IT. IT decisions used to be made
more ad hoc, but with the new set-up, ATP tries to define common rules that must
Successful Enterprise Architecture                                                       106

be followed. ATP acknowledges that implementing this is very complex and has, as
a consequence, started an EA programme to assist them in establishing these
common rules and governing the structure in future.

10.4.        Stage 1 – evaluation
Below, I evaluate ATP in stage 1 based on my guidelines.

                          Stage 1 Scorecard: EA foundation

         Processes                            ATP’s performance                 Scores

Needs analysis and a                 ATP has clearly established a sense of     Green
cost benefit analysis to             urgency in relation to setting up an EA.
establish the need for               They are moving from a silo structure
an EA                                to a ‘one organisation, one process,
                                     one system’ structure aiming for a
(CM: Establish a sense of
                                     more agile system portfolio. Achieving
                                     this, ATP intends to control their IT
                                     more centrally, including making their
(Model: Schekkerman’s EA
                                     IT more business driven. To be able to
cost benefit models)
                                     do this, ATP has acknowledged that an
                                     EA is the discipline that can assist

Top management buy-                  EA in ATP has top-management buy-          Green
in                                   in. Top management has approved
                                     that the ITAD will carry out an EA
(CM: Develop a vision and
                                     programme that is in line with ATP’s
                                     vision and objectives. Further, top-
                                     management will regularly have to
(CM: Empower employees
                                     approve larger projects and
for broad-based action)
                                     assignments within the EA programme,
                                     and will also continuously have the EA
                                     status presented.

Establish common EA                  The ITAD has thoroughly defined what       Yellow
definition and ensure                they understand by an EA. However, in
common understanding                 a governance perspective, I do believe
Successful Enterprise Architecture                                                      107

of the EA programme                  they ought to focus more specifically
                                     on EA governance to ensure
                                     establishing all the relevant structures
                                     and processes necessary to ensure
                                     compliance and vitality in their EA (see
                                     section 10.7.1.).

Establish current and                Using the Glocalisation model, I have      Green
desired high-level                   analysed ATP’s current and desired
governance structures                high-level IT structures. This mapping
                                     shows that they are heading towards
(Model: Glocalisation
                                     being more central. This seems to be
                                     in line with ATP’s general governance
                                     model and ATP’s goal, which is to
                                     create a more streamlined IT portfolio
                                     that has an organisation-wide focus
                                     with high prioritisation on cross-
                                     organisational integration.

                                     EA is a programme that will assist ATP
                                     in establishing and governing this
                                     more central structure, and assists ATP
                                     in creating a map that shows their
                                     business and IT alignment as well as
                                     their interrelationships.

10.5.        EA approach – (stage 2)
In this stage, I will analyse how ATP has approached their EA with respect to
establishing an EA organisation and executive board. I will also look into how the
ITAD ensures occupying the right competences and knowledge and how they have
selected an EA framework and methodology, which they found appropriate.

10.5.1. EA organisation and executive board
The ITAD in ATP is responsible for establishing and implementing the EA
programme in ATP. Even though this is an IT department, they do seem to be very
conscious of the business importance when establishing an EA (see section
Successful Enterprise Architecture                                                 108

10.7.3.). Jytte Bertelsen has been the ‘champion’ of the EA programme. Such a
person is very important in relation to convincing top management of the benefits
in establishing a new programme and in keeping the top management’s attention
on the specific programme. She is, however, aware that it is dangerous if an entire
programme depends solely on only one person. Therefore, another person from the
ITAD has been appointed project manger on the implementation of the EA project.

There has not been established a special EA executive board in ATP. Instead the
project organisation reports to ATP’s ‘general executive board’. I do believe that it
might be worth considering whether a special EA executive board would benefit the
EA process.

It is unclear to me whether the ‘general executive board’ is actually an IT executive
board, but I believe it is. If they instead establish a special EA executive board they
could strengthen execution by involving both IT and business representatives to get
the full perspective. Further, such an EA executive board would most likely follow
the EA implementation closer than the general executive (IT-) board does today.
This should be positive for the EA implementation process, as it would involve top
management more effectively, and, consequently, make them more visible to the
organisation in general. This solution would probably ease the EA implementation
and EA anchoring in ATP.

10.5.2. Competences and knowledge
ATP has implemented employee performance reviews to ensure that the employees
occupy the necessary knowledge and competences in relation to current and future

Bertelsen (interview 1, 2005) says that because they are in the forefront with EA in
Denmark, they have to attend seminars hosted by ‘EA gurus’ that work with EA
professionally. She does not believe that there is sufficient EA knowledge in
Denmark, and therefore they need to attend international conferences. ATP has
included on the employees’ balance scorecard that each employee must have had
at least five educational days a year. Further, ATP’s staff satisfaction survey
measures if there is a match between the staff’s assignments and their

This demonstrates that ATP sees competences as a very important aspect. They
seem to understand that it is necessary that the employees’ competences match
Successful Enterprise Architecture                                                    109

ATP’s goals. If this match does not exist, it is impossible to reach the high-level

10.5.3. EA framework and methodology
Bertelsen (interview 1, 2005) believes that there exist a lot of interesting and
useful EA frameworks and methods. To match ATP’s organisation, they just need to
be slightly modified. Consequently, ATP has based their framework mainly on
Zachman’s EA framework. They have, however, also drawn inspiration from the
framework inherent in a tool called ‘Qualiware’ and the Ministry of Science,
Technology, and Innovation’s ‘White Paper’ model about IT architecture
(‘Hvidbogen’). Further, they have looked at how other organisations work with EA
frameworks, and, subsequently, created an EA framework that supports ATP’s
needs and desires.

The basis for mapping ATP’s ‘to be’ state into their framework has been ATP’s
business and IT strategies. They have examined how ATP’s statement ‘one
organisation, one process, one system’ can be supported architecturally and tried to
turn ATP’s business and IT goals into processes that work in their daily business.
According to Bertelsen (interview 1, 2005), their objective with EA is to make sure
that everybody follows and uses the EA content and only conscious exceptions will
be allowed.

In establishing the EA framework, ATP has placed business and IT strategies at the
same level. This was very important to Bertelsen (interview 2, 2005), as it shows
that the strategies influence each other. “I believe that it is very important that the
IT strategy also affects the business strategy [and not just the other way around],”
says Bertelsen (interview 2, 2005, 1:06:38). The figure below illustrates the equal
importance of business and IT strategies.
Successful Enterprise Architecture                                                 110

Figure 22 Establishing EA in ATP (in Danish) (for full size see appendix J)

Source: ATP

Often the business strategy would be above the IT strategy, but placing the two at
the same level shows an open-mindedness toward new opportunities influenced by
different trends. Bertelsen (interview 2, 2005) comments that it was a conscious
choice that was not approved without discussions and required thorough
explanations, as many people in ATP believed that the business strategy should be
considered superior just as it used to be. But the deviation here shows how ATP
views IT as more than just a supporting tool. In the process of establishing an EA,
they have acknowledged that IT is a strategic tool that can add value to ATP if used
with carefully towards ATP’s main goals.

10.6.         Stage 2 evaluation
Below, I evaluate ATP in stage 2 based on my guidelines.
Successful Enterprise Architecture                                                      111

                            Stage 2 Scorecard: EA approach

        Processes                           ATP’s performance                  Scores

EA organisation and              ATP has defined the ITAD as responsible       Yellow
EA executive board               for the EA, and within this department
                                 responsibility has been shared among
(CM: Create a guiding
                                 various employees. They have not
                                 established a special EA executive board,
                                 which, however, I do believe they should
(CM: Key employees)
                                 consider. I find that such a board should
(CM: Leadership)                 represent both IT and business
                                 perspectives / people. This will show the
                                 organisation more clearly that the ATP top
                                 management has fully understood EA’s
                                 potential, and it will probably ease the EA
                                 implementation and anchoring.

Ensure relevant                  ATP is aware of their competences in          Yellow
competences and                  relation to each individual assignment.
knowledge                        They do not specifically mention human
                                 capital needs e.g. EA architects. They are,
(CM: Empower
                                 however, aware that they need ‘best
employees for broad-
                                 practice’ experience from EA professionals.
based action)

Select EA framework              ATP has mainly based their framework on       Green
and EA methodology               Zachman’s EA framework. ATP found that
                                 they might as well use the existing
(Model: EA framework)
                                 frameworks contrary to reinventing the

                                 It this way it seems that ATP has managed
                                 to use an existing framework (- even a
                                 complex framework as Zachman’s) and
                                 turned it into matching ATP’s specific
Successful Enterprise Architecture                                                       112


Define EA scope                  The scope of ATP’s EA seems to be based        Yellow
                                 on their NAFS project. This is, however,
(Model: EA framework)
                                 not completely clear to me. I find that they
                                 ought to make clear whether their EA
                                 scope has to cover the entire ATP or only
                                 parts of the organisation. This would
                                 clearly illustrate how comprehensive their
                                 EA is.

10.7. EA/(IT) governance and management – ensure
    compliance and vitality (stage 3)
ATP is aware that they need to define and establish governance to make EA
effective in the organisation. Bertelsen (interview 1, 2005) argues that it is not
possible to have an EA that is alive without having governance surrounding it. She
comments that one thing is to be conscious about EA, but another thing is to
integrate it into the staff’s behaviour. To be able to implement EA in the
organisation, she finds that governance and quality assurance play important roles
and, thus, those two areas must cover the entire framework. The ITAD will begin
examine how it all fits together, and how it can be implemented in the organisation
in the current year.

10.7.1. IT decision structures
ATP has decided to define governance at two levels. The conceptual level of their
framework (see section 10.7.3.) will be owned and run by a separate IT
Governance Group (ITGG), and the other three lower levels (the logical level, the
operational level and the implementation level, (see section 10.7.3.) will be owned
and run by the ITAD. The ITGG is not established yet, but it has been decided that
a project will be initiated during this year (2006). The ITAD has identified the scope
of the ITGG in relation to governance at the top level of ATP’s EA framework. The
fact that the ITGG has not been established yet gives the ITAD time to prepare
their requirements carefully and they will be ready when the ITGG is established.
Bertelsen (interview 2, 2005) does not consider the division of governance as a
problem but she is aware of the necessary ties between this new group and the
Successful Enterprise Architecture                                                      113

I agree that there must exist very strong ties between the ITAD and the ITGG. It is
immensely important that this new group understands ATP’s EA and the
governance requirements it brings with it, otherwise, the ITGG could undermine the
entire EA programme. The ITGG will be responsible for governing the conceptual
level of EA, which is the basis for all the other EA information including the
governance of ATP’s IT principles. If this is not carefully governed, it would be
impossible to implement and anchor the EA in the organisation.

Bertelsen (interview 1, 2005) explains that all levels in ATP’s EA are planned to be
governed after the principle ‘follow or explain’. This should make it impossible to
avoid the EA principle when altering e.g. information in the lower levels, unless
specifically granted approval by the ITAD. This principle requires a business case
that explains the reasons for the change including economic benefits. Changes to
the EA at the conceptual level requires the involvement of the top management.
For example, adjustments to the IT principles (see section 10.7.2.) are not possible
without the top management’s consent.

The ITAD governs the EA at the three lower levels of the EA, which are actually all
controlled via their development model. According to Bertelsen (interview 2, 2005),
this department can therefore take decisions with respect to these three lower
levels without involving the top management, but mostly by following their
development model and complying with the content at the conceptual level. It is,
however, the top management that has made the decision to have a development
model that controls much in the three lower levels, and the ITAD cannot without
the involvement of the top management change the development model.

This is actually governance at different organisational levels. Top management is
involved in the overall decisions but is not involved at a detailed level. It is very
clear that the ITAD is aware that governance of EA at ATP is key in making the EA
implementation useful. However, I believe that they ought to be more specific in
relation to how they intent to ensure governance at the three lower levels as well
as the EA upper level. Applying EA governance (as defined in the theoretical part of
this thesis) upon their EA would provide them with the necessary structures and
processes to ensure compliance and vitality for their entire EA. This is done by, for
example, establishing, among other things, process owners, escalation structures,
maintenance and a development model. These structures and processes are
relevant for the entire EA and applying those would make the domain
Successful Enterprise Architecture                                                                              114

responsibilities easier to control when delegated to various parties – which I find is
very rational.

To illustrate the various domain responsibilities and desired central IT decision
structures in ATP, I have mapped ATP’s decision structures into the extended ITG
matrix. My aim is not to perform an in-depth analysis of ATP’s decision structures
but merely to show their overall direction towards more central IT decision

Figure 23 A simplification of ATP’s new (desired) more central IT decision


                 IT              IT               IT               Business         IT              Business
                 Principles      Architecture     Infrastructure   Application      Investment      Processes
                                                  Strategies       Needs

                 Input   Deci-   Input    Deci-   Input    Deci-   Input    Deci-   Input   Deci-   Input   Deci-
                         sion             sion             sion             sion            sion            sion



     IT          ITAD

     Federal                              ITEB             ITEB    PO       ITEB            ITEB    PO      BEB

                                          NAFS             NAFS    NAFS     NAFS            NAFS    NAFS    NAFS

                                          ITAD             ITAD    ITAD     ITAD            ITAD      *     *

     Duopoly             ITEB    NAFS             NAFS                              NAFS

                         ITGG    ITAD             ITAD                              ITAD


Source: Based on MIT as cited in Ross & Weill, 2004 including own contribution

ITEB: IT executive board

BEB: Business Executive Board

PO: Process owners

*: Other unknown
Successful Enterprise Architecture                                                    115

The above model shows the NAFS project’s high influence in modernising ATP’s
system portfolio. In the ‘IT principles’ domain, the ITAD provides input, which is
approved by the IT executive board, and, in the future, the IT governance group
(ITGG) will also be involved in the decision-making. In the ‘IT architecture’, ‘IT
infrastructure strategies’ and ‘IT investments’ domains, the NAFS project is
currently providing most of the input. In the future, it will probably be the ITAD
that provides the input through their EA. The general IT executive board takes the
high-level decisions, and the NAFS project and ITAD take decisions at a lower level.
As regards the ‘Business application needs’ domain, NAFS, the ITAD and various
process owners provide input, and the decisions are taken by the IT executive
board, the NAFS project or the ITAD dependent on the decision in question. As was
pointed out in the theoretical section of this thesis, the above ITG matrix should be
extended with a ‘business processes’ domain - a domain that arises from the
business strategy and, thus, represents the business perspective. In ATP, I believe
that input would be from business process owners and NAFS in their empowerment
of changing ATP’s 11 business lines to ‘one organisation, one process, one system’.
Dependent on the decision in question, they will probably be taken by the NAFS
project themselves in the project phase, probably together with a business
executive board or ideally an EA board, which also ought to be involved in the
decisions in the other domains.

The above analysis illustrates that the NAFS project, of course, has a very central
role in modernising the systems. In addition, my mapping illustrates a much more
central decision making process compared to previously where each department
could make their own decisions based on their individual needs. Further, it shows
the IT governance group’s responsibilities in relation to the IT principles. If the
extended ITG matrix is adjusted to cover ATP’s EA domains (levels), the ITAD could
use this model to map EA domain responsibilities. This would also illustrate the
cooperation necessary between those domains.

10.7.2. IT Principles
Based on ATP’s business and IT strategies, the ITAD has established 10 IT
architecture principles. “We have translated our business and IT goals to something
we can work with in our daily work,” says Bertelsen (interview 1, 2005, 0:24:05).

The 10 principles are:

    1. One organisation – one process – one system
Successful Enterprise Architecture                                                 116

    2. Optimisation of ATP’s business processes

    3. Portfolio focus

    4. Formalise and standardise information

    5. Service oriented architecture

    6. Integration of standard systems

    7. Outsourcing

    8. Loose coupling

    9. Scalability

    10. Architecture and methodology focus

ATP will govern their IT architectures according to these principles. Further,
Bertelsen (interview 1, 2005) comments that whenever any of these principles are
ignored it will be a conscious choice.

10.7.3. Establishing the EA framework content
It is important to involve the business side when establishing the EA. Bertelsen
(interview 2, 2005) emphasises that the business must understand IT’s role and the
inter-relationships between IT and the business. This is easier to achieve if using
business expressions when explaining the relationships. ATP’s new head of
‘Customers and Products’ has a background in the IT area. Bertelsen (interview 2,
2005) comments that it is positive to have a person like him on the business side,
because he understands the IT vocabulary and knows how to explain IT to the
business people using business expressions. This will ease the co-operation and
understanding between the two spheres, which is necessary to establish an EA.
Successful Enterprise Architecture                                                     117

Figure 24 ATP’s EA framework (in Danish) (for full size see appendix K)

Source: ATP

ATP’s EA framework consists of a conceptual level, which targets the board of
directors, the management, and their business, and includes the EA principles. The
second level is the logical level that consists of projects and solutions, which
contains the individual business processes (solutions). The third level is the
operational level, which is the physical design and involves developers and
implementers. The lowest level is the implementation level, which consists of jobs
running on the machines. The EA model exists of six columns that are named:
‘Strategy’, ‘Process’, ‘Solutions’, ‘Information’, ‘Stakeholders’, and ‘Technology’.
Bertelsen (interview 1, 2005) comments that the information in the cell ‘conceptual
level/information’ is actually defined by business employees together with the ITAD.
Bertelsen (interview 1, 2005) says that all the content in the different cells are
interrelated across the EA. Even though the framework can be considered as a
bookshelf in which the individual artifacts can be looked upon separately, there
exist threads behind the scenes that bind it all together. For example, if a server
breaks down, it is possible to see which solutions are affected and then it is easy to
check which clients to inform. This is exactly one of main purposes with an EA.
Successful Enterprise Architecture                                                    118

Creating an overview of the business that makes the technological and business
integration visible and ensures this alignment in future.

ATP intends to implement their EA by making a transition plan that includes
information on where they are today, where they wish to be in future and a gap
analysis of the two situations that contains a prioritisation of the projects that are
to be initiated. In connection with the NAFS project, ATP has already prepared a lot
of the work. For example, they have analysed their business processes, their use
cases, they are currently defining their business workflows etc. Thus, Bertelsen
(interview 2, 2005) emphasises that based on this information, the ITAD must -
through their EA - define how it all fits together and make sure that it stays
updated and established in the organisation.

ATP uses the product ‘Qualiware’ to store all their EA content. This product allows
them to view each cell including its content in detail or see an overall picture of
ATP’s EA online. “This ought to make it [the EA content] more accessible [to the
organisation],” comments Bertelsen (interview 1, 2005, 0:35:41). Currently, their
information is more scattered across the organisation and they want to bring it

10.7.4. Development model
ATP’s development model will be integrated with the EA. Integrating the model with
EA will ensure that any new idea is evaluated against ATP’s goals from a holistic
point of view through their EA. Thus, a project will not be approved if it does not
match ATP’s goals, including the IT principles. Bertelsen (interview 2, 2005)
emphasises that, for example, the business and a customer together could come up
with a brilliant idea, but if the idea does not match the business goals at all it would
be far too expensive to realise such a project.

ATP wants to control their projects through their development model, and it seems
that they are aware of the model being very central in relation to complying with
the EA. It is important that they integrate this model with their EA soon, otherwise
they cannot control the changes that are made.

10.7.5. EA maintenance
Several activities must be conducted regularly and followed up upon in relation to
the EA. Bertelsen (interview 2, 2005) comments that the ITAD is still working on
what exactly continuity in the EA discipline includes, but some of the activities are:
Successful Enterprise Architecture                                                     119

    •   Yearly cycles around adjustment of the principles

    •   Adjustments of the metrics they will establish in relation to evaluating the

    •   Define all the specific terms they use in relation to EA.

    •   If there are changes to their business strategy, their EA must be adjusted

    •   Always be aware of new trends / new technological possibilities.

It is up to the ITAD to put this into practice and establish it in the organisation.

In relation to being responsive to new trends, the ITAD plans to set up different
activities. Once a year or half a year, they will look into developments on the
technological market. In the customer department this is already done by specific
employees that are continuously aware of new market opportunities, new laws, the
competitors etc. An idea could be to look at how this is working and copy some of it
to the technical side. The employees in the ITAD is also members of various
experience groups, and the head of the ITAD, Richard Haagensen seems to put
time into having a good knowledge of new trends, possibilities etc. “Actually, one of
ITAD’s assignments is to be in the forefront of the technological trends,” says
Bertelsen (interview 2, 2005, 0:44:12).

In conclusion, ITAD is aware of maintenance of the EA in more areas. This is what I
consider an important part of ensuring the EA vitality. It is important that the EA is
updated in relation to both ATP’s strategies but also externally in relation to general
business and IT trends, and ATP seems to have a good understand of this aspect.

10.7.6.        Artifact owners
For all the artifacts in the EA framework, ATP will define an owner. This owner will
be defined at department level. The departments are, consequently, responsible for
making sure that the artifacts are maintained and not changed without approval by
the EA organisation (ITAD). It is up to the owner to allow other employees to work
with their artifact and make sure that the artifact is quality stamped before it is put
back into the EA.

According to Bertelsen (interview 2, 2005), the ITAD will define the minimum
requirements regarding ownership, responsibilities, input right/duty,
Successful Enterprise Architecture                                                   120

communication etc., but it is the owners’ responsibility to execute it. All the
information will be stored and visible in the EA framework. The ITAD’s goal is to link
ownership to the organisational chart, as this will show which artifacts are affected
by an organisational change. This is an interesting and ambitious thought. To assist
defining these roles and responsibilities, the RACI and the extended ITG matrix
could be useful. Especially, as ATP has split their EA governance up into more
domains, the various archetypes could assist them in structuring ownership and
responsibilities at these various levels or domains.

10.7.7. Escalation structure
Bertelsen (interview 1, 2005) comments that the EA framework is also a possibility
to say no to good ideas from a holistic point of view, if a new project does not
match ATP’s business goals and IT principles visible through the EA. Being able to
establish this in the ATP organisation requires an escalation structure that must be
followed in case of disagreements. If this is not in place, it will be hard to integrate
the EA into the staff’s daily work, as no flexibility exist.

The ITAD has not defined an escalation structure yet. Bertelsen (interview 2, 2005)
believes, however, that escalation go through the ITAD as a first step, then decision
will reach the IT management and hereafter the IT chief executive. She believes
though that, only rarely, the decisions need to go further than to the ITAD.

10.7.8. Communication and stakeholders
The ITAD is preparing a communication plan that describes how and when they
approach the different stakeholders. They know that it is impossible to reach the
entire organisation at one time also due to the fact that some are more positive
towards the EA implementation than others. Further, the communication approach
also depends on whether the target audience is IT or business people. According to
Bertelsen (interview 2, 2005), they will first approach the IT management, the
business management and the corporate management. They have also defined in
their plan that they will give lectures on the EA both internally and externally. “At
the moment, I do not believe that it is difficult to sell it [EA],” says Bertelsen
(interview 2, 2005, 1:00:15). This is due to the fact that the ITAD receives a lot of
positive feedback, at the moment.

Bertelsen (interview 2, 2005) wants to make the staff use EA as part of their daily
behaviour. “The management should not act as police officers, it [EA] must be used
because it eases the daily work,” says Bertelsen (interview 2, 2005, 0:26:32).
Successful Enterprise Architecture                                                     121

Based on this, the ITAD plans to hold organisational workshops informing their
stakeholders of the advantages in relation to the EA.

The ITAD has also created small EA gimmicks. For example, they have produced a
small leaflet explaining the basic idea with EA that has much focus on the ten
principles. This leaflet is easy accessible for the organisation and gives a good
overview of the EA. Bertelsen (interview 2, 2005) has spoken to the project
managers in ATP and, according to Bertelsen (interview 2, 2005), they were all
very positive towards the EA. They liked the 10 principles, which would help them
perform their jobs. For example, in relation to evaluating suppliers, they would now
use the principles and demand the supplier describes how they can support ATP.

The ITAD is aware that implementing and establishing the EA in the ATP
organisation takes time and requires a lot of work. According to Bertelsen
(interview 2, 2005), their intention is thus to first focus on the stakeholders that
view changes positively. There will always be employees that are against changes,
but if they put their efforts towards the ones that are positive towards new
initiatives, they will most often motivate the others to work in the same direction. It
is impossible to focus on all the employees, and, therefore, it makes most sense to
focus on those that are interested in EA and posses a motivating nature and have

ATP believes that they are well on their way in their EA work. At the same time,
they are also very conscious about that much of their work is on PowerPoint and in
practise a lot is still to be done to implement and establish the EA in ATP.

10.8.        Stage 3 evaluation
Below, I evaluate ATP in stage 3 based on my guidelines.

               Stage 3 Scorecards: EA governance and management

           Processes                           ATP’s performance               Scores

Establish future IT                  ATP is aware of the necessity of          Yellow
decision structures                  governance in relation to establishing
                                     their EA in the organisation to ensure
(Model: The extended ITG
                                     compliance and vitality. However, when
                                     talking about governance they put high
Successful Enterprise Architecture                                                    122

                                     focus on governance at the top level in
                                     their EA framework, which will be
                                     governed by a new IT governance
                                     group. This is perfectly fine, but to
                                     ensure governance structures and
                                     processes covering their entire EA
                                     framework, I believe that they ought to
                                     focus on EA governance (as defined in
                                     this thesis theoretical framework). This
                                     would ensure governance alignment
                                     between the various EA domains.

                                     I believe that ATP could use my
                                     extended ITG matrix as a basis upon
                                     which to analyse their desired decision
                                     structures in the various EA domains.
                                     This would demonstrate the domain
                                     responsibilities. In addition, this could
                                     assist in making the escalation
                                     structures clear in relation to the various

Establish governing                  ATP has established 10 principles based       Green
principles                           on their business and IT strategies.
                                     These principles will govern their IT
(CM: Develop a vision and
                                     The ITAD finds it very important to
                                     communicate these principles to the
                                     organisation, as they believe this would
                                     make the organisation understand the
                                     EA purpose. As a consequence, they
                                     have created a small easy-to-read
                                     leaflet stating and explaining these

Establish the EA                     It seems that the ITAD is only mapping        Green
Successful Enterprise Architecture                                                   123

Map the organisation’s               their ‘to be’ states in the EA, because
‘as is’ state                        the NAFS project works with the ‘as is’
                                     state. The ITAD is using an EA
Map the organisation’s ‘to
                                     framework that is highly based on
be’ state
                                     Zachman’s framework.

Prepare transition plan
                                     The ITAD has prepared a transition plan
                                     as regards the move from ATP’s current
(Model: EA framework)
                                     state to their desired state. Thus, in
                                     close cooperation with the NAFS’s
                                     project, the ITAD is planning and
                                     implementing the required changes.

Adjust general project               ATP’s will establish one development        Yellow
model(s) to contain EA               model that integrates compliance
                                     towards the new IT architectures.
(CM: Anchor new
approaches in the culture)           However, I believe, that ATP still needs
                                     some work in relation to defining the
                                     structures that must be embraced in
                                     such a model, e.g. escalation structures,
                                     communication responsibilities,
                                     measurements etc.

Adjust maintenance to be             The ITAD is aware of various EA             Yellow
in line with the EA                  maintenance aspects including general
content                              IT trends. However, I believe that they
                                     should examine closer whether there
                                     exist minor changes that will never be
                                     caught by the development model, and
                                     whether the ITAD wants to control those
                                     changes, at all.

Map process owners and               ATP will define artifact owners at the      Yellow
responsibility roles                 department level. I find this very
                                     pragmatic, as it is almost impossible to
(CM: Empower employees
                                     control ownership at individual levels in
Successful Enterprise Architecture                                                      124

for broad-based action)              such a large organisation.

(CM: Key employees)                  I believe the ITAD could use the RACI
                                     model to establish and communicate
(Model: RACI)
                                     artifact roles and responsibilities in a
                                     very structured way. Further, they could
(Model: The extended ITG
                                     use my extended ITG matrix to map
                                     various domain responsibilities. This will
                                     clearly establish, in which domains top
                                     management must take decisions and in
                                     which domains the ITAD can take

Define escalation                    ATP needs to establish a strict escalation     Yellow
structures                           structure to create flexibility in their EA.
                                     Such a structure must be apparent in
(CM: empower employees
                                     their development model.
for broad-based action)
                                     To anchor the EA in the organisation, it
                                     is important for the employees to know
                                     they can escalate a decision. The ITAD
                                     seems to be aware of the need of such a
                                     structure, it is, however, not defined

User groups, committees              The ITAD is in general aware of any            Yellow
                                     technological trends. I believe though
(CM: Empower employees
                                     that they could extend this to also cover
for broad-based action)
                                     any new developments or ‘best
                                     practices’ within EA. This might provide
(CM: Anchor new
                                     the ITAD with ideas in relation to how to
approaches in the culture)
                                     implement the EA in the ATP

Map stakeholder and                  ATP is communicating their EA very             Green
prepare communication                professionally. They are aware of their
plan                                 different stakeholders and their various
                                     needs. They even create gimmicks to
Successful Enterprise Architecture                                                 125

(CM: Communicate the                 reach all people in a positive way.
change vision
                                     Further, they aim to reach those
CM: Key employees)                   employees that are positive towards EA,
                                     as they believe they will set positive
                                     examples for the other staff.

10.9.        Maturity and measurement (stage 4)
ATP will start implementing the two top rows in the EA framework based on the
work produced by the NAFS project. According to Bertelsen (interview 2, 2005), as
the NAFS project prepares much of the work, they will consequently be involved in
defining which parts the ITAD starts with when implementing the EA. “It [EA] is so
big, we have to work with it in phases,” Bertelsen (interview 2, 2005, 0:06:36).
Working with all the areas at once would be too comprehensive – it will be too
many big changes for the organisation at one time. A change process is more easily
implemented if it is done in steps allowing the process to be absorbed by the staff
through several iterations.

The ITAD is interested in evaluating the value, which their new architectures
generate. Bertelsen (interview 2, 2005) comments that currently the management
supports the EA, but this endorsement does not come automatically. Therefore, the
ITAD must establish metrics that evaluate and show the value added by EA, and
examine whether they can improve their work in different areas. Bertelsen
(interview 2, 2005) says that they must show that there is a positive cost benefit in
establishing an EA, otherwise, it does not have any justification. If the EA
encounters lack of support from the top management at some point in future, it is
important that the ITAD can show positive results (if they are positive!) that
support the continuation of the EA through a cost-benefit analysis. Bertelsen
(interview 2, 2005), points out that they have not yet defined the economic
measurement metrics, but it is important that the ITAD integrate these metrics
from the beginning and start measuring as soon as possible.

This discussion is closely related to the discussion of whether EA and IT governance
has come to stay at ATP. According to Bertelsen (interview 2, 2005) it is not
obvious that ATP works with service-oriented architecture in five years from now -
there might be another methodology that is more relevant than EA in the future.
Successful Enterprise Architecture                                                         126

“Everything changes, and it is naïve to believe that an IT architecture or solution
lasts forever. It is important to be open to changes and only as long as EA works
and generates results is it relevant for ATP,” says Bertelsen (interview 2, 2005,

ATP is interested in discussing maturity and will also work on this field in 2006. I
believe that using the models I have suggested in my maturity and measurement
section in the theoretical part would bring useful inspirations as to how to approach
such evaluations. Evaluating ATP’s EA based on GAO’s toolbox and Herzum’s
maturity models could be an interesting exercise that together with my guidelines
could bring measurement a step closer and indicate in which areas ATP needs more
attention and focus.       Measuring ATP’s ‘EA’ performance
Based on GAO’s EA maturity model, I evaluate ATP as being in phase 3, and based
on Herzum’s EA maturity model, at the beginning of the blueprinting phase. ATP
is developing their EA. They seem to have defined their scope based on the NAFS
project and have analysed their ‘to be states’ based on NAFS’s mapping of ATP’s
current state. However, at the moment, the EA is still very much isolated as plans
in the ITAD, which shows that ATP is just on their way through a very thoroughly
planning stage towards an EA implementation stage.

10.10. Stage 4 evaluation
Below, I evaluate ATP in stage 4 based on my guidelines.

                  Stage 4 Scorecard: EA maturity and evaluation

           Processes                            ATP’s performance                 Scores

Evaluate EA maturity                 ATP is interested in EA maturity, but they    Red
                                     are not measuring anything yet. I believe
(Model: GAO)
                                     that they could draw inspiration from GAO
                                     and Herzum’s EA maturity models in
(Model: Herzum)
                                     strengthening and establishing their EA.

Evaluate the EA results              ATP is interested in measuring the value      Red
as regard facilitation               of their EA. They even specifically points
of change, integration               to the fact that they have to show
Successful Enterprise Architecture                                                      127

and business                         positive EA results to be able to continue
alignment                            their EA in the long run.

(CM: Generate short-                 Again, I believe that ATP could receive
term wins)                           inspiration from USA via the OMB model.
                                     This model would assist them in
(CM: Consolidate gains
                                     establishing measurements as regards,
and produce more
                                     for example, how well the EA facilitates
                                     change. I am aware that ATP’s EA is not
                                     yet fully established. However, they are
(Model: OMB)
                                     beginning to implement parts of it, and,
(Model: Schekkerman’s                therefore, I believe, that they ought to
EA cost benefit models)              define above measurements as soon as
                                     possible. Further, establishing such
                                     metrics at this point would clearly
                                     establish the EA goals.

Evaluate better IT                   Again, I believe that ATP ought to begin     Red
investments –                        defining measurements that establish
economic evaluation                  whether the IT architectures are leading
                                     to better IT investment decision making,
(CM: Generate short-
                                     since this is a prerequisite for EA’s
term wins)

(CM: Consolidate gains
and produce more

(Model: Schekkerman’s
EA cost benefit models

(Model: Set shadow cost
of internal synergies in
open architecture)
Successful Enterprise Architecture                                                   128

10.11. Conclusion
ATP has made thorough preliminary EA planning work. They are conscious of why
they want to establish an EA, and what they expect an EA can do for ATP. They
have drawn inspiration from established EA frameworks and relating
methodologies. Now they face the big challenge of moving their EA from PowerPoint
plans to implementing it in the ATP organisation. They are preparing a transition
plan to move from their ‘as is’ to their ‘to be’ state.

In relation to governance of their EA, ATP is very focused on an IT governance
group that they will set up. This group will be in charge of the governance of the
top conceptual level in their EA framework, which includes their principles.
However, I believe that they ought to apply the EA governance structures and
processes, mentioned in this thesis theoretical framework, upon their EA. This will
provide them with structures and processes in relation to ensuring compliance and
vitality in their entire EA, and make the division of domain responsibilities easier to

Further, the ITAD ought to establish EA measurements to assess the value that EA
generates, as soon as possible. This should, beyond justifying EA’s existence,
identify or confirm ATP’s objectives in establishing an EA and could even shape the
objectives more clearly. The (hopefully) positive results should be communicated
broadly to the organisation, which will probably ease the changes the EA generates.
Successful Enterprise Architecture                                                  129

11. Comparing the two cases
The figures below show my case analyses scores based on my guidelines. From an
EA perspective, the figures show that in many areas both organisations have
established some of the necessary mechanisms to make their IT portfolio more
business driven.

Figure 25 SKAT’s scores based on my guidelines

                           EA NEEDS ANALYSIS

                      TOP MANAGEMENT BUY-IN                        E   E   E
                                                         STAGE 1   V   V   V
                       COMMOM EA DEFINITION                        A   A   A
                                                                   L   L   L
  C                  GOVERNANCE STRUCTURES                         U   U   U
  H                                                                A   A   A
  A                                                                T   T   T
                EA ORGANISATION, EXECUTIVE BOARD                   E   E   E
  G           RELEVANT COMPETENCES AND KNOWLEDGE         STAGE 2                S
  E                                                                E   E   IT   T
              SELECT EA FRAMEWORK AND METHODOLOGY                  A   A        A
  M                                                                        I    G
  A                         DEFINE SCOPE                           M   R   N    E
  N                                                                A   E   V
  A                                                                T   S   E    4
  G       I      I    E      P       M   P   E   U   C
                                                                   U   U   S
  E       T      T    S      R       A   R   S   S   O
                                                                   R   L   T
  M                   T      O       I   O   C   E   M
                                                                   I   T   M
  E       D      P    A      J       N   C   A   R   M
                                                                   T   S   E
  N       E      R    B      E       T   E   L       U
                                                                   Y       T
  T       C      I    L      C       E   S   A   G   N
          I      N    I      T       N   S   T   R   I
          S      C    S              A       I   O   C   STAGE 3
          I      I    H      M       N   O   O   U   A
          O      P           O       C   W   N   P   T
          N      L    E      D       E   N       S   I
                 E    A      E           E   S       O
                 S           L           R   T       N
          T                              S   R
          R                                  U
          U                                  C
          C                                  T
          T                                  U
          U                                  R
          R                                  E

Source: Own contribution
Successful Enterprise Architecture                                                       130

Figure 26 ATP’s scores based on my guidelines

                           EA NEEDS ANALYSIS

                      TOP MANAGEMENT BUY-IN                        E   E    E
                                                         STAGE 1   V   V    V
                       COMMOM EA DEFINITION                        A   A    A
                                                                   L   L    L
  C                   GOVERNANCE STRUCTURES                        U   U    U
  H                                                                A   A    A
  A                                                                T   T    T
                EA ORGANISATION, EXECUTIVE BOARD                   E   E    E
  G            RELEVANT COMPETENCES AND KNOWLEDGE                                  S
  E                                                      STAGE 2   E   E    I      T
            SELECT EA FRAMEWORK AND METHODOLOGY                    A   A    T      A
  M                                                                                G
  A                        DEFINE EA SCOPE                         M   R    I      E
  N                                                                A   E    N
  A                                                                T   S    V      4
  G        I      I   E      P       M   P   E   U   C
                                                                   U   U    E
  E        T      T   S      R       A   R   S   S   O
                                                                   R   L    S
  M                   T      O       I   O   C   E   M
                                                                   I   T    T
  E        D      P   A      J       N   C   A   R   M
                                                                   T   S    M
  N        E      R   B      E       T   E   L       U
                                                                   Y        E
  T        C      I   L      C       E   S   A   G   N
           I      N   I      T       N   S   T   R   I
           S      C   S              A       I   O   C   STAGE 3            S
           I      I   H      M       N   O   O   U   A
           O      P          O       C   W   N   P   T
           N      L   E      D       E   N       S   I
                  E   A      E           E   S       O
                  S          L           R   T       N
           T                             S   R
           R                                 U
           U                                 C
           C                                 T
           T                                 U
           U                                 R
           R                                 E

Source: Own contribution

In the following, I will briefly point to the main similarities and differences in the
various stages.

11.1.          Stage 1: EA foundation
Both SKAT and ATP are heading towards more centralism in relation to governing
their IT. In this respect, they have both established a sense of urgency in
modernising their IT to make it more business driven. However, their way to
control this business driven approach is very different. Where ATP believes that EA
is a discipline that will help them control and sustain the IT and business alignment,
SKAT does not consider EA for more than just a framework. Therefore, SKAT is not
aware that the processes they are building to implement and govern their IT
modernisation are, in fact, already mirrored in the EA discipline. This means that
Successful Enterprise Architecture                                                     131

they miss the experience and structures that an EA can provide them - an
experience and structure that would probably make the IT modernisation process
less complex. The fact that SKAT is not recognising the benefits that an EA would
give them, and the fact that they are actually performing many of the EA initiatives,
is, of course, apparent from my scores and discussions of SKAT’s IT modernisation

Both organisations have top-management’s buy-in. ATP’s top management has
approved that the organisation will build an EA to implement and govern a more
business driven IT-portfolio. As the purpose of an EA is to improve the business and
IT alignment, applying this discipline will ensure the business focus in the long
term. Since SKAT is not using the EA discipline consciously, the danger could be
that they get too IT focused. When the IT modernisation has been implemented,
the business perspective must be preserved, which would be easier if they apply
the EA discipline that incorporates both the business and IT perspectives. Both ATP
and SKAT aims at a more business driven IT portfolio and establishing this through
the EA discipline would sustain the business focus, not least in the long term.

11.2.         Stage 2: EA approach
SKAT has set up the ITASS department as the responsible unit for their IT
modernisation, and in ATP, the ITAD is responsible for their EA. ATP ought to
consider establishing a specific EA executive board. This will strengthen the belief
that EA is very important and necessary to ensure compliance and vitality in their
business driven IT portfolio in the ATP organisation. The board should include both
business and IT people to ensure both sides are represented. Of course, SKAT
ought to deliberately create an EA and define EA ownership and an EA executive

Both organisations have defined scope. Regarding SKAT it has been specifically
identified which business processes and which underlying technology will be
modernised. It seems that ATP’s scope is based on their NAFS’s project
productions, which makes it somewhat unclear to me what it actually contains at
this point.

Both SKAT and ATP are aware of their needs to attract competences. SKAT
specifically states that their need is to recruit architects that have both business
and IT competences. This actually, once again, indicates SKAT’s wants to improve
their business and IT alignment.
Successful Enterprise Architecture                                                  132

A very interesting difference exists in the two organisations’ perception of
Zachman’s EA framework. ATP has created their framework based on Zachman, as
they found that they might as well use some existing tool instead of reinventing the
wheel. SKAT, on the other hand, did not believe that Zachman could do anything
for them. An interesting angle here is to what extent different consultants have
impacted the EA view of the individual organisations, directly or indirectly. Had
SKAT involved consultants that were knowledgeable of and pro Zachman or EA in
general, they might have been able to use this framework – or another EA
framework – to create the map of their organisation, and who knows, they might
actually had been commencing on an EA to implement and sustain their IT and
business alignment.

11.3.        Stage 3: EA governance and management
Applying the ITG extended matrix, even though in a slightly simplified version,
shows central streamlined decision structures in both organisations. This is in line
with both organisations’ aims. They have both established principles of how to
govern their IT architectures. SKAT has mapped their ‘as is’ and ‘to be’ states based
on their own framework. Accordingly they have made a transition plan of how to
move from their current to their desired state through different phases. It seems
that the ITAD in ATP has mapped their ‘to be’ state based on their ‘as is’ state
mapped in the NAFS project. They have performed their mapping of their desired
state using their EA framework based highly on Zachman’s EA framework, which
has provided them with a structure in relation to how to approach the mapping.
Subsequently, they have prepared a transition plan of how to move from the ‘as is’
to the ‘to be’ state.

Both organisations are aware of governance, and in this respect they both focus on
IT governance. ATP is dividing the governance of their EA into two groups. First
they define governance of the upper level in the EA framework and attach this to
their general IT governance, whereas governance of the lower levels is defined as
the ITAD’s responsibility. I suggest that ATP applies EA governance upon their
entire EA framework, as this will ensure coherent and integrated governance
structures and processes across all EA domains regardless of domain responsibility.
SKAT does not discuss governance at the various levels of their map of the
organisation but value their project model as being a very important governance
mechanism. This project model belongs to a specific project organisation that is
constantly improving the model, and it has, currently, been extended to also
Successful Enterprise Architecture                                                  133

embrace some of the new IT architectures. Therefore, the project model plays a
very important role in the IT modernisation. The project model has integrated
escalation structures and communication structures, among other things, but needs
to cover all changes in SKAT to be complete. ATP has planned to establish one
development model covering all developments and changes in ATP.

At SKAT it is almost always the business that drives architectural changes, whereas
at ATP it could both be the business and new technology. This might be an
indication of SKAT being a public organisation compared to ATP that is a public–
private entity and functions as a more independent organisation. It seems that ATP
has more freedom to work with client services, whereas SKAT relies more directly
on the government’s budgets and a given service structure, which probably has a
much more business/benefit focus than technology focus. This is in contrast to ATP
where technological opportunities that will strengthen their business could very well
drive changes just like any business opportunity could drive changes. In this way,
ATP values the business and IT strategies as being able to influence each other,
whereas in SKAT, mainly the business strategy may influence the IT strategy and
not the other way round. This also explains their different views to user groups.
SKAT does not have specific IT user groups looking into new technology, but ATP
does, in fact, have such groups. ATP should, however, consider to also establish EA
user groups to follow EA best practices. To conclude, it is positive that ATP has
acknowledged that both technology and the business could impact each other, and
that both sides could drive value creation towards reaching the organisation’s
overall goals.

Both SKAT and ATP has defined process owners. ATP has a very structured
definition of ownership at the department level for each EA artifact, and SKAT is
also defining process owners at the department level but has problems with some
of the system process owners being too dependent on single individuals.

As regards escalation structures in case of disputes, and to ensure architectural
flexibility, SKAT has, as mentioned above, an integrated escalation structure build
into their project model. ATP knows they need to establish an escalation structure
but has not done it yet. Such a structure should also be build into their
development model.

As with the other preparatory work, ATP has thoroughly prepared a stakeholder
analysis and communication plan. They have created easy to read leaflets
Successful Enterprise Architecture                                                  134

explaining their 10 IT principles and the essence of their EA. SKAT is also aware of
their stakeholders and communication, but it seems to be more on an ad hoc basis.
As a result, SKAT’s IT modernisation seems to be very dependent on the ITASS’
office manager, Morten Hass. ATP, on the other hand, seems to be very structured
and have made thorough plans, which makes it easier to share the responsibilities
among various employees, as everybody knows the objectives and what is going

11.4.        Stage 4: EA maturity and measurement
ATP is interested in measuring their EA maturity whereas SKAT is not, with SKAT
once again claiming not to be conducting an EA, and measuring the actual map of
the organisation, which they believe is an EA, is of no interest to them. However,
assessing both organisations against GAO and Herzum’s maturity models is rather
interesting. This analysis shows that SKAT and ATP has satisfied some of the points
from more or less each stage, but from an overall perspective, both seem to be
around stage 3 in both models. Both organisations are still in the planning phase
and at the beginning of the implementation phase. Of course, it can be discussed
whether SKAT is actually in stage 3 since they are not deliberately conducting an
EA. However, my evaluation has been based on those processes they have
established in implementing their IT modernisation ignoring the fact that they claim
not to be implementing an EA. Thus, they, of course, lack the important aspect to
acknowledge the value the EA discipline would bring to SKAT in implementing and
sustaining their IT modernisation.

SKAT and ATP is not measuring any of their results, just yet. They have not started
evaluating whether EA (IT modernisation) facilities better change management,
improve IT standardisation etc., or whether their architectures facilitate better IT
investment decision making. They are, however, both interested in measuring
these values, but find it challenging to come up with such measurements. OMB
might provide inspiration in this respect. In conclusion both organisations needs
much more work to reach one of the higher maturity stages.

11.5.        Conclusion
Both SKAT and ATP is conducting business driven IT modernisations and wants to
sustain the business and IT alignment in future. The main difference between the
two organisations is that SKAT compared to ATP is not acknowledging that an EA is
the discipline that may help establish and ensure this alignment, even though they
Successful Enterprise Architecture                                                135

are, in fact, establishing many EA processes. This indicates that ATP seems to be
better equipped to sustain the business driven IT architecture in the future. ATP in
comparison to SKAT has made many of the necessary preliminary EA investigations
and seems much more structured in their implementation. However, I believe, that
the two organisations could actually learn from each others’ experiences. For
example, SKAT is very strong on governance enabled through a strong project
model, whereas ATP is much more aware of the value of EA, in general, which could
be an eye opener for SKAT seeing what EA is actually all about.
Successful Enterprise Architecture                                                 136

12. Conclusion
Improving business driven cross-organisational IT integration seems to be a hot
topic among today’s organisations. Many organisations want to move away from a
silo decision structure where each department runs its own systems based on their
own needs. More organisations value their IT portfolio as a strategic asset that
exists to support their business goals, and, consequently, want to improve their
business and IT alignment. Introducing the EA discipline in an organisation is often
an instrument to achieve a central business driven IT portfolio. Implementing an EA
serves to illustrate an organisation’s business and IT integration right from the top
strategy level down to the detailed technological level.

Based on the conclusions from the theoretical framework, I have prepared
guidelines consisting of four phases ‘phase 1: EA foundation’, ‘phase 2: EA
approach’, ‘phase 3: EA governance and management’ and ‘phase 4: maturity and
measurement’. In the first phase, I seek to establish the reason why an
organisation ought to establish an EA that is, what EA means to them and why they
believe EA might bring value to their organisation. In this respect, the organisation
should ensure top-management buy-in to anchor the EA process at the executive
level of the organisation. In stage two, an established EA organisation must
perform a more detailed planning of the project and secure that the necessary EA
competences and knowledge are present in the organisation. At this stage, the EA
scope, EA framework and EA methodology that best serve the organisation’s needs
must be chosen. Having performed those two stages carefully, the organisation has
established a basis on which they can implement their EA according to well-defined
IT principles that support their business strategy. This implementation is one of the
main tasks of stage three. Further, this stage deals with EA compliance and vitality
through governance. In the governance section in the theoretical part, EA
governance was found to be the discipline that ensures EA agility and continuity. In
this respect, it is important that the organisation is aware that getting EA working
in the organisation’s daily work requires incorporating EA into the employees’
behaviour. This can, for example, be done by, building well-defined decision
structures in the EA domains, implementing a strong project model that integrate
the EA content into IT-related projects, establish process owners for each EA
artifact, establish EA escalation structures to ensure flexibility and ensure
communication throughout the EA implementation process. Further, to justify the
EA existence, the EA value added must be assessed and communicated
Successful Enterprise Architecture                                                 137

continuously to the various EA stakeholders. This is done in stage four. By creating
my guidelines and testing the four phases, including the integrated change
management processes that strengthen the EA implementation, on my two case
analyses, I aim to answer my research question: “how an organisation can
establish and sustain a successful EA”.

As concluded in the SKAT analysis, they viewed EA as constituting of merely a
framework used as a means to create a map of the organisation. Implementing
their IT modernisation, SKAT claimed that they were not able to find any EA
framework that could assist them in creating an overview of SKAT. Thus, they were
interesting in mapping their organisation, but they were not particularly interested
in establishing an EA – even though this is actually what they are doing. In my
findings, this essentially means that SKAT misses important aspects of what an EA
can, actually, do for them. If SKAT understood that an EA is more than just an EA
framework, I believe, they would find it much more helpful in implementing and
governing their IT modernisation. Further, implementing an EA in relation to their
IT modernisation would guarantee a business perspective in relation to their IT,
also in the future. However, from a governance perspective, SKAT is very strong.
For example, they have a very impressive project model that is used in the entire
organisation, and which they continuously improve. Thus, they have recently
included their new IT architecture requirements into this model, which means the
IT-related projects are forced to take account and incorporate the new IT structures
into their projects. SKAT, however, needs to extend this model to embrace all
projects, but the model definitely serves as an excellent example of a governance
mechanism that ensures compliance and vitality.

ATP, on the other hand, has made a very thorough preliminary analysis of how and
why EA can create value to them. Thus, they have prepared many of the necessary
initial investigations. Consequently, they have a well-defined planned process for
their EA implementation in relation to establishing their EA. The big challenge facing
ATP is how to implement their EA and anchor it into their staff’s behaviour - staff
that is unfamiliar with working according to such structures. ATP intends to divide
the governance responsibilities of their EA into two separate groups. One group will
be responsible for the top level in ATP’s EA framework, whereas the ITAD (the
second group) will be responsible for the lower levels. In this respect, my
conclusion is that ATP should focus on EA governance to ensure coherent
governance structures and processes that are integrated in all the EA domains. This
Successful Enterprise Architecture                                                  138

will make the division of governance responsibilities easier to control, and ensure
compliance and vitality of the EA.

Overall, this thesis theoretical framework and the case analyses demonstrate that
EA is a very complex discipline to implement and anchor. My guidelines serve to
inspire organisations to bring a structure into this discipline and bridge the gap that
currently exist between EA theory and practice to be able to establish and sustain a
successful EA.
Successful Enterprise Architecture                                                   139

13. Reflection
When preparing the preliminary investigations, my objective of this thesis was
actually slightly different from the current scope. My initial idea was to analyse EA
in two highly EA mature organisations, and look into how the organisations
measured their EA results to calibrate performance and re-optimise future EA plans
to ensure continuity. However, as I contacted various organisations and discussed
EA maturity with one of the leading EA consultants Per Strand, Strand & Donslund,
I discovered it was very difficult to find such EA mature organisations. Given the
apparent lack of companies that have reached an advanced stage in their EA
implementation, I found it interesting to look into what it actually takes for
organisations to reach a high EA maturity level. When starting writing my thesis, I
had only known of EA for about six months (one semester class and a 4 week
project), and it definitely does seem more comprehensive and complex to establish
a successful EA than I had anticipated. The process of writing this thesis has been
very interesting and inspiring. Beyond learning a lot about the interplay between EA
in theory and EA in practise, I believe and hope this thesis contributes to the EA
field by providing EA implementation guidelines that I hope will provide some up
front information of what it takes for organisations that wants to go through an EA
implementation programme.

13.1.        Applied theory, best practices and models
In this thesis, I am taking a practical approach trying to investigate and explain the
main processes that are important to create a successful EA. My work is based on a
mixture of books, articles, online information and not least interviews with leading
consulting firms in the area (Garner Group, Denmark and IBM, Denmark) to get a
macro picture of what is being done in terms of EA in the industry. The interviews
with the consultants gave me a basis for understanding the extent to which theories
are applied, in practise, and the level of maturity the industry has reached so far. I
try to cover various angels of different theoretical aspects by discussing several
authors’ approach to EA and their results in different areas within EA. In this
process, I take a broad perspective by viewing EA theory from the angle of other
related theories that to some extent interfaces with EA (e.g. governance and
change management). One problem with EA theory is that no commonly
acknowledged definition exists. This is an important gap, as organisations must be
specifically aware of what they intend to implement. Consequently, I try to come up
with a definition covering EA in the broad perspective. From my experience and
Successful Enterprise Architecture                                                     140

research, I believe that too often organisations initiate different projects without
knowing what it actually takes and which direction to walk. If you do not fully
understand what you implement, you will also not know the best implementation
plan and the best direction, in which the project must go in order to optimise
problem solving in the long run.

13.1.1. Frameworks
Zachman is a natural starting point when discussing EA frameworks, as he is often
seen as the father of enterprise architecture, where I find Bernard’s methodology a
useful inspiration for understanding the EA processes surrounding the framework.
Unfortunately, there seems to exist a somewhat prevalent perception in the
industry that an EA framework constitutes an entire EA. Most people that work with
EA know of or have heard about Zachman. However, the danger is that his
framework does not include any processes or methodologies on how to map an
organisations current and future states (‘as is’ and ‘to be’) or how to keep them
updated, as the EA processes evolves. There is clearly a risk of viewing EA as
nothing but a framework. Bernard’s EA Cube, on the other hand, is an example of a
more simple but also more specific framework. Even though Bernard’s work is
based on Zachman’s framework, it is easier to approach, as Bernard includes a
specific methodology describing how to establish the EA content. This thesis
suggests that it is important to spend time on the preliminary planning stage
focussing on the organisation’s needs, getting top management’s commitment to
the plan, and on this basis examine which framework and/or methodologies to use
for the organisations EA implementation and subsequent anchoring. Which EA
approach is taken will often differ from organisation to organisation, but the plan
should be more than a framework.

13.1.2. Governance
Governance is a very important aspect of enabling EA in the organisation. Again, I
find it important for an organisation to discuss and define how it understands
governance, and how this is best applied to the EA content. While much of the
literature actually focuses on IT governance, EA governance (EAG) needs a
definition of its own as it broadens the discipline to also capture the business
processes. When I started looking into governance, the IT governance (ITG) angle
seemed to be the predominant approach, and, at this stage, I had not heard about
EAG at all. Currently, there seems to be much more attention around ITG. In my
interviews with SKAT and ATP, the organisations also only discussed ITG and did
Successful Enterprise Architecture                                                   141

not mention EAG. When interviewing Gartner Group, they only talked about ITG
and put high focus on the ITG matrix. To me this model seems very useful in
relation to establishing decision structures in the different EA domains, however, it
must be extended to also cover the business perspectives. Thus, in relation to
creating an EA, I believe that the ITG matrix is too IT focused. If the aim is to
improve the business and IT alignment, the model needs to be extended to cover
business processes – the ITG matrix needs to become an EAG matrix. In working
with EAG from a theoretical perspective, I try, in this thesis, to take a first step in
exactly that direction. I extend the ITG matrix and illustrate how the extended
approach works in my case analyses. I think the extended approach is useful in the
empirical analysis since it, as opposed to the ITG matrix, points to how the
organisations in general can struggle to get the business processes implemented
and, in practice, might be skewed towards extracting pure IT synergies. Getting
business processes aligned is, of course, the crux of EA.

Thus, organisations should focus more on EAG as opposed to ITG when they run EA
programmes to secure integration of business aspects more clearly. In my
definition of EAG, I have been inspired by different sources from IBM Denmark, IBM
Canada (separate sources) and articles from the Cutter Consortium. I believe that
the set-up I arrive at points more clearly to what is needed to govern an EA at all
the levels than what I have seen elsewhere. This view is supported in the empirical
case analysis where I apply the EAG set-up specifically.

13.1.3. Change management
The introduction to change management (CM) in my thesis is useful because EA
implementation triggers so many business transformation processes. Often the
main purpose of reorganisation in today’s organisations is to create agility to be
more capable of adapting to changes effectively and efficiently. Here EA
programmes are not different in nature, and, thus, I find it natural to include CM
processes in the EA implementation. In particular, I think it is useful to work with
Kotter’s eight steps as an integral part of the EA process, as shown in my EA
guidelines. Hopefully, the integration of CM in the guidelines will be one ingredient
that helps organisations broaden their perception of EA implementation process as
more than an EA framework.

13.1.4. Maturity
EA maturity and evaluation stands as a weak spot in this thesis. This is not because
I have not prioritised this aspect. Indeed my initial scope was to focus on only this
Successful Enterprise Architecture                                                   142

topic - in particular the measurement part, which I believe must be an important
but also advanced ingredient in EA. In the end, measurement will demonstrate the
business value of EA. However, there is just lack of companies in Denmark that has
come very far in implementing an EA. This is also true for ATP and SKAT. Somehow
this contrast, for example, the US and, as my initially practical knowledge was
related to mainly foreign institutions like the Ministry of Veteran Affairs in the US,
this angle initially was very natural to me. However, literature dealing with EA
maturity does exists and this literature and the interviews with the consultants
stands as the main input for stage 4 (EA Maturity) in my guidelines.

Both GAO and Herzum’s maturity models are good inspirations for EA maturity
guidelines. Even though they both describe similar EA maturity phases, they end
out with two different approaches. A third model, the OMB model is more
appropriate in relation to EA measurement, for example, to assess how well EA
facilitates change in an organisation. In a fourth approach, Schekkerman focuses on
economic EA measurement possibilities. Schekkerman is definitely interesting, but I
would have appreciated more specific recommendations about what is most useful
in relation to an EA.

In a maturity respect, I believe it could be interesting to create public EA maturity
benchmark measures to promote competition among organisations. Of course,
many private organisations may not want to make their results public, but the
government could use such measurements to create competition inside their own
agencies. Hopefully, competition will promote the use of EA and promote sharing of
best practices. In the end, this could lead us towards a more effective and efficient
central administration. I will get back to this point later.

13.1.5. The case studies
I use two case studies to test my guidelines, and on top, I have supplemented the
empirical analysis by using leading consultants to assess whether the results seem
representative for EA practise. Consistency between my guidelines and my
interviews is secured by common interview guides used towards both organisations.
Including two cases and spending time with consultants instead of focussing on just
one organisation has, of course, some pros and cons. On the negative side, two
cases means less time and space to analyse each case and in that way, it has not
been possible to perform an in-debt analysis in all the EA related items. On the
positive side, I get a much better overview of EA in practice. My choice here is
clearly intentional. My aim in this thesis is to produce and evaluate general
Successful Enterprise Architecture                                                   143

guidelines that focus on implementation and assess how the guidelines work.
General guidelines for the industry, by definition, cannot be evaluated using just
one case. Therefore, to be able to test my guidelines, I need minimum two cases
and maybe this is not even enough. I need to cover a broad spectrum and, on top,
try to gain at least some depth. To mitigate the problem of ‘only two organisations’,
I have prioritised to also interview consultants at Gartner Group and IBM to be able
to get a broad view of what the industry does. In this way, I feel that my working
process have been optimised to establish my guidelines and test those within my
time limit. My assessment is that this process has actually worked very well.

When I selected my two cases, my selection criterion was two organisations that
have worked with EA for a while. Various consultants told me that ATP and SKAT
had come pretty far. This is somewhat interesting in relation to SKAT. They claim
themselves that they are not establishing an EA, but various EA consultants from
outside has the perception that they are creating an EA and has, in fact, climbed
the first couple of EA maturity steps. This only strengthen my conclusion that if
SKAT themselves acknowledges the value an EA would bring to them, the IT and
business alignment would be more secure in the future.

13.1.6. Conclusion
Almost all theory I have read has been relevant in shaping my EA guidelines. I
think it is useful to consider different approaches and models in the
implementations process as opposed to follow just one general theory. The partial
approach is reflected in my guidelines that provide a “toolkit” that can be adapted
to the particular organisation. The alternative is, of course, that the organisations
follows a ‘one model approach’ suggested by, for example, a given consultant. This
is particularly a risk if the organisation does not understand enough about EA
before starting actual implementation. As mentioned, the partial approach is
preferred in my guidelines. For example, I include both the Glocalisation model and
the extended ITG matrix to analyse and evaluate the organisation’s EA governance
decision structures. The extended matrix clarifies the organisation’s IT decision
structures in the various EA domains and the Glocalisation model helps
understanding whether more central governance happens at the expense of local
responsiveness. Further, both models clarify whether the organisation’s IT decisions
structures match their general governance structures. Thus, I try to mix useful
models and practices from various disciplines to end up with guidelines that can be
used by most organisations.
Successful Enterprise Architecture                                                   144

13.2. The purpose of my guidelines and the thesis in
My guidelines have been very useful in analysing SKAT and ATP’s EA work, and will
hopefully serve as inspiration to other organisations in establishing and evaluating
necessary processes to create a successful EA. However, I do not define how
organisations specifically should approach the implementation. While this is an
interesting extension it must be done carefully as it can make the guidelines too
company specific.

To be able to control the EA implementation and anchoring, I believe the
organisation can take advantage of the best practices that already exist. This can
save resources and steer around mistakes that others have learned from. During
my interviews, I experienced the perception that Zachman’s framework was only
useful for university researches. My view here is that some organisations tend to
underestimate the foundation stage, which they consider too theoretical. I have
experienced this directly myself when I was working at the A.P. Moller - Maersk
Group as a project coordinator in an intranet project group. In this particular
project, the needs analysis was, in my view, not prioritised enough and, as a result
the objectives became unclear and volatile. Changing plans, of course, lead to lack
of focus and little execution. To coordinate efforts, an organisation must create a
common understanding of the EA plan and clarify the ultimate goal of implementing
an EA.

If an organisation decides to implement an EA, the organisation must set-up an EA
project group to look at best practices that can help them getting started. Often,
the organisation goes and hire consultants right away to assist or even be in charge
of the programme implementation. I believe it would beneficial if the individual
organisation prepares itself to be able to challenge the consultants better right from
day one. As discussed earlier, the consultants will, by nature, be biased towards
their own predefined models and processes that might not fit all organisations.
They will only bring one view to implementing an EA. During my valuable interviews
with the different consultants, I experienced that Gartner Group was not so
interested in talking specifically about EA but preferred discussing IT governance.
At the time of the interview, Gartner Group indicated that they did not really have a
satisfactory EA framework. Instead they spent much of their time modelling ITG -
this was their approach to EA. IBM, on the other hand, showed me their own
model, which they believed contained what was necessary to implement EA. It is
Successful Enterprise Architecture                                                     145

only naturally for consultants to have a preference for using their own solutions –
after all, they probably came to the particular solution method because they think it
is the best approach. But again, working from a certain solution angle risk putting
the solution method and not the organisation in focus. A balance is needed here,
and such a balance can only be obtained if the organisation can stand as a strong
opponent to the consultants. Having EA experts inside the organisation helps
customising the EA implementation to the organisation’s business processes, IT
tools and needs of the organisation in general. In this respect, my guidelines can
assist in assessing what an organisation should prepare when commencing on an
EA programme. As such, I hope that my guidelines will give an organisation a
better start to EA by broadening the scope contrary to many of the existing EA
methodologies where the EA framework often seems to get most attention.

13.3.        Further research
Below I will emphasise some of the areas that I find could be very interesting to
investigate further. These areas are selected based on my experiences and
thoughts during writing this thesis.

13.3.1. EA governance versus IT governance
As an extension to this thesis, it could be interesting to further compare the ITG
and EAG disciplines from an EA perspective by building and further evaluating my
extended business aligned ITG matrix. In my opinion, there is too much focus on
ITG in the EA literature. If the objective is to implement a more central but flexible
IT structure and improve the business and IT alignment, EA is a relevant
programme and then EAG – and not ITG - is the governance discipline that should
be in focus. Jeanne Ross, one of the researchers behind the ITG matrix is currently
writing a book on EA, and when this book is published, probably around summer
2006, it will be interesting to see whether she is still using the ITG matrix as the
main EA governance tool.

13.3.2. EA measurements
Another interesting extension is to integrate methods to measure the value added
in EA more specifically – both inside my guidelines and in my empirical studies. The
task could be to examine how an organisation can create measurements and
combine the measures with feedback mechanisms to continuously optimise and
improve the EA in the organisation. As I demonstrated in my analyses of SKAT and
ATP, they are very interested in this topic but simply do not know how to approach
it. In this respect, Schekkerman might provide some initial direction, although more
Successful Enterprise Architecture                                                   146

specific examples that shows clear examples of how to calculate the IT investments’
improvements based on an EA, in my view, would make his work more complete
from a practical point of view. If specific examples can be given to guide
practitioners better, I believe organisations would implement measurements much
earlier in the EA process than seems to be the case today. In this thesis, lack of
measurement was evident throughout my empirical work.

13.3.3. The public / private aspect
As a third extension that was defined to be beyond the scope of this thesis is to
look into public/private aspects. For example, it would be interesting to examine if
there exist differences in the necessary roles in public and private organisation. For
example, how does the public sector in general (represented in this work by SKAT),
make sure that politicians are involved in the process to be able to extract
synergies between public agencies, but also to be able to close down things before
they get too far off the track. To put this into perspective, the government could
just look to the US where legislation motivates public agencies to look into EA
before they get their budget financed. Building laws on EA might be a bit too radical
for a more consensus run Danish public sector, but setting up best practice
benchmarks for agencies could at least be a start for the Danish public sector. This
would, for example, have helped SKAT. The benchmarks could act as a cornerstone
for measuring, and as such could stand as a first step towards a public EA maturity
model helping to clarify the scope of EA better. More public sector knowledge about
what EA is and how it creates value could set a useful example for organisations in
Denmark in general.

13.4.        Conclusion
EA is an extensive and complex process. However, if an organisation wants to look
at the relationship between the IT portfolio and business processes, if the
organisation wants the content to be structured by central governance processes,
and wants to manage change to the organisation’s working processes as they go
along, then EA is very likely to be the programme that might help them. My
guidelines aim to establish a practical guide on how to approach and implement an
EA based on a comprehensive theory mapped for practical use. I have created four
main stages:
Successful Enterprise Architecture                                                  147

    1. EA foundation stage

    2. EA approach stage

    3. EA governance and management stage

    4. EA maturity and measurement stage

The content through the stages is supported by change management principles and
a partial modelling toolkit from the literature. The four stages mirror, in broad
terms, what I view necessary for EA to be applied more broadly and with higher
success rates in organisations in the future.
Successful Enterprise Architecture                                                  148



I distinguish between business and IT architectures as illustrated below using
Zachman’s EA framework. The upper circle refers to business architectures whereas
the lower refers to IT architectures.

Figure 27 Illustration of business and IT architectures

Source: www.zifa.com


In this thesis, discipline is used based on the following definition: “a system of rules
of conduct or method of practice” (Websters online dictionary, 2006 and
WordReference, 2006).


In this thesis, I view theory as “a well-substantiated explanation of some aspect of
the natural world; an organised system of accepted knowledge that applies in a
Successful Enterprise Architecture                                                 149

variety of circumstances to explain a specific set of phenomena; ‘theories can
incorporate facts and laws and tested hypotheses’; ‘true in fact and theory’”
(Webster’s online dictionary, 2006).

However, I also use the term theory and theoretical framework when I refer to the
included disciplines (EA, governance, change management and maturity) or some
of them.


I use organisation as an overall term for all terms relating to enterprise, concern,
company, business. Thus, I do not distinguish between e.g. organisation,
enterprise, concern, company and business.
Successful Enterprise Architecture                                                   150

Appendix A: Interviews and interview summaries
  with SKAT

Interview guide to my first interview with Told & Skat, Monday 29 August

This is only a guide to make sure that the interview is kept on track. Still there is
and should be room for deviations. Also since it is my first interview with Told &
Skat, there might be other aspects and areas that the interview person might want
to talk about that I have not thought about.

The guide is in Danish as the interview organisation is a Danish public agency (Told
& Skat) and thus the interview will be carried out in Danish.


General baggrundsviden:

Interview person:

Kontorchef Morten Hass, IT-strategi, -arkitektur og –sikkerhed

Ansvar og opgaver?

1) Hvorfor fik I fokus på IT?

2) Hvad er jeres mål?

3) Hvad dækker I, hele ministeriet eller ”kun” styrelsen?

4) Bruger I bevidst Enterprise Architecture og IT Governance disciplinerne?

5) Hvordan ser du, de to discipliners sammenhæng?

Enterprise Architecture

6) Har I brugt en EA procesmodel ala Hvidbogens/Zachman?


Successful Enterprise Architecture                                                   151

7) Har I kortlagt jeres as is og to be situationer?


        Hvordan lukker I gap’et?

8) I forbindelse med definitionen af jeres IT arkitektur – tog I så udgangspunkt i
kunden eller teknologien, eller …?

IT Governance

9) Har der været en "før IT Governance tid" og i så fald, hvordan har processen
omkring indførslen af IT Governance været?

10) Hvordan influerer kulturen (politisk) på beslutningerne (top-down – bottom up
/ konsensus)?

11) Har I fået opbygget nogle klare og optimale beslutningsprocesser?

12) Har I brugt en model, f.eks. Ross og Weill?

13) Hvem tager følgende beslutninger:

        IT principper; IT arkitektur; IT infrastruktur strategier;

        Forretningsapplikationer; IT investeringer; Andre

14) Hvordan bruger I ITIL?


Hvordan sikrer I jer koblingen til jeres strategi?


15) Hvordan skabes der kontinuerlighed i jeres IT-styringsproces? – så jeres
arkitektur og styringsprocesser ikke bliver forældet?

16) Hvordan styres projektporteføljen?

17) Hvordan vurderer I, hvilke nye IT projekter, der skal igangsættes?

(Hvordan fungerer projektenhedens projektmodel – koblingen til arkitekturen)
Successful Enterprise Architecture                                                 152

18) Hvordan sørger I for altid at have alle aspekter (f.eks. strategi) med i nye
løsninger, således, at det ikke kun er teknologien, der bestemmer?

19) Hvordan implementerer, forankrer og kontrollerer I ændringer?

20) Hvad med alle de forandringer, der er ved at ske (kommunalreformen). Er der
taget højde for dem?

21) Indgår I i et samarbejde med projektenheden og de andre kontorer?


22) Koordinerer I med andre ministerier og eksterne partnere?

23) Er jeres systemer integreret med de regionale T&S myndigheder?



24) Har I opnået jeres mål?

25) Skaber jeres bevidste IT-styringsproces synergier på tværs af organisationen?

26) Er I blevet mere agile på IT området?

27) Hvilke resultater har I opnået (både håndgribelige og uhåndgribelig)?

        Er der f.eks. økonomisk gevinst i IT moderniseringen?

        Har der været andre drivkrafter?

28) Hvordan ser fremtiden ud?

29) Måler I modenhed og I så fald, hvor modne vurderer I jer selv til at være?

30) Er EA og ITG kommet for at blive i Told & Skat?


Er det muligt med et opfølgningsmøde sidst i september?

Er det muligt at maile med eventuelle opfølgningsspørgsmål?
Successful Enterprise Architecture                                   153

Summary of my first interview with SKAT (then Told & Skat) on 29 August

Introduction: Morten Hass asks to my background

Time: 0:00:00 – 0:01:14

Morten asks why I believe EA is an important area

Time: 0:01:15 – 0:01:52

Morten asks about my thesis focus and my objectives

Time: 0:01:53 – 0:03:22

When Told & Skat started focusing on IT

Time: 0:03:23 – 0:04:20

Told & Skat’s focus on EA

Time: 0:04:21 – 0:07:31

Told & Skat’s ‘Connect Strategy’

Time: 0:07:32 – 0:09:34

Told & Skat’s use of an EA model

Time: 0:09:35 – 0:11:00

Told & Skat’s approach to crate an overview of their business

Time: 0:11:01 – 0:13:18

        Told & Skat’s five governing principles

        Time: 0:12:30 – 0:13:00

Governance in Told & Skat

Time: 0:13:19 – 0:15:30

The purpose with architecture according to Morten Hass
Successful Enterprise Architecture                                         154

Time: 0:15:31 - 0:16:32

How Told & Skat got an overview over their systems

Time: 0:16:33 – 0:17:59

Governance in Told & Skat

Time: 0:18:00 – 0:19:12

Why build an IT architecture according to Morten Hass

Time: 0:19:13 – 0:20:37

The problems involved for an administrative staff function

Time: 0:20:38 – 0:21:34

Top management buy-in in Told & Skat

Time: 0:21:35 – 0:22:33

Municipal reform

Time: 0:22:34 – 0:25:34

        Citizen portal

        Time: 0:23:24 – 0:25:34

Web services

Time: 0:25:35 – 0:26:03

The core idea of EA according to Morten Hass

Time: 0:26:04 – 0:26:58

Told & Skat’s savings due to their IT modernisation

Time: 0:26:59 – 0:28:55

Avoidance of redundant development (management model / governance model)
Successful Enterprise Architecture                      155

Time: 0:28:56 – 0:31:04

Reference model

Time: 0:31:05 – 0:32:30

The systems uptime in Told & Skat

Time: 0:32:31 – 0:33:33

In need of three architects

Time: 0:33:34 – 0:34:03

Project model in Told & Skat

Time: 0:34:04 – 0:35:01

Necessary structure

Time: 0:35:02 – 0:37:45


Time: 0:37:46 – 0:38:57

A drawing of the business (T&S)

Time: 0:38:58 – 0:48:37

Judgement the process in retrospective by Morten Hass

Time: 0:48:38 – 0:51:41

The biggest challenge

Time: 0:51:42 – 0:53:50

Architectural requirements

Time: 0:53:51 – 0:54:17

Modelling tools
Successful Enterprise Architecture              156

Time: 0:54:18 – 0:55:06

T&S’s role in my thesis

Time: 0:55:07 – 0:55:58

Governance on the basis of only simple models

Time: 0:55:59 – 0:58:09

Further contact between Told & Skat and me

Time: 0:58:10 – 0:59:55
Successful Enterprise Architecture                                                                                                                                                        157

Interview guide to my second interview with SKAT, Friday 9 December


Morten Hass, Kontorchef, IT-strategi, arkitektur og sikkerhed (IT Services)


1) Hvordan er organisationsdiagrammet ændret siden kommunalreformen?

                                                T ilp a s n in g a f s ty r e ls e n til
                                                m o d e r n is e r in g o g fu s io n

                                                                                                          D ir e k tio n e n
                                                                                                                                         P ro je k to rg a n is e rin g i
                                                                                                                                   a fd e lin g e r o g p ro je k te n h e d

                                                                                     D ir e k tio n s -
                                                                                                                          P r o je k tk o n to r
                                                                                     s e k re ta r ia t

                                                                                                      B o rg e r o g                                P e r s o n a le -
                                                              Ret                P la n læ g -                                                                            P r o je k t-
                                               T o ld                                                 E rh ve rv s -           IT -S e r v ic e s          og
                                                                                    n in g                                                                                enheden
                                                                                                        s e r v ic e                                 U d v ik lin g

                                                        A f d e lin g e r e f te r p ro c e s a n s v a r                      A R K IT E K T U R S T Y R IN G !
                                                                                                                               L e v e ra n d ø rs ty rin g

Enterprise Architecture

2) Hvordan definerer I EA (indeholder ikke nødvendigvis et rammeværk)?

3) Når I ikke bruger et EA rammeværk, hvordan har I så fået overblikket (rammen
(scopet) for EA programmet)?

4) Er det muligt at få kopi af jeres nuværende EA oversigt?

5) Hvordan hænger EA sammen med IT moderniseringen?

6) SKAT har en ‘projektmodel’ og en ‘changemodel’ – hvordan hænger de sammen
med SKAT’s EA?

7) Er al udvikling dækket af de to ovenfor nævnte modeller?

8) Hvordan sikres opdateringen af de enkelte informationer (forretnings- og
tekniske processer, modeller etc.) i jeres EA model (kort over forretningen) (både
generel opdatering og i henhold til den overordnede strategi)?

9) Hvordan defineres ejerskab og ansvarlig for de enkelte informationer i EA
modellen (alt arbejde omkring f.eks. en model blandt andet guidelines), og hvordan
sikres input ret/pligt, kommunikation til de rette personer (afdelinger) samt
Successful Enterprise Architecture                                               158

procedure ved overgivelse af f.eks. ejerskab mv. (RACI – er det dækkende for de
enkelte informationer)?

10) Er ejerskab (RACI) på person eller afdelingsniveau?

11) Måler I eller er I interesseret i EA modenhed? (Kunne man lave en EA
modenhedsmodel a la det offentlige i USA – kunne det ikke skabe positiv
konkurrence om at få noget i gang i det offentlige Danmark – synliggøre det)?

IT Governance

12) Hvordan definerer SKAT IT Governance?

13) Hvordan involverer ITG SKAT’s EA arbejde?

14) Hvordan er ledelsesstrukturen i SKAT i det daglige (Glocalisation: Pure Central,
Federal, Multi Local eller Parantal)?

15) Hvordan er sammenhængen mellem den generelle styring og den måde hvorpå
SKAT’s IT styres?

16) I kraft af at Gartner bruges, har SKAT brugt/bruger den nedenfor viste model, i
bekræftende fald, hvordan er sammenhængen med jeres EA?
Successful Enterprise Architecture                                                                     159


                  IT Principles      IT Architecture           IT             Business                IT
                                                         Infrastructure      Application
A                                                          Strategies          Needs            Investment

R               Input   Decision     Input   Decision   Input   Decision   Input   Decision   Input   Decision



E   Federal



17) Hvordan styres IT i dag, og hvordan ønsker SKAT deres IT skal styres i

Implementering og forankring

18) Hvordan implementeres og forankres EA og ITG i organisationen?

19) Hvordan modtages EA og styringen heraf i organisationen?

20) Hvordan styres, implementeres og forankres ændringer i SKAT?

Organisering af EA

21) Er der etableret en EA organisation – hvad indeholder den, og hvad er målet
med den (hvordan er EA organiseret) (beslutningsprocesser) (komiteer)?

22) Hvordan sikres, at nye tiltag (initiativer og projekter) går via jeres EA?

23) Hvordan holder I jer opdateret med, hvad der sker i organisationen og ude i
”verden”, f.eks. nye teknologier?
Successful Enterprise Architecture                                                 160

24) Ledelsens involvering – både med henblik på en eskaleringsstruktur og
forståelse for EA og ITG generelt?

25) Vigtigheden af en ildsjæl (udover Morten) for at bevare ledelsens interesse?

26) Hvordan involveres de enkelte afdelinger med henblik på deres krav til IT?

27) Hvordan betales for EA (IT) ydelserne?


28) Hvordan er EA’s kommunikationsstrukturer defineret?

29) Stakeholderanalyse?


30) Hvordan defineres, hvilke kompetencer, der er nødvendige?

31) Hvordan sikres, at EA organisationen har de relevante kompetencer?


32) Hvad er jeres mål med EA og ITG, og hvordan evalueres de (Evalueringen af
selve EA’en, f.eks. faciliterer den change, økonomisk)?

33) Hvordan evaluerer I jeres IT investeringer (business value)?

34) Hvad har I opnået, og hvor langt er I kommet?

35) Er EA og ITG kommet for at blive i SKAT?


Opfølgning pr. mail?
Successful Enterprise Architecture                                          161

Summary of my second interview with SKAT on 9 December 2005

SOA according to Morten Hass

Time: 0:00:00 – 0:01:04

Morten Hass’s general comments to my questions

Time: 0:01:05 – 0:02:18

Changes to SKAT’s organisational chart

Time: 0:02:19 – 0:03:43

Definition of EA and SKAT’s approach to EA

Time: 0:03:44 – 0:17:02

SKAT’s Project Model

Time: 0:17:03 – 0:23:00

Update of the EA picture including ownership

Time: 0:23:01 – 0:31:28


Time: 0:31:29 – 0:37:21

IT Governance in SKAT

Time: 0:37:22 – 0:40:12

Similarities between governance of the organisation in general and the IT

Time: 0:40:13 – 0:47:23

Gartner’s governance Matrix

Time: 0:47:24 – 0:48:18

Governance of IT in relation to general governance
Successful Enterprise Architecture                     162

Time: 0:48:19 – 0:51:00

Implementation and anchoring of the IT modernisation

Time: 0:51:01 – 0:58:11

How are EA and the implementation received in SKAT

Time: 0:58:12 – 0:59:18

Project Model – further information

Time: 0:59:19 – 0:59:30

Technological trends

Time: 0:59:31 – 01:12:47

Escalation structures

Time: 01:12:48 – 01:13:04

Champion– meeting the business needs

Time: 01:13:05 – 01:19:53

The involvement of the various departments

Time: 01:19:54 – 01:20:15

Payment of the IT Services

Time: 01:20:16 – 01:21:20


Time: 01:21:21 – 01:21:29

Stakeholder analysis

Time: 01:21:30 – 01:22:57

Successful Enterprise Architecture   163

Time: 01:22:58 – 01:24:43


Time: 01:24:44 – 01:26:45

The IT investments’ business value

Time: 01:26:46 – 01:27:38

Are EA and ITG to stay in SKAT

Time: 01:27:39 – 01:29:00

Final Comments - conclusions

Time: 01:29:01 – 01:38:15
Successful Enterprise Architecture                                                164

Interview guide to my interview with SKAT’s project’s organisation,
Monday 19 December 2005

Mail 16 December 2005:

Jeg er blandt andet interesseret i følgende:

    •   Information og vejledning omkring jeres projektmodel

    •   Information og vejledning omkring jeres business case "model"

    •   Kommunikation i forbindelse med ændringer og projekter, der går via

    •   Måler I på projekterne? Hvordan?

    •   Hvordan er jeres samarbejde med Morten Hass' afdeling "IT Arkitektur,
        Sikkerhed og Strategi?

    •   Hvad er jeres syn på deres arbejde omkring arkitektur, og hvordan ser I
        jeres indflydelse i den forbindelse (specielt i forbindelse med implementering
        og forankring)?

    •   Andet du mener er vigtig at vide i forbindelse med projektmodellen og jeres
        opgaver og placering i organisation?
Successful Enterprise Architecture                                              165

Summary of my interview with SKAT’s Project Organisation on 19
December 2005

Interview person Marc Larsen, project coordinator, Project Organisation

March introduces his job function – portfolio management

Time: 0:00:00 – 0:03:25

Strategic portfolio management

Time: 0:03:26 – 0:04:06

Introduction to the cooperation between the Project Organisation and the IT

Time: 0:04:07 – 0:05:09

Project Organisation including project model

Time: 0:05:10 – 0:06:34

IT architecture integration into the project model

Time: 0:06:35 – 0:08:50

Description of project model

Time: 0:08:51 – 0:59:50

                IT projects integration to ITASS

                Time: 0:11:54 – 0:16:16

                Illustration of a specific status report in the project model

                Time: 0:22:40 – 0:27:45

                The legislative changes

                Time: 0:28:50 – 0:31:25

                Assessment of the project results
Successful Enterprise Architecture                                                 166

                Time: 0:31:26 – 0:37:04

                Score model of the projects reflecting SKAT’s vision and mission

                Time: 0:37:05 – 0:39:50

                Implementing project management complying with their project model

                Time: 0:39:51 – 0:41:20


                Time: 0:43:30 – 0:49:25

                Reception of the project model in SKAT

                Time: 0:50:45 – 0:53:13


Time: 0:59:51 – 1:02:19
Successful Enterprise Architecture                                                  167

Appendix B: Interviews and interview summaries
  with ATP

Interview guide to my first interview with ATP, Friday 9 September 2005.

This is only a guide to make sure that the interview is kept on track. Still there is
and should be room for deviations. Also since it is my first interview with ATP, there
might be other aspects and areas that the interview person might want to talk
about that I have not thought about.

The guide is in Danish as the interview organisation is a Danish public/private
agency (ATP) and thus the interview will be carried out in Danish.


General baggrundsviden:

Interview person:

Jytte Bertelsen:



1) Hvorfor fik I fokus på EA?

2) Hvad er jeres mål?

3) Bruger I bevidst både EA og IT Governance?

4) Hvordan definierer du EA og ITG?

5) Hvordan ser du de to discipliners sammenhæng?

Enterprise Architecture

6) Hvad er de grundlæggende principper for, at I har en EA?

7) Har I brugt en EA procesmodel ala Hvidbogens/Zachman?
Successful Enterprise Architecture                                              168



8) Har I kortlagt jeres as is og to be situationer?


        Hvordan lukker I gap’et?

9) I forbindelse med definitionen af jeres IT arkitektur, hvad var så jeres
udgangspunkt (kunden, teknologien, eller…)?

10) Hvordan ser jeres IT arkitektur ud? (bygger på SOA?)

IT Governance

11) Hvorfor har I fået fokus på ITG?

12) Hvordan influerer kulturen (politisk) på beslutningerne (styring) (top-down –
bottom up / konsensus)?

        (Hvorfor koncern?)

13) Har I fået opbygget nogle klare og optimale beslutningsprocesser?


14) Har I brugt en model, f.eks. Ross og Weill?

15) Hvem tager følgende beslutninger:

        IT principper; IT arkitektur; IT infrastruktur strategier;

        Forretningsapplikationer; IT investeringer; Andre

16) Bruger I ITIL?


        Hvordan sikrer i jer koblingen til jeres strategi?

Successful Enterprise Architecture                                                  169

17) Hvordan skabes der kontinuerlighed i jeres IT-styringsproces, så jeres
arkitektur og styringsprocesser ikke bliver forældet?

18) Hvordan styres projektporteføljen?

19) Hvordan vurderer I, hvilke nye IT projekter, der skal igangsættes?

20) Hvordan koordinerer I på tværs af afdelingen, f.eks. nye projekter?

21) Hvordan sørger I for altid at have alle aspekter (f.eks. strategi, definerede
standarder) med i nye løsninger, således, at det ikke kun er teknologien, der

22) Hvordan implementerer, forankrer og kontrollerer I ændringer?

23) Er jeres systemer integreret eksternt?

        Hvordan og hvordan styres det?


24) Har I opnået jeres mål?

25) Hvordan skaber jeres bevidste IT-styringsproces synergier på tværs af

26) Er I blevet mere agile på IT området?

27) Hvilke resultater har I opnået (både håndgribelige og uhåndgribelig)?

        Er der f.eks. økonomisk gevinst i ”et system”?

        Har der været andre drivkrafter?

28) Hvordan ser fremtiden ud?

29) Måler I modenhed og I så fald, hvor modne vurderer I jer selv til at være?

30) Er EA og ITG kommet for at blive i ATP?

31) Hvad er gået godt – ikke gået godt?

32) Er der noget I ville have gjort anderledes
Successful Enterprise Architecture                            170


Er det muligt med et opfølgningsmøde i oktober?

Er det muligt at maile med eventuelle opfølgningsspørgsmål?
Successful Enterprise Architecture                                              171

Summary of my first interview with ATP on 9 September 2005

Interview person Jytte Bertelsen, ATP

Introduction to the various groups in the IT Architecture department

Time: 0:00:00 – 0:09:32

Re-establishing the system portfolio to service-oriented architecture and on a new

Time: 0:09:33 – 0:13:45

        Previous silo structure in ATP

        Time: 0:12:28 – 0:13:45

The structure in the new system portfolio

Time: 0:13:46 – 0:21:28

ATP’s Enterprise Architecture

Time: 0:21:29 – 0:33:52

        The reason why ATP wish to establish an EA

        Time: 0:26:20 – 0:27:56


Time: 0:33:53 – 0:34:19

ATP’s tool Qualiware

Time: 0:34:20 – 0:36:04

Jytte’s involvement in the NAFS project

Time: 0:36:05 – 0:36:25

Project governance in relation to EA

Time: 0:36:26 – 0:37:17
Successful Enterprise Architecture                                  172

Use of models and methodologies

Time: 0:37:18 – 0:38:16


Time: 0:38:17 – 0:40:35

EA and ITG

Time: 0:40:36 – 0:47:33

The future process in my thesis with specific focus on ATP’s role

Time: 0:47:34 – 0:48:18

Jytte Bertelsen’s staff

Time: 0:48:19 – 0:48:58

Jytte Bertelsen’s background

Time: 0:48:59 – 0:51:10


Time: 0:51:11 – 0:52:21
Successful Enterprise Architecture                                                   173

Interview guide to my second interview with ATP, Friday 18 November


Jytte Bertelsen, Chef for Metode og Enterprise Arkitekturafdelingen.

Pia, Studentermedarbejder i Metode og Enterprise Arkitekturafdelingen.

Generelt om ATP

1) Er det muligt at se et organisationsdiagram over ATP’s selskaber, afdelinger og

2) Er der systemintegration mellem alle selskaber, afdelinger og services?


3) Hvad står NAFS for?

4) Hvordan er sammenhængen helt præcis mellem ATPs Domænelandskab og EA?


5) Hvordan er ledelsesstrukturen i ATP i det daglige (Glocalisation: Pure Central,
Federal, Multi Local eller Parantal)?

6) Hvordan er sammenhængen mellem den generelle styring og den måde hvorpå
ATPs IT styres?

7) Hvordan styres IT i dag, og hvordan ønsker ATP deres IT skal styres i fremtiden?

8) Hvordan sikres opdateringen af de enkelte informationer i jeres EA model (både
generel opdatering og i henhold til den overordnede strategi)?

9) Hvordan defineres ejerskab og ansvarlig for de enkelte informationer i EA
modellen (alt arbejde omkring f.eks. en model blandt andet guidelines), og hvordan
sikres input ret/pligt, kommunikation til de rette personer samt procedure ved
overgivelse af f.eks. ejerskab mv. (RACI – er det dækkende for de enkelte

10) Hvordan implementeres og forankres EA og ITG i organisationen?
Successful Enterprise Architecture                                                174

11) Hvordan modtages EA og styringen heraf i organisationen?

12) Hvordan styres, implementeres og forankres ændringer i ATP?

13) Hvordan integreres projektmodellen i jeres EA?

Organisering af EA

14) Er der etableret en EA organisation – hvad indeholder den, og hvad er målet
med den (hvordan er EA organiseret) (beslutningsprocesser) (komiteer)?

15) Hvordan sikres, at nye tiltag (initiativer og projekter) går via jeres EA?

16) Hvordan holde I jer opdateret med, hvad der sker i virksomheden og ude i
”verden”, f.eks. nye teknologier?

17) Ledelsens involvering – både med henblik på en eskaleringsstruktur og
forståelse for EA og ITG generelt?

18) Vigtigheden af en ildsjæl (udover Jytte) for at bevare ledelsens interesse?

19) Hvordan involveres de enkelte afdelinger med henblik på deres krav til IT?

20) Hvordan betales for IT ydelserne?


21) Hvordan er EAs kommunikationsstrukturer defineret?


22) Hvordan defineres, hvilke kompetencer, der er nødvendige?

23) Hvordan sikres, at EA organisationen har de relevante kompetencer?


24) Hvordan evaluerer I jeres IT investeringer?

25) Hvad er jeres mål med EA og ITG, og hvordan evalueres de?

26) Hvad har I opnået?

27) Er EA og ITG kommet for at blive i ATP?
Successful Enterprise Architecture   175


Opfølgning pr. mail?
Successful Enterprise Architecture                            176

Summary of my second interview with ATP on 18 November 2005


Time: 0:00:00 – 0:00:56

How far has ATP come in their EA work

Time: 0:00:57 – 0:02:45

Which activities are necessary to implement the EA in ATP

Time: 0:02:46 – 0:11:21

        How will ATP use the architectures

        Time: 0:04:52 – 0:05:19

        Continuous evaluation of the use of the EA

        Time: 0:07:42 – 0:09:27

        Organisational implementation

        Time: 0:09:28 – 0:10:07

        Communication plan

        Time: 0:10:08 – 0:11:21

Governance at the EA levels

Time: 0:11:22 – 0:20:15

Threads in the entire EA framework between the artifacts

Time: 0:20:16 – 0:22:20

Governance – who are to take which decisions

Time: 0:22:21 – 0:26:26

        The follow or explain principle
Successful Enterprise Architecture                177

        Time: 0:24:11 – 0:25:19

        Escalation structure

        Time: 0:25:20 – 0:26:26


Time: 0:26:27 – 0:27:50

Change management

Time: 0:27:51 – 0:29:18

Stakeholders - implementation

Time: 0:29:19 – 0:30:17

Development model

Time: 0:30:18 – 0:33:03

Quality assurance

Time: 0:33:04 – 0:34:44


Time: 0:34:45 – 0:35:33


Time: 0:35:34 – 0:38:52


        Time: 0:36:09 – 0:38:52

General governance of ATP – Glocalisation model

Time: 0:38:53 – 0:40:27

Project portfolio governance
Successful Enterprise Architecture                              178

Time: 0:40:28 – 0:41:38

Updates in relation to new technology or business initiatives

Time: 0:41:39 – 0:47:12


Time: 0:47:13 – 0:49:03

IT Decisions

Time: 0:49:04 – 0:51:00

EA champion

Time: 0:51:01 – 0:53:19

Departments’ requirements to IT (SLA)

Time: 0:53:20 – 0:58:00

Payment of the IT services

Time: 0:58:01 – 1:00:05


Time: 1:00:06 – 1:01:11

ATP maturity

Time: 1:01:12 – 1:01:50


Time: 1:01:51 – 1:04:55

Organisational structures

Time: 01:04:56 – 01:06:27

Business strategy and IT strategy at the same level
Successful Enterprise Architecture       179

Time: 01:06:28 – 01:09:21

IT governance

Time: 01:09:22 – 01:11:53

Evaluation of IT investments

Time: 01:11:54 – 01:12:14

Are EA and ITG to stay in ATP

Time: 01:12:15 – 01:15:06

Daily management – Glocalisation model

Time: 01:15:07 – 01:18:20


Time: 01:18:21 – 01:27:32
Successful Enterprise Architecture                                            180

Appendix C: Interview and interview summary with
  Gartner Group, Denmark

Interview guide to my interview with Henrik Zangenberg, Gartner Group,
Thursday 15 September 2005

The interview is in Danish and consequently the guide is in Danish

1) Hvorfor ser I EA og IT Governance disciplinerne som vigtige?

2) Hvordan definerer du EA og ITG (deres formål)?

3) Hvordan ser du de to discipliners sammenhæng?

4) Hvilke EA og ITG modeller bruger I og hvorfor?

5) Hvordan foregår indførslen af EA og ITG, og hvad skal man som virksomhed
være opmærksom på?

6) Hvordan hjælper EA og ITG med at styre IT fra et forretningsperspektiv?

7) Hvor er Danmark i dag (både i det offentlige og private)?

8) Hvor er vi på vej hen, og hvad kræver det?

Keywords: Agil, kontinuerlighed, optimale beslutningsprocesser.
Successful Enterprise Architecture                                              181

Summary of my interview with Gartner Group, Denmark on 15 September

Introduction (my current problem definition)

Time: 0:00:00- 0:01:22

Gartner’s perspective on architecture in a governance connection – Zangenberg
describes Gartner’s governance model

Time: 0:01:23 – 0:05:42

Is there a best way of incorporating governance

Time: 0:05:43 – 0:08:39

        The Region Midtjylland and Nordjylland projects

        Time: 0:06:22 – 0:06:57

Introduction to Gartner Group

Time: 0:08:40 – 0:12:13

Region Midtjylland and Nordjylland – mapping of their current governance
structures into Gartner’s governance model

Time: 0:12:14 – 0:27:55

        Answer to my previous question whether there is a model that

        works better than another

        Time: 0:17:00 – 0:27:55

                 Told & Skat – heading towards more centralism

                 Time: 0:23:29 – 0:23:56

Is the governance model dependent on EA – how does EA and ITG relate to each

Time: 0:27:56 – 0:45:36
Successful Enterprise Architecture                                             182

        Gartner’s Glocalisation model

        Time: 0:30:59 – 0:43:13

                 Gartner’s use of the Glocalisation model

                 Time: 0:39:44 – 0:43:13

Model that is concerned with whether the organisation has the right staff

Time: 0:45:37 – 0:51:16

What does it takes to create an architecture

Time: 0:51:17 – 0:53:12


Time: 0:53:13 – 0:54:24

General conclusions

Time: 0:54:25 – 0:59:44

Currently, there exist much focus on architecture and governance in organisations

Time: 0:56:45 – 0:57:04

Architecture and governance are connected

Time: 0:57:05 – 0:57:43

Project management – how do you maintain your EA

Time: 0:57:44 – 0:58:49
Successful Enterprise Architecture                                            183

Appendix D: Interview and interview summary with
  IBM, Denmark

Interview guide to my interview with Peter Dreyer, IBM, Thursday 22 September

1) Hvorfor ser I EA og IT Governance disciplinerne som vigtige?

2) Hvordan definerer du EA og ITG (deres formål)?

3) Hvordan ser du de to discipliners sammenhæng?

4) Hvilke EA og ITG modeller bruger I og hvorfor?

5) Hvordan foregår indførslen af EA og ITG, og hvad skal man som virksomhed
være opmærksom på?

6) Hvordan hjælper EA og ITG med at styre IT fra et forretningsperspektiv?

7) Hvor er Danmark i dag (både i det offentlige og private)?

8) Hvor er vi på vej hen, og hvad kræver det?

Keywords: Agil, kontinuerlighed, optimale beslutningsprocesser.
Successful Enterprise Architecture                               184

Summary of my interview with IBM, Denmark on 22 September 2005

Introduction to my thesis

Time: 0:00:00 – 0:02:08

IS Lite (a Gartner concept)

Time: 0:02:09 – 0:03:14

Does IBM have a generic governance model

Time: 0:03:15 – 0:04:09

Governance seen from IBM’s (Peter Dreyer) perspective and EA

Time: 0:04:10 – 0:19:20

        A description of the areas within EA

        Time: 0:07:18 – 0:07:55

                 Mapping of the EA to the business

                 Time: 0:07:56 – 0:09:38

                 IBM’s EA Model

                 Time: 0:09:39 – 0:19:20

Organisation of EA

Time: 0:19:21 – 0:23:52

The organisations’ awareness of EA and Governance

Time: 0:23:53 – 0:26:20

The active part of the EA model

Time: 0:26:21 – 0:30:00

The complexity of EA
Successful Enterprise Architecture                  185

Time: 0:30:01 – 0:32:46

EA at the organisation ‘SKF’

Time: 0:32:47 – 0:47:24

        RACI models – decision models

        Time: 0:40:39 – 0:44:09

Necessary with both EA and an organisation hereof

Time: 0:47:25 – 0:48:41

Do the organisations think in terms of EA

Time: 0:48:42 – 0:51:35

Update of EA and the communication herof

Time: 0:51:36 – 0:54:09

EA and governance in future

Time: 0:54:10 – 0:56:57

Peter Dreyer’s job

Time: 0:56:58 – 1:03:45


Time: 1:03:46 – 1:05:28
Successful Enterprise Architecture   186

Appendix E: Zachman’s EA framework
Version d. 27 maj 2005. SAS-kontoret - IT-services
                                                                                                                                                                               Offentlige processer
                                                           Portaler                          Registrering                                                   Produkter                                                     Fordeling                                          Afregning.                                                Sikkerhed
                                                        - Virk.DK
                                                                                       - Virk. reg.                                                                                                                                                                                                                                     - Politi
 Kundeprocesser        Serviceudbyder                   - Kommunale                                                                                                                                                                                           - Statens
                                                                                       - Person reg.                                                                                                                                                                                                                                    - Beredskab
                                                        kvikskranker                                                                                                                                             - Kontanthjælp                               KoncernBetalinger
   Virk. etablering         Revisor                     - SU-styrelsen                 - Tinglysning                                        - Produktstøtte                                                      - Dagpenge                                   - NemKonto
                                                        - Netbanker                    - Byggesag                                           - Produktilladelse                                                   - Boligstøtte
                                                                                       - Motorregistrering                                  - Produktkvoter                                                      - Friplads

    Virk. økonomi             Bank
    Økonomisystem                                                                                                                                                                     Skatteprocesser
                                                       Kundekontakt                          Registrering                                                    Angivelse                                                       Opgørelse                                          Afregning                                      NP 4 Kontrol med illegal
   Virk. medarbej.        Lønservice                   TastSelv Erhverv                                         ES
      Lønsystem                                                                                                                                                                                                                                                                                                                GPP    PC-SURVEIL             AFIS
                                                       Nyt TastSelv                                             SE
                                                                                                                                                                         DR                                                                                                             DR
                                                                                                                                                                                                                                                                                                                                                                                                                        Successful Enterprise Architecture

                                                                                                                                                                                                                                                                                                                                      Transit (NCTS)         SCENT/CIS
                                                       LetLøn                                           Ny Registrering
                                                                                                                                                Spil.dk                                                                                                                          PC-           Ny Debitor
    Virk. produkt           Importør                         TStele                                                                                            Intrastat                                                                                          SAP38

                                                            Ny Portal
                                                                                                                                            Import      e-Export      Nyt Liste        Nyt YM-
                                                                                                                                        E-handel           Eksport YM-syst          Liste
                                                          Din Skattes
     Virk. logistik         Speditør                                                            Slutmandtal

                                                                                                                                        PAF             PAL        EIS         EROS

                                                       TastSelv Borger KMD                                  CSR-P                                                                                             Forskud                  ABS
                                                                                                                                                                                                                                                              TURS      KOBRA           KR-L      BYS       OLVER

                                                       TastSelv Borger                                                                               COR           MIA                         SA              SP       Uddata                        EVS
       Flytning        Ejendomsmægler
                                                                                                                                                 RKO: AKFA AKSA ANPA BHO CPS                                           Gammel SLUT 1988 - 1991
                                                            Gennemstilling 3 I                                                                                       L
                                                                                                                                                      FINK GI   KTR IFPA IRTE

                                                                                                                                                                                                                         Gammel SLUT 1992 - ?
                                                           Gennemstilling 3 II
                                                                                                                                                     SVUR        SVUR IGS                   VUR
                                                                                                                                                                                                                                                       SLUT        (kontrol, beregning,
      Transport          Bilforhandler                                                                                                                Ny Ejendomsvurdering                                                                                                opgør.)
                                                                                                                                                                                                                                                                KMD Debit
                                                                                                                                               StaPri          Modep          Motor                                                                                                                                                        Arbejdsmiljø
                         Trafikselskab                                                                                                                                                                        MT-fil         VSO/VBO
                                                        Et nummer                              Nyt Motorsystem
                                                                                                                                                                                                                                                                 CKR-K       Fordelingssys           SAP38
   Person familier          Advokat                                                                          CKR-A
                                                                                                                                                              Kontrol                                                                                         KMD Debit       Inddrivelse
                                                                                                                                                                                                                                                                                                                               Skatteanke-             Landskatte-
                                                                                 Træskoregistret                            KINFO            DIPSY         Kvalipro           VK                                                                                                     Bøde
                                                                                                                                                                                                      SLS-E            RAP       LS/SLS-S                                 RUF                      Ny Inddrivelse              nævn                    retten
     Person job                                                                                                                                                                                                                                                                    beregning
                                                       Skattecenter                    LUP                ELO
                                                                                                                                Nye udsøgninger                                                     HARPUN          SEES             SLS-P                       DFLS           CFR      FAS/RES         FAS/STU
                            A-kasse                                                                                                                                                                                                                                                                                                    Økonomistyring
                                                                                                                                                                                      Sagsbehandling                                                                                                                                   Personale
                                                                                                                                                                                                                                                                                                                                                                         Appendix F: SKAT’s map of their organisation

                                                                                                                                                                                                                                             RegAfg                       Bevillinger
                              Bank                                                                                                                                                                                                                                                                                                     IT
   Person økonomi                                                                            Captia -           Remedy            Scanjou      KOM*IT            KMD                                                                                                                                                                   Rigsrevisionen

                                              SP 1: Økonomistyring                     SP 2: Personale                                                         SP 3: IT                                                SP 4: Intern                           SP 5:                              SP 6: Interne                              SP 7:
                                                                                                                TiRe/LISY               Fælles          Ny ENS        BRAS           INKO           FROC
                                                                                 MUS      UAS      LUKAS                                                                                                                Revision                        Ministerbetjening                         aktiviteter                        Ledelsesinformation

                                                                                                                                        Telefoni        DAP              BR        Intermedi        PRINT                                                                                                                            TiRe/LISY
                                                SAP9                             PAI         SAPHR        REKS        Idébank                                                                                                Elrev
                                                                                                                                                                                                                                                                                                   Bibliotek        Registre
                                                                                                                                             Dist.             Std. klient         Driftplan        Nyt DW

                                                                                                                                         servermiljø             prog.

Omlægning af grænseflader                Større funktionelændring                      Lukkes eller                                                           Ændres ikke                                                                    Nyudvikling                                                    Ikke vurderet
mv.<= 25%                                25-75%                                        reimplementeres
Successful Enterprise Architecture                 188

Appendix G: ATP’s overall organisational diagram
Successful Enterprise Architecture   189

Appendix H: IT departments in ATP
Successful Enterprise Architecture   190

Appendix I: ATP’s domain landscape
Successful Enterprise Architecture   191

Appendix J: Establishing EA in ATP
Successful Enterprise Architecture   192

Appendix K: ATP’s EA
Successful Enterprise Architecture                                                 193


Bernard, Scott A. (2004). An Introduction to Enterprise Archiecture. Bloomington,
        Indiana: AuthorHouse

Bernard, Scott A. (2005). An Introduction to Enterprise Archiecture. Bloomington,
        Indiana: AuthorHouse

Brundage, George and Gøtze, John. (2004). EA Governance guide for enterprises
        and institutions. Unpublished draft.

Kotter, John P. (1996). Leading Change. Boston, Massachusetts: Harvard Business
        School Press

Launsø, Laila and Rieper, Olaf. (2000). Forskning om og med mennesker.
        København, Danmark: Nyt Nordisk Forlag

Sarantakos, Sotirius. (1998). Social Research. New York, USA: Palgrave

Schekkerman, Jaap. (2005). The Economic Benefits of Enterprise Architecture.
        Victoria, BC, Canada: Trafford

Spewak, Steven H. (1992). Enterprise Architecture Planning. New York, USA:

Weill, Peter and Ross, Jeanne W. (2004). IT Governane, How Top Performers
        Manage IT Decision Rights for Superior Results. Boston, Massachusetts:
        Harvard Business School Press

Yin, Robert K. (2003). Case study Research. Thousand Oaks, CA: Saga Publications


A Conversation with John Zachman. (August, 2005). Journal of Enterprise
        Architecture. (p. 6)

Chemers, Martin. (2003). Leadership Effectiveness: An Integrative Review, in Hogg,
        Michael & Scott Tindale Blackwell Handbook of Social Psychology: Group
        Processes. From the collection of articles: Organisational Behaviour and
        Changes Processes, Fall 2005. (pp. 376-399).
Successful Enterprise Architecture                                               194

Drucker, Peter F. and Senge, Peter M. (Sommer 2001). Strategier til
        forandringsledere – en samtale mellem Peter F. Drucker og Peter M. Senge.
        Ledelse i dag. Nr. 44, 11. årgang, Nr. 3.

Herzum, Peter. (2003). Applying Enterprise Architecture. Cutter Consortium, Vol. 6,
        No. 3

Mayo, David and Tiemann, Michael. (August, 2005). EA: IT’s not just for IT
        anymore. Journal of Enterprise Architecture

Orr, Ken. (2003). Frameworks and Processes for Developing Enterprise
        Architectures. Cutter Consortium. Vol. 6, No. 2

Orr, Ken. (2004). Collaborative Enterprise Architecture Governance. Cutter
        Consortium. Vol. 7, No. 20.

Orr, Ken. (2004). The Three Faces of Enterprise Architecture. Cutter Consortium.
        Vol. 7, No.1

Pavlak, Alex. (August, 2005). Simplify the Creating of Enterprise Architecture with
        Special Expert Teams. Journal of Enterprise Architecture.

Scott, Jeff. (2004). Collaborative Enterprise Architecture Governance. Cutter
        Consortium. Vol. 7, No. 20

Scott, Jeff. (2004). EA, The ”Logical” Way. Cutter Consortium. Vol. 7, No. 10

Senge, Peter M. (Sommer 2001). En lære for forandringsledere. Ledelse i dag. Nr.
        44, 11. årgang, Nr. 3.

Zachman, John. (1987/1999). A framework for information systems architecture.
        IBM systems Journal. Vol. 38, Nos. 2 and 3

Zachman, John and Sowa, John. (1992). Extending and formalizing the framework
        for information systems architecture. IBM Systems Journal. Vol. 31, No. 3



Successful Enterprise Architecture                                          195






http://local.cips.ca/informatics/ppt/2005/2005-05-31-er.ppt (Spurway and














Successful Enterprise Architecture                                      196














http://www.va.gov/oirm/architecture/EA/theory/ TJEK






Successful Enterprise Architecture                                                197






Bertelsen, Jytte. ATP on 9 September 2005 and 18 November 2005

Dreyer, Peter. IBM, Denmark on 22 September 2005

Hass, Morten. SKAT on 29 August 2005 and 29 December 2005

Larsen, Marc. SKAT on 19 December 2005

Zangenberg, Henrik. Gartner Group, Denmark, on 15 September, 2005

Phone conversation with Per Strand, Strand & Donslund, July 2005


Course description. Subject: IT Governance. Copenhagen Business School. 2005

Course material. Subject: T8. IT University. Fall 2005

Hjort-Madsen, Kristian. (August, 2005). Managing and Implementing Enterprise
         Architectures in Government: Understanding Institutional Forces and IS
         Control. PHD Status Report. IT University Copenhagen and National IT and
         Telecom Agency, Denmark

Hvidbog om IT-arkitektur (2003). Ministeriet for Videnskab, Teknologi og Udvikling

Various Computerworld Magasines, Autumn 2005

To top